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

Как три источника работают вместе, видно на обычном разборе. Замечен всплеск: за неделю в репозитории появилось необычно много правок от агента. Аналитика показывает, что объём вырос у двоих человек, а не у всей команды, - значит, дело не в новой версии инструмента. Журнал аудита показывает, что накануне этим двоим расширили роль. События агента показывают, какие именно инструменты стали вызываться и сколько вызовов прошло без подтверждения. Ни один из трёх источников по отдельности этой цепочки не даёт: первый видит объём без причины, второй - причину без последствий, третий - последствия без контекста.

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

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

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

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

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

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