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 стабильнее, риск рецидивов ниже, а доверие пользователей и регуляторов — выше.