DevOps
On-Call и Incident Management
В 2021 году Facebook был недоступен 6 часов из-за ошибки конфигурации BGP. Ущерб - $60M потерянной выручки и 3.5B пользователей без сервиса. Их incident management процесс отработал: правильная эскалация, быстрая диагностика, postmortem без поиска виноватых. Плохой incident management превращает 30-минутный outage в 6-часовой хаос.
- **Netflix** публикует все postmortems публично - это стало индустриальным стандартом blameless культуры и помогло сотням компаний избежать аналогичных инцидентов
- **Atlassian** использует runbook automation: при OOM в production автоматически выполняется heap dump, сервис перезапускается, и только потом будится on-call - MTTR сократился с 15 до 3 минут
- **AWS** управляет тысячами on-call ротаций через собственную систему на базе PagerDuty - каждый engineer проводит 1 неделю в месяц в дежурстве, что создаёт прямую обратную связь с надёжностью кода
PagerDuty и Alerting
PagerDuty - платформа управления инцидентами: получает алерты от Prometheus, Datadog, Cloudwatch, Grafana и уведомляет дежурного инженера (on-call) через SMS, звонок, Slack. Ключевой механизм - escalation policy: если дежурный не отвечает за 5 минут, алерт идёт следующему в цепочке.
Критически важно избегать alert fatigue - состояния когда инженеры начинают игнорировать алерты из-за их количества. Правило: алерт должен требовать действия человека. Если ничего не нужно делать - это не алерт, это информация. Google SRE рекомендует: алерт = угроза SLO, всё остальное - в dashboard.
Что такое alert fatigue и почему это опасно?
Runbooks
Runbook - пошаговая инструкция для обработки конкретного инцидента. Инженер в 3 ночи не должен думать - он должен следовать инструкции. Хороший runbook: ссылка в алерте → диагностика (какие команды запустить) → митигация (как остановить ущерб) → эскалация (когда звонить следующему человеку).
Runbook должен быть живым документом: после каждого инцидента обновлять пропущенные шаги. Автоматизированные runbooks (runbook automation) в PagerDuty или Rundeck выполняют первые шаги автоматически: перезапуск сервиса, очистка кэша, масштабирование вверх - без пробуждения инженера. Это снижает MTTR (Mean Time To Restore) в разы.
Какой главный принцип хорошего runbook?
Postmortem
Postmortem (или incident review) - документ, анализирующий инцидент после его устранения. Цель - найти root cause и предотвратить повторение, не найти виноватых. Google и Amazon культивируют blameless postmortem: люди действовали рационально с учётом информации которая у них была в тот момент.
Структура postmortem: Impact (что и кто пострадал, $-эквивалент), Timeline (хронология событий), Root Cause (настоящая причина, не симптом), Contributing Factors (что способствовало), Action Items (конкретные задачи с ответственными и дедлайнами). Action Items без owner и deadline - это просто список желаний.
Что означает принцип 'blameless postmortem'?
Escalation и SLA/SLO
SLA (Service Level Agreement) - контракт с клиентом: '99.9% uptime в месяц, иначе возврат денег'. SLO (Service Level Objective) - внутренняя цель: '99.95% uptime' (выше SLA чтобы был буфер). Error budget = 1 - SLO: при 99.9% SLO error budget = 43.8 минуты в месяц. Escalation policy определяет кто отвечает при разных severity.
Severity levels в production компаниях: SEV1 = полный outage, бизнес критично, будить всех, звонить VP; SEV2 = значительная деградация, будить on-call + team lead; SEV3 = минор, плановое рабочее время; SEV4 = улучшение, в следующий спринт. Автоматическое эскалирование через PagerDuty если acknowledge не пришло за N минут.
SLA и SLO - это одно и то же, просто разные названия
SLA - внешний контракт с клиентом с финансовыми последствиями (99.9%). SLO - внутренняя цель команды, всегда выше SLA (99.95%) чтобы нарушение SLO стало сигналом до нарушения SLA
Если SLO = SLA, первое же незначительное нарушение SLO уже нарушает клиентский договор. Буфер между ними даёт команде время реагировать
Что такое Error Budget в контексте SLO?
Ключевые идеи
- **PagerDuty + умные алерты** - алерт только если угрожает SLO; escalation policy гарантирует что инцидент не останется без ответа
- **Runbook** - пошаговая инструкция без необходимости думать в 3 ночи: диагностика → митигация → эскалация → rollback
- **Blameless postmortem + Error Budget** - системный анализ причин и конкретные Action Items предотвращают повторение; error budget балансирует надёжность и скорость разработки
Связанные темы
Incident management опирается на мониторинг и логирование:
- ELK Stack и логирование — Kibana - первый инструмент on-call инженера при расследовании инцидента по логам
- Distributed Tracing — Jaeger помогает быстро локализовать проблемный сервис при инциденте в микросервисной архитектуре
Вопросы для размышления
- Как определить правильный severity level для инцидента который затрагивает 5% пользователей но 100% платежей?
- Что нужно чтобы blameless postmortem действительно работал, а не был формальностью?
- При error budget 99.9% SLO - стоит ли проводить плановые учения (game days) если бюджет почти исчерпан за первые 2 недели месяца?