Настройка Post-Mortem процесса для анализа инцидентов
Post-mortem — это структурированный анализ инцидента после его устранения. Цель — понять, почему произошло, и предотвратить повторение. Без post-mortem одинаковые инциденты случаются снова и снова, потому что никто не занимался устранением корневых причин.
Принципы blameless post-mortem
Blameless — не про поиск виноватых. Если инженер допустил ошибку, причина — в системе, которая позволила эту ошибку совершить без защитных механизмов. Правильный вопрос: «Почему система позволила это произойти?», а не «Кто нажал не ту кнопку?».
Культура blame приводит к тому, что люди скрывают инциденты и не признают ошибки. Это хуже, чем сам инцидент.
Когда проводить post-mortem
- SEV1 инциденты — всегда, в течение 48 часов
- SEV2 инциденты — всегда, в течение 72 часов
- SEV3 — по решению команды, если инцидент выявил системную проблему
- Повторяющиеся SEV4 — стоит провести, если один и тот же симптом третий раз
Структура post-mortem документа
# Post-Mortem: [Краткое описание инцидента]
**Дата:** 2025-11-15
**Severity:** SEV1
**Длительность:** 47 минут (14:23 - 15:10 UTC)
**Impact:** ~12,000 пользователей не могли завершить оплату
## Хронология
| Время | Событие |
|---|---|
| 14:23 | PagerDuty алерт: error rate > 5% на payment service |
| 14:28 | Инженер принял алерт, начал расследование |
| 14:35 | Обнаружено: БД не принимает новые подключения |
| 14:42 | Выявлена причина: connection pool исчерпан |
| 14:55 | Применено временное решение: restart connection pool manager |
| 15:10 | Сервис восстановлен, ошибки ушли |
## Корневая причина
Connection pool (pgBouncer) был настроен на max_client_conn=100.
После деплоя новой версии приложения количество воркеров увеличилось с 4 до 8,
каждый открывает до 15 соединений. При пиковой нагрузке: 8 * 15 = 120 > 100.
## Что пошло не так
- pgBouncer max_client_conn не пересматривался при изменении числа воркеров
- Нет алерта на приближение к лимиту connection pool (было бы видно заранее)
- В deployment checklist нет пункта про проверку DB connection settings
## Что сработало хорошо
- Алерт обнаружил проблему через 2 минуты после начала
- Runbook для DB connection issues помог быстро локализовать причину
- Команда отреагировала в рамках SLA
## Action Items
| Задача | Ответственный | Срок |
|---|---|---|
| Увеличить max_client_conn до 300, пересчитать под текущую архитектуру | @db-team | 2 дня |
| Добавить метрику pgbouncer_clients_active и алерт при > 80% | @ops-team | 3 дня |
| Обновить deployment checklist: раздел DB connections | @team-lead | 1 неделя |
| Документировать формулу расчёта connection pool | @db-team | 1 неделя |
Проведение post-mortem встречи
Участники: все, кто участвовал в ответе на инцидент + технический лид + при необходимости product owner.
Длительность: 60-90 минут. Если нужно больше — проблема в подготовке документа.
Структура встречи:
- Обзор хронологии (10 мин) — все должны иметь одинаковое понимание фактов
- Анализ корневых причин (20-30 мин) — техника 5 Why
- Что можно было сделать лучше (15 мин)
- Что сработало хорошо (5 мин) — важно для морального духа
- Формирование action items (15 мин) — с ответственными и сроками
Техника 5 Why для поиска корневой причины
Почему сервис упал?
→ Connection pool исчерпан
Почему connection pool исчерпан?
→ Число соединений превысило max_client_conn
Почему число соединений превысило лимит?
→ Число воркеров увеличилось при деплое
Почему увеличение воркеров не было учтено в конфиге pgBouncer?
→ Нет процесса проверки DB-конфига при изменении масштаба
Почему нет такого процесса?
→ Deployment checklist не охватывает зависимости конфигов
Корневая причина: отсутствие процесса проверки конфигурационных зависимостей при деплое. Action item направлен именно сюда.
Хранение и аналитика post-mortem
Документы хранятся в Confluence/Notion с тегами: severity, service, cause-category. Категории причин:
- Configuration (неправильный конфиг)
- Deployment (проблема при деплое)
- Dependency failure (сторонний сервис)
- Capacity (нехватка ресурсов)
- Human error (ошибочное действие)
Ежеквартальный обзор: какие категории преобладают → куда направить инвестиции в надёжность.
Action Items: как избежать кладбища задач
Post-mortem бесполезен, если action items никто не выполняет. Обязательные условия:
- Конкретный ответственный (не «команда», а имя)
- Чёткий срок
- Тикет в Jira/Linear создаётся сразу на встрече
- Обзор выполнения на следующей post-mortem встрече
Сроки внедрения процесса
- Шаблон документа + хранилище — 1 день
- Обучение команды + первый тестовый post-mortem — 1-2 дня
- Интеграция с incident tracker — 1 день