Операции и Управление → Предотвращение инцидентов

Предотвращение инцидентов

1) Зачем это нужно

Лучшая реакция на инцидент — это его отсутствие. Для iGaming/финтеха каждая минута простоя — потерянные ставки/депозиты, штрафы от провайдеров, репутационные риски. Системная профилактика снижает Change Failure Rate, стабилизирует SLO и высвобождает время команд для развития, а не тушения пожаров.

• Свести к минимуму вероятность инцидентов на критичных путях (депозит, ставка, запуск игры, вывод).
• Перехватывать деградации до удара по SLO и кошельку.
• Ограничить радиус отказа (blast radius) и ускорить восстановление.

2) Базовые принципы профилактики

1. SLO-first и error budget: изменения не выпускаются, если рискуют выбить SLO и сжечь бюджет.
2. Defence in depth: слои защит — от схем данных и конфигов до сетевых политик и фичефлагов.
3. Design for failure: брейкеры, таймауты, ретраи с джиттером, идемпотентность, деградации.
4. Small & reversible changes: маленькие инкременты + быстрый откат (feature flags/канарейка).
5. Observability by design: метрики/логи/трейсы для каждого критичного шага и связи.

3) Карта рисков и критичных путей

Составьте «карту боли» по доменам: Payments, Bets, Games, KYC, Promotions, Jackpots, Content.

• Бизнес-метрики (конверсия, GGR, средний чек).
• Технические SLO (latency p95/p99, uptime, success rate).
• Зависимости (внутренние/внешние), лимиты/квоты.
• «Safe mode» поведение (что отключаем/упрощаем).
• Runbook владельца.

4) Guardrails (защитные барьеры)

Таймауты и брейкеры: у вызывающего сервиса таймаут короче суммы внутренних; брейкер открывается при росте ошибок/латентности.
Bulkhead-изоляция: отдельные пулы соединений/воркеров на даунстримы.
Rate limit & backpressure: защита от лавин и ретрай-штормов.
Фичефлаги деградации: «минимальный режим» — легкие ответы, кэш-реплаи, отключение тяжелых фич.
Мульти-вендор и фейловер: альтернативные PSP/KYC, переключение маршрутов.
Валидация конфигов: схемы/линеры/политики для безопасного изменения фич и лимитов.

5) Управление изменениями (Change Management)

Pre-release gates: тесты, безопасность, CDC (consumer-driven contracts), совместимость схем.
Канареечный релиз + автогейты: 1% → 10% → 100%; авто-стоп при росте p99/error rate/бюджета сгорания.
Feature flags: мгновенный откат/переключение поведения без деплоя.
Release calendar: избегаем пиковых окон спорта/турниров и maintenance у провайдеров.
Post-deploy checks: автосмок, сравнение метрик «до/после» с порогами.

6) Тестирование как превентивная мера

Unit/contract/integration: контракты OpenAPI/AsyncAPI, CDC против провайдера/мока.
Load & stress: профили трафика для прайм-тайма; тесты на лимиты коннектов/IOPS/квот.
Soak/long-haul: утечки ресурсов, рост задержек на горизонте часов/дней.
Chaos/game-days: падение брокера/PSP/KYC, разрыв региона, «медленный провайдер».
Disaster Recovery Drills: регулярные тренировки переключения регионов и восстановления БД.

7) Раннее обнаружение деградаций

Capacity-alerts: headroom, лаги очередей, коннекты БД, eviction в кэшах.
SLO-burn-rate: сигнал при опасной скорости «сжигания» бюджета.
Адаптивные пороги: сезонность/суточные шаблоны для снижения ложных.
Составные алерты: «lag ↑ + HPA at max + open circuit» ⇒ высокий риск.
Vendor health: квоты/таймауты/ошибки по каждому провайдеру + стоимость вызовов.

8) Работа с внешними провайдерами

OLA/SLA ↔ SLO: привязка договоренностей к нашим целям.
Playbooks фейловера: маршруты PSP-X ⇆ PSP-Y, кэш токенов, grace-режимы депозитов.
Сэндбоксы и контракты: тестовые флоу перед каждым мажорным изменением.
Окна провайдеров: аннотации на дашбордах и автоматические suppress-правила.

9) Данные, конфиги и секреты

Политики изменений: code-review двух пар глаз, валидация схем/JSON/YAML.
Секреты: KMS/Secrets Manager, ротация, разделение по окружениям/ролям.
Флаги/лимиты: изменение через API с аудитом и мгновенным откатом.
Миграции: «двухшаговые» (expand → migrate → contract), суммарная обратная совместимость.

10) Обучение и готовность команд

On-call тренинги: симуляции инцидентов, Shadow-дежурства, централизованные runbook’и.
Единые форматы коммуникаций: шаблоны статусов/хендоверов/инцидент-апдейтов.
Безопасная культура: постмортем без обвинений, механистические причины и превентивные действия.

11) Дашборды профилактики (минимум)

Risk & Readiness: SLO/бюджет, headroom по слоям, «топ уязвимых связей».
Change Safety: процент канареек, откаты, алерты «после релиза», CTR автогейтов.
Vendor Panel: p95/error/квоты/стоимость по каждому провайдеру, время ответа саппорта вендора.
Chaos/DR Readiness: частота упражнений, время переключения региона, успешность восстановлений.
Config/SecOps: изменения флагов/лимитов/секретов, аномалии.

12) Примеры превентивных алертов

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) Чек-лист предотвращения (ежедневно/перед пиками)

• Актуальный календарь пиков (матчи, турниры, кампании, окна провайдеров).
• Headroom по API/БД/кэшам/очередям, готовность HPA/VPA, прогрев кэшей.
• Состояние провайдеров (квоты, лимиты, деградации за 24ч), настроен фейловер.
• Канареечные гейты включены, фичефлаги отката доступны владельцам.
• Алерты SLO/Capacity активны, suppression прописан на плановые работы.
• Runbook’и обновлены, on-call подтвержден, каналы эскалаций рабочие.

14) Анти-паттерны (чего избегать)

«Большие ночные релизы» без канарейки и флагов.
Общие пулы потоков на все даунстримы (head-of-line blocking).
Ретраи на неидемпотентные операции и на таймауты узких мест.
Отсутствие гистерезиса в алертах → пиление по порогу.
Слепая вера в SDK вендора без наблюдаемости и управления таймаутами.
«Сделаем в проде» без стейджа/сандбокса и CDC.

15) KPI профилактики

Change Failure Rate (цель ≤ 10–15% либо ваша целевая).
Pre-Incident Detect Rate: доля инцидентов, предотвращенных на стадии деградации.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage защит: % критичных путей с флагами/брейкерами/таймаутами/канарейкой.
Chaos/DR cadence: частота и успешность учений.
Vendor readiness: среднее время переключения на резервного провайдера.

16) Быстрый старт (30 дней)

Неделя 1: карта критичных путей, SLO и владельцы; включить SLO-burn-алерты и capacity-алерты.
Неделя 2: канареечные гейты + фичефлаги; базовые chaos-сценарии (провайдер/очередь).
Неделя 3: дашборды «Change Safety» и «Vendor Panel», фейловер-плейбуки.
Неделя 4: DR-учение (частичное), ретроспектива и план hardening’а на квартал.

17) Шаблоны (фрагменты)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q: Что внедрить в первую очередь, если ресурсов мало?
A: SLO-burn-алерты на критичных путях, канареечные гейты и фичефлаги отката; затем — карта рисков и фейловер провайдеров.

Q: Как понять, что профилактика «работает»?
A: Снижается Change Failure Rate, растет доля предотвращенных инцидентов, падает MTTR и шум алертов, уменьшается количество «ночных» пейджей.

Q: Нужны ли регулярные chaos-учения?
A: Да. Без тренировки фейловер и DR почти всегда дольше и болезненнее, чем кажется на бумаге.