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

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

Ескалація інцидентів - це керований процес швидкого залучення правильних ролей і ресурсів для мінімізації впливу на користувачів і бізнес-метрики.

• Швидкість важливіша за ідеальність. Краще задекларувати інцидент раніше і деескалувати, ніж запізнитися.
• Єдине командування. Один відповідальний за рішення - Incident Commander (IC).
• Прозорість. Чіткі статуси і канали комунікації для внутрішніх і зовнішніх стейкхолдерів.
• Документованість. Всі кроки, рішення і таймлайни фіксуються для аудиту і поліпшень.

2) Градація серйозності (SEV/P-рівні)

• SEV-0/P0 (критичний) - повна недоступність ключової функції (логін/платіж), витік даних, юридичний ризик. Негайний пейдж всього ядра on-call, freeze релізів.
• SEV-1/P1 (високий) - деградація p95/p99, підвищена частка помилок/відмов у ключовому процесі, недоступність регіону/провайдера.
• SEV-2/P2 (середній) - часткова деградація для обмеженої когорти (регіон, провайдер), є обхідний шлях.
• SEV-3/P3 (низький) - не критично для користувача, але вимагає уваги (фонова затримка ETL, прострочений звіт).

• Радіус ураження (скільки користувачів/оборот) × тривалість × чутливість (регуляторика/PR) → рівень SEV.

3) KPI процесу

MTTD (час виявлення) - від початку інциденту до першого сигналу.
MTTA (час прийняття) - від сигналу до підтвердження IC.
MTTR (час відновлення) - до відновлення SLO/функції.
Escalation Latency - від підтвердження до підключення потрібної ролі/команди.
Reopen Rate - частка інцидентів, повторно відкритих після «вирішено».
Comm SLA - дотримання інтервалів зовнішніх/внутрішніх апдейтів.

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

Incident Commander (IC): власник рішення, встановлює рівень, план, freeze, ескалації, деескалацію. Не пише фікси.
Tech Lead (TL): технічна діагностика, гіпотези, координація інженерів.
Comms Lead (CL): статус-сторінки, клієнтська та внутрішня комунікація, узгодження з Legal/PR.
Scribe: точна фіксація фактів, таймлайну, прийнятих рішень.
Liaisons (зв'язні): представники зовнішніх провайдерів/команд (платежі, KYC, хостинг).
On-call інженери: виконання плану, запуск плейбуків/відкатів.

Призначте чергові графіки і бекапи по кожній ролі.

5) Канали та артефакти

War-room канал (ChatOps): єдина точка координації (Slack/Teams) з шаблоном авто-анотацій (версії, прапори, канарки).
Відеоміст для SEV-1 +.
Тікет інциденту (one-pager): ID, SEV, IC, учасники, гіпотеза/діагноз, кроки, ETA, статус, імпакт, посилання на графіки.
Статус-сторінка: публічна/внутрішня; розклад регулярних апдейтів (наприклад, кожні 15-30 хвилин для SEV-1 +).

6) Тайм-бокси і стандартні інтервали

T0 (хв. 0-5): IC призначений, SEV присвоєний, freeze релізів (якщо потрібно), war-room відкритий.
T + 15 хв: перше публічне/внутрішнє повідомлення (що порушено, workaround, наступне вікно апдейта).
T + 30/60 хв: ескалація наступного рівня (платформа/БД/безпека/провайдери), якщо немає стійкої динаміки.
Регулярні апдейти: SEV-0: кожні 15 хв; SEV-1: кожні 30 хв; SEV-2+: щогодини.

7) Правила авто-ескалації (політики спрацювання)

• Burn-rate бюджету помилок вище порогу в короткому і довгому вікнах.
• Кворум зовнішніх проб: ≥2 регіонів фіксують деградацію HTTP/TLS/DNS.
• Бізнес-SLI (успіх платежів/реєстрацій) падає нижче SLO.
• Security-сигнатури: підозра на витік/компрометацію.
• Провайдерський сигнал: вебхук статусу «major outage».

8) Процес від виявлення до рішення

1. Декларація інциденту (IC): SEV, охоплення, freeze, запуск плейбуків.
2. Діагностика (TL): гіпотези, ізоляція радіуса (регіон, провайдер, фіча), перевірки (DNS/TLS/CDN/БД/кеші/шина).
3. Мітигуючі дії (швидкі перемоги): відкат/канарка ↓, фіча-прапор деградації, failover провайдера, rate-limit, кеш-оверлей.
4. Комунікація (CL): статус-сторінка, клієнти/партнери, Legal/PR, оновлення за графіком.
5. Підтвердження відновлення: зовнішня синтетика + реальні метрики (SLI), зняття freeze.
6. Деескалація: зниження SEV, перехід в спостереження N хвилин/годин.
7. Закриття та RCA: підготовка пост-мортему, action items, власники і терміни.

9) Робота з зовнішніми провайдерами

Власні проби до провайдерів з декількох регіонів + дзеркальні лог-приклади запитів/помилок.
Угоди про ескалацію (контакти, SLA відповіді, пріоритет, вебхуки статусу).
Автоматичний failover/перероздача трафіку по SLO провайдера.
Доказова база: таймлайн, sample запити/відповіді, графіки латентності/помилок, ID тікету провайдера.

10) Регуляторика, безпека та PR

Security/P0: ізоляція, збір артефактів, мінімізація розголошення, обов'язкові повідомлення (внутрішні/зовнішні/регулятор).
Legal: узгодження формулювань зовнішніх апдейтів, облік договірних SLA/штрафів.
PR/Клієнтський сервіс: готові шаблони відповідей, Q&A, компенсації/кредити (якщо застосовно).

11) Шаблони повідомлень

• "Ми розслідуємо інцидент SEV-1, що зачіпає [функцію/регіон]. Симптоми: [коротко]. Ми активували обхідний шлях [опис]. Наступне оновлення - в [час]"

• "Діагностика: [гіпотеза/підтвердження]. Дії: [перемкнули провайдера/відкотили реліз/включили деградацію]. Імпакт знижений до [відсотків/когорти]. Наступний апдейт - [час]"

• "Інцидент SEV-1 вирішено. Причина: [коренева]. Час відновлення: [MTTR]. Наступні кроки: [фікс/перевірки/спостереження N годин]. Пост-мортем - [коли/де]"

12) Плейбуки (зразкові)

Падіння успіху платежів: знизити частку на провайдера A, перевести X% на B; включити «degrade-payments-UX»; включити ретраї в лімітах; оповістити фін-команду.
Зростання p99 API: зменшити канарку нової версії; вимкнути важкі фічі; збільшити кеш-TTL; перевірити БД-індекси/коннекти.
Проблема DNS/TLS/CDN: перевірити сертифікати/ланцюжок; оновити запис; перемкнути на резервний CDN; Переглянути кеш.
Security-підозра: ізоляція вузлів, ключова ротація, включення mTLS-ручок, збір артефактів, повідомлення Legal.

13) Деескалація та критерії «вирішено»

• SLI/SLO стабільно в зеленій зоні ≥ N інтервалів;
• виконані мітигуючі дії і спостереження - без регресу;
• для security-класу - підтверджена закритість векторів, ключі/секрети ротовані.

Закриття - тільки після фіксації таймлайну, власників action items і термінів.

14) Post-mortem (некаральний)

1. Факти (таймлайн, що бачили користувачі/метрики).

2. Коренева причина (технічна/процесна).

3. Що спрацювало/не спрацювало в ескалації.

4. Превентивні заходи (тести, алерти, ліміти, архітектура).

5. План дій з дедлайнами і власниками.

6. Зв'язок з error budget і перегляд SLO/процесів.

15) Метрики зрілості процесу

Частка інцидентів, задекларованих до скарг користувачів.
MTTA за рівнями SEV; час на підключення потрібної ролі.
Дотримання інтервалів апдейтів (Comm SLA).
Відсоток інцидентів, вирішених плейбуками без ручної «творчості».
Виконання action items з пост-мортемів вчасно.

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

«Хто-небудь зробіть що-небудь» - немає IC/ролей.
Багатоголосся у war-room - суперечка про версії замість дій.
Пізня декларація → втрата часу на збір людей.
Немає freeze і анотацій релізів - паралельні зміни маскують причину.
Відсутність зовнішньої комунікації - ескалація скарг/PR-ризик.
Закриття без пост-мортема і дій - повторюємо ті ж помилки.

17) Чек-лист IC (кишенькова картка)

• Присвоїти SEV і відкрити war-room.
• Призначити TL, CL, Scribe, перевірити on-call присутні.
• Включити реліз-freeze (при SEV-1 +).
• Підтвердити джерела істини: дашборди SLI, синтетика, логи, трейсинг.
• Прийняти швидкі мітигуючі дії (відкат/прапори/failover).
• Забезпечити регулярні апдейти за розкладом.
• Зафіксувати Criteria for Resolve і спостереження після відновлення.
• Ініціювати пост-мортем і призначити власників action items.

18) Вбудовування в щоденні операції

Тренування (game-days): симуляції за ключовими сценаріями.
Каталог плейбуків: версіоновані, протестовані, з параметрами.
Інструменти: ChatOps-команди «/declare », «/page», «/status », «/rollback».
Інтеграції: тікетинг, статус-сторінка, пост-мортеми, CMDB/сервіс-каталог.
Узгодження з SLO/Error Budget: тригери авто-ескалації та правила freeze.

19) Підсумок

Ескалація - це операційна дисципліна, а не просто дзвінок черговому. Чіткі рівні SEV, призначений IC, готові плейбуки, тайм-бокси оновлень і інтеграція з метриками SLO і budget-політиками перетворюють хаотичну пожежу в керований процес з передбачуваним результатом - швидким відновленням сервісу, мінімальним PR/регуляторним ризиком і системними поліпшеннями після кожного інциденту.