Суть
Инцидент заканчивается не восстановлением сервиса, а разбором. Разбор бывает двух видов, и от выбора зависит, повторится ли авария.
| Работает | Хоронит причины |
|---|---|
| «Как система позволила ошибке случиться?» | «Кто нажал?» — разбор превращается в трибунал |
| Факты и таймлайн: люди делятся деталями без страха | Страх наказания — детали замалчиваются |
| «Неизвестно» — честный ответ с задачей на расследование | Догадка вместо «неизвестно» — ложная корневая причина |
| Разбор ≤ 48 часов, пока детали свежи | Тот же инцидент повторяется — систему никто не починил |
Факторы инцидента распределяются по четырём группам: люди, процесс, технологии, контекст. Обычно виноваты минимум два — поэтому поиск единственного виновного заведомо даёт неверный ответ.
Шаблон документа
Шесть секций:
- Сводка и влияние — сервис, severity, сколько пользователей задето.
- Таймлайн — от обнаружения до восстановления, с принятыми решениями.
- Причины — корневая и сопутствующие факторы.
- Что сработало / что нет — сигналы, runbook, коммуникация.
- Уроки — что команда узнала о системе и о процессе.
- Action items — у каждого владелец и срок; в бэклог, не в стол.
В шапке — номер, название, severity, дата публикации, лейблы (влияние, длительность, в какой версии применена митигация).
Шаблон держат стабильным хотя бы полгода. Смысл не в форме, а в мышечной памяти: команда, разбирающая инциденты по одной и той же структуре, начинает мыслить ею во время самой аварии.
Культура измерима: DORA
Аргумент против восприятия blameless как «мягкости». Метрики элитных команд:
- < 1 часа — время восстановления после сбоя (против дней у отстающих);
- < 5% — change failure rate, доля релизов, ломающих продакшен;
- 2,3× — во столько раз чаще команды с blameless-разборами создают высокоэффективные системы (Accelerate).
Специфика AI-сервисов
Корневая причина у агентных инцидентов редко бывает одной строкой кода. Типичная формулировка: «промпт изменили под новую модель, регресс проявился на редком классе запросов, который не был представлен в golden dataset, а канареечная выборка была слишком мала, чтобы его увидеть». Здесь четыре фактора сразу, и виновного среди них нет.
Отсюда следствие: action items после AI-инцидента чаще уходят не в код, а в процесс — расширить эвал-набор, добавить стратификацию в канарейку, завести отдельный runbook, поднять порог отката (см. Canary Release LLM).
Две сложности переноса DORA на агентов
Change failure rate, когда поломка — это качество. Классическое определение опирается на бинарный признак: изменение привело к сбою или нет. У агента изменение приводит к просадке качества, которая не видна в кодах ответа. Переносится метрика заменой признака отказа: изменение считается неудачным, если после выкатки сработал любой из гейтов отката — падение eval pass rate ниже порога, рост стоимости запроса, всплеск safety-срабатываний, рост доли отказов. Все четыре уже измеряются в релизном конвейере (Canary Release LLM), и метрика начинает считаться сама, без отдельного учёта.
Важная оговорка: считать надо от момента обнаружения, а не от момента выкатки, иначе тихая деградация, найденная через неделю, не попадёт в статистику того релиза, который её вызвал.
Владелец action item, когда причины нет в компоненте. Если разбор упёрся в отсутствующий процесс — нет регрессионного набора, никто не смотрит на дрейф, — назначать владельцем автора кода бессмысленно: он не может завести процесс. Владельцем становится тот, кто распоряжается ресурсом, которого не хватило: временем команды, приоритетом в бэклоге, доступом к данным. Практическое правило разбора: если для action item не находится владельца с полномочиями, пункт сформулирован слишком крупно — его дробят до уровня, на котором полномочия появляются, иначе он не будет сделан и вернётся следующим инцидентом.
Связано с
- Incident Management AI — процесс, который заканчивается этим документом
- Agent Failure Modes — типология причин, которые ищет разбор
- Canary Release LLM — куда чаще всего уходят action items
- AgentOps — эксплуатационная практика в целом