Разбор инцидентов после стабилизации: причины, выводы и действия по предотвращению повторений.

Цель

• Понять корневую причину без поиска виноватых.
• Зафиксировать факты, таймлайн и принятые решения.
• Определить действия: исправления, улучшение мониторинга, обновление runbook’ов, изменения в коде или процессах.

Когда проводить

• Обязательно для инцидентов S1 и S2.
• По решению команды — для S3 при повторяющихся или поучительных случаях.

Формат

1. Краткое описание — что произошло, когда, какой сервис/функция затронуты.
2. Таймлайн — ключевые события от первого признака до стабилизации.
3. Корневая причина — техническая и/или процессная.
4. Что сработало / что нет — действия по реагированию, коммуникация, инструменты.
5. Действия — список задач с владельцами и сроками (багфиксы, алерты, документация, обучение).
6. Уроки — что изменить в архитектуре, процессах или runbook’ах.

Документ хранится в репозитории или wiki; ссылка — в тикете инцидента.

Культура

• Postmortem — blameless: фокус на системе и процессах, а не на персональной вине.
• Участие всех, кто был вовлечен в реагирование и кто может внести вклад в выводы.

Связанные страницы

• Incident Management — процесс инцидентов
• Runbooks — обновление процедур после инцидента
• Severity Levels — когда постмортем обязателен