Пост-інцидентні розбори

1) Навіщо потрібні пост-інцидентні розбори

Пост-інцидентний розбір (post-mortem/AAR) - це структурований процес навчання організації після збою. Мета - не пошук винних, а виявлення кореневих і сприяючих причин і закріплення вимірюваних дій (CAPA), які знижують ризик повторення і вартість інцидентів, покращуючи SLO, MTTR і довіру клієнтів/регуляторів.

2) Принципи (Just Culture)

Без звинувачень: аналізуємо системи, рішення і контекст, а не персоналії.
Факти важливіші за думки: таймлайн, логи, метрики, трейси, артефакти змін.
E2E-погляд: від симптомів на клієнті до внутрішніх залежностей і зовнішніх провайдерів.
Перевірюваність: кожна гіпотеза підтверджується експериментом/даними.
Замикання циклу: розбір → CAPA → контрольні точки → ретест.

3) Коли запускати розбір і які бувають формати

Обов'язковий: SEV-0/1; порушення SLA/регуляторних вимог; витік даних; значущий PR-ризик.
Прискорений (light): SEV-2 з помітним впливом або повторюваними симптомами.
Комунікаційний AAR: якщо збій торкнувся статус-сторінку/підтримку, перевіряємо SLAs апдейтів і якість повідомлень.

Терміни: чернетка за 48-72 години, фінальна версія - до 5 робочих днів (якщо не обумовлено інакше).

4) Ролі та відповідальність

Власник розбору (RCA Lead): організовує процес, веде зустріч, відповідає за якість звіту і CAPA.
Incident Commander (IC): надає фактологію інциденту і рішення.
Tech Leads (за системами): аналіз причин, що підтверджують артефакти.
Comms/Support/Legal: оцінка комунікацій та вимог комплаєнсу.
Scribe: протокол, збір доказів, дотримання структури.
Стейкхолдери продукту/бізнесу: вплив на клієнтів/оборот, пріоритизація CAPA.

5) Підготовка: що зібрати до зустрічі

Таймлайн (UTC): T0 виявлення → Tn відновлення; релізи/фіч-прапори/конфіги, статус провайдерів.
Дані спостережуваності: графіки SLI/SLO, error-rate, перцентилі, логи, трасування, скріншоти.
Контекст змін: посилання на PR/деплою, міграції БД, фіч-прапори, плани робіт.
Імпакт: порушені когорти/регіони/провайдери, хвилини простою, кредити по SLA.
Комунікації: чернетки/пости на статус-сторінці, відповіді саппорту, внутрішні анонси.
Політики/плейбуки: що повинно було відбутися по процесу, де були відхилення.

6) Методики аналізу (виберіть комбінацію)

5 Why: швидке розкриття причинного ланцюжка (ризик - надмірне спрощення).
Діаграма Ісікави (Fishbone): People / Process / Platform / Policy / Partner / Product.
Fault Tree Analysis (FTA): дедукція від події до безлічі причин (AND/OR).
Change Analysis: що змінилося в період інциденту vs стабільний стан.
Causal Graph: граф причинно-наслідкових зв'язків для складних мікросервісів і зовнішніх залежностей.
Human Factors Review: втома, інформаційний шум, неактуальні runbook'і.

7) Структура звіту (шаблон)

1. Резюме (Executive Summary): що, коли, на кого вплинуло, підсумковий статус.
2. Імпакт: SLI/SLO, користувачі, регіони/провайдери, хв. простою, фінансові/регуляторні ефекти.
3. Таймлайн (UTC): ключові події, релізи, рішення IC, комунікації.
4. Спостереження та дані: графіки, логи, трейси, дифи конфігів/схем.
5. Гіпотези та перевірки: прийняті/відкинуті, посилання на експерименти/симуляції.
6. Кореневі причини: системні/процесні/технічні (ясні формулювання).
7. Сприяючі фактори: чому не помітили/не зупинили раніше.
8. Що спрацювало/що не спрацювало: процеси, інструменти, люди.
9. CAPA: коригувальні та попереджувальні заходи з власниками/термінами/метриками успіху.
10. План верифікації: контрольні точки D + 14/D + 30, критерії закриття.
11. Версії для зовнішніх сторін: клієнтська/регуляторна (без чутливих даних).
12. Додатки: артефакти, посилання на тікети/PR, скріншоти дашбордів.

8) CAPA: Як зробити дії робочими

Кожна дія має власника, дедлайн і KPI ефекту (наприклад, зниження change-failure-rate на X%, нульовий повтор 90 днів, зменшення burn-rate в піках).
Розділяйте Corrective (виправити) і Preventive (не допустити) заходи.
Прив'язуйте до policy-as-code: альберти, SLO-гейти, автоскейл/ліміти, GitOps.
CAPA потрапляє в публічний беклог з оглядами на щотижневих операційних зустрічах.

9) Перевірка ефекту і закриття

Контрольні точки: D + 7 (проміжно), D + 14/D + 30 (основні), D + 90 (підсумок).
Верифікація: тести/симуляції (game day), shadow-трафік, спостережуваність (стабільні SLI в зеленій зоні), відсутність рецидивів.
Закриття можливе тільки при виконаних CAPA і підтверджених метриках.

10) Комунікації та комплаєнс

Внутрішні: зрозумілий статус для продуктових/підтримки/менеджменту, SLA апдейтів дотримані.
Зовнішні: статус-сторінка, розсилки клієнтам/партнерам; мова без звинувачень, чіткий план запобігання.
Регуляторика: терміни повідомлень, деперсоналізація прикладів, незмінне зберігання звітів і артефактів.

11) Метрики зрілості процесу

Час публікації звіту: факт vs SLA (наприклад, ≤5 робочих днів).
CAPA completion rate: % дій, закритих вчасно.
Reopen rate: частка інцидентів-повторів за 90 днів.
Частка системних причин vs «людська помилка».
Алерт-гігієна: зниження помилкових пейджів, зростання покритих runbook'ами алертів.
Зміна DORA-метрик: MTTR, change-failure-rate до/після.

12) Чек-листи

Перед розбором

• Визначено власника RCA та склад учасників.
• Зібраний таймлайн і артефакти (логи/графіки/релізи/прапори).
• Оцінено імпакт по когортах/регіону/провайдерам.
• Підготовлені чернетки розділів «Імпакт» і «Таймлайн».
• Релевантні політики/плейбуки зіставлені з фактичними діями.

Під час

• Зафіксовані прийняті/відхилені гіпотези і підстави.
• Визначені кореневі і сприяють причини.
• Сформований CAPA-план з KPI і термінами.
• Узгоджені версії звіту для зовнішніх сторін (при необхідності).

Після

• Звіт опубліковано вчасно, доступ за ролями.
• CAPA занесені в беклог, власники підтверджені.
• Призначені контрольні точки і міні-симуляція для перевірки.
• Оновлені runbook/SOP/алерти/документація.

13) Анти-патерни

«Винна людина X» - без системних причин → повтор.
Звіт без CAPA або без власників/термінів - папір заради паперу.
Немає фактів/артефактів - висновки на відчуттях.
Занадто спільна мова («перевантаження БД») без конкретних змін.
Ігнорування комунікацій та комплаєнсу - репутаційні ризики.
Закриття без перевірки ефектів - рецидиви через тижні.

14) Міні-шаблони

Шапка звіту

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Формулювання кореневої причини (приклад)

CAPA (фрагмент)

Включити canary-маршрутизацію до PSP-A (1%→5%→25%), власник: @payments -tl, до: 2025-11-07, KPI: нульові P1 інциденти при релізах провайдерів 30 днів.
Переналаштувати таймаути/ретраї із загальним часом ≤ SLA 800 мс, власник: @platform -sre, до: 2025-11-05, KPI: p99 <600 мс під навантаженням N.
Додати бізнес-SLI по BIN-когортам, власник: @data -lead, до: 2025-11-10, KPI: детекція деградацій <5 хв.

15) Вбудовування в щоденну практику

Щотижневі RCA-рев'ю: статус CAPA, нові уроки, оновлення процесів.
Каталог пост-мортемів в wiki з тегами (сервіс, SEV, причини) і пошуком.
Симуляції за мотивами інциденту через 2-4 тижні для перевірки заходів.
Включення уроків в онбординг on-call і оновлення навчальних сценаріїв.

16) Підсумок

Пост-інцидентні розбори - це механізм системного поліпшення. Коли факти зібрані, причинність доведена, дії вимірні і перевірені, організація накопичує операційний капітал надійності: падають MTTR і повторні інциденти, зростає передбачуваність релізів і довіра клієнтів.