Хороший postmortem не ищет виноватого. Его цель — понять систему и улучшить процесс. Если в отчете написано “разработчик ошибся”, пользы мало. Если написано “не было smoke test на миграцию”, “алерт сработал поздно”, “runbook был устаревшим” или “rollback занимал слишком много времени”, команда получает конкретные точки улучшения.
Для ИИ-агентов postmortem нужен не только при падении сервера. Инцидентом может быть массовая галлюцинация в ответах поддержки, неправильный tool call, утечка данных, рост стоимости токенов, ошибка RAG-поиска, неудачный rollout промпта или действие агента без нужного approval. Такие случаи тоже нужно разбирать как системные сбои.
Практичный postmortem заканчивается action items: обновить мониторинг, добавить evals, изменить guardrails, поправить runbook, усилить логирование, добавить тест, ограничить права инструмента или изменить процесс релиза. Без ответственных и сроков postmortem превращается в красивый отчет, который никто не использует.
Примеры
- После сбоя API команда пишет postmortem: таймлайн, impact, root cause, что сработало и какие action items нужны.
- ИИ-агент поддержки дал серию неверных ответов из-за устаревшей базы знаний, и команда разбирает incident как RAG-проблему.
- После неудачного релиза промпта postmortem показывает, что не было regression suite на ключевые сценарии.
- DevOps-команда фиксирует, что алерт сработал через 30 минут, потому что метрика была настроена слишком грубо.
- Агент вызвал опасный tool call без подтверждения, и в postmortem добавляют approval workflow и read-only mode.
Где используется
- Разбирать технические, продуктовые и AI-инциденты после восстановления сервиса.
- Фиксировать таймлайн: обнаружение, реакция, mitigation, recovery и коммуникации.
- Понимать impact для пользователей, клиентов, команды и бизнеса.
- Находить системные причины, а не назначать виноватого.
- Создавать action items с ответственными и сроками.
- Улучшать мониторинг, алерты, runbook, rollback и release process.
- Добавлять evals, guardrails и regression tests для ИИ-агентов.
- Разбирать ошибки RAG, tool calling, prompt rollout и утечки данных.
- Собирать базу знаний по инцидентам для обучения команды.
Связанные термины
Action item
Action items
Agent trace
Alert enrichment
Approval workflow
Audit log
Cost monitoring
Guardrails
Частые вопросы
Что такое postmortem простыми словами?
Это разбор сбоя после инцидента: что случилось, почему, как это повлияло на пользователей и какие действия помогут не повторить проблему.
Почему postmortem должен быть blameless?
Если искать виноватых, люди начинают скрывать детали. Blameless-подход помогает увидеть слабые места системы, процессов, мониторинга и тестов.
Что должно быть в postmortem?
Обычно включают summary, impact, timeline, root cause, что сработало, что не сработало, action items, ответственных и сроки выполнения.
Нужен ли postmortem для ошибок ИИ-агента?
Да. Массовые неверные ответы, утечки, опасные tool calls, рост стоимости или провал RAG-поиска стоит разбирать как полноценные инциденты.
Какая частая ошибка в postmortem?
Ограничиться описанием события без конкретных action items. Такой отчет быстро забывается и не улучшает систему.
