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

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. Коммуникации: шаблон апдейта (Импакт→Диагностика→Действия→След. апдейт), каналы и частоты.
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→улучшения.
6. SLA свежести и квартальные ревью; отчет по метрикам качества.

16) Итог

Плейбуки — это операционные сценарии с развилками и перилами, которые переводят хаос “а что делать?!” в предсказуемую последовательность решений. Когда плейбуки стандартизированы, интегрированы с алертами и регулярно тренируются, команда реагирует быстрее, риски контролируются, а бизнес видит стабильность и зрелость эксплуатации.