Спрос на усовершенствованные цифровые услуги и новые возможности со стороны как клиентов, так и высшего руководства доводит цифровые операции до предела. Руководители компаний ожидают, что команды разработчиков будут регулярно создавать и внедрять новые функции для улучшения сервисов. Однако, хотя инструменты кодирования с поддержкой ИИ помогают разработчикам оправдывать эти растущие ожидания, они также усиливают нагрузку на операционные команды.
Больший объем развертываемого кода означает больше потенциальных точек отказа. Команды, управляющие цифровыми операциями вручную, рискуют оказаться перегруженными объемом и скоростью инцидентов, которые создает ускоренная ИИ разработка. Рабочие процессы, на которые они когда-то полагались, рушатся, и они рискуют попасть в ловушку «исправления неисправностей», когда тушение пожаров не оставляет времени на переосмысление процессов для сокращения числа будущих инцидентов.
«Тот же ИИ, который создает операционную сложность, может ее и решить».
Но вот в чем заключается парадокс: тот же ИИ, который создает операционную сложность, может ее и решить. Организации, которые внедряют ИИ в операционную деятельность с таким же энтузиазмом, какой они проявляли к разработке с помощью ИИ, опережают конкурентов, все еще застрявших в реактивном режиме.
Как укореняется цикл «поломка-ремонт»
Объем и скорость генерации кода ИИ приводят к всплеску проблем, отвлекая старших инженеров от стратегической работы и заставляя их заниматься сортировкой предупреждений. Команды попадают в реактивные шаблоны, когда отсутствуют интеллектуальная фильтрация предупреждений, корреляция, классификация и контекст. Постоянный шум предупреждений не позволяет инженерам расставлять приоритеты в уведомлениях, и они могут в конечном итоге тратить время на преследование несуществующих проблем, в то время как настоящие проблемы остаются скрытыми.
Эти проблемы усугубляются, если у команд также отсутствуют автоматизированные рабочие процессы или стандартизированные протоколы реагирования на инциденты. Без установленных рабочих процессов каждый инцидент рассматривается как единичный случай, что приводит к неэффективности, которую многие операционные подразделения меньше всего могут себе позволить. Цикл «поломка-ремонт» укореняется еще сильнее, когда специалисты по реагированию вынуждены управлять несколькими изолированными инструментами для создания заявок, мониторинга, чата и других задач. Время, которое они тратят на переключение между инструментами, оставляет меньше времени на управление самим инцидентом.
Даже когда ИИ и автоматизация внедряются, они часто используются изолированно для конкретных задач или рабочих процессов, что ограничивает их ценность. Согласно новому отчету PagerDuty, организации, сообщающие об улучшении отказоустойчивости, чаще всего связывают прогресс с интегрированными инструментами, которые поддерживают полный жизненный цикл инцидента, или с более тесной системной интеграцией. Специализированные агенты ИИ расширяют эти возможности за счет автономного управления реагированием на инциденты, сбора коллективных знаний и применения полученных знаний для предотвращения повторяющихся проблем.
Растущая когнитивная нагрузка усугубляет проблему
Цикл «слома-ремонта» создает огромную нагрузку на инженеров DevOps. От них не только ожидают реагирования в режиме реального времени на инциденты с кодом, который они, возможно, не писали, но и требуют писать код, понимать, как он работает, и постоянно отслеживать поведение системы.
Эти ожидания просто нереалистичны в то время, когда разработчики могут создавать прототипы за часы, а не за недели или месяцы, а сложные зависимости доводят когнитивную нагрузку до предела. Возможно, неудивительно, что 42% организаций сообщают, что серьезные инциденты и перебои в работе сервисов значительно влияют на моральный дух разработчиков и способствуют их выгоранию.
Три стратегии для преодоления этого цикла
Мы не можем решить эту проблему с помощью найма персонала. В мире не хватает инженеров DevOps, чтобы идти в ногу с циклами разработки, поддерживаемыми ИИ, а привлечение дополнительных сотрудников создаст риск возникновения еще большей операционной путаницы между командами и линиями связи. Вместо этого операционные команды должны принять ИИ (включая ИИ-агентов) так же, как их коллеги-разработчики приняли кодирование с помощью ИИ.
«В мире не хватает инженеров DevOps, чтобы идти в ногу с циклами разработки с помощью ИИ… привлечение дополнительных сотрудников создаст риск возникновения еще большей операционной путаницы…»
Технологии ИИ могут направлять запросы, предоставлять контекст, сопоставлять оповещения и находить релевантные исправления из аналогичных инцидентов, позволяя операционным командам действовать быстро даже при увеличении рабочей нагрузки.
Рассмотрите следующие три шага, чтобы выйти из динамики «слома-ремонта»:
1. Переход от ручной сортировки к устранению проблем на основе событий
Операционные команды, которые продолжают использовать ручные процессы, обречены повторять одни и те же реактивные рабочие процессы каждый раз, когда сталкиваются с новым инцидентом. Они могут разорвать этот цикл с помощью автоматизированных руководств, которые запускают заранее определенные скрипты для более быстрой диагностики и устранения неполадок. Самые продвинутые платформы идут дальше, внедряя ИИ, который учится на каждом взаимодействии. Машинное обучение анализирует исторические данные о событиях и инцидентах, чтобы предложить практические правила оркестрации, создавая автоматизацию на основе событий, которая предотвращает инциденты до того, как они потребуют вмешательства человека. Анализ после инцидента усиливает эти усилия, позволяя ИИ автоматически агрегировать данные из Slack, системных оповещений и других каналов для выявления шаблонов, которые могут стать повторяемыми рабочими процессами.
2. Автоматизируйте реагирование, чтобы защитить ритм релизов
Еще одним следствием цикла «поломка-ремонт» является то, что команды ручной эксплуатации замедляют ритм релизов, чтобы снизить риск. Это может обернуться против них, если это означает более крупные и рискованные изменения, которые приводят к большему количеству инцидентов, еще больше снижая желание ускорить развертывание. Автоматизировав реагирование на инциденты, операционные команды могут полностью изменить эту логику. Благодаря интеллектуальной сортировке оповещений и подавлению шума разработчики могут с уверенностью внедрять более мелкие и частые изменения.
Когда происходят инциденты, агенты ИИ могут автоматически обнаруживать, сортировать и диагностировать их, чтобы инженеры могли сразу приступить к их устранению. Создание таких самовосстанавливающихся ИТ-систем с помощью многоагентного ИИ меняет подход организаций к обеспечению отказоустойчивости. Когда команды не перегружены управлением инцидентами, они дают разработчикам возможность развертывать изменения чаще, что упрощает реагирование на инциденты.
3. Переложить «рутинную работу», чтобы удержать инженерные кадры
Когда организации застревают в режиме «поломка-ремонт», ручные процессы приводят к большему количеству перерывов и вызовам старших инженеров в нерабочее время. Тот факт, что большая часть этой работы носит повторяющийся характер и может быть автоматизирована, добавляет еще один повод для разочарования у операционных команд. Выгорание и текучесть кадров часто становятся наиболее распространенными последствиями, создавая цепную реакцию, в результате которой теряются институциональные знания, а организация становится более уязвимой.
Автоматизируя повторяющуюся работу и внедряя агентов ИИ, организации снимают нагрузку с перегруженных операционных команд, позволяя им сосредоточиться на инновациях, а не на тушении пожаров. Переложив «рутинную работу» на агентов ИИ, старшие инженеры могут вернуться к творческой и высокоэффективной работе, для которой они были наняты. Все в выигрыше.
Пусть ИИ управляет сложностью ИИ
Организации, которые не понимают реальности цикла «поломка-ремонт», обречены на то, что инновации на базе ИИ превратятся в операционную нагрузку. Им следует обратиться к ИИ и специализированным агентам, чтобы те взяли на себя эту нагрузку, что позволит им использовать его мощь для ускорения развертывания кода, не перегружая операционные команды.
Начните с автоматизации хорошо понятных, повторяющихся инцидентов с помощью автоматизации рунбуков. Расширьте сферу применения до сортировки и диагностики на основе ИИ, а затем добавьте автоматизированную документацию, рекомендации по непрерывному улучшению и интеллектуальное управление дежурствами. Каждый уровень устраняет рутинную работу, не лишая человека возможности принимать решения.
Операционные команды должны рассмотреть возможность передачи задач по устранению неисправностей ИИ и позволить своим сотрудникам заниматься инновациями.
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться