Управління інцидентами

(Розділ: Технології та Інфраструктура)

Коротке резюме

Управління інцидентами - це повторюваний процес швидкого відновлення користувацької цінності і мінімізації збитку бізнесу. Опора - чіткі ролі (Incident Manager, Tech Lead, Comms), SLO-гейти, ескалації, ChatOps-процеси, підготовлені рунабуки і «безобвинні» пост-інцидентні розбори з вимірними action items.

1) Цілі та принципи

Швидкість і безпека: швидкий діагноз → безпечна стабілізація → стійке відновлення.
Єдиний власник: призначений Incident Manager (IM) приймає процесні рішення.
Комунікації як продукт: передбачувані апдейти для стейкхолдерів і користувачів.
Дані> думки: SLO/метрики/трейси/логи - джерело правди.
Blameless: розбір причин без персональних звинувачень; фокус на системних поліпшеннях.

2) Класифікація інцидентів (Severity/Impact/Urgency)

• SEV1 (критичний): серйозний збиток виручці/TTW/платежам,> 20% користувачів або цілі регіони; SLA порушений/загроза PII.
• SEV2 (високий): часткова деградація ключових потоків (депозит/ставка/запуск ігор), вплив 5-20%.
• SEV3 (середній): помітна деградація вторинних сервісів, обхід є.
• SEV4 (низький): мінор, обмежений ефект, без впливу на SLO/SLA.

Impact: хто торкнуться (все/регіон/тенант/канал). Urgency: швидкість деградації (fast-burn/slow-burn по бюджету помилок).

3) Життєвий цикл інциденту

1. Detect - сигнал з алертів/SLO/синтетики/репортів.
2. Acknowledge - on-call підтверджує прийом, призначає IM.
3. Triage - оцінка SEV/Impact, збір гіпотез, відкриття War-Room.
4. Mitigate - стабілізація (відкат/перемикання маршруту/фічефлаги/масштабування).
5. Communicate - регулярні статус-апдейти (всередині/назовні).
6. Recover - повне відновлення SLO/бізнес-метрик.
7. Close - фіксація хронології, збір артефактів, PIR (RCA + action items).

4) Ролі та відповідальність (RACI-схема)

Incident Manager (IM) - власник процесу, призначає ролі, стежить за часом, приймає процесні рішення (R).
Technical Lead (TL) - веде діагностику/гіпотези/фікси, координує інженерів (A/R).
Communications (Comms) - статус-апдейти, зв'язок з підтримкою/бізнесом/PR, статус-сторінка (R).
Scribe - протокол (таймлайн, прийняті рішення, посилання, артефакти) (R).
Stakeholders - продукт/платежі/ігрові провайдери/безпека (C/I).

Мінімум на SEV1: IM + TL + Comms + Scribe. На SEV2 допускається поєднання ролей.

5) War-Room и ChatOps

Окремі канали: '#incident -warroom- <id>'( робочий),'#incident -status'( тільки апдейти).
Шаблонні команди: `/incident start`, `/status update`, `/call <owner>`, `/rollback`, `/freeze`, `/scale +N`.
Бот підтягує контекст: останні релізи, дашборди, пов'язані алерти, trace exemplars, схеми залежностей.
Правила спілкування: коротко, за фактами, один спікер (TL), IM модерує.

6) Тригери і гейти

SLO-гейти: fast/slow burn, падіння конверсії платежів, TTW p95> порогу, p99 API ↑, черги виплат «горять».
Автодії: stop canary, rollback, включення degrade-режиму (обмеження функцій), включення синтетики високої частоти.
Freeze: всі релізи/міграції стоп до стабілізації і PIR.

7) Типові сценарії (рунабук-патерни)

A) Платежі: зростання таймаутів/відмов у PSP

1. Stop promote і заморожування релізів платіжного контуру.
2. Перемкнути маршрут PSP на резервний, підняти таймаут/ретраї по політиці.
3. Звірка незавершених транзакцій, повтор з ідемпотентними ключами.
4. Комунікація Comms → саппорт: Чи працюєш резерв? ETA.

B) API p99↑ і 5xx після релізу

1. Відкат (blue-green/canary → stable).
2. Перевірити кеш-хіт, глибину черг, гарячі точки БД/провайдерів ігор.
3. Тимчасове масштабування, обмеження важких фіч через feature flags.

C) Провайдер ігор недоступний

1. Перемкнути трафік на доступні студії/ігри, показати банер статусу.
2. Включити синтетичні перевірки кожні 30-60с.
3. Узгодити компенсації/бонуси (по політиці) - внести в PIR.

D) Витік/підозра на PII

1. Ізоляція компонент, ревокація ключів/токенів, збір логів (WORM).
2. Узгодження правової комунікації/регуляторики.
3. Пост-інцидентні дії: секрет-ротація, маскування, доступи.

8) Комунікації (внутрішні/зовнішні)

Частота апдейтів: SEV1 - кожні 15-30 хв, SEV2 - 30-60 хв.

• Що зламано: "Депозити через PSP-X: зростання таймаутів"
• Кого торкнулося: «TR/BR, ~ 18% користувачів потоку».
• Коли почалося: «12:07 EET, SEV1.»
• Що робимо: «Перемикаємо маршрут на PSP-Y, включені ретраї/обмеження ставки».
• Наступний апдейт: «через 20 хвилин».
• Контакт: «IM @duty-im, TL @oncall-pay.»

Публічний статус (сторінка/соцмережі) - скорочений, без PII і зайвих деталей, з ETA і посиланням на подальші оновлення.

9) Збір артефактів та аудит

Таймлайн подій (хвилинна точність), версії сервісів, фіча-прапори, зміни конфігів.
Знімки дашбордів, приблизні траси (trace_id), логи «до/під час/після».
Посилання на тікети, PR, релізи, рунабуки.
Звіт з комунікацій (коли/кому/що).
Все складається в картку інциденту.

10) Закриття та PIR (Post-Incident Review)

• Резюме: що сталося, масштаб, тривалість, SEV.
• Вплив: користувачі/регіони, SLO/SLA, фін. ефект.
• Таймлайн: детально, по хвилинах.
• Root Cause: технічна + організаційна (чому недетектували раніше).
• Detections & Defenses: що допомогло/підвело (алерти, синтетика, фічефлаги).
• Action Items: конкретні завдання, власники, терміни (і як перевіримо ефект).
• Lessons Learned: що змінюємо в процесі/архітектурі/спостережуваності.

Правила: без звинувачень, максимум фактів, обов'язковий follow-up через 2-4 тижні перевірки виконаних пунктів.

11) Метрики надійності процесу

MTTD (Mean Time To Detect) - середній час виявлення.
MTTA (… Acknowledge) - до підтвердження on-call.
MTTR (… Restore) - до відновлення SLO.
Change Failure Rate -% релізів, що призвели до інцидентів.
Incident Rate по SEV, розподіл по доменах (Payments/Games/Infra).
Alert Quality: частка галасливих/помилкових, час до дії після алерта.
Комм-SLA: дотримання періодичності статус-апдейтів.

12) Інтеграції з SLO і релізами

Гейти в CD: промоушен канарки тільки при зелених SLO-проксі (availability, p95, conv, TTW).
Freeze-процедури: при fast-burn/SEV1 - стоп релізів до PIR.
Авто-анотації в графах: релізи/прапори/міграції видно на дашбордах.

13) Регуляторика та комплаєнс

PII: маскування/псевдонімізація в логах/трейсах, WORM-сховища аудиту, контроль доступу.
Регіональність: не виносити дані користувача за межі дозволених юрисдикцій.
Звітність: формалізовані листи/повідомлення регуляторам - шаблони і процес ескалації.

14) Навчання та готовність (Game-Day)

Щоквартальні навчання: «падіння PSP», «провайдер ігор недоступний», «p99 сплеск», «витік ключа».
Таймери на MTTA/MTTR, ретро за вправами.
Оновлення рунабуків і контактів, перевірка ChatOps-команд.

15) Чек-лист готовності (до інциденту)

1. Узгоджені SEV-правила і матриця ескалацій.
2. Призначені on-call ротації, IM/TL/Comms/Scribe.
3. Рунабуки за ключовими сценаріями (платежі, ігри, БД, кеші, черги).
4. SLO-карта і burn-rate алерти, статус-сторінка.
5. ChatOps-бот: команди, автоконтекст, шаблони статусів.
6. Шаблони PIR і картки інциденту.
7. Регулярні game-day і ревізії контактів/прав.
8. Політика freeze і «червона кнопка» (rollback/kill-switch).

16) Антипатерни

Немає єдиного IM, «натовп лідирує» → хаос і затримки.
Відсутність SLO-гейтів → пізня детекція, галасливі алерти.
Реліз під час інциденту без freeze → каскадні збої.
Логів і трейсів недостатньо, немає артефактів → слабкий PIR.
Обвинувальна культура → приховані помилки, страх ескалації.
Комунікації «за натхненням» → втрата довіри бізнесу/користувачів.

17) Шаблони (копіюйте у вашу wiki)

A) Картка інциденту (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Статус-апдейт (внутрішній)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (шапка)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Підсумки

Сильне управління інцидентами - це структура + дисципліна: заздалегідь обумовлені ролі, SLO-гейти, відпрацьовані рунабуки, прозорі комунікації і «безобвинний» PIR. Такий контур скорочує MTTA/MTTR, знижує вартість простоїв, зміцнює довіру користувачів і дозволяє релізувати сміливіше - але безпечно.