Root Cause Analysis

1) Що таке RCA і навіщо воно потрібно

Root Cause Analysis - структурований процес виявлення кореневих причин інциденту з метою виключити повторення. У центрі - факти, причинно-наслідкові зв'язки і системні поліпшення (процеси, архітектура, тести), а не пошук винних.
Цілі: запобігти рецидиву, знизити MTTR/частоту інцидентів, поліпшити SLO, зміцнити довіру регуляторів і партнерів.

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

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

3) Вхідні артефакти та підготовка

Таймлайн по UTC: T0 виявлення → T + дії → T + відновлення.
Дані спостережуваності: логи, метрики (в т. ч. по когортах), трейси, синтетика, статус-сторінка.
Зміни: релізи, фіч-прапори, конфіги, провайдерські події.
Оточення: версії, хеш артефактів, SBOM, інфраструктурні мітки.
База інциденту: опис імпакту (SLO/SLA, клієнти, оборот), прийняті рішення, workaround'и.
Chain of custody: хто і коли збирав/змінював докази (важливо для комплаєнсу).

4) Методики RCA: коли яку

1. 5 Why - швидко з'ясувати причинний ланцюжок для вузьких проблем. Ризик: «згорнути» складну систему до лінійки.
2. Діаграма Ісікави (Fishbone) - розкласти фактори за категоріями: People/Process/Platform/Policy/Partner/Product. Корисно на початку.
3. Fault Tree Analysis (FTA) - дедукція від події до наборів причин (AND/OR). Для інфраструктури та відмов «по дереву».
4. Causal Graph/Event Chain - граф залежностей з імовірностями та вагою вкладу. Хороший для мікросервісів і зовнішніх провайдерів.
5. FMEA (Failure Modes & Effects Analysis) - профілактика: режими відмов, тяжкість (S), частота (O), виявлюваність (D), RPN = S × O × D.
6. Change Analysis - порівняння «як було/як стало» (диф конфігів, schema, версій).
7. Human Factors Review - контекст рішень людей (алертова втома, погані плейбуки, перевантаження).

Рекомендована зв'язка: Fishbone → Change Analysis → Causal Graph/FTA → 5 Why за ключовими гілками.

5) Покроковий процес RCA

1. Ініціювати: призначити власника RCA, визначити термін випуску звіту (наприклад, 5 робочих днів), зібрати команду (IC, TL, Scribe, представники провайдерів).
2. Зібрати факти: таймлайн, графіки, релізи, логи, артефакти; зафіксувати версії і контроль сум.
3. Картувати вплив: які SLI/SLO постраждали, які когорти (країни, провайдери, VIP).
4. Побудувати гіпотези: первинні, альтернативні; зазначити які перевіряються зараз.
5. Перевірити гіпотези: відтворення на стейджі/симуляції/канарці, аналіз трейсів, fault injection.
6. Визначити кореневі і сприяючі причини: технологічні, процесні, організаційні.
7. Сформувати CAPA: коригувальні (виправити) та попереджувальні (не допустити); метрики успіху і терміни.
8. Узгодити та опублікувати звіт: внутрішня база знань +, при необхідності, зовнішня версія для клієнтів/регулятора.
9. Верифікувати ефект: контрольні точки через 14/30 днів; закриття дій.

6) Що вважається «кореневою причиною»

• слабкі тести/фіч-прапори, відсутні ліміти/алерти, двозначна документація, некоректні дефолти, тендітна архітектура.
• Часто це комбінація факторів (конфігурація × відсутність гейта × навантаження × провайдер).

7) CAPA: коригувальні та попереджувальні заходи

• фікс коду/конфігів, відкат патерну, зміна лімітів/таймаутів, додавання індексів, репліка/шардинг, перероздача трафіку, оновлення сертифікатів.

• тести (контрактні, хаос-кейси), альберти (burn rate, кворум синтетики), політика релізів (canary/blue-green), GitOps на конфіги, навчання/чек-листи, дублювання провайдера, DR-навчання.

Кожній дії: власник, дедлайн, очікуваний ефект, метрика перевірки (наприклад, зниження change-failure-rate на X%, відсутність повторів 90 днів).

8) Верифікація гіпотез і ефектів

Експерименти: fault injection/chaos, shadow-трафік, A/B конфігів, навантажувальні з реальними профілями.
Метрики успіху: відновлення SLO, стабілізація p95/p99, відсутність сплесків error-rate, скорочення MTTR, тренд з burn-rate і zero-reopen на 30 днів.
Контрольні точки: D + 7, D + 30, D + 90 - перегляд виконання CAPA і впливу.

9) Шаблон звіту RCA (внутрішній)

1. Коротке резюме: що сталося, коли, кого торкнулося.
2. Імпакт: SLI/SLO, користувачі, регіони, оборот/штрафи (якщо є).
3. Таймлайн (UTC): основні події (алерти, рішення, релізи, фікси).
4. Спостереження та дані: графіки, логи, трасування, конфіги (диффи), провайдерські статуси.
5. Гіпотези та перевірки: прийняті/відкинуті, посилання на експерименти.
6. Кореневі причини: технологічні, процесні, організаційні.
7. Сприяючі фактори: «чому не помітили/не зупинили».
8. CAPA-план: таблиця дій з власниками/термінами/метриками.
9. Ризики та залишкові вразливості: що ще потрібно моніторити/тестувати.
10. Додатки: артефакти, посилання, графіки (перелік).

10) Приклад (короткий, узагальнений)

Подія: падіння успіху платежів на 35% в 19:05–19:26 (SEV-1).
Імпакт: e2e-SLO порушено 21 хв, порушено 3 країни, повернення/компенсації.
Причина 1 (тех): нова версія валідатора карти збільшила латентність до 1. 2 з → таймаути до провайдера.
Причина 2 (проц): був відсутній canary для провайдера «A», реліз пройшов відразу на 100%.
Причина 3 (орг): алерт-поріг по бізнес-SLI не охоплював конкретний BIN-діапазон (VIP-когорта).
CAPA: повернути стару версію валідатора; ввести canary 1/5/25%; додати бізнес-SLI по BIN-когортам; домовитися про failover 30% на провайдера «B»; хаос-кейс «slow upstream».

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

Виконання CAPA в термін (% закритих в 30 днів).
Reopen rate (інциденти, повторно відкриті в 90 днів).
Change-failure-rate до/після.
Частка інцидентів, де знайдені системні причини (а не тільки «людська помилка»).
Покриття тестами нових сценаріїв з RCA.
Час випуску звіту (SLA публікації).

12) Особливості регульованих доменів (фінтех/iGaming тощо)

Звітність назовні: клієнтські/регуляторні версії звіту без чутливих деталей, але з планом запобігання повторів.
Аудит-лог і незмінюваність: зберігання артефактів, підписані звіти, прив'язка до тікетів, CMDB, релізних логів.
Дані користувачів: деперсоналізація/маскування в прикладах логів.
Терміни повідомлень: прив'язати до контрактів і норм (наприклад, N годин на первинне повідомлення).

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

«Винен Вася» - зупинка на людському факторі без системних причин.
Відсутність перевірок гіпотез - висновки щодо інтуїції.
Занадто загальний RCA («сервіс був перевантажений») - без конкретних змін.
Немає CAPA чи ні власників/термінів - звіт заради звіту.
Приховування інформації - втрата довіри, неможливість навчання організації.
Перевантаження метриками без зв'язки з SLO/бізнес-SLI.

14) Інструменти та практики

Сховище RCA (wiki/knowledge base) з метаданими: сервіс, SEV, причини, CAPA, статус.
Шаблони та боти: генерація каркаса звіту з інциденту (таймлайн, графіки, релізи).
Граф причинності: побудова подієво-причинної карти (наприклад, на базі логів/трейсів).
Chaos-каталог: сценарії для відтворення минулих інцидентів у стейджі.
Dashboards «після RCA»: окремі віджети, що підтверджують ефект CAPA.

15) Чек-лист «готовий до публікації»

• Таймлайн і артефакти повні і перевірені.
• Кореневі причини визначені і доведені тестами/експериментами.
• Розділені кореневі і сприяють причини.
• CAPA містить власників, терміни, вимірювані метрики ефекту.
• Є план верифікації через 14/30 днів.
• Версія для зовнішніх стейкхолдерів підготовлена (якщо потрібно).
• Звіт пройшов тих/проц-рев'ю.

16) Підсумок

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