Эта глава темы 11 фокусируется на incident response процессе, эскалации и postmortem-практике.
В реальном проектировании и эксплуатации систем материал помогает задавать измеримые reliability-цели, выбирать инженерные механики устойчивости и снижать стоимость инцидентов на масштабе.
Для System Design interview глава полезна тем, что формирует ясную operational-аргументацию: как вы проверяете надежность, где находятся риски деградации и какие guardrails закладываете заранее.
Практическая польза главы
Практика проектирования
Переводите знания о incident response процессе, эскалации и postmortem-практике в конкретные эксплуатационные решения: интерфейсы алертинга, runbook-границы и rollback-стратегии.
Качество решений
Оценивайте архитектуру через SLO, error budget, MTTR и устойчивость critical-path, а не только через функциональную полноту.
Interview articulation
Структурируйте ответ вокруг reliability lifecycle: сигнал деградации, реакция, локализация причины, восстановление и профилактика повторов.
Trade-off framing
Явно фиксируйте компромиссы по incident response процессе, эскалации и postmortem-практике: скорость релизов, уровень автоматизации, стоимость observability и операционная сложность.
Primary source
Google SRE: Emergency Response
Классический разбор того, как строить управляемую реакцию на инциденты в production.
Incident Management - это отдельная инженерная дисциплина, а не набор ad-hoc действий во время аварии. Она определяет, как команда обнаруживает проблему, координирует on-call, принимает решения об эскалации и превращает инцидент в системные улучшения.
В связке с Observability & Monitoring Design и SLI/SLO-практикой incident management задает рабочую модель: кто отвечает за реакцию, когда нужно эскалировать и как закреплять уроки через postmortems.
Почему это дисциплина
Единая операционная модель
Incident management связывает detection, triage, mitigation, коммуникации и recovery в один управляемый процесс.
Четкие роли и ответственность
Во время инцидента команда не спорит о том, кто принимает решения: есть Incident Commander, owner сервиса и каналы эскалации.
Цикл обучения после инцидента
Blameless postmortem переводит инцидент из стресса в инженерные улучшения: action items, владельцы, сроки и контроль результата.
Incident lifecycle: от сигнала до обучения
1. Detection и triage
Сигнал из мониторинга/алерта подтверждается через impact на пользователя, после чего назначается severity и owner реакции.
2. Stabilization
Приоритет - ограничить ущерб: rollback, feature flag off, traffic shaping, отключение проблемного dependency или read-only режим.
3. Escalation
Если окно восстановления срывается или затрагивается критичный пользовательский поток, вызываются дополнительные специалисты по заранее описанным правилам.
4. Recovery
После стабилизации команда восстанавливает нормальный SLA/SLO, проверяет консистентность данных и закрывает временные workaround-механизмы.
5. Postmortem и follow-up
Команда фиксирует timeline, root cause, contributing factors и набор инженерных изменений, которые снижают риск повторения.
On-call модель
Каждый page-alert должен иметь owner, runbook и понятный expected response time.
On-call смена не должна быть «слепой»: обязательны handoff-ритуалы и актуальный контекст по рисковым зонам.
Escalation policy хранится рядом с operational документацией и регулярно тестируется на game day/симуляциях.
Дежурство проектируется как устойчивая практика: ограничение нагрузки, замена смен и понятная компенсация.
Escalation matrix
| Severity | Триггер | Первое действие | Кого эскалируем | Макс. задержка |
|---|---|---|---|---|
| SEV-1 | Недоступен критичный пользовательский путь или массовая потеря транзакций | Немедленный созвон war-room, фиксация Incident Commander | Platform/SRE lead, security и бизнес-дежурный | 0-5 минут |
| SEV-2 | Сильная деградация latency/error rate без полной остановки сервиса | Triage on-call + owner сервиса, ограничение blast radius | Соседние команды по зависимостям и release owner | 10-15 минут |
| SEV-3 | Локальная проблема без заметного бизнес-ущерба | Обработка по runbook в рамках текущей смены | При необходимости - в рабочее время продуктовой команды | До 1 часа |
Postmortem: обязательный выход инцидента
Impact: кого затронул инцидент, как измеряли ущерб и как долго длилась деградация.
Timeline: хронология событий, действий и точек принятия решений.
Root cause и contributing factors: технические и процессные причины без поиска виноватых.
Action items: конкретные изменения с owner, дедлайном и ожидаемым снижением риска.
Verification: как команда проверит, что изменения действительно снизили вероятность повторения.
Метрики зрелости Incident Management
MTTD
Время от начала деградации до обнаружения
MTTA
Время до подтверждения инцидента и назначения owner
MTTR
Время до восстановления пользовательского пути
Repeat Incident Rate
Доля повторных инцидентов на одну и ту же root cause
Escalation Quality
Доля инцидентов с корректной severity и своевременной эскалацией
Частые антипаттерны
Считать, что incident management = только чат в мессенджере без ролей, SLA реакции и формального owner.
Эскалировать слишком поздно из-за страха «потревожить» соседние команды или менеджмент.
Проводить postmortem как ритуал без action items с владельцами и дедлайнами.
Оценивать on-call только по количеству закрытых алертов, игнорируя качество triage и снижение повторяемости.
Рекомендации
Описать incident lifecycle как стандарт команды: detection -> triage -> mitigation -> recovery -> learning.
Сделать escalation policy частью инженерного контракта: условия вызова, роли, каналы и SLA реакции.
Стандартизировать шаблон postmortem и связывать каждый action item с метрикой риска или MTTR.
Проводить регулярные incident drills, чтобы on-call и эскалации работали под нагрузкой, а не только на бумаге.
References
Связанные главы
- SLI / SLO / SLA и Error Budgets - задаёт базовые сигналы, через которые назначается severity и оценивается impact инцидента.
- Observability & Monitoring Design - показывает, как проектировать алерты и runbooks для быстрого detection и triage.
- Troubleshooting Interview - тренирует практические навыки диагностики и принятия решений во время продовых сбоев.
- The Site Reliability Workbook (short summary) - дополняет главу прикладными практиками incident response, on-call и postmortem-культуры.
- Эволюция SRE: внедрение AI-ассистента в Т-Банке - показывает, как incident management масштабируется через платформизацию и автоматизацию.