Операції та Управління → Зниження наслідків інцидентів

Зниження наслідків інцидентів

1) Мета і принципи

Мета: не допустити ескалації інциденту в відмову сервісу і звести збиток до мінімуму: за часом простою, грошам, репутації та регуляторним ризикам.

• Containment first: зупинити поширення збою (blast radius ↓).
• Graceful degradation: краще «працює гірше», ніж «не працює зовсім».
• Decouple & fallback: незалежні компоненти та безпечні альтернативи.
• Decision speed > perfect info: швидкі оборотні дії (feature flag, route switch).
• Communicate early: одне джерело правди, чіткі статуси і ETA за стадіями.

2) Модель інциденту і таксономія наслідків

Вплив: користувачі (регіон, сегмент), гроші (GGR/NGR, процесинг), комплаєнс (KYC/AML), партнери/провайдери.
Типи: деградація продуктивності, часткова відмова залежності (PSP, KYC, провайдер ігор), регресія релізу, інцидент даних (затримка вітрин/ETL), DDoS/спайк навантаження.
Рівні (P1-P4): від критичного простою core-флоу до локального дефекту.

3) Патерни зниження наслідків (технічні)

3. 1 Локалізація та обмеження blast radius

Ізоляція по шартах/регіонах: відключаємо проблемний шард/регіон, інші продовжують роботу.
Circuit Breaker: швидка відмова від залежностей при помилках/таймаутах ⇒ захист воркерів.
Bulkhead (перегородки): окремі пули з'єднань/черги для критичних шляхів.
Traffic Shadowing/Canary: прогін частини трафіку через нову версію до повного перемикання.

3. 2 Керована деградація (graceful)

Read-only режим: тимчасове блокування мутацій (наприклад, ставки/депозити) при збереженні навігації та історії.
Функціональні відсічки: відключення другорядних віджетів/лендскейпів, важких рекомендацій, «гарячих» пошуків.
Кеш-фолбек: службові відповіді зі stale-кешу (stale-while-revalidate), спрощені моделі.
Спрощені ліміти: зниження розміру бетча/сторінки, подовження TTL, відключення дорогих фільтрів.

3. 3 Управління навантаженням

Shed/Throttle: відкидати надлишкові запити «справедливо»: по IP/ключу/ендпойнту, з пріоритетом core-операцій.
Backpressure: обмеження продюсерів по lag споживачів; динаміка retry з джиттером.
Queue shaping: виділені черги під P1-флоу (виплати, авторизація) і фонову аналітику.

3. 4 Швидкі перемикачі

Feature Flags & Kill-switch: миттєве відключення проблемної фічі без релізу.
Traffic Routing: перемикання провайдера (PSP A→B), обхід збійного датацентру, переклад на «теплу» репліку.
Toggle конфігов: таймаути, ретраї, ліміти QPS - через конфіг-центр з аудитом.

3. 5 Дані та звітність

Відкладені мутації: запис в outbox/лог з подальшою доставкою.
Тимчасова денормалізація: зменшення навантаження на БД читанням з матеріалізованих вітрин.
Degrade BI: тимчасово показувати last-good-snapshot з позначкою "дані на 12:00 UTC».

4) Доменні приклади (iGaming)

Провал KYC-провайдера: включаємо альтернативного провайдера; для «низькоризикових» лімітів - тимчасова верифікація за спрощеним сценарієм зі зниженими лімітами рахунків.
Висока латентність PSP: тимчасовий пріоритет на локальні гаманці, зниження лімітів виплат, постановка частини виплат в чергу «T + Δ».
Збій у ігрового провайдера: приховуємо конкретні тайтли/провайдера, зберігаємо лобі та альтернативи, відображаємо банер «Ведуться роботи, спробуйте X/Y».

5) Організація та ролі (ICS - Incident Command System)

IC (Incident Commander): єдина координація, пріоритизація дій.
Ops Lead / SRE: containment, рутинги, фіча-прапори, інфраструктура.
Comms Lead: оновлення статусу, сторінки статусу, внутрішній чат/пошта.
Subject Matter Owner: власник порушеної підсистеми (PSP, KYC, провайдер ігор).
Liaison до бізнесу: продукт, підтримка, фінанси, комплаєнс.
Scribe: таймлайн, рішення, артефакти для пост-мортема.

Правило: не більше 7 ± 2 осіб в активному «war-room», решта - «за запитом».

6) Комунікації

Канали: статус-сторінка, внутрішній #incident -канал, PagerDuty/телеміст, шаблони апдейтів.
Темп: P1 - кожні 15-20 хв; P2 - 30-60 хв.
Шаблон апдейту: що зламалося → кого торкнулося → що вже зроблено → наступний крок → орієнтир за часом наступного апдейта.
Підтримка клієнтів: заздалегідь підготовлені макроси і FAQ для L1/L2, маркери «часткова деградація», компенсаційна політика.

7) Метрики успіху і тригери

MTTD/MTTA/MTTR, Час containment, SLO Burn Rate (1h/6h/24h вікна).
Revenue at risk: оцінка недоотриманого GGR/NGR за сегментами.
Blast radius %: частка користувачів/регіонів/функцій під впливом.
Comms SLA: своєчасність апдейтів статусу.
False-positive/false-negative алертів, вторинні інциденти.

• p95 ключового API> поріг 5 хв поспіль → включити кеш-фоллбек і тротлінг.
• Consumer lag> 2 хв → заморозити продьюсерів non-critical, підняти воркери.
• PSP success <97% 10 хв → перевести частку трафіку на резервного PSP.

8) Плейбуки (стислі)

8. 1 «Латентність ↑ у/api/deposit»

1. Перевірити error% і PSP-зовнішні таймаути → включити короткі таймаути і джитерні ретраї.
2. Увімкнути кеш лімітів/довідників, відключити важкі перевірки «за місцем».
3. Частково перевести трафік на резервний PSP.
4. Тимчасово знизити ліміти виплат/депозитів для зниження ризику.
5. Пост-фікс: індекс/денорм, посилити асинхронність.

8. 2 «KYC зависає»

1. Перемкнути на альтернативного провайдера, включити «спрощений KYC» з обмеженнями.
2. Кешувати статуси KYC для вже пройдених.
3. Комунікація: банер в профілі, ETA.

8. 3 «ETL/BI відстає»

1. Позначити панелі «stale» + timestamp.
2. Призупинити важкі перебудови, включити інкрементальні.
3. Паралелізм джобів ↑, пріоритет на вітрини з операційними KPI.

9) Дизайн-рішення до інциденту (проактивно)

Таблиця фіч-прапорів: атомарні вимикачі за ендпойнтами/провайдерами/віджетами.
Політики троттлінгу/шеддингу: заздалегідь узгоджені рівні «бронза/срібло/золото» за пріоритетами.
Тести деградації: регулярні «fire-drills», game-days, хаос-експерименти (додавання затримок/помилок).
Квоти зовнішніх залежностей: ліміти, бюджет помилок, backoff стратегії.
Runbook’и: короткі покрокові інструкції та команди/конфіги з прикладами.

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

Fail-safe: при деградації - блокувати операції з ризиком порушень, а не «посилювати ретраї».
PII і фіндані: при ручних обходах - строгий аудит, мінімальні привілеї, токенізація.
Сліди: повний журнал дій IC/операторів, зміна прапорів/конфігів, експорт таймлайну.

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

«Чекаємо, поки стане ясно» - втрата золотого часу containment.
«Викручуємо ретраї до перемоги» - сніговий ком і шторм у залежностей.
Глобальні фіч-прапори без сегментації - гасіть свічку, не електрику в місті.
Тиша «щоб не лякати» - зростання тікетів, втрата довіри.
Тендітні ручні процедури без аудиту - ризик комплаєнсу.

12) Чек-листи

Перед релізом критичних змін

• Канарський маршрут + швидкий відкат (feature flag).
• SLO guardrails і алерти по p95/error%.
• Навантаження на залежні сервіси змодельовано.
• Комунікаційний план і власники.

Під час інциденту

• Визначено IC і канали зв'язку.
• Застосований containment (ізоляція/прапори/роути).
• Включена керована деградація.
• Статус-сторінка оновлена, підтримка повідомлена.

Після інциденту

• Пост-мортем ≤ 5 робочих днів, без «пошуку винних».
• Екшени з власниками і дедлайнами.
• Тест на повторюваність: сценарій відтворюється і покритий алертами/тестами.
• Оновлені плейбуки та тренінги.

13) Міні-артефакти (шаблони)

• Що сталося → Вплив → Коренева причина → Що спрацювало/не спрацювало → Довгострокові фікси → Action items (власники/терміни).

14) Підсумок

Зниження наслідків інцидентів - це дисципліна швидких і оборотних рішень: локалізувати, деградувати керовано, перерозподілити навантаження, комунікувати прозоро і закріпити поліпшення. Ви виграєте хвилиночну «тактичну стабільність» сьогодні - і перетворюєте її в стратегічну стійкість завтра.