Чем быстрее команды выпускают код с помощью ИИ, тем больнее обходятся сбои после релиза. На этом фоне AI-инциденты становятся не теоретической темой для демо и конференций, а вполне приземленной задачей для SRE, платформенных команд и техдиров: если верить оценке, приведенной в публикации, около 70% инцидентов связаны с изменениями в коде. Проблема, по версии PagerDuty, в том, что у большинства инструментов здесь нет главного слоя — не анализа, а исполнения.
Об этом сообщает The New Stack со ссылкой на Жоау Фрейтаса, Chief AI Officer в PagerDuty. Его тезис звучит неприятно знакомо для любой команды, которая уже пробовала «прикрутить ИИ» к онколлу: рынок охотно продает умное распознавание, суммаризацию, поиск по логам и красивые объяснения, но часто не закрывает участок между обнаружением проблемы и реальным действием. Проще говоря, модель умеет рассказать, что сломалось, но не всегда способна безопасно и последовательно встроиться в процесс восстановления сервиса.
Это важная развилка для всей категории AI-инструментов в эксплуатации. Последние два года отрасль активно автоматизирует разработку: кодогенерация, ревью, тесты, подсказки по архитектуре, агентные сценарии. В результате скорость поставки растет, а вместе с ней растет и объем изменений, которые попадают в прод. Если раньше бутылочным горлышком был сам релиз, то теперь им все чаще становится управление последствиями релиза. И вот тут выясняется, что AI-инциденты нельзя закрыть одним чат-ботом поверх observability-стека. Нужен слой, который понимает контекст инцидента, умеет работать с цепочкой инструментов и не ломается в момент, когда от него ждут не слов, а действий.
Судя по описанию материала, Фрейтас говорит именно об этом недостающем промежуточном уровне: между сигналом от мониторинга и конкретным вмешательством в систему. Для инженеров это звучит как старая добрая оркестрация, только в новой упаковке. Мало определить вероятную причину деградации. Надо еще знать, какой сервис затронут, какие зависимости у него критичны, кто владелец, какие playbook уже одобрены, что можно откатывать автоматически, а что требует человека в контуре. Без такого слоя AI-инциденты превращаются в дорогую версию статуса "мы нашли что-то подозрительное".
Отдельный контекст здесь добавляет Model Context Protocol, который все чаще всплывает в разговорах об агентных системах. Идея понятна: если ИИ должен не только отвечать, но и действовать, ему нужен стандартизованный доступ к инструментам, данным и контексту. Но стандартизованный доступ сам по себе не равен надежной автоматизации. Для инцидент-менеджмента этого мало: система должна учитывать права, приоритеты, границы ответственности и цену ошибки. Одно дело — попросить модель подготовить черновик postmortem. Совсем другое — разрешить ей менять конфигурацию, катить rollback или отключать шумные алерты в живой системе. На словах все любят autonomous operations, на практике бизнес обычно хочет не автономию любой ценой, а управляемость и проверяемость.
Для русскоязычной IT-аудитории здесь есть вполне прикладной вывод. Если компания сейчас выбирает платформу для AI-инцидентов, смотреть только на качество резюме, чат-интерфейс и скорость поиска по телеметрии уже недостаточно. Важнее проверить, есть ли у решения внятная исполняющая часть: интеграции с incident response, понятные runbook, ограничения на действия, журнал изменений, человек в контуре там, где риск ошибки высок, и связка с существующим стеком оповещений и ownership-моделью. Иначе получится знакомый корпоративный сюжет: ИИ красиво объясняет аварию, а чинят ее по-прежнему в Slack, Zoom и руками дежурного инженера, который в этот момент еще и перепроверяет, не нафантазировала ли модель лишнего.
На рынке это, вероятно, подталкивает AI Operations к следующему этапу взросления. Конкуренция будет идти уже не вокруг того, кто лучше суммирует инцидент или быстрее пишет статус-апдейт, а вокруг того, кто аккуратнее встроит ИИ в реальные процедуры восстановления. Для вендоров это неудобная зона: меньше магии в интерфейсе, больше тяжелой инженерии, интеграций и ограничителей. Для покупателей — наоборот, полезный сдвиг. Потому что в эксплуатации ценится не тот ИИ, который звучит умно, а тот, который не добавляет еще один инцидент поверх первого.