Прод-простой
Полная недоступность сервиса, потеря данных, security breach. Бизнес теряет деньги каждую минуту.
response15 мин
recovery< 4 ч
resourcesall-hands
S8 · Incident response · 24/7Когда что-то ломается —
Когда что-то ломается —
мы уже работаем.
5 этапов с фиксированным SLA: detect → ack → investigate → mitigate → resolve. Прозрачный лог инцидентов, обязательный post-mortem, no-blame культура. Реакция начинается за 15 минут, не за день.
12 мин
avg MTTR
99.97%
uptime · 14 мес
100%
post-mortem
Что считаем инцидентом
Не «всё что не работает». Чёткое определение: критерий «инцидент = пользовательский impact + срочность». Без споров и серых зон в момент когда нужно действовать.
Формула: impact × urgency × scope
Любая ситуация, которая прерывает запланированную работу команды и требует немедленной реакции. Не баг в backlog, не feature-request. Инцидент — это всегда: «прямо сейчас плохо пользователям и нужно что-то делать».
// impact
Кому больно
Платные клиенты? Free-users? Один сегмент? Internal users? Considers blast radius.
// urgency
Как срочно
Теряются ли деньги каждую минуту? Есть workaround? Возможен ли отложенный fix?
// scope
Сколько затронуто
1 user или 100%? Один регион или global? Один endpoint или весь API?
Что не инцидент
Эти случаи — нормальный flow поддержки или development. Идут через обычные каналы (Linear, email, weekly sync), не через PagerDuty.
- Запрос на новую фичу — в Linear backlog, на ближайший sprint
- Cosmetic-баг, который видит 1 пользователь — в P4 backlog
- Плановое деплой-окно — в weekly sync, не PagerDuty
- Slow API без user impact — в metrics dashboard, не alert
- Вопрос «а как сделать X» — в Slack-канал, не on-call
- Деградация на staging — info в Linear, не P1
4 уровня severity
Чёткие критерии — что считать каким уровнем. Понятная реакция: кто, как быстро, до какого момента. Без споров «насколько критично» когда счёт идёт на минуты.
Частичный сбой
Деградация UX, ошибки у части пользователей, slow response. Бизнес работает, но ощутимо.
response1 ч
recovery< 8 ч
resourceson-call team
Незначительный баг
Workaround есть, UX страдает но работает. Edge-case, влияющий на <1% юзеров.
response4 ч
fixв спринте
resourcesобычный flow
Cosmetic / nice-to-fix
Опечатки, визуальные мелочи, request на улучшение. В бэклоге, без хирургии.
response24 ч
fixbacklog
resourcesslack-канал
5-этапный incident process
Не «как-то разбираемся». Отлаженный playbook на основе SRE-практик Google и Stripe. Каждый этап с owner-ом, артефактом и временем SLA.
Step 01
< 1 мин
Detect
Sentry / Grafana / PagerDuty ловят отклонение от baseline за секунды. Auto-alert если threshold нарушен.
→ alert · PagerDuty
Step 02
< 15 мин
Acknowledge
On-call инженер получает звонок. Принимает alert, открывает war-room в Slack, эскалация если P1.
→ war-room channel
Step 03
10–30 мин
Investigate
Trace через OTel + logs + dashboards. Hypothesis-driven debug, без угадайки. RCA-документация в Slack.
→ RCA hypothesis
Step 04
< 4 ч (P1)
Mitigate
Hotfix через GitOps · rollback · feature-flag · scaling. Цель — вернуть метрики в норму, RCA потом.
→ deploy + monitoring
Step 05
+ 30 мин
Resolve + PM
Подтверждаем что метрики стабильны 30+ минут. Закрываем инцидент. Назначаем post-mortem на D+1.
→ post-mortem doc
Стек monitoring + alerting
Не «у нас есть мониторинг». Конкретный стек best-of-breed, который мы развернули в 30+ продуктах. Каждый инструмент с конкретной ролью.
Se
Sentry
// error tracking
Frontend + backend ошибки в realtime. Source maps, release tracking, performance traces. Alerts на error-rate.
Gr
Grafana + Prometheus
// metrics
Системные метрики, бизнес-KPI, SLO-tracking. Дашборды для CFO + on-call. Alert-rules с эскалацией.
Ph
Posthog
// product analytics
Product events, funnel-analytics, session-replay. Ловит UX-проблемы которые не видны в метриках.
PD
PagerDuty
// on-call rotation
Расписание дежурств, авто-эскалация, integration с Slack/PD-mobile. Звонок инженеру за 15 мин.
Sl
Slack
// communication
War-room каналы для инцидентов, integration с alerts. Shared-канал с клиентом для прозрачности.
OT
OTel + Jaeger
// distributed tracing
Distributed tracing для микросервисов. Видим где именно теряются миллисекунды. Critical для RCA.
Li
Linear
// post-mortem tracking
Action items из post-mortem в Linear. Owner, deadline, статус. Не «обсудили и забыли», а трекинг.
CF
Cloudflare
// WAF + DDoS
WAF, rate-limiting, DDoS-mitigation, edge cache. Многие потенциальные P1 ловятся здесь до прода.
Post-mortem · учимся, не виним
После каждого P1/P2 — обязательный разбор. No-blame culture: смотрим на процесс, а не на людей. Action items с owner и сроком. Публикуем клиенту в shared-канал.
Post-mortem · INC-2024-0142 · Stripe-webhook P1
опубликован · D+1 · 09:32 МСК// что произошло
14:08–15:46 МСК. Error-rate на Stripe-webhook повысился до 14% из-за роста latency на стороне Stripe. Наш timeout 30s не справлялся. Затронуто ~12% transactions, 8 пользователей получили двойное списание (компенсировано).
// метрики инцидента
- ●Detect: 0 мин (sentry alert · auto)
- ●Ack: 1 мин 33 сек
- ●Mitigation: 34 мин
- ●Total MTTR: 1 ч 38 мин
- ●Customer-impact: 8 transactions
// что работало хорошо
- ●Sentry alert сработал за 90 сек
- ●On-call ack за 1 мин 33 сек
- ●OTel trace быстро показал root-cause
- ●GitOps pipeline — deploy за 4 мин
- ●Customer-support уведомил всех затронутых
// что нужно улучшить
- ●Timeout был жёстко зашит — вынесли в env-config
- ●Не было monitoring Stripe-latency напрямую — добавили
- ●Customer-support узнал о problem от юзеров — добавили auto-уведомление
- ●Runbook не покрывал этот сценарий — обновили
// action items
- ●AI-1234 Stripe-latency dashboard · @АИ · D+3
- ●AI-1235 Auto-уведомление CS при P1 · @МД · D+5
- ●AI-1236 Update runbook · @ИК · D+7
- ●AI-1237 Chaos-test для third-party APIs · @АИ · D+14
// no-blame отметка
Это не «виноват on-call» или «плохой код». Это процесс не учёл сценарий внешней latency. Все action-items — про процесс и инструменты. Команда отработала на 10/10 в условиях, которых процесс не предусматривал.
Как мы делаем, чтобы не повторялось
Любой инцидент — это сигнал. Реактивная фиксация — минимум. Превентивная работа — 80% наших усилий. Большинство потенциальных P1 ловим в monitoring до того, как пользователь заметил.
Continuous chaos engineering
Раз в месяц — chaos-engineering день. Сами ломаем сервисы, проверяем reaction. Находим weak spots до того как нашёл production.
→ ежемесячно · 1 день
Synthetic monitoring 24/7
Headless-боты раз в минуту делают полный flow: login → create → pay → logout. Если что-то не работает — alert до того как пожаловался юзер.
→ 60 проверок / минуту
Dependency-сканирование
Renovate + Snyk. Auto-PR на security-патчи, weekly merge tech-debt-обновлений. Зависимости не залёживаются на месяцы.
→ daily scans
Load-test перед каждым релизом
k6 + GitHub Actions. Если новый код медленнее baseline на 10%+ — блокировка release. Не дотягиваем до прод-инцидентов.
→ pre-release gate
Quarterly disaster recovery drill
Раз в квартал — full disaster recovery: восстановление prod-DB из backup, failover в другой регион. Уверены что план работает.
→ 4 раза в год
Security audit + pentest
Quarterly internal audit + annual external pentest. Compliance-questionnaire — готовы к 152-ФЗ, GDPR, ISO 27001 без аврала.
→ 4× audit + 1× pentest / год
Цифры за последние 12 месяцев
Аггрегированные метрики со всех 14 продуктов на support. Прозрачно публикуем — каждый клиент видит свой кусок в shared-канале.
14
продуктов на support
Bronze → Enterprise
99.97%
медианный uptime
по всему портфелю
12 мин
median MTTR
от detect до mitigation
0
SLA нарушений
за последние 12 мес
847
alerts обработано
82% — false positives
23
P1/P2 инцидентов
среднее 2 в месяц
100%
post-mortem написано
опубликовано клиентам
4.8 / 5
client NPS
после каждого инцидента
Частые вопросы
Что обычно спрашивают на discovery про incident response.
Что если ваш on-call инженер заболел / в отпуске?
Rotation из 3 инженеров на каждом продукте. Если primary on-call недоступен — звонок идёт secondary через 5 минут, потом tech-lead через 10 минут. За 14 месяцев — 0 раз когда некому было ответить.
Кто платит за чужие downtime (Stripe / AWS / Google)?
Если корневая причина — third-party (Stripe outage, AWS region down) — это не считается нарушением нашего SLA. Но мы всё равно работаем на mitigation: failover, fallback-режимы. Раз в год обычно бывает 1–2 таких инцидента.
Можно ли получить доступ к нашим dashboards?
Да. На Silver+ — read-only доступ к Grafana и Posthog. На Gold+ — полный доступ + еженедельные slides по метрикам. На Enterprise — co-management мониторингом, ваши инженеры могут менять alerts.
Что входит в SLA по compensations на Gold?
Если uptime за месяц меньше 99.95% — возврат 10× стоимости упущенных часов в виде кредита на следующий месяц. Это не «процент от monthly fee», а реальный расчёт downtime × MRR-impact. За 14 мес работы — 0 раз выплат.
Что делать в момент инцидента нам, клиенту?
Ничего. Серьёзно. У вас отдельный канал в Slack — туда придёт уведомление о начале инцидента, ETA на mitigation, статус. От вас не требуется ничего, кроме одного: быть на связи если у нас вопрос про бизнес-приоритеты.
Как часто обновляется runbook?
После каждого инцидента — обязательно (если он раскрыл gap). Плюс quarterly review всех runbook'ов. Это living document, не «написали 2 года назад и забыли». В Notion с историей изменений.
Что с инцидентами в нерабочие часы?
Это и есть смысл 24/7 поддержки. Bronze — рабочие часы. Silver — 24/7 с дежурным. Gold — именной on-call с гарантированным ack за 15 мин в любое время. Enterprise — dedicated team с разнесёнными timezone (Москва + Калининград).
Кейс · 14 месяцев на Gold
SaaS Spotigo на Gold-tier с 1-го дня после релиза. 14 месяцев работы. Метрики ниже — реальные, верифицированы клиентом.
SaaS · Gold tier · 14 мес
1 P1 за 14 месяцев. Recovery 3.5 ч. SLA не нарушен.
14 месяцев на Gold. Метрики за год: avg MTTR 12 мин, P1 — 1 раз (3h 32m), P2 — 8 раз (avg recovery 4 ч), P3 — 23 раза. 0 compensations выплачено — SLA выдержан всегда. 100% post-mortem опубликованы в shared-канале клиента.
14 месGold tier1 P1 · 8 P2 · 23 P30 SLA нарушений
14 мес
непрерывной работы
1
P1 инцидент
12 мин
avg MTTR
100%
post-mortem
Когда инцидент случится — будем готовы.
30 минут с on-call lead. Обсудим текущий уровень monitoring, runbook, alerts. После звонка — рекомендация SLA-tier и план onboarding в поддержку.