PagerDuty / On-call
Тема дорожной карты · Observability
PagerDuty — платформа управления инцидентами и расписаниями дежурств, связывающая системы алертинга наблюдаемости с людьми, ответственными за реагирование на продакшен-инциденты. Она интегрируется с Alertmanager, Grafana, Datadog и практически любым другим инструментом наблюдаемости через вебхуки или нативные интеграции, маршрутизируя высокоприоритетные алерты к нужному дежурному инженеру на основе настраиваемых политик эскалации. Политики эскалации PagerDuty определяют, кто получает вызов первым, как долго ждать перед эскалацией и кто является конечным адресатом эскалации, — гарантируя, что критические инциденты никогда не остаются без ответа. Расписания дежурства в PagerDuty распределяют операционную нагрузку между членами команды с возможностью замен при запланированном отсутствии и заметками при передаче для преемственности контекста. Эффективное управление дежурством с помощью PagerDuty включает отслеживание среднего времени до подтверждения (MTTA) и среднего времени до устранения (MTTR) как метрик наблюдаемости самого процесса реагирования на инциденты.
Как это работает
PagerDuty / On-call соединяет observability-данные с людьми через on-call ротации. Инструменты: Alertmanager (Prometheus-native), Grafana Alerting (multi-source), PagerDuty / OpsGenie / Squadcast (incident management поверх). Правила оценивают metrics/logs/traces-запросы; срабатывают при for: 5m; роутятся по labels (severity: page vs severity: ticket); идут в каналы (PagerDuty, Slack, Telegram, webhook). SLO burn-rate alerts — современный best practice.
Когда применять
Алертите на симптомы (SLO burn rate, error rate, latency), не на причины (CPU, RAM). Multi-window multi-burn-rate alerts — fast pages для внезапно-плохого, slow tickets для постепенной деградации. Всегда runbook URL в annotations. Тестируйте алерты в staging до production. Аудитьте alert fatigue раз в квартал — убивайте алерты, на которые никто не реагирует.
Типичные ошибки
Ловушки PagerDuty / On-call: pages на инфра-метриках, не затрагивающих юзеров (CPU > 80% на 12-ядерном боксе в 3:00 на non-user-facing job); flapping-алерты (нет for:); алерты без runbook = хаос в 3:00; все алерты в один Slack-канал (alert fatigue).