Перейти к основному содержимому

Runbook'и инцидент-плейбуки

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа​

Документ определяет конкретные runbook'и платформы Vitiana для реагирования на каноничные классы инцидентов. Это пошаговые инструкции для дежурного оператора с явными командами диагностики, безопасными смягчающими действиями (safe immediate actions), критериями эскалации, точками принятия решений.

Включает:

  • Каноничную модель runbook (Runbook, RunbookStep, RunbookExecution).
  • Восемь главных runbook'ов по классам инцидентов (на основе классификации из Observability And Incident Response).
  • Каноничную процедуру эскалации.
  • Каноничные категории post-mortem.
  • Дерево принятия решений «изолировать / откатить / продолжить».
  • Связь с алертами и журналом инцидентов.
  • Подписание и одобрение runbook'ов перед использованием.
  • Регулярный реалистичный тренинг (game days).
  • Метрики операционной зрелости (MTTR, MTBF, доля автоматического разрешения).
  • Фазы развёртывания.

Документ читается после:

В корневых документах зафиксирована структура и классификация инцидентов. Этот документ даёт конкретные процедуры — то, что дежурный достаёт в момент срабатывания алерта.

Runbook'и — критическая операционная инфраструктура. Без них даже опытный дежурный в стрессе ночного срабатывания пропустит шаг, ошибётся в команде, забудет проверить инвариант. Runbook — это зафиксированный опыт команды, доступный в момент острой необходимости.

Реальное состояние реализации: на текущей фазе платформа не имеет формализованных runbook'ов. Этот документ закладывает каноничную структуру и первые runbook'и для основных сценариев фазы Bootstrap → 2.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: runbook'и задаются платформой, не наследуются от поставщиков. Если поставщик отвечает медленно — runbook платформы говорит «как платформа смягчает удар», а не «как платформа подстраивается под поставщика».

Главное решение​

Каждый каноничный класс инцидента имеет утверждённый runbook с пошаговой процедурой, безопасными immediate actions и явными точками эскалации.

Это означает:

  • Runbook — структурированная сущность в системе, не Wiki-страница без контроля версий.
  • Каждый шаг — явный с командой, ожидаемым результатом, действием при отклонении.
  • Безопасные immediate actions — действия, которые гарантированно не делают хуже, выполняемые до полной диагностики.
  • Эскалация — каноничная с фиксированными временами ответа и явными ролями.
  • Регулярные тренинги (game days) — runbook должен проверяться на реалистичных сценариях, не только читаться.
  • Post-mortem обязателен для всех инцидентов severity high+ с действиями (action items) на улучшение runbook'ов.
  • Версионирование runbook'ов — каждое изменение фиксируется, можно вернуться к предыдущей версии.
  • Доступ через единый интерфейс — дежурный из алерта одним кликом попадает на нужный runbook.

Каноничная модель runbook​

Главные сущности​

Runbook — runbook (общая сущность)​

{
  runbook_id: UUID,
  runbook_key: string,
  runbook_namespace: string,
  applicable_incident_class: enum,
  applicable_severity_levels: array,
  steps: array,
  tools_required: array,
  permissions_required: array,
  estimated_resolution_minutes: integer,
  approval_state: enum,
  approved_by: array,
  schema_version: string,
  last_tested_at: timestamp,
  last_used_at: timestamp,
  next_review_at: timestamp,
  is_active: boolean,
  created_at: timestamp,
  updated_at: timestamp
}

Поля:

  • applicable_incident_class — класс инцидента из Observability And Incident Response: supplier_degradation / ingestion_integrity / booking_disruption / payment_disruption / surface_contract / settlement_reconciliation / cross_contour / isolation_incident / infrastructure_outage / release_regression.
  • applicable_severity_levels — для каких уровней применим (critical / high / medium / low).
  • tools_required — какие инструменты нужны (grafana_dashboard:<id> / kafka_admin_console / kubectl / postgresql_console / provider_admin_console:stripe и так далее).
  • permissions_required — какие разрешения нужны дежурному.
  • approval_state — состояние одобрения (pending_review / approved_for_use / deprecated).
  • last_tested_at — когда последний раз runbook был успешно отработан в game day.

RunbookStep — шаг runbook​

{
  step_id: UUID,
  runbook_id: UUID,
  step_order: integer,
  step_type: enum,
  description: string,
  command_or_action: object,
  expected_outcome: string,
  decision_branches: array,
  is_safe_immediate: boolean,
  estimated_seconds: integer,
  required_tools: array,
  required_permissions: array
}

Поля:

  • step_type — тип (diagnostic_query — запрос для определения состояния; safe_mitigation — безопасное смягчающее действие; decision_point — точка принятия решения; risky_action_requires_approval — рискованное действие с одобрением; escalation_check — проверка нужно ли эскалировать; communication_action — обязательные сообщения; recovery_validation — проверка восстановления).
  • is_safe_immediate — true для шагов, которые можно выполнять до полной диагностики без риска ухудшить.
  • decision_branches — массив условий и переходов к другим шагам (для decision_point).
  • command_or_action — конкретная команда или действие (с примером).

RunbookExecution — исполнение runbook​

{
  execution_id: UUID,
  runbook_id: UUID,
  triggered_by_incident_id: UUID,
  operator_user_id: UUID,
  started_at: timestamp,
  completed_at: timestamp,
  outcome: enum,
  steps_executed: array,
  deviations_from_runbook: array,
  notes: string,
  effectiveness_rating: integer
}

Поля:

  • triggered_by_incident_id — связь с записью инцидента в общей системе.
  • steps_executed — массив выполненных шагов с временными метками и результатами.
  • deviations_from_runbook — отклонения от runbook (для последующего ревью runbook'а).
  • effectiveness_rating — оценка эффективности runbook'а оператором (1–5) для последующих улучшений.

Связь с другими каноничными сущностями​

Каноничный шаблон шагов runbook​

Каждый runbook следует общему шаблону (на основе структуры из Observability And Incident Response, раздел Incident Playbook Structure):

Шаг 0. Acknowledge alert (подтверждение получения)
   ↓
Шаг 1. Quick triage — определение severity и blast radius
   ↓
Шаг 2. Safe immediate mitigation (если применимо)
   ↓
Шаг 3. Diagnostic queries
   ↓
Шаг 4. Root cause hypothesis
   ↓
Шаг 5. Decision: contained / needs_escalation / needs_rollback
   ↓
Шаг 6. Targeted mitigation (по гипотезе)
   ↓
Шаг 7. Recovery validation
   ↓
Шаг 8. Communication (партнёрам, тенантам, status page)
   ↓
Шаг 9. Resolution and incident closure
   ↓
Шаг 10. Post-mortem trigger (для severity high+)

Безопасные immediate actions на шаге 2 — то, что точно не делает хуже:

  • Активация feature flag для отключения проблемного компонента (через Платформа экспериментов и A/B-тестирования, kill switch).
  • Снижение rate limit для проблемного потока трафика.
  • Активация резервного провайдера (для платежей, для сети распространения контента, для сторонних сервисов).
  • Активация деградации поиска до базовой релевантности (см. Поиск и обнаружение, стратегия деградации).

Runbook 1. Supplier Degradation Incident​

Применим к классу: supplier_degradation Признаки: рост pending_supplier_confirmation бронирований, рост unknown_external_state, рост задержек ответа от конкретного поставщика, malformed payload waves.

Шаг 0. Acknowledge​

  • Подтвердить алерт в системе (pagerduty.acknowledge).
  • Зафиксировать timestamp начала работы.

Шаг 1. Quick triage (1–3 мин)​

Цель: определить какой поставщик деградирует, насколько широко это влияет.

Команды/проверки:

# Дашборд supplier health (см. analytics-and-bi.md, витрина 3)
открыть: dashboards/supplier_health_mart

# Метрики
- доля успешных вызовов по поставщикам за последний час
- задержка p95 ответа по поставщикам
- доля unknown_external_state по поставщикам

Ожидаемое: один поставщик с резким падением показателей.

Решение:

  • Если затронут один поставщик — продолжить с этим runbook.
  • Если затронуты несколько — переключиться на runbook Cross-Contour Incident (см. ниже).

Шаг 2. Safe immediate mitigation​

Безопасные действия:

  • Активировать circuit breaker для проблемного поставщика — все новые запросы получают мгновенный ответ «временно недоступно» вместо ожидания таймаута. Это снимает нагрузку с пула рабочих процессов.
# Через панель управления:
toggle feature_flag: supplier.<supplier_id>.circuit_breaker = open
  • Активировать fallback на других поставщиков для поиска (если применимо). Поиск автоматически перестаёт включать проблемного поставщика в выдачу.

Шаг 3. Diagnostic queries​

Цель: понять причину деградации.

Запросы:

  1. Свежие логи поставщика — последние 100 запросов с ответами/ошибками.
  2. Статус интеграционного контура — kafka events for supplier_<id>_intake.
  3. Внешние индикаторы — статус-страница поставщика, недавние сообщения от поставщика.
  4. Оповещения от службы поддержки поставщика (email, Slack от account manager поставщика).

Шаг 4. Root cause hypothesis​

Каноничные гипотезы для деградации поставщика:

  • A. Поставщик в маинтенансе или инциденте на своей стороне.
  • B. Изменение API поставщика, ломающее наш слой приёма данных.
  • C. Переполнение rate limit поставщика на нашей стороне.
  • D. Сетевая проблема между нашими дата-центрами и поставщиком.
  • E. Утечка credentials или блокировка ключа поставщика.

Шаг 5. Decision​

ГипотезаДействие
A — внешний инцидентПродолжить с активным circuit breaker, мониторить, проинформировать партнёров через статус-страницу
B — API breaking changeЭскалация инжиниринговой команде ingestion, runbook не разрешает; требуется код-фикс
C — наш rate limit overflowСнизить выходной rate, activate gradual recovery
D — сетевая проблемаЭскалация infrastructure team
E — credentials issueЭскалация security team немедленно

Шаг 6. Targeted mitigation​

Гипотеза A: ничего не делаем сверх immediate actions. Ждём восстановления поставщика.

Гипотеза C:

# Постепенное восстановление трафика к поставщику
toggle feature_flag: supplier.<supplier_id>.outbound_rate_limit = 50% normal
# Подождать 5 минут, проверить метрики, если ОК — увеличить до 100%

Шаг 7. Recovery validation​

Критерии успеха:

  • Доля успешных вызовов поставщика выше 95% за 15 минут.
  • Доля unknown_external_state для бронирований этого поставщика возвращается к baseline.
  • Партнёрские обращения по проблемам уменьшаются.

Шаг 8. Communication​

  • Status page обновляется в зависимости от blast radius.
  • Партнёрам — webhook через Уведомления и коммуникации, класс system_health.
  • Внутренней команде — обновление в инцидент-канале.

Шаг 9. Resolution​

  • Закрыть circuit breaker (supplier.<supplier_id>.circuit_breaker = closed).
  • Возобновить нормальные rate limits.
  • Закрыть инцидент в системе.

Шаг 10. Post-mortem​

Обязателен для severity high или выше. Тема: «Что мы можем сделать, чтобы нагрузка одного поставщика не влияла на других».

Runbook 2. Booking Disruption Incident​

Применим к классу: booking_disruption Признаки: рост ошибок commit_tour или commit_booking, рост unknown_external_state, рост failed без явной причины, рост обращений в поддержку с ключевыми словами «не подтвердилось», «висит», «деньги списали».

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

Команды:

# Дашборд booking funnel (см. analytics-and-bi.md, витрина 2)
открыть: dashboards/booking_funnel_mart

# Метрики последних 30 минут:
- доля переходов в unknown_external_state
- доля failed
- доля saga rollbacks (для пакетных туров)

Ожидаемое: чёткий рост одной из метрик.

Решение: определить, в каком слое проблема:

  • В стыковке с поставщиком → перейти к Runbook 1 (Supplier Degradation).
  • В платёжном слое → перейти к Runbook 3 (Payment Disruption).
  • В слое orchestration на стороне платформы → продолжить с этим runbook.

Шаг 2. Safe immediate mitigation​

  • Активировать повышенный rate limit на новые бронирования (мягкая защита от лавинного эффекта если проблема связана с очередью).
  • Если идёт релиз менее 1 часа назад → подготовить rollback релиза (через Релизы и совместимость).

Шаг 3. Diagnostic queries​

  1. Свежие BookingStateTransition за час — паттерны переходов.
  2. Состояние очередей kafka:booking-transitions и kafka:booking-confirmation-pending.
  3. Распределение failure_reason для failed за последний час.
  4. Метрики базы данных: задержки, locks.

Шаг 4. Root cause hypothesis​

  • A. Регрессия после недавнего релиза.
  • B. Деградация инфраструктуры (БД, очередь).
  • C. Внешняя проблема (поставщик/платёжный провайдер) проявляется как booking disruption.
  • D. Аномальный профиль трафика (легитимный пик, неавторизованный bot, DDoS).

Шаг 5. Decision​

  • A → rollback релиза немедленно (blast radius пропорционален timing).
  • B → infrastructure team escalation.
  • C → переключиться на соответствующий runbook.
  • D → анализ source pattern, возможно ограничение по тенанту/IP.

Шаг 6. Targeted mitigation​

Гипотеза A: rollback через стандартную процедуру Релизы и совместимость.

Шаг 7. Recovery validation​

  • Доля бронирований в confirmed за 15 минут возвращается к baseline.
  • BookingRestorationJob отрабатывают с нормальной скоростью.

Шаг 8–10. Communication / Resolution / Post-mortem​

Стандартные шаги.

Runbook 3. Payment Disruption Incident​

Применим к классу: payment_disruption Признаки: рост payment.transaction.failed, deterioration метрик провайдера платежей, увеличение chargeback.opened.

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

Команды:

# Дашборд платежей
открыть: dashboards/payment_health

# Метрики:
- доля успешных PaymentTransaction.captured за час
- задержки ответа PSP
- доля 3DS challenges (если резко выросло — возможна деградация на стороне банков-эмитентов)

Шаг 2. Safe immediate mitigation​

Если деградация одного PSP:

  • Активировать failover на резервный PSP через Платёжный домен, политика маршрутизации.
toggle feature_flag: payment.routing.<region>.primary_psp = <fallback_psp>

Если деградация всех PSP:

  • Активировать soft block на новые крупные платежи (выше определённой суммы) до выяснения. Маленькие платежи — обрабатываются.

Шаг 3. Diagnostic queries​

  1. Логи PSP за час — distribution кодов ошибок.
  2. Состояние webhook-канала PSP (приходят ли уведомления).
  3. Внешний статус PSP (Stripe status page и аналогичные).

Шаг 4. Root cause hypothesis​

  • A. Внешний инцидент PSP.
  • B. Наш ключ PSP компрометирован/заблокирован.
  • C. Рост 3DS challenges из-за внешней регуляторной волны (например, банки массово ужесточили).
  • D. Регрессия в нашем платёжном коде после релиза.

Шаг 5. Decision​

ГипотезаДействие
AFailover на резервный PSP до восстановления
BЭскалация security team немедленно
CАктивация retry policy с exponential back-off, мониторить
DRollback релиза

Шаг 6–10. По стандартному шаблону​

Runbook 4. Settlement / Reconciliation Incident​

Применим к классу: settlement_reconciliation Признаки: settlement event lag, mismatch burst, refund reversal failure, reconciliation backlog beyond threshold.

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

# Дашборд finance/settlement
открыть: dashboards/settlement_health

# Метрики:
- backlog очереди settlement events
- доля mismatch (расхождение между нашими и провайдерскими цифрами)
- задержка между booking.confirmed и settlement.created

Шаг 2. Safe immediate mitigation​

Финансовый контур требует особой осторожности. Безопасные действия:

  • Только остановка новых проблемных операций, не отмена уже идущих.
  • Заморозка payout_batch создания, пока не выяснена причина (платежи поставщикам не уйдут до проверки).

Запрещённые impulsive actions:

  • ❌ Откат платежей вручную.
  • ❌ Любая массовая операция Refund без подтверждения CFO.

Шаг 3. Diagnostic queries​

  1. Свежие Settlement за день с состояниями.
  2. Журнал расхождений (mismatch log).
  3. Состояние очереди settlement-reconciliation.

Шаг 4–5. Root cause + Decision​

Финансовые инциденты обязательно эскалируются финансовой команде даже при подтверждённой causation. Это правило защиты от ошибки «на ходу».

Шаг 6. Targeted mitigation​

Только после одобрения финансовой команды. Каноничные действия — restart settlement-reconciliation consumer, replay events из DLQ, ручная корректировка Settlement записей.

Шаг 7–10. По стандартному шаблону, post-mortem обязателен независимо от severity.​

Runbook 5. Surface Contract Incident​

Применим к классу: surface_contract Признаки: партнёрский API возвращает несовместимые ответы, agency-visible stale quote state, B2C false finality, proposal publication inconsistency.

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

# Дашборд contract testing
открыть: dashboards/contract_health

# Метрики:
- доля 5xx ответов на партнёрской поверхности
- доля schema mismatch errors
- доля webhook delivery failures

Шаг 2. Safe immediate mitigation​

  • Если деградация после релиза → rollback (см. Runbook 2 шаг 6).
  • Если затронут один тенант → активация enhanced logging для этого тенанта.

Шаг 3. Diagnostic queries​

  1. Сравнение текущего OpenAPI spec с опубликованным (см. Скелеты OpenAPI).
  2. Состояние contract testing pipeline.
  3. Журнал webhook deliveries за час.

Шаг 4–5. Гипотеза и решение​

Преимущественно — регрессия после релиза. Rollback — главный инструмент.

Шаг 6–10. По стандартному шаблону​

Runbook 6. Ingestion Integrity Incident​

Применим к классу: ingestion_integrity Признаки: replay storm, matching regression, canonical update block, abnormal publication gating surge.

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

# Дашборд ingestion
открыть: dashboards/ingestion_pipeline

# Метрики:
- backlog ingestion очередей
- доля matching errors
- частота publication gating

Шаг 2. Safe immediate mitigation​

  • При replay storm → активация slow mode ingestion (снижение rate replay, defer non-critical replays).
  • При publication gating surge → активация strict gating до выяснения (новые предложения проходят через manual review).

Шаг 3–10. По стандартному шаблону​

Runbook 7. Cross-Contour Incident​

Применим к классу: cross_contour Признаки: проблема проходит через несколько слоёв (например, supplier drift → repricing wave → agency disruption).

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

Самая опасная категория. Главное — определить где именно и в каком порядке проявляется проблема.

# Дашборд operational health (cross-contour)
открыть: dashboards/platform_health

# Метрики:
- доля «зелёных» сервисов
- паттерны корреляции метрик
- timeline появления алертов

Шаг 2. Safe immediate mitigation​

  • Активация command center — выделенный канал для координации, с участием на разных слоях.
  • Назначение incident commander — один человек, координирующий всех остальных.

Шаг 3–10. Координация работы по нескольким runbook'ам параллельно​

Runbook 8. Isolation Incident​

Применим к классу: isolation_incident Признаки: срабатывание IsolationBoundaryCheck severity critical или high. См. Сила тенантной изоляции.

Шаг 0. Acknowledge​

Шаг 1. Quick triage (1–3 мин)​

Каждое срабатывание = подозрение на утечку. Без спокойного анализа — сразу к containment.

Шаг 2. Safe immediate mitigation​

  • Немедленное containment — блокировка операции, вызвавшей нарушение.
  • Карантинизация возможно затронутых данных.
  • Уведомление CISO в течение 15 минут.

Шаг 3. Diagnostic queries​

Полный набор из Сила тенантной изоляции.

Шаг 4–10. Полный поток инцидента изоляции​

С обязательной готовностью к регуляторному уведомлению в 72 часа.

Каноничная процедура эскалации​

Уровни эскалации​

  1. Primary on-call — дежурный первой линии, отвечает в течение 15 минут.
  2. Secondary on-call — резерв, если primary не отвечает за 15 минут.
  3. Engineering manager — для технических решений требующих опыта.
  4. Director / VP Engineering — для крупных архитектурных решений.
  5. CTO / CISO — для критических инцидентов или security-инцидентов.
  6. CEO — только для критических инцидентов с регуляторными последствиями или существенным финансовым ущербом.

Каноничные триггеры эскалации​

  • Время — если инцидент не локализован за фиксированное время по severity (например, для critical — 30 мин, для high — 2 часа), автоматическая эскалация на следующий уровень.
  • Тип — security и compliance инциденты сразу эскалируются CISO.
  • Финансовый ущерб — потери выше определённого порога — эскалация финансовой команде и leadership.
  • Затронуты Enterprise-партнёры — эскалация к VP Customer Success.

Запрет на «героическое одиночное расследование»​

Если дежурный задерживается на инциденте более 60 минут без видимого прогресса — обязательная эскалация. Гордость и нежелание тревожить других — операционный риск.

Регулярные тренинги (game days)​

Принцип​

Runbook без регулярного использования деградирует — устаревают команды, меняются дашборды, забывается контекст. Решение: регулярные тренировки в боевой обстановке.

Каноничные форматы​

  • Game day — раз в квартал. Команда платформы выбирает один runbook, инжиниринг искусственно вызывает соответствующий инцидент в pre-production среде, дежурный отрабатывает по runbook'у в реальном времени.
  • Tabletop exercise — раз в месяц. Команда проходит runbook в обсуждении, без реального инцидента — что бы делал, какие команды, какие решения.
  • Chaos engineering — для зрелой фазы (фаза 3+). Автоматизированные спонтанные ввдения сбоев в pre-production для проверки устойчивости.

Обязательность​

  • Каждый дежурный — минимум один game day в квартал.
  • Каждый runbook должен быть отработан хотя бы раз в полгода — отсутствие отработки означает last_tested_at устарел, runbook становится «зомби» и требует ревью.

Дерево принятия решений «изолировать / откатить / продолжить»​

При любом инциденте — каноничный декомпозированный анализ:

Q1: Знаем ли мы причину?
   └─ нет → продолжить диагностику
   └─ да → Q2

Q2: Можем ли смягчить без отката?
   └─ да → mitigation, мониторинг
   └─ нет → Q3

Q3: Был ли релиз менее 1 часа назад?
   └─ да → rollback (быстрый и обратимый)
   └─ нет → Q4

Q4: Затронут весь трафик или ограниченная часть?
   └─ ограниченная → изолировать (feature flag, kill switch для затронутого segment'а)
   └─ весь → Q5

Q5: Финансовый ущерб накапливается?
   └─ да → emergency stop (приоритет — остановить ущерб)
   └─ нет → продолжить целенаправленную диагностику с эскалацией

Метрики операционной зрелости​

Главные метрики​

  • MTTD (Mean Time To Detect) — среднее время от начала проблемы до её обнаружения. Цель — менее 5 минут для critical, менее 15 минут для high.
  • MTTA (Mean Time To Acknowledge) — от обнаружения до подтверждения дежурным. Цель — менее 10 минут.
  • MTTR (Mean Time To Resolve) — от начала до полного восстановления. Цель — зависит от класса инцидента (см. SLA).
  • MTBF (Mean Time Between Failures) — между крупными инцидентами. Цель — рост со временем.
  • Доля автоматического разрешения — какая часть алертов разрешается без вмешательства человека (через self-healing). Цель — рост с фазами.
  • Доля повторов того же класса инцидента — индикатор недостаточного post-mortem follow-through.
  • Готовность runbook'ов — last_tested_at свежее заданного порога для всех активных runbook'ов.

Алерты на сами runbook'и​

  • Алерт при использовании deprecated runbook (по approval_state).
  • Алерт при расхождении между runbook и реальностью (например, упоминание удалённого инструмента).
  • Алерт при last_tested_at старше 6 месяцев для активного runbook.

Связь с другими инцидент-категориями​

Cascade инциденты​

Один инцидент может породить другой:

  • supplier_degradation → booking_disruption → payment_disruption (если поставщик принимал платежи) → settlement_reconciliation.
  • release_regression → surface_contract → partner_complaints.
  • infrastructure_outage → почти все остальные классы.

В таких случаях runbook'и выполняются последовательно или параллельно под координацией command center.

Совместная работа с компонентными контурами​

  • При payment_disruption — runbook платежей координируется с runbook'ом связанной поверхности.
  • При isolation_incident — runbook изоляции имеет приоритет над любыми другими (security first).

События runbook'ов​

СобытиеКогдаГлавные потребители
runbook.execution.startedЗапуск runbook'а в инцидентеКонтур аудита
runbook.execution.step_completedЗавершение шагаАналитика runbook'ов
runbook.execution.escalatedЭскалация по runbook'уКонтур наблюдаемости
runbook.execution.completedЗавершение runbook'аАналитика, post-mortem trigger
runbook.deviation_detectedОтклонение от runbookКоманда runbook owners (для ревью)
runbook.tested_in_game_dayGame day отработкаКонтур обучения
runbook.requires_reviewПревышен next_review_atКоманда runbook owners
runbook.publishedПубликация одобренного runbook'аКоманда дежурных
runbook.deprecatedПеревод runbook'а в устаревшийКоманда дежурных

Полная таксономия — в Первоначальная таксономия событий.

Технологический выбор​

КомпонентТехнологии
Хранилище runbook'овВерсионируемый Markdown в Git с metadata-индексом в БД
Доступ дежурногоВнутренний веб-интерфейс с глубокой ссылкой из алерта
АлертингPagerDuty / OpsGenie / собственный сервис на базе уведомлений
Game day автоматизацияScenarios как код (например, через Chaos Toolkit или собственная инфра)
Командный канал инцидентаSlack / Discord / Teams + интеграция с системой инцидентов
Audit logПлатформа данных, специальный класс приватности compliance_log

Фазы развёртывания​

Фаза Bootstrap (0–6 месяцев)​

Что разворачивается:

  • Каноничная модель (Runbook, RunbookStep, RunbookExecution) зафиксирована.
  • 4 главных runbook'а (Supplier Degradation, Booking Disruption, Payment Disruption, Surface Contract) — без расширенной диагностики.
  • Простой алертинг через Grafana с привязкой к runbook URL.
  • On-call rotation для рабочих часов.

Триггер выхода:

  • Появление первого партнёра в production — нужно круглосуточное покрытие критических инцидентов.

Фаза 2 — Production runbooks (6–18 месяцев)​

Что разворачивается:

  • Все 8 runbook'ов реализованы и одобрены.
  • 24/7 покрытие critical и high инцидентов.
  • Регулярные game days (раз в квартал).
  • PagerDuty или аналог как алертинг.
  • Audit log использования runbook'ов.
  • Метрики MTTD, MTTA, MTTR в дашбордах.

Триггер выхода:

  • Появление Enterprise-партнёров с расширенными SLA.
  • Многорегиональная инфраструктура — нужны runbook'и для региональных инцидентов.

Фаза 3 — Mature operations (18–30 месяцев)​

Что разворачивается:

  • Расширенный набор runbook'ов для специфичных сценариев.
  • Self-healing для типовых случаев — автоматическое исполнение safe_immediate шагов без человека.
  • Chaos engineering как часть релизного цикла.
  • ML-приложения для предсказания инцидентов (см. Платформа машинного обучения).
  • Расширенная аналитика runbook'ов (эффективность, deviation patterns).

Фаза 4 — Multi-region operations (30+ месяцев)​

Что разворачивается:

  • Multi-region runbook'и с региональной координацией.
  • Federated incident response для крупных корпоративных партнёров с собственными SOC.
  • Полная зрелость chaos engineering.

Архитектурные решения с тезисным обоснованием​

Решение 1. Runbook — структурированная сущность, не Wiki​

Цель: обеспечить версионирование, утверждение, аналитику использования.

Тезисы:

  1. Wiki без контроля версий — хаос: правки без журнала, устаревшие команды, конфликтующие версии.
  2. Структурированная сущность даёт audit, journaled deviations, эффективность.
  3. Современные платформы (PagerDuty, FireHydrant) — все имеют runbook'и как первоклассные сущности. Это база.

Решение 2. Безопасные immediate actions перед полной диагностикой​

Цель: уменьшить blast radius до выяснения причины.

Тезисы:

  1. В большинстве инцидентов несколько минут до подтверждённой причины — это критическое время.
  2. Безопасные действия (kill switch, failover, rate limit reduce) гарантированно не делают хуже.
  3. Без них дежурный «парализован» поиском причины пока ущерб накапливается.

Решение 3. Каноничная эскалация с автоматическими триггерами​

Цель: исключить «героическое одиночное расследование» и обеспечить корректное привлечение нужных ролей.

Тезисы:

  1. Без явных триггеров эскалация всегда запаздывает (дежурный «вот-вот разберусь»).
  2. Автоматическая эскалация по времени даёт защиту от усталости и ошибок.
  3. Каноничные триггеры (security incident → CISO; financial damage → CFO) — стандарт индустрии.

Решение 4. Регулярные game days как обязательная практика​

Цель: не дать runbook'ам деградировать без проверки.

Тезисы:

  1. Runbook без отработки — фантом. Команды устаревают, дашборды переезжают, контекст забывается.
  2. Game day в pre-production — единственный реалистичный способ проверить.
  3. Современные платформы (Netflix, AWS, Google) — все строят culture chaos engineering. Это база.

Решение 5. Финансовые инциденты — обязательная эскалация финансовой команде​

Цель: предотвратить катастрофические impulsive actions с реальными деньгами.

Тезисы:

  1. Финансовые операции необратимы (или дороги для отката).
  2. Дежурный в стрессе может принять неправильное решение под давлением.
  3. Эскалация — защита от собственной ошибки.

Открытые развилки​

Развилка 1. Конкретный сервис алертинга​

PagerDuty (commercial) vs OpsGenie (commercial) vs self-hosted (Grafana OnCall, или собственный сервис на базе Уведомления и коммуникации).

Эскалируется: при подготовке к фазе 2 (production launch).

Развилка 2. Степень self-healing автоматизации​

В фазе 3 — автоматизация выполнения safe_immediate шагов без человека. Глубина (от простого toggle feature flag до полной автоматизации targeted mitigation для типовых случаев) — открытая развилка.

Эскалируется: при выходе из фазы 2.

Развилка 3. Outsourcing of L1 on-call​

Возможна модель аутсорсинга L1 on-call (для покрытия 24/7 без раздувания внутренней команды). Каноничные runbook'и — основа возможности аутсорсинга. Решение — открытая развилка.

Эскалируется: при росте инцидентного объёма.

Развилка 4. Federated incident response для Enterprise​

Крупные корпоративные тенанты могут иметь собственные SOC и команды реагирования. Нужна координация между ними и платформой. Глубина (от обмена статусами до совместной работы в реальном времени) — открыта.

Эскалируется: при подписании первого Enterprise-партнёра с собственным SOC.

Развилка 5. Regional incident response​

Многорегиональная инфраструктура (фаза 4) требует региональных команд реагирования и/или follow-the-sun coverage. Конкретная модель — открыта.

Эскалируется: при многорегиональной развёртке.

Связанная документация​

Корневые архитектурные документы​

Связанные операционные документы​

Связанные доменные документы​

Документы развития​

Архитектурные правила​