Ситуація: у п'ятницю ввечері падає payment service, error rate > 5%, 12 000 користувачів не можуть завершити оплату. Команда гасить пожежу 47 хвилин. Причина — connection pool вичерпано, тому що при деплої збільшили кількість воркерів, але забули оновити конфіг pgBouncer. Через місяць — той самий симптом. Ця ситуація знайома багатьом SRE-інженерам. Без робочого post-mortem процесу інциденти повторюються в 60% випадків. Ми допомагаємо впровадити blameless post-mortem культуру, щоб такі помилки не повторювалися.
Key principle: blameless post-mortem culture — не про пошук винних, а про покращення системи. Наш досвід: без post-mortem інциденти повторюються в 60% випадків; з post-mortem — менше 20%. Час на розслідування скорочується на 30–50%. Зниження SEV1 досягає 60% за півроку.
Чому важливий blameless post-mortem?
Blameless — не про пошук винних. Якщо інженер припустився помилки, причина — в системі, яка дозволила цю помилку скоїти без захисних механізмів. Правильний підхід — запитати, чому система дозволила помилці статися, а не хто натиснув не ту кнопку. Культура blame призводить до приховування інцидентів і небажання визнавати помилки — це гірше самого інциденту. Ми пропонуємо готовий шаблон і процес, який вбудовується у вашу incident management систему.
Коли і як проводити post-mortem
Визначення інцидентів для розбору
- SEV1 інциденти — завжди, протягом 48 годин
- SEV2 інциденти — завжди, протягом 72 годин
- SEV3 — за рішенням команди, якщо інцидент виявив системну проблему
- Повторювані SEV4 — варто провести, якщо один і той самий симптом втретє
Структура post-mortem документа
Кожен документ містить хронологію, кореневу причину, що пішло не так, що спрацювало добре, та action items. Приклад хронології:
| Час | Подія |
|---|---|
| 14:23 | PagerDuty алерт: error rate > 5% на payment service |
| 14:28 | Інженер прийняв алерт, почав розслідування |
| 14:35 | Виявлено: БД не приймає нові підключення |
| 14:42 | Виявлено причину: connection pool вичерпано |
| 14:55 | Застосовано тимчасове рішення: restart connection pool manager |
| 15:10 | Сервіс відновлено, помилки зникли |
Хід зустрічі
Учасники: всі, хто брав участь у відповіді на інцидент + технічний лідер + за потреби product owner. Тривалість: 60-90 хвилин. Етапи: огляд хронології (10 хв), аналіз кореневих причин (20-30 хв) за допомогою техніки 5 Why, обговорення покращень (15 хв), що спрацювало добре (5 хв), формування action items (15 хв) з відповідальними та термінами.
Техніка 5 Why
Приклад: Connection pool вичерпано → чому? кількість з'єднань перевищила max_client_conn → чому? кількість воркерів збільшилася при деплої → чому? немає процесу перевірки DB-конфігу при зміні масштабу → чому? deployment checklist не охоплює залежності конфігів. Коренева причина: відсутність процесу перевірки конфігураційних залежностей при деплої.
Категорії причин
Документи зберігаються з тегами: severity, service, cause-category. Основні категорії: Configuration, Deployment, Dependency failure, Capacity, Human error. Щоквартальний огляд допомагає спрямувати інвестиції в надійність.
Які результати дає впровадження?
Порівняння без post-mortem і з post-mortem:
| Критерій | Без post-mortem | З post-mortem |
|---|---|---|
| Повторюваність інцидентів | Висока (60% повторюються) | Низька (менше 20%) |
| Час на розслідування | Великий (немає шаблону) | Скорочується на 30–50% |
| Відповідальність за виправлення | Розмита | Закріплена за конкретними людьми |
| Культура команди | Страх і приховування | Прозорість і довіра |
Зниження частоти SEV1 на 60% економить до $60,000 на рік для команди з 10 осіб (середній SEV1 інцидент коштує $10,000). Скорочення часу розслідування на 30–50% економить 10+ людино-годин на тиждень.
Як гарантувати виконання action items?
Post-mortem марний, якщо action items ніхто не виконує. Обов'язкові умови:
- Конкретний відповідальний (не «команда», а ім'я)
- Чіткий термін
- Тікет у Jira/Linear створюється одразу на зустрічі
- Огляд виконання на наступній post-mortem зустрічі
Для аналітики використовуйте дашборд з категоріями причин, щоб виявити системні проблеми. Налаштування інтеграції з PagerDuty допомагає автоматизувати збір метрик.
Процес впровадження post-mortem
- Аудит поточного процесу управління інцидентами та виявлення зон росту
- Розробка шаблону post-mortem під вашу інфраструктуру та стек
- Навчання команди: workshop з blameless культури та техніки 5 Why
- Пілотний post-mortem на реальному інциденті з наставництвом
- Інтеграція з тікет-системою (Jira/Linear) та налаштування автоматичного збору метрик
- Щоквартальний огляд результатів та коригування процесу
Що входить в роботу
- Готовий шаблон post-mortem документа в Confluence/Notion
- Навчання команди (до 2 годин)
- Інтеграція з Jira/Linear: автоматичне створення action items
- Налаштування дашборду для аналітики причин
- Підтримка протягом місяця після впровадження
Терміни орієнтовно
- Базове впровадження: від 3 до 5 днів
- Повний цикл з навчанням та налаштуванням: від 5 до 10 днів
Вартість розраховується індивідуально. Щоб отримати консультацію та точну оцінку, зв'яжіться з нами. Замовте пілотний проект — ми проведемо аналіз одного інциденту і покажемо результат.