Реакція на інциденти та аварії

(Розділ: Операції та Управління)

1) Визначення та цілі

Інцидент - подія, що порушує SLO/безпеку/комплаєнс або створює ризик для клієнтів, грошей, даних, репутації.
Цілі реакції: швидко відновити сервіс, мінімізувати збитки, зафіксувати докази, прозоро комунікувати і не допустити повторення.

Ключові принципи

Safety first: захист людей/даних/грошей важливіше функцій.
One throat to choke: єдиний Incident Commander (IC) приймає рішення.
Actionable now: кожна гіпотеза супроводжується перевіркою/дією.
Evidence matters: все логується, артефакти підписуються, таймлайн - детальний.

2) Класифікація (severity & пріоритет)

Тригер: порушення SLO, правило алерта, ручний репорт, юридичний інцидент (DPO/CCO).

3) Ролі та відповідальність (RACI)

Incident Commander (A) - лідер інциденту, постановка завдань, прийняття рішень, зміни IC при довгих інцидентах.
Tech Lead (R) - технічна діагностика/фікси, координація SRE/інжинірингу.
Comms Lead (R) - пише статус-оновлення (всередині/зовні), власник статус-сторінки.
Scribe (R) - протокол, таймлайн, збір артефактів.
Security/Legal (C/A для сек'юріті-випадків) - оцінка ризиків, обов'язкові повідомлення.
Customer Support (C) - шаблони відповідей, маршрутизація тікетів.
Partner Liaison (C) - комунікація з провайдерами/тенантами.
Management (I) - інформування, бізнес-рішення (кредити/компенсації).

4) Перші 15 хвилин (шаблон)

1. Призначити IC і відкрити картку інциденту (чат-канал, відеоміст, Jira/Tracker).
2. Присвоїти SEV і зафіксувати SLO-симптом (що саме порушено).

• включити runbooks/руни: circuit-breakers, тротлінг, перемикання маршруту, пауза промо;
• при компрометації - kill-switch чутливих функцій.
• 4. Команди: Tech Lead - діагностика; Comms - «технічний холд» (через 10-15 хв - перше оновлення).
• 5. Визначити гіпотези (три максимум), призначити власників, поставити таймери на перевірку (5-10 хв).
• 6. Збирати артефакти: снапшоти метрик, конфіги, хеші релізів, логи з'trace _ id', квитанції.

5) Перша година (шаблон)

Комунікація v1 (15-20 хв): факт, охоплення, симптоми, що робимо, наступне оновлення. Без спекуляцій.
Межі інциденту: які регіони/тенанти/канали/версії порушені.
Контроль збитку: тимчасові капи/обмеження, відключення «галасливих» інтеграцій, включення деградаційного режиму.
Форензика: заморозити ротації логів, захистити артефакти (WORM/підписи).
Дорожня карта відновлення: T + 30/T + 60 з чек-поінтами.

6) Комунікації та статус-сторінка

Внутрішні інтервали: P1 - кожні 15 хв, P2 - 30-60 хв.
Зовнішні: статус-сторінка/тенанти/партнери по SLA.

• Що видно: "з X:YY UTC зростання відмов checkout в регіоні EU (p95> 250 мс) "
• Кого зачіпає: «оператори A/B/C, ~ 40% трафіку»
• Що робимо: "включили альтернативний маршрут, троттлінг промо; працюємо з провайдером PSP-1"
• Дані/дедлайни: «наступне оновлення через 15 хв»
• Компенсації: «застосуємо кредит-ноти згідно SLA після закриття інциденту»

7) Плейбуки (референси для iGaming/фінтех)

PriceMismatch (вітрина ≠ checkout): форс-інвалідація кешу, звірка'fx _ version/tax _ rule _ version', заморожування динамічних промо, компенсація розбіжностей по політиці.
WebhookLag (партнери/афіліати): масштабування воркерів, збільшення batch, пріоритет ретраїв, тимчасовий кап на нові підписки.
Payments Outage/PSP-деградація: переключення на резервного PSP, зниження таймаутів клієнтів, ручний кліринг черги, «сірі» транзакції в карантин.
RTP Drift: пауза бонусів, перевірка таблиць виплат/версій, розширення вікна спостереження, відкат профілю RTP.
Fraud Spike: посилити velocity/ліміти, включити додаткову KYC-перевірку, ізоляція підозрілих когорт, ручною рев'ю високих виграшів.
Data/PII Exposure: ізоляція систем, повідомлення DPO/Legal, інвентаризація порушених записів, регуляторні повідомлення по термінах.

8) Інструменти та руни (auto-actions)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Гвард-рейли: захист від «сідлання» - відкати обмежені, журнали підписані, кожна дія ↔ IC/Scribe.
Доказовість: DSSE-підписи, хеші снапшотів, Merkle-зрізи логів.

9) Завершення інциденту

Критерії: SLO відновлені, черга погашена, дані/гроші звірені, ризики закриті, комунікації відправлені.
Ритуал закриття: фінальне оновлення статусу, зафіксований таймлайн, список впливів, попередні гіпотези причин, призначена дата пост-мортема.

10) Пост-мортем (без звинувачень)

Термін: P1 - протягом 3 робочих днів; P2 - 5 робочих днів.
Зміст: факти/таймлайн, першопричини (5 Whys/FRAM), вплив (SLO, фінанси, клієнти), що спрацювало/ні, action items (owner, термін, вимірний ефект).
Перевірка ефективності: через 30-60 днів - рев'ю виконання і метрик (повторюваність, MTTR, шум алертів).

11) Метрики та SLO інцидент-менеджменту

MTTD/MTTA/MTTR, Change Failure Rate, Time to Comms v1,% авто-дозволених (рунами).
Alert Noise: частка неактуальних сигналів, pages per on-call shift.
Repeat Incidents: частка повторів за 90 днів.
Post-mortem SLA: частка проведених/закритих у строк.
SLO реакції: P1 - перша комунікація ≤ 15 хв; MTTR ≤ 60 хв; повнота артефактів = 100%.

12) Право/комплаєнс/приватність

Юридичні повідомлення: терміни локальних регуляторів щодо витоків/інцидентів.
PII-мінімізація: доступ до первинки тільки через затверджені джоби; токенізація/маскування.
Зберігання артефактів: WORM-журнали, період зберігання по юрисдикціях; контроль доступу (RBAC/ABAC, JIT).
Контрагенти: договірні SLA, процес ескалації, квитанції розглядів.

13) Організація чергувань та ескалацій

24×7 on-call: ротації за ролями (SRE, App, Data, Security, Payments).
Матриця ескалацій: хто за регіони/продукти/провайдерів; дублювання контактів (чат/голос/SMS).
Навчання (GameDays): симуляції - падіння PSP, лавина ретраїв, розсинхрон цін, компрометація ключа, відмова регіону.

14) Дашборди інцидентів

Спека (зараз): статус SLO, p95/p99, карта регіонів/тенантів, черга завдань, артефакти зібрані/ні.
Історія: тренди за типами інцидентів, ефективність рун, повторюваність причин.
Контроль якості: повнота таймлайну, «coverage» пост-мортемів, SLA комунікацій.

15) Чек-лист впровадження

• Затвердити шкалу SEV і тригери SLO.
• Призначити ролі (IC/Tech/Comms/Scribe/Sec/Legal) і ротації 24 × 7.
• Запустити єдиний шаблон картки інциденту і статус-сторінку.
• Описати плейбуки (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Реалізувати руни з аудитом і «червоною кнопкою».
• Включити форензик-політику: WORM/підписи/збір артефактів.
• Регламент комунікацій (внутр ./внешн.) , SLA оновлень.
• Пост-мортем процес і шаблони; KPI виконання action items.
• GameDays щомісяця; квартальний огляд трендів інцидентів.
• Метрики IR на дашборді (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

Чому «IC один»?
Єдина точка прийняття рішень прибирає хаос і прискорює реакцію.

Коли оголошувати публічно?
Як тільки є підтверджений факт і план стабілізації. Оцініть регуляторні терміни.

Що важливіше - фікс чи звіт?
Спочатку - відновлення і безпека. Паралельно - збір артефактів. Звіт - після стабілізації.

Чи можна автоматизувати все?
Ні, але руни закривають «часті і прості» кроки. Решта - через чіткі плейбуки і тренування.

Резюме: Сильний Incident Response - це не тільки PagerDuty і чат-канал. Це дисципліна ролей, швидкі перші 15 хвилин, керовані руни, прозорі комунікації, форензика з доказовістю і обов'язковий пост-мортем. З таким контуром ви знижуєте MTTR, захищаєте гроші і дані, і підвищуєте довіру клієнтів і регуляторів.