Incident Management AI

Суть

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

Severity: три уровня

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

Роли при SEV-1

• Incident commander — координирует и не чинит руками. Как только координатор ушёл в консоль, инцидент теряет управление.
• Communications — общается с клиентами и внутренними стейкхолдерами, снимая эту нагрузку с инженеров.
• Technical lead — ведёт митигацию по runbook.

Роли назначаются на время инцидента и не совпадают с должностями.

Тихая деградация и severity. Уровень назначается по влиянию на пользователя, а не по скорости обнаружения — иначе всё, что нашли поздно, автоматически становится мелочью. Неделя незамеченной деградации качества обычно означает больший накопленный ущерб, чем часовой отказ, потому что за это время сервис успел выдать много плохих ответов, и часть из них уже привела к решениям. Практический критерий — сколько запросов прошло через деградировавший путь и обратимы ли их последствия; из этого же следует, что такие случаи требуют не только починки, но и ретроспективного разбора уже отданных ответов (Agent Failure Modes, тихие сбои).

Runbook: инструкция на плохой день

Документ на один класс инцидентов из пяти секций:

1. Симптомы — какие алерты и жалобы указывают на этот сценарий.
2. Диагностика — логи, трейсы, дашборды с конкретными ссылками.
3. Митигация — откат версии, выключение флага, рестарт — по шагам.
4. Эскалация — кому звонить и при каких условиях.
5. Восстановление — критерий «всё хорошо» и объявление отбоя.

Три правила, без которых runbook не работает:

• Один runbook — один класс инцидентов. «Деградация качества ответов», «рост латентности», «отказ провайдера» — отдельные документы. Универсальный документ не читают.
• Шаги, а не советы. «Посмотреть логи» — совет; «открыть дашборд X, применить фильтр Y» — шаг.
• Обновляется вместе с релизом. Runbook, описывающий позапрошлую архитектуру, вреднее отсутствующего.

Главная ценность — снижение давления решений: ночью человек с высокой ценой ошибки не должен придумывать план.

Три времени инцидента держатся врозь

Разбор аварии сводит вместе три вещи, которые обязаны остаться различимыми:

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

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

Неустановленная первопричина остаётся предположением и помечается как предположение. Инцидент закрывается митигацией, а не объяснением; объяснение, записанное как факт до подтверждения, потом никто не пересматривает — оно уже выглядит проверенным (Paraphrase Drift).

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

Типовая митигация для AI-сервиса

Порядок действий, отличающийся от классического бэкенда:

1. Выключить флаг сломанной фичи — секунды, без деплоя (Feature Flags LLM).
2. Откатить связку на тёплую предыдущую версию (Canary Release LLM).
3. Проверить провайдера — деградация может быть не вашей: 429, 529, изменения на стороне модели.
4. Проверить cache hit rate и стоимость — финансовый инцидент выглядит как рост счёта при живом сервисе (Cost Anomaly Alerting).

Связано с

• Blameless Postmortem — что происходит после отбоя
• Feature Flags LLM — самый быстрый инструмент митигации
• Canary Release LLM — откат на тёплую версию как штатная процедура
• Cost Anomaly Alerting — отдельный класс инцидентов: деньги, а не доступность
• Support Escalation Ladder — эскалация единичных ошибок, из которых вырастают инциденты
• Paraphrase Drift — почему версия причины, записанная без пометки, потом читается как установленная