Реагирование на инциденты с AI в программировании: правила, которые предотвращают второй сбой

Почему AI может сделать сбой ещё хуже

Во время сбоя кажется, что важна только скорость. И именно тогда AI-ассистент может направить команду не туда.

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

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

Риск резко растёт, как только появляются записывающие действия. Один restart, изменение config, очистка queue, правка schema или cleanup script могут стереть доказательства, которые вам ещё нужны. Как только кто-то перезаписывает файл, ротирует лог или меняет данные в production, команда теряет часть истории. Тогда вы уже отлаживаете не исходный сбой. Вы отлаживаете сбой плюс собственное вмешательство.

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

Небольшие команды чувствуют это давление ещё сильнее. Если один человек одновременно отвечает за incident command, программирование и deploy, AI может усиливать поспешные решения вместо того, чтобы быть страховкой. Инструмент быстрый. Эта скорость полезна, когда нужно кратко пересказать логи или сравнить недавние изменения. Но это плохая причина позволять ему писать прямо в production.

Большинство вторых сбоев начинается одинаково: частичные данные, правдоподобный patch и отсутствие чёткой границы, что именно команда может менять. Защитите диагностику, ограничьте объём patch и требуйте человеческого approval перед любыми записывающими действиями. Так срочность не превратится в новую проблему поверх первой.

Начните с диагностики только для чтения

Когда срабатывают алёрты, сделайте AI читателем, а не писателем. Сначала отключите доступ к изменениям. Никаких правок файлов, никаких изменений config, никаких сгенерированных patch и никаких deploy, пока человек не установит границы.

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

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

Что собрать

• Недавние логи затронутого сервиса
• Метрики по ошибкам, задержкам, трафику и использованию ресурсов
• Трассировки для упавших запросов или медленных путей
• Заметки о недавних deploy, изменениях config, feature flags и инцидентах

Делайте запрос узким. Попросите таймлайн, список симптомов, вероятную зону поражения и пробелы в данных. Спрашивайте: «Что изменилось первым?» или «Какой сервис начал ломаться раньше остальных?» Избегайте запросов вроде «почини это» или «напиши patch» на этом этапе.

Полезная сводка отделяет факты от догадок. Факты — это то, что команда может проверить: всплеск ошибок в 09:14, один сервис перезапускался дважды, сбои checkout выросли после изменения config. Догадки должны быть в отдельном разделе и явно помечены.

Сохраняйте каждый запрос и каждый ответ в incident channel, ticket или документе с заметками. Позже эта запись поможет команде пересмотреть решения, заметить неверные предположения и улучшить запросы для следующего инцидента. Она также упрощает approval, потому что все видят, что именно показали модели и как она сформулировала проблему.

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

Задайте границы patch до того, как кто-то начнёт писать код

Во время сбоя расплывчатые запросы делают AI опасным. Если попросить его «починить ошибки», он может тронуть retries, логирование, routing, packages и вспомогательный код за один раз. Так небольшая проблема в production превращается во второй сбой.

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

Запишите границы

Коротко зафиксированная область работ помогает всем оставаться честными. Это может выглядеть так:

• Сервис в рамках: только auth API
• Файлы в рамках: session_validator.go и один связанный config file
• Разрешённые изменения: один timeout, один retry count или один feature flag
• Вне рамок: изменения schema базы данных, обновления packages, refactoring и cleanup-правки

Именно последний пункт важнее всего. Запретите schema changes, dependency bumps и refactoring во время инцидента. AI часто предлагает их, потому что в diff это выглядит полезно. Но когда пользователи уже страдают, польза от таких изменений бывает редко.

Привязывайте каждый patch к одной гипотезе. Если вам кажется, что сбои запросов вызваны слишком агрессивным retry loop, меняйте только retry setting или ветку, которая его запускает. Не смешивайте сюда cleanup логов, переименование переменных, новые абстракции или несвязанные исправления тестов. Ревьюер должен суметь одной фразой сказать, что именно patch пытается доказать.

Заранее определите rollback, прежде чем кто-то начнёт писать код. Решите, будет ли команда откатывать один commit, выключать feature flag, восстанавливать известное хорошее значение config или заново выкатывать последний рабочий image. Запишите, кто может это сделать и сколько это займёт. Если rollback занимает двадцать минут и требует пяти ручных шагов, patch слишком широк для режима инцидента.

Небольшие команды обычно справляются с этим лучше всего, когда под давлением остаются предсказуемыми. Узкий patch может казаться медленным пять минут. Широкий patch способен съесть всю оставшуюся ночь.

Решите, кто утверждает каждое действие

Путаница с approval создаёт собственный ущерб. Если «да» могут сказать три человека, каждый предполагает, что кто-то другой проверил patch. Если финальное решение ничьё, поспешный фикс может попасть в production со скрытыми побочными эффектами.

Назначьте одного incident lead и дайте этому человеку последнее слово по изменениям кода. Ему не обязательно самому писать patch. Но у него должно быть достаточно контекста, чтобы удерживать исправление в узких рамках, останавливать расползание scope и говорить «нет», когда команда начинает гадать.

Даже под давлением хорошо работает простое разделение ролей. Один человек собирает факты и подтверждает вероятную причину. Другой проверяет patch и убеждается, что он решает только подтверждённую проблему. Третий выполняет deploy, наблюдает за rollout и готовит rollback. Один человек даёт финальное approval для любого merge, который влияет на production.

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

Человеческое согласование должно происходить дважды. Сначала перед merge. Потом перед rollout. Первая проверка отвечает на вопрос: мы доказали причину, сделали patch маленьким и избежали лишней уборки? Вторая проверка спрашивает: у нас есть rollback, мы выкатываем в правильное место и знаем, какая метрика покажет, что исправление сработало?

Повышайте планку approval, когда patch затрагивает payments, authentication, permissions или customer data. В этих областях второй сбой может возникнуть очень быстро. Маленькая ошибка может заблокировать доступ пользователям, списать деньги дважды или записать неверные данные, которые потом сложнее исправить, чем исходный баг.

Помогает реалистичный пример. Допустим, AI-инструмент предлагает правки в session handling после всплеска login failures. Ревьюер может принять узкий фикс в одном middleware file. Но если предложенный patch также меняет billing retries или account state, incident lead должен остановить его и привлечь владельца этой области до любого deploy.

Во время инцидента важна скорость. Но чёткие линии approval важнее.

Простой процесс на первые 30 минут

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

Сначала назовите влияние на клиента простыми словами. Могут ли пользователи войти, оплатить, синхронизировать данные или завершить основную задачу? Затем отметьте системы, которые касаются этого пути: app, API, queue, database, cache или один недавний deploy. Это сужает область поиска до того, как команда начнёт тратить время на шум.

Для первых проверок зафиксируйте модель в режиме только чтения. Попросите её кратко пересказать логи, сравнить config, сгруппировать ошибки, посмотреть недавние diff и указать странности в тайминге. Пока не просите исправления. Ранние догадки выглядят полезными, но часто уводят команду к неправильному patch.

Помогает простой таймер:

• В первые 5 минут подтвердите влияние, затронутые сервисы и последнее известное хорошее состояние.
• К 10-й минуте соберите свежие данные из логов, метрик, трассировок и недавних изменений.
• К 20-й минуте сформулируйте одну гипотезу и проверьте только её на новых данных.
• До 30-й минуты подготовьте один маленький patch или один rollback, который соответствует данным.

Держите гипотезу узкой. «Новая настройка cache сломала чтение session» — полезно. «Что-то не так с инфраструктурой» — нет. Если свежие данные ломают гипотезу, отбросьте её и сформулируйте следующую. Одна ясная догадка лучше пяти полусформированных споров.

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

Один человек пишет patch. Другой его утверждает. Сохраняйте approval workflow простым. Один reviewer решает «да» или «нет», а один владелец отвечает за rollback, если patch даст сбой.

Затем подготовьте изменение, быстро проверьте проблемный путь и следите за коротким набором сигналов перед более широким rollout: error rate, latency, queue depth и один бизнес-показатель, например успешный checkout или login. Если эти числа идут не в ту сторону, остановите rollout и вернитесь к данным.

Реалистичный пример

В 9:12 утра клиенты начинают видеть ошибки checkout через несколько минут после изменения config в payment pipeline. Изменение казалось маленьким: кто-то уменьшил queue timeout, чтобы быстрее очищать зависшие задачи. Вместо этого новые заказы начали накапливаться, API calls стали ждать слишком долго, а число неудачных checkout выросло так быстро, что support заметил проблему ещё до того, как алёрт на дашборде успел разбудить всех.

Один инженер достаёт логи и историю deploy, но команда оставляет AI-ассистента в режиме только чтения. Он может искать по логам, сопоставлять временные метки, сравнивать недавние изменения и кратко пересказывать шаблоны, но не может править код или трогать настройки. Через несколько минут он замечает один и тот же сигнал в трёх местах: всплеск timeout начинается сразу после изменения config, checkout workers начинают падать рывками, а latency растёт одновременно с этим.

Команда задаёт границы patch ещё до того, как кто-то начнёт писать фикс. Они разрешают только одно изменение: вернуть queue timeout для checkout workers к последнему известному хорошему значению. Всё остальное пока запрещено, включая изменения retries, настройку database и cleanup-работы, которые могут подождать, пока пожар не погашен.

Эта граница не даёт инциденту ухудшиться. AI предлагает ещё одну корректировку: увеличить retries, чтобы упавшие задачи запускались быстрее. Ревьюер отклоняет её. Больше retries отправило бы ещё больше трафика в уже медленный путь и могло бы поднять error rate и latency ещё выше.

После того как человек утверждает единственный rollback config, команда сначала выкатывает его на небольшую долю трафика. Они следят за error rate, queue depth и p95 latency в течение десяти минут. Цифры движутся в нужную сторону: сбои checkout падают, queue depth перестаёт расти, а время ответа стабилизируется.

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

Ошибки, которые запускают второй сбой

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

Одна частая ошибка — позволить AI напрямую править production config. Изменения config выглядят маленькими, но они могут перезапустить сервисы, сломать secrets или перенаправить трафик неожиданным образом. Сначала держите AI только в read-only diagnostics, а потом проводите любые изменения config через тот же approval path, который использовал бы человек.

Другая ошибка — упаковывать три идеи в один hot patch. Правка timeout, изменение retries и fix cache могут звучать связанно, когда пользователи уже не могут работать. Но это всё равно три отдельных ставки. Если patch сработал, вы не знаете, что именно помогло. Если он провалился, rollback становится сложным, а зона поражения — больше.

Команды также принимают patch без плана rollback, потому что инцидент кажется срочным. Это потом только отнимает время. До любого merge назовите точный file, flag или commit, который вы откатите, и человека, который сделает это, если error rate снова вырастет.

Устаревшие логи создают больше проблем, чем многие готовы признать. Если последний deploy уже поменял код, старые traces могут повести команду к неправильному багу. Проверьте timestamp, release version и environment, прежде чем AI начнёт кратко пересказывать логи или предлагать исправление. Пять минут на свежие данные могут сэкономить час погони за призраками.

Когда стресс растёт, ревью часто исчезает. А именно тогда оно нужнее всего. Один инженер может не заметить скрытый побочный эффект, особенно если AI сгенерировал diff за секунды. Второй человек должен задавать простые вопросы: Что изменилось? Что мы оставили нетронутым? Как это откатить?

Простой пример делает риск очевидным. Ошибки checkout растут после deploy, и AI предлагает увеличить размер database pool, изменить retry logic и отключить одну проверку validation. Такой набор слишком рискованный. Начните с самого маленького изменения, связанного с текущими логами, оставьте остальное вне patch и убедитесь, что rollback занимает один шаг, а не превращается в ночную суету.

Быстрые проверки перед merge или deploy

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

Начните с одного вопроса: соответствует ли это изменение одной проверенной гипотезе? Если команда думает, что worker queue падает из-за слишком короткого timeout, diff должен оставаться близко к этой проблеме. Если patch ещё и обновляет логирование, рефакторит helper или меняет поведение retries в другом сервисе, остановитесь и сократите scope.

Вторая человеческая проверка во время инцидента не является опцией. Перед merge diff должны читать два человека: автор и один reviewer, который не писал код. Задача reviewer — не восхищаться аккуратным кодом. Его задача — заметить рискованные лишние изменения, скрытые правки config, обновления dependencies и правки, которые затрагивают больше систем, чем планировала команда.

Используйте короткий release gate перед deploy:

• Patch меняет только код или config, связанные с проверенной причиной.
• Команда может откатить всё за минуты с известным commit, image или toggle.
• Кто-то уже назвал сервисы, которые могут почувствовать побочные эффекты после релиза.
• У команды уже открыты нужные графики, логи и алёрты.

Последний пункт важнее, чем многие признают. Если вы исправляете checkout timeout, сразу после релиза смотрите на success rate checkout, API latency, database connections и queue depth. Не смотрите только на общий uptime dashboard и не думайте, что вы в безопасности. Patch может снизить одну ошибку, но поднять другую.

Запишите шаг rollback до deploy, а не после. Формулируйте просто: кто нажимает кнопку, что именно откатывается и сколько это должно занять. Если rollback зависит от того, что три человека вспомнят shell commands на память, у вас нет плана rollback.

Если хоть один ответ звучит расплывчато, подержите merge ещё несколько минут. Эта пауза дешевле, чем объяснять, почему исправление вызвало более широкий сбой.

Следующие шаги для вашей команды

Команды лучше справляются с инцидентами, когда правила помещаются на одной странице. Для AI-assisted incident response на этой странице должны быть четыре простых ответа: что AI может смотреть, что может менять, кто может утверждать изменение и какие доказательства команда обязана сохранить. Если правила длиннее, люди будут пропускать их, когда давление вырастет.

Начните с простого. По умолчанию оставьте только чтение для диагностики, пока назначенный человек не утвердит patch. Ограничьте каждый patch самым маленьким безопасным исправлением и отметьте, что находится вне рамок. Назначьте одного approver для каждого уровня серьёзности и запасного. Сохраняйте prompt, diff, результат теста, заметку об approval и решение о deploy.

Потом потренируйтесь. Двадцатиминутной тренировки достаточно. Возьмите вымышленный сбой, попросите одного человека собрать диагностику, другого — проверить вывод AI, а третьего — утвердить или отклонить patch. Слабые места станут заметны быстро. Большинство команд понимает, что правила нормальные, но передача ответственности идёт медленно или никто не знает, кто принимает финальное решение.

Храните эту запись там, где команда уже ведёт заметки по инцидентам. Не разбрасывайте её по чатам, терминалам и личным документам. Во время postmortem эти prompts и diff показывают, оставался ли AI в рамках patch или подтолкнул команду ко второму сбою. Они также делают следующую тренировку полезнее, потому что вы можете сравнить реальные решения с playbook.

Для этого не нужен большой процесс. Один короткий набор правил, одна короткая тренировка и одна аккуратная запись решений уже переведут большинство команд в гораздо более безопасное состояние.

Если у вашей команды мало людей или путь approval расплывчатый, внешняя помощь может ускорить настройку. Oleg Sotnikov на oleg.is работает со стартапами и небольшим бизнесом как fractional CTO и может помочь выстроить практичные правила AI для инцидентов, workflow ревью и защиту production без лишней бюрократии.