Система реагирования на инциденты для AI-агентов: чёткие правила действий

Почему инциденты быстро выходят из-под контроля

Небольшой сбой за считаные минуты может превратиться в три разные версии событий. Один инженер видит всплеск ошибок, один агент винит последний деплой, другой указывает на базу данных, а третий копается в логах, которые вообще не связаны с реальной причиной.

Вот первая проблема: когда люди и агенты исходят из разных предположений, они тратят время на параллельные действия, которые не помогают. У инженера теперь две задачи: найти проблему и не дать агентам сделать хуже.

Ложные срабатывания вредят по-другому. Если агенты реагируют на каждый краткий всплеск ошибок, инженер начинает их игнорировать. После недели шумных алертов даже реальный сбой платежей может выглядеть как очередной безобидный скачок. Доверие быстро падает, а реагирование замедляется именно тогда, когда скорость важнее всего.

Медленное реагирование дорого обходится, но рискованные автоматические действия могут стоить ещё дороже. Агент, который слишком рано перезапускает сервисы, откатывает код, очищает очереди или блокирует трафик, может превратить небольшую проблему в простой, заметный клиентам. Если в продакшен попадёт неверное исправление, восстановление займёт больше времени, потому что команде придётся отменять это исправление и решать исходную проблему.

В небольшой команде это особенно сложно. Один человек не может одновременно читать все алерты, смотреть все графики, проверять все предложенные действия и держать в голове чёткую хронологию. AI может сильно помочь, но только если каждый агент точно знает, где заканчиваются его полномочия.

Полезная схема реагирования не пытается сделать из агентов полноценную ops-команду. Она даёт им узкие задачи, понятные пороги и жёсткие ограничения. Один агент собирает доказательства. Другой группирует похожие алерты. Третий предлагает откат и ждёт одобрения.

В этом и цель: двигаться быстро, не позволяя автоматике гадать. Инженер должен понимать, какие алерты важны, какой агент может действовать и где системе нужно остановиться и спросить человека. Когда эти правила понятны, инциденты остаются меньше, спокойнее и их гораздо проще устранять.

Определите, чем владеет система

Начните с жёсткой границы вокруг того, к чему агент может прикасаться. Если граница размыта, автоматизация начинает гадать. В небольшой команде один инженер может одновременно следить за деплоями, фоновыми задачами, логами и ошибками, которые видят клиенты, поэтому каждой зоне нужны чёткие рамки.

Запишите реальные системы и действия клиентов простыми словами. Включите серверы приложения, базы данных, очереди, запланированные задачи, запуск CI/CD и действия клиентов вроде регистрации, входа, оформления заказа и сброса пароля. Так область ответственности становится реальной. И сразу видно, где неудачное автоматическое действие может быстро навредить пользователям.

Простая карта владения должна отвечать на пять вопросов:

• К каким системам могут обращаться агенты?
• На какие действия клиентов зависят эти системы?
• Может ли агент наблюдать, предлагать, менять или вообще не трогать каждую область?
• Какие правила отличаются между тестом, staging и production?
• Какой инженер принимает окончательное решение?

Названия ролей важнее, чем многие команды думают. «Наблюдать» — значит читать логи, метрики, трассировки и историю деплоев. «Предлагать» — значит предлагать откат или называть вероятную причину. «Менять» — должно оставаться узким и обратимым, например перезапустить worker или временно остановить один шумный job. «Никогда не трогать» — должно покрывать удаление данных, изменение платёжных записей, прав доступа или отправку сообщений клиентам.

Держите действия в тесте отдельно от действий в production. В тесте или staging агенты могут пробовать более широкие шаги, потому что зона риска небольшая. В production по умолчанию лучше оставаться почти в режиме только чтения. Если вы разрешаете действия на запись, убедитесь, что их легко отменить и что они не меняют клиентские данные.

Назначьте одного инженера, который принимает окончательное решение до того, как что-то пойдёт не так. Во время инцидента общая ответственность часто превращается в путаницу. Один человек должен решать, безопасно ли предложение агента, стоит ли продолжать изменения в production и когда нужно вмешаться человеку.

Если другой инженер не может прочитать вашу карту и понять её за минуту, значит система всё ещё владеет слишком многим.

Задайте значимые уровни тревог

Если каждый алерт выглядит срочным, системе никто не доверяет. Инженер привыкает к шуму, а агенты начинают гадать. Хорошая схема использует небольшой набор уровней тревоги, которые люди могут быстро прочитать и без споров понять, что делать.

Для большинства команд достаточно трёх или четырёх уровней:

• Info: что-то изменилось, но пользователи этого не чувствуют
• Warning: пользователи могут почувствовать это скоро, если паттерн продолжится
• Major: пользователи уже чувствуют проблему, но сервис ещё работает с ограничениями
• Critical: ломаются основные сценарии, данные под угрозой или сбой быстро распространяется

У каждого уровня должно быть три опоры: влияние на клиента, временное окно и число. Влияние на клиента отвечает на вопрос, что именно сломалось. Временное окно показывает, это случайный всплеск или настоящий инцидент. Число показывает, сколько ошибок, пользователей или систем пересекло порог.

Например, всплеск CPU на 30 секунд не должен будить кого-то среди ночи. А рост доли ошибок в оформлении заказа выше 3% в течение 5 минут — это уже другое дело. Если за это же окно срываются 200 платежей, алерт должен сразу перейти в Major или Critical, потому что ущерб уже реален.

Используйте два порога, а не один. Первый запускает действие. Второй снижает шум. Алерт может входить в Warning при 1% неудачных запросов за 5 минут, но будить инженера или запускать автоматический откат только при 3% за 5 минут. Такой зазор помогает системе сохранять спокойствие, когда трафик кратко проседает или один узел начинает вести себя странно.

Удаляйте алерты, на которые никто не реагирует. Будьте в этом жёсткими. Если алерт срабатывает, а команда продолжает его игнорировать, значит алерт неправильный. Понизьте уровень, объедините его с другим сигналом или уберите совсем. У каждого алерта должен быть владелец и понятное следующее действие.

Хорошие пороги звучат скучно. Именно этого и нужно добиваться. В 3 часа ночи «ошибки оформления заказа выше 3% в течение 5 минут» всегда лучше, чем «обнаружена аномалия».

Дайте каждому агенту права на команды

Если каждый агент может делать всё, система разваливается, как только растёт давление. Один агент должен проверять, один может предлагать, и только один должен выполнять рискованные изменения. Некоторые действия должны оставаться у инженера.

Для небольшой команды хорошо работает простое разделение:

• Агент-наблюдатель читает логи, метрики, трассировки, недавние деплои и diffs конфигурации.
• Агент для первичного разбора группирует алерты, предполагает вероятную причину и предлагает следующие шаги.
• Агент-действие может перезапустить сервис, очистить зависшую очередь или масштабировать worker в рамках фиксированных лимитов.
• Агент отката может вернуть последний деплой, но только когда сработает заданный триггер.
• Инженер одобряет рискованные изменения, вызывает людей и разбирает всё, что не входит в плейбук.

Права на чтение могут быть широкими. Права на запись должны быть узкими. Права на перезапуск обычно безопаснее, чем права на откат, поэтому не давайте их обоим агентам по умолчанию. Запись в базу данных, изменения правил firewall, ротация секретов и всё, что может удалить клиентские данные, должны оставаться у одного доверенного исполнителя или у инженера.

Заставьте каждого агента объявлять намерение перед действием. Это может быть короткое сообщение простыми словами: «Я планирую перезапустить checkout-api, потому что доля ошибок 18% уже 10 минут, а последний деплой изменил использование памяти. Подожду 60 секунд на отмену». Так у инженера есть реальный шанс остановить плохой шаг. И остаётся понятная запись о том, кто что сделал и почему.

Не менее важен и список запрещённых действий. Держите его коротким, чтобы люди могли вспомнить его в стрессе. Ни один агент не должен выполнять команды, которые удаляют продакшен-данные, отключают бэкапы, стирают audit logs, меняют настройки биллинга или ротируют секреты во время инцидента, если инженер не дал прямое одобрение.

Именно здесь многие команды начинают халтурить. Они раздают широкие права, потому что так кажется быстрее. И это действительно быстрее — до первого неверного отката или массового перезапуска. Чёткие права на команды делают автоматизацию полезной. Агенты остаются в своей зоне, а инженер сохраняет контроль, когда цена ошибки высока.

Добавьте точки остановки до того, как ущерб распространится

Автоматизация должна быстро выполнять небольшие, обратимые задачи. Но как только действие может удалить данные, списать деньги или опубликовать публичное сообщение, система должна остановиться и спросить человека. Когда возможный ущерб растёт, контроль важнее скорости.

Для команды с одним инженером фиксированные точки остановки работают лучше, чем расплывчатые правила. Агенты лучше справляются, когда граница обозначена прямо. Перезапуск сервиса или очистка безопасного кэша может быть допустима. Но удаление записей, возврат средств, изменение биллинговых настроек или публикация публичного сообщения должны каждый раз ждать одобрения.

Задайте и жёсткий лимит повторов. Если агент трижды пытается одно и то же исправление, а алерт всё ещё срабатывает, остановите цикл. Повторные попытки тратят время и могут сделать небольшой сбой хуже. После лимита агент должен собрать логи, перечислить все выполненные команды и передать случай инженеру.

Разногласия между агентами — ещё одна причина остановиться. Если один агент хочет откат, а другой — изменить конфиг или перезапустить jobs, не позволяйте им продолжать действия. Передайте решение человеку. Разные рекомендации обычно означают, что агентам не хватает контекста, а угадывать под давлением рискованно.

Короткого набора правил обычно достаточно:

• Пауза перед разрушительными действиями, изменениями, связанными с деньгами, или публичными сообщениями.
• Пауза после фиксированного числа неудачных попыток исправления.
• Пауза, когда два агента предлагают разные следующие шаги.
• Пауза, когда агент не может объяснить, почему действие безопасно и обратимо.

Представьте сбой checkout после деплоя. Один агент перезапускает API. Другой предлагает заново запустить упавшие billing jobs. Ошибки оплаты продолжаются. Это и есть момент, когда нужно заморозить автоматизацию, не трогать клиентские списания и дать инженеру принять решение. Хорошие точки остановки почти не замедляют команду. Зато они не дают одному плохому решению превратиться в более крупный инцидент.

Проходите инцидент шаг за шагом

Когда срабатывает алерт, не спешите чинить всё в первую же минуту. Сначала подтвердите, что сигнал настоящий. Один агент может проверить вторую метрику, сравнить её с недавней базой и убедиться, что монитор сам не сломался, чтобы команда не гналась за ложным алертом или коротким всплеском, который уже прошёл.

Когда сигнал выглядит реальным, разделите работу. Дайте одному агенту задачу собрать факты: что сломалось, когда началось, какой сервис затронут, сколько пользователей это чувствуют и ухудшается ли ситуация. Дайте второму агенту одну узкую задачу: проверить недавние изменения, например деплои, правки конфигурации, изменения feature flag, истекшие сертификаты или инфраструктурные события.

Сужайте и путь к исправлению. Пусть только один агент предлагает действия. Этот агент должен предложить один лучший шаг и один запасной вариант с короткой причиной, ожидаемым результатом и риском. Если три агента одновременно предлагают три разные правки, инженер теряет время на сортировку шума вместо восстановления сервиса.

Дальше каждый раз используйте один и тот же цикл: одобрить, выполнить, проверить, записать. Инженер одобряет действие, агент выполняет разрешённую команду или готовит откат, а потом все проверяют, помогло ли изменение. Записывайте точное действие, кто его одобрил, время и что произошло после. Короткие заметки особенно важны, когда первый шаг помогает лишь частично.

Проверке нужно немного терпения. Наблюдайте за метриками достаточно долго, чтобы заметить откаты, отложенные очереди или скрытые повторы. Если доля ошибок падает на одну минуту, а потом снова растёт, инцидент всё ещё открыт.

Закрывайте инцидент только после того, как сервис стабилизируется. Обычно это означает, что алерт остаётся чистым в заданном окне, клиентские метрики выглядят нормально, и в фоне больше не растёт backlog. Если графики всё ещё дрожат, оставляйте комнату открытой и продолжайте наблюдать.

Держите всех в одной картине во время инцидента

Путаница распространяется быстрее, чем баг. Когда один инженер работает с несколькими агентами, исправление может уйти не туда, если обновления одновременно живут в чате, логах и памяти. Используйте одну общую заметку об инциденте как источник истины.

Эта заметка должна быть простой и скучной. Каждая запись должна содержать четыре вещи: время, ответственного, текущий факт и следующий шаг. Если агент что-то проверил, напишите, что именно. Если инженер перехватил управление, напишите почему.

Используйте один формат для каждого обновления

Короткие обновления двигают инцидент вперёд. Они же помогают быстрее заметить неверные догадки.

• 14:07 - Agent A - доля ошибок выросла с 2% до 18% после деплоя - проверяю логи платежного сервиса
• 14:10 - Engineer - заблокировал откат - новый деплой также изменил схему базы данных
• 14:14 - Agent B - найден всплеск таймаутов на одном endpoint - готовлю безопасный откат конфигурации

Этот формат полезен сразу по двум причинам. Никому не нужно разбирать стену текста. Инженер за секунды просматривает хронологию и видит, что изменилось, кто отвечает и что будет дальше.

Записи об одобрении важны не меньше, чем статусные обновления. Если инженер одобряет шаг, запишите причину одним предложением. Если инженер его блокирует, запишите и это. «Заблокировал перезапуск, потому что глубина очереди была стабильной, а перезапуск мог бы уронить in-flight jobs» — уже достаточно. Позже эта заметка объяснит решение без долгого созвона.

Оставьте след для следующего инцидента

Когда система снова стабилизируется, сохраните короткую заметку после инцидента в том же месте. Держите её краткой:

• что сломалось
• какое действие помогло
• какое действие чуть не ухудшило ситуацию
• какое правило нужно изменить перед следующим разом

Команда из одного человека с AI-агентами может двигаться очень быстро. Чистая общая заметка и есть то, что делает эту скорость полезной, а не хаотичной.

Простой пример: ошибки checkout после деплоя

В 14:14, через пять минут после релиза, ошибки checkout подскакивают с 0,4% до 6,2%. Это пересекает согласованный порог, поэтому инцидент открывается сразу. Никому не нужно спорить, достаточно ли это серьёзно. Правило уже ответило за всех.

Именно здесь ясная схема реагирования помогает небольшой команде. Одному инженеру не нужно вручную гоняться за каждой уликой, пока клиенты не могут оплатить заказ.

Агенты делят работу. Один сравнивает недавние логи с последним стабильным периодом и видит резкий рост ошибок 500 на endpoint checkout. Другой проверяет последний деплой, изменённые файлы и обновления конфигурации. Третий следит за платёжными сигналами, чтобы понять, не падает ли сам gateway или проблема начинается внутри приложения.

Через две минуты инженер получает короткое резюме:

• ошибки начались сразу после deploy 1842
• время ответа провайдера платежей выглядит нормальным
• сбои сосредоточены вокруг нового вызова расчёта налога
• откат, вероятно, быстро снизит долю ошибок

Агенты могут предложить действие, но сами откатывать production не могут. Это и есть точка остановки. Инженер читает доказательства, проверяет, что план отката безопасен, и одобряет его.

После отката работа не заканчивается. Один агент ещё 15 минут следит за ошибками checkout. Другой проверяет успешность платежей и подтверждает, что число завершённых заказов вернулось к обычному уровню. Агент деплоя проверяет, что никаких последующих jobs или миграций от неудачного релиза не осталось.

Алерт закрывается только после того, как восстановление держится стабильно весь период наблюдения. Если доля ошибок падает на две минуты и потом снова растёт, инцидент остаётся открытым.

Эта короткая пауза важна. Быстрое действие решает первую проблему. Внимательное наблюдение гарантирует, что команда не закроет инцидент, пока клиенты всё ещё натыкаются на сломанный checkout.

Частые ошибки, которые создают шум или риск

Большинство сбоев начинается ещё до самого инцидента. Команды настраивают правила, которые на бумаге выглядят безопасными, а потом обнаруживают, что каждый маленький скачок будит инженера, два агента пытаются чинить одно и то же или агент бесконечно повторяет попытки, пока мелкая проблема не превращается в полноценный outage.

Первая ловушка — слишком низкие пороги. Если небольшой скачок latency или короткое падение success rate вызывает page, инженер учится игнорировать алерты. Агенты тоже усваивают неправильный урок, потому что реагируют на шум, а не на настоящую проблему. Ставьте пороги так, чтобы они ловили боль пользователей, а не каждый краткий всплеск. Пятиминутный тренд ошибок обычно говорит больше, чем одна плохая минута.

Права доступа создают следующую группу проблем. Два агента не должны иметь одинаковые права на запись для одного и того же сервиса, базы данных или шага деплоя. Один может проверять, другой — готовить план отката, но только один должен выполнять изменения в этой области. Когда два агента могут писать одновременно, появляются гонки, дублирующие действия и запутанные логи.

Логика повторов тоже нуждается в жёсткой границе. Если агент может перезапустить job, откатить деплой или перенаправить трафик, ограничьте число попыток и после этого заставьте человека проверить ситуацию. Бесконечные повторы выглядят активностью, но часто скрывают тот факт, что первое действие только ухудшило положение.

Также помогает чётко разделить работу:

• один агент собирает факты
• один агент предлагает следующий шаг
• один инженер одобряет или отклоняет рискованные изменения
• один агент выполняет одобренное действие

Такое разделение кажется строгим, но оно экономит время, когда давление растёт. Видно, кто принял решение, кто действовал и почему.

Последняя ошибка — пропустить короткую заметку после инцидента. Не ждите длинного формального отчёта. Запишите триггер, алерты, которые сработали, что сделал каждый агент, где должна была сработать точка остановки и какое правило вы измените следующим. В небольшой команде эта заметка становится вашей памятью. Без неё тот же шумный алерт и то же рискованное поведение вернутся на следующей неделе.

Быстрая проверка и следующие шаги

Хорошая схема должна быть понятна с первого взгляда. Один инженер должен открыть единый экран и сразу увидеть три вещи: уровень тревоги, кто отвечает за инцидент и что система делает сейчас. Если эта информация разнесена по нескольким экранам, люди теряют время, а агенты работают со старым контекстом.

Рискованные команды требуют более жёстких правил, чем простые шаги по расследованию. Агент может сам собирать логи, сравнивать недавние деплои или обновлять внутреннюю заметку об инциденте. Но он не должен откатывать production, менять правила firewall, ротировать секреты или удалять данные, если человек не одобрил этот путь заранее или если workflow не достиг жёсткой остановки.

Короткая проверка находит большинство слабых мест:

• Проверьте, что основной экран инцидента показывает severity, владельца и текущее действие вместе.
• Проверьте, что у каждой рискованной команды есть понятное правило одобрения или жёсткая остановка.
• Проверьте, что каждый порог можно объяснить одним простым предложением.
• Проверьте, что у агентов есть только те права, которые нужны им для их части работы.
• Проверьте, что дежурный инженер может быстро остановить автоматизацию.

Пороги важнее, чем думает многие команды. Если никто не может объяснить, почему срабатывает алерт, правило слишком расплывчатое.

То же самое относится и к более широкой инженерной системе вокруг таких агентов. Такой дисциплинированный, AI-first способ работы близок к тому, что делает Oleg Sotnikov через oleg.is: практичная автоматизация, чёткие границы и системы, которые помогают небольшой команде работать быстрее, не теряя контроль.

Если ваш процесс реагирования на инциденты всё ещё держится на памяти, разбросанных чатах и слишком широких правах агентов, начните с исправления этих трёх областей. Вам не нужна сложная методология. Вам нужны понятные пороги, узкие права на команды и точки остановки, которые не дают плохой догадке превратиться в более крупный outage.