Postmortem: анализ инцидентов

Postmortem (post-incident review) — структурированный документ и процесс анализа инцидента в production с целью понять причины и предотвратить повторение.

Зачем нужно

Инциденты случаются в любой команде. Важно не кто виноват, а что сломалось в системе. Blameless postmortem (без поиска виноватых) — культура, которую используют Google, Netflix, Atlassian: она позволяет инженерам честно описывать произошедшее и находить системные улучшения. Для разработчика участие в postmortem — возможность учиться на реальных авариях.

Где используется

  • Production-инциденты — падение сервера, потеря данных, деградация производительности
  • Неожиданные баги — регрессии, попавшие в прод
  • Любое событие с влиянием на пользователей — даже короткое

Структура postmortem-документа

# Postmortem: [Название инцидента]

## Severity
P1 (критический) / P2 (высокий) / P3 (средний)

## Дата и время
Начало: 2026-03-15 14:32 UTC
Обнаружение: 14:35 UTC
Восстановление: 15:10 UTC
Длительность: 38 минут

## Влияние
- Затронуто пользователей: ~12 000
- Недоступный сервис: API авторизации
- Потери: 0 данных / снижение конверсии на X%

## Хронология (Timeline)
14:30 — Деплой версии 2.3.1
14:32 — Начали поступать ошибки 500 от /auth/login
14:35 — Алерт в PagerDuty, дежурный инженер принял
14:40 — Идентифицирована причина: env-переменная JWT_SECRET отсутствует
14:45 — Rollback на 2.3.0 запущен
15:10 — Сервис восстановлен

## Root Cause (Первопричина)
В деплое 2.3.1 была добавлена новая env-переменная JWT_SECRET,
но она не была добавлена в production-конфиг.
CI не проверял наличие переменных окружения.

## Contributing Factors (Сопутствующие факторы)
- Нет автоматической проверки env-переменных при деплое
- Checklist деплоя не обновлялся 6 месяцев
- Staging-окружение использовало дефолтное значение

## Action Items
| Задача | Ответственный | Срок |
|--------|---------------|------|
| Добавить проверку env-vars в CI | @devops | 2026-03-22 |
| Обновить deployment checklist | @tech-lead | 2026-03-20 |
| Настроить алерт на отсутствие критических переменных | @sre | 2026-03-25 |

## Что прошло хорошо
- Алерты сработали быстро (3 мин)
- Rollback занял менее 30 мин
- Коммуникация с командой была чёткой

## Что можно улучшить
- Время обнаружения: 3 мин — можно сократить до 1 мин
- Env-переменные должны проверяться в CI, а не в prod

Blameless культура

НЕЛЬЗЯ:
✗ "Вася задеплоил без тестирования"
✗ "Маша не проверила конфиг"

НУЖНО:
✓ "Процесс деплоя не имел проверки X"
✓ "Система не уведомляла об отсутствии Y"

Люди не приходят на работу, чтобы ломать продакшн. Если человек ошибся — значит, система позволила ошибиться.

Частые ошибки

Ошибка Проблема Решение
Не проводить postmortem для "мелких" инцидентов Маленькие проблемы накапливаются Для любого влияния на пользователей
Поиск виноватых Люди скрывают проблемы Blameless-культура, фокус на системе
Action Items без срока и ответственного Ничего не выполняется Конкретный владелец + дедлайн
Провести postmortem и забыть Инцидент повторяется Трекинг action items в Jira/Linear

Связанные темы

Ресурсы