Симуляції інцидентів

1) Навіщо проводити симуляції

• знижують MTTD/MTTA/MTTR, підвищують впевненість у відкатах і фейловерах;
• виявляють проломи в процесах (ескалація, комунікації) і архітектурні слабкості;
• служать входом в RCA→CAPA і покращують документацію (runbook/SOP);
• підтверджують готовність до вимог SLA/регуляторів/аудиту.

2) Формати симуляцій

Tabletop (настільна) - розмовний сценарій на дошці/в чаті: дешево, швидко, відмінно для відпрацювання ролей і комунікацій.
Game Day (навчання в стейджі/проді з обмеженнями) - практичні кроки по плейбуках; в проде - тільки безпечні, оборотні дії з чіткими гейтами.
Chaos Engineering - керовані збої (відключення залежностей/мережі/вузлів) для перевірки стійкості і SLO-гейтів.
DR-навчання (Disaster Recovery) - відмова AZ/регіону, відновлення з бекапів, перемикання провайдерів.
Comms-drill - суто комунікації: статус-сторінка, шаблони повідомлень, PR/Legal.

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

Incident Commander (IC) - приймає рішення, веде план, деескалацію.
Tech Lead (TL) - діагностика, технічні «інжекти» і гіпотези.
Comms Lead (CL) - внутрішні/зовнішні апдейти, статус-сторінка.
Scribe - протокол (таймлайн, дії, рішення, артефакти).
Observers/Assessors - фіксують метрики і відповідність процедурам.
Red Team (за бажанням) - вводить непередбачені «інжекти».

Ролі збігаються з бойовими інцидентами - перенесення навичок максимальне.

4) Метрики успіху симуляцій

MTTD/MTTA/MTTR по синтетичному інциденту.
Comm SLA: своєчасність і якість апдейтів.
SLO-guardrails: коректна реакція на burn-rate, кворум зовнішніх проб.
Runbook fidelity: % кроків виконано за документом, без імпровізації.
Escalation latency: швидкість підключення потрібної ролі/провайдера.
Checklists pass-rate: дотримання «готовий/прийняв/закрив».
Noise & Fatigue: зайві алерти, перевантаження on-call.
CAPA completion: частка виконаних дій після симуляції.

5) Підготовка: що потрібно до старту

Мета та гіпотези: що перевіряємо (процеси, архітектуру, людей).
Сценарій та «інжекти»: послідовність симптомів/подій з таймінгами.
Обмеження безпеки: заборона на незворотні зміни; точки скасування.
Дані та стенди: синтетичний трафік, фіч-прапори деградації, безпечні ключі.
Документи: посилання на runbook/SOP, ескалацію, контакт-лист провайдерів.
Спостережуваність: заздалегідь позначені дашборди/алерти, test-канарок.
Логістика: час/тривалість, учасники, war-room канал, запис.

6) Проведення симуляції: етапи

1. Brief (5-10 хв): IC нагадує цілі, ролі, правила безпеки, критерії завершення.
2. T0 - Інжект симптомів: алерт (и), падіння бізнес-SLI, зовнішній статус провайдера.
3. Тріаж і ескалація: присвоєння SEV, freeze релізів, підключення потрібних ролей.
4. Діагностика: гіпотези, перевірка DNS/TLS/CDN/БД/кеш/шини, анотації релізів.
5. Мітигуючі дії: otkat/kanareyka↓, фіча-прапори деградації, failover провайдера, ліміти/ретраї.
6. Комунікації: регулярні апдейти (формат: Impakt→Diagnostika→Deystviya→Sled. апдейт).
7. Відновлення та верифікація: зовнішня синтетика + SLI в зеленій зоні N інтервалів.
8. Debrief (AAR): 15-30 хв - факти, висновки, CAPA.

7) Приклади сценаріїв (каталог)

Падіння успіху платежів: провайдер A деградує в одній країні; очікувані дії - перерозподіл трафіку, включення спрощеного UX, комунікація.
DNS-збій: помилка запису/TTL, частина користувачів не резолвить домен; очікувані кроки - фікси/фолбек, очищення CDN, статус-апдейти.
Прострочений TLS-сертифікат: рукостискання ламається для старих клієнтів; очікується аварійне продовження і перевірка ланцюжка.
Kafka lag: зростання затримки в подіях KYC/AML; очікування - масштабувати консьюмерів, обмежити продюсерів.
БД p99 ↑ і зростання 5xx: вузькі індекси, ліміт конектів; очікування - фіча-прапори, ліміти, hotfix/відкат.
Регіональна відмова: відключення AZ/PoP; очікування - GSLB/Anycast перемикання, перевірка даних і SLO.
Комунікаційний Drill: все «зелене», але перевіряємо шаблони, інтервали і узгодження з Legal/PR.

8) Шаблон «інжекту» (картка)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Безпека та комплаєнс

Прод-симуляції - тільки оборотні: фіч-прапори, перемикання трафіку малими частками, репліки для читання, «shadow traffic».
Контроль доступу/аудит: всі дії через ChatOps/пайплайн; журнали в незмінному сховищі.
PII/секрети - не використовуються в навчальних артефактах; дані деперсоналізовані.
Регуляторика: якщо симуляція зачіпає клієнтські комунікації - позначка «вчення» в приватних каналах; публічні пости не імітуються.

10) Оцінка та AAR → RCA → CAPA

AAR (After Action Review) - відразу після навчань: що очікували/побачили, що спрацювало/ні.
RCA - для істотних провалів (наприклад, не спрацювала ескалація) за шаблоном RCA.
CAPA - список дій з власниками/термінами/метриками ефекту (зміни в плейбуках, алертах, архітектурі).
Контрольні точки - D + 14/D + 30: перевірка виконання, повторний міні-дрил по вразливих місцях.

11) Документація та артефакти

План симуляції: цілі, сценарій, інжекти, учасники, вікна, критерії успіху.
Таймлайн (UTC): T0...Tn, рішення IC, технічні кроки, апдейти.
Знімки дашбордів/логів, витримки алертів і статусів.
Підсумковий звіт: метрики, розбіжності з плейбуками, CAPA.
Оновлення документації: правки runbook/SOP/контактів, посилання на нові дашборди.

12) Частота і охоплення

Tabletop: 2-4 рази на місяць (за ключовими потоками і ролями).
Game Days в стейджі: 1-2 рази на місяць.
Chaos-кейси (прод-лайт): щоквартально, строго за гейтами.
DR-навчання: 1-2 рази на рік з реальним перемиканням.
Comms-drill: щомісяця для тренування шаблонів і SLA апдейтів.

13) Чек-листи

Перед симуляцією

• Сценарій, «інжекти», критерії успіху, вікна безпеки.
• Узгоджені ролі, канали, статус шаблонів.
• Доступність стендів/прапорів/дашбордів перевірена.
• План скасування і оборотності задокументований.
• Ризики та вплив на SLO/клієнтів оцінені.

Під час

• SEV присвоєно, freeze релізів (якщо потрібно).
• Комунікації за розкладом, формат витриманий.
• Всі дії через інструменти з аудитом.
• Scribe веде протокол, збирає артефакти.
• Безпека: заборони/обмеження дотримуються.

Після

• AAR проведено, звіт збережено.
• RCA (при провалах) ініційований.
• CAPA оформлені з власниками/термінами.
• Оновлені runbook/SOP/контакти.
• Заплановано ретест вразливих місць.

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

«Імпровізація замість плану» - немає сценарію і критеріїв успіху.
Ризики без гейтів і плану скасування - навчання перетворюються на інцидент.
Відпрацювання тільки техніки без комунікацій та ескалації.
Відсутність AAR/RCA - команда не вчиться.
Прод-хаос без спостережуваності і SLO-гардрейлів.
Непрозорі права: таємні ручні правки в проді.

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

Повістка Game Day (60-90 хв)

1. Brief (5 хв) → Цілі, ролі, безпека.
2. Сценарій T0 (5 хв) → Подача симптомів.
3. Тріаж/ескалація (10 хв).
4. Діагностика + дії (30-45 хв) - 1-2 «інжекту».
5. Відновлення та верифікація (10 хв).
6. AAR (15 хв) - висновки, CAPA.

Шаблон AAR (короткий)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Підсумок

Симуляції інцидентів - це «тренажер» для людей, процесів і архітектури. Регулярні, безпечні і вимірні вчення перетворюють кризи в рутину: команда швидше реагує, плейбуки реально працюють, архітектура стійкіша, а регулятор і клієнти бачать зрілість операційної функції. Головне - чіткі цілі, безпечні гейти, хороші метрики і обов'язкове AAR→RCA→CAPA.