Плейбуки операцій

1) Що таке плейбук і чим він відрізняється від runbook

Runbook - лінійна покрокова інструкція для типової операції/алерта («зроби раз, два, три»).
Плейбук - дерево рішень для сценаріїв з розвилками: різні симптоми → різні гіпотези → різні гілки дій. Включає критерії вибору, гейт-умови і fallback-гілки.
Призначення плейбука - зменшити MTTA/MTTR і рівень імпровізації при невизначеності.

2) Де плейбуки потрібні в першу чергу

Інциденти: падіння SLO (availability/latency/success), провал бізнес-SLI (конверсія/успіх платежів).
Зміни: релізи, міграції, фіча-прапори, конфіги (canary/rollback).
Вікна обслуговування: апгрейди БД/брокерів, ротації сертифікатів.
Провайдери: PSP/KYC/CDN/IDP - деградації і свіч-овер.
Безпека: компрометований ключ, підозріла активність.
DataOps: прострочення свіжості, дрейф схеми, деградація пайплайна.

3) Стандарти плейбука (мінімальний склад)

1. Картка: Ідентифікатор, Версія/Дата, Власник (команда/роль), Сервіси/регіони/тенанти, Пов'язані політики/стандарти.
2. Мета та умови запуску: які SLO/SLI захищаємо, які алерти/тригери застосовні.
3. Симптоми ↔ Гіпотези: таблиця відповідностей, як швидко відсікти невірні гіпотези.
4. Дерево рішень: розвилки, гейти безпеки, критерії зупинки/продовження.
5. Дії: покрокові блоки з командами/посиланнями на runbook'і.
6. Комунікації: шаблон апдейта (Impakt→Diagnostika→Deystviya→Sled. апдейт), канали і частоти.
7. Відкат/фолбек: чіткий backout-план, ліміти і прапор деградації UX.
8. Критерії завершення: метрики, тимчасові вікна спостереження.
9. Evidence: що зберегти (логи, графіки, скріншоти, ID тікетів).
10. Історія змін: changelog, відомі обмеження.

4) Таксономія плейбуків (приклад каталогу)

INC- - інциденти (SLO/SLI, провайдери, інфраструктура).
REL- - релізи, відкати, конфіги/прапори.
MW- - вікна обслуговування (DB/queue/cert/OS).
SEC- безпека (доступи, ключі, підозрілі дії).
DATA- - свіжість/якість/схеми.
PROV- - зовнішні провайдери (PSP/KYC/CDN/Email/SMS).

5) Життєвий цикл і володіння

1. Ініціювання: за результатами інциденту/симуляції/зміни.
2. Чернетка: автор = власник сервісу; рев'ю: SRE/безпека/дані (по домену).
3. Пілот: tabletop/game-day; фіксація часу проходження і дефектів.
4. Публікація: в репо (Docs-as-Code), версія, теги, посилання на дашборди.
5. Актуалізація: по RCA/CAPA, мінімум раз на квартал; SLA свіжості.
6. Архів/депрекація: при заміні/втраті актуальності.

6) Інтеграція з інструментами

Alert → Playbook: кожна Page-правила посилається на рівно один базовий плейбук.
ChatOps: '/play start <id>'відкриває картку, фіксує evidence, ставить таймери апдейтів.
CMDB/каталог: у сервісу список релевантних плейбуків, власники, SLO, дашборди.
GitOps: плейбуки і runbook'і живуть в Git, проходять PR-рев'ю і лінтери.

7) Метрики якості плейбуків

Actionability: ≥ 90% запусків призводять до конкретних дій без ескалації «через незнання».
Time-to-first-action: хвилина-дві від Page до першого осмисленого кроку.
Coverage: % Page-алертів, що мають прив'язаний плейбук (ціль 100%).
Freshness: частка плейбуків свіжіша 90 днів.
Defect rate: зауваження на рев'ю/симуляціях на 100 плейбуків.
Reuse: скільки разів плейбук реально застосовувався (і до яких результатів привів).

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

«Плейбук-енциклопедія» на 20 сторінок без дерева рішень.
Команди без очікувань результату («виконати X» - а що має змінитися?).
Немає backout-плану і лімітів - ризик ескалації проблеми.
Не вказані канали/інтервали комунікацій - зростання PR-ризиків.
Плейбук без власника/дати оновлення - ніхто не вірить в його актуальність.
Десятки схожих плейбуків замість одного параметризуемого.

9) Міні-шаблон плейбука (YAML-ідея)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Готові приклади (фрагменти)

A) Платежі: «Провайдер деградує в одному регіоні»

Симптоми: зниження success_ratio TR-когорти, зростання таймаутів PSP-A.
Рішення: зменшити вагу PSP-A для TR, включити degrade-UX, посилити ретраї з бюджетом ≤ SLA, підготувати клієнтський апдейт.
Backout: повернути ваги при зелених SLI 60 хвилин.

B) БД: «Зростання p99 і connection errors»

Симптоми: p99↑, помилки connection reset, зростання wait events.
Рішення: включити read-only сценарії, лімітувати write-навантаження, масштабувати пул/репліки, при необхідності - гарячий фейловер.
Backout: відкат параметрів, репліка-прайм.

C) Кеш: «Miss rate ↑ → навантаження на БД»

Симптоми: miss rate> 40%, зростання CPU БД.
Рішення: збалансувати eviction policy, збільшити пам'ять/шардинг, тимчасово включити read-through, обмежити RPS на гарячих ключах.
Backout: повернути політику, пересоздать проблемний shard.

D) CDN: «Регіональна деградація контенту»

Симптоми: зростання latency/timeout в одній країні, скарги RUM.
Рішення: змінити routing map/GSLB, обійти проблемний POP, знизити TTL, включити origin-shield.
Коммс: статус-апдейти з географією впливу.

E) KYC: «Провал ідентифікацій»

Симптоми: падіння approve rate, зростання vendor_error.
Рішення: переключити частину трафіку на альтернативного провайдера, знизити суворість правил (в рамках політики), ініціювати ручний review для VIP.
Compliance: лог всіх змін, повідомлення Risk/Legal при необхідності.

11) Комунікації (шаблон апдейта)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Чек-лист автора плейбука

• Вказані мета, власники, SLO/SLI і тригери.
• Є таблиця «Симптоми ↔ Гіпотези» і дерево рішень.
• Здійсненні кроки з очікуваними результатами і гейтами безпеки.
• Прописані backout/fallback і умови повернення.
• Шаблон комунікацій і частоти апдейтів.
• Посилання на дашборди/алерти/лог-пошуки/трейси.
• Обов'язкова секція evidence і критерії завершення.
• Версія, дата, SLA свіжості, історія змін.

13) Чек-лист рев'юера

• Плейбук відтворюємо на tabletop/game-day.
• Кроки безпечні (ліміти/канарка/авто-відкат), секрети не розкриваються.
• Ролі та ескалації ясні; IC/Comms вказані.
• Немає дублювання з сусідніми плейбуками; параметри винесені.
• Зрозуміло, коли зупиняти і переходити до fallback/rollback.
• Документ доступний з алерта в 1 клік.

14) Параметризація та перевикористання

Виносьте змінні (регіон, провайдер, пороги) в'values.'.
Загальні кроки (наприклад, «знизити вагу провайдера», «включити degrade-UX») оформляйте окремими runbook'ами.
Підтримуйте генератори з шаблонів: `plb new --type=INC --service=payments`.

15) Дорожня карта впровадження (4-6 тижнів)

1. Інвентаризація Page-алертів → зіставити кожному базовий плейбук.
2. Шаблони: затвердити структуру YAML/Markdown, чек-листи і лінтери.
3. Топ-5 сценаріїв (платежі/БД/CDN/KYC/кеш) → написати/відкатати на tabletop.
4. Інтеграція: посилання з алертів, ChatOps команди, evidence-бот.
5. Навчання: щотижневі mini-drill по одному плейбуку; AAR→uluchsheniya.
6. SLA свіжості і квартальні рев'ю; звіт по метриках якості.

16) Підсумок

Плейбуки - це операційні сценарії з розвилками і поручнями, які переводять хаос «а що робити?!» в передбачувану послідовність рішень. Коли плейбуки стандартизовані, інтегровані з алертами і регулярно тренуються, команда реагує швидше, ризики контролюються, а бізнес бачить стабільність і зрілість експлуатації.