Налаштування 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 | Застосовано тимчасове рішення: перезапуск 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 день