Кто пейджит пейджер?

На Reddit наткнулся на прекрасный по боли тред: "PagerDuty went down and my day went straight to hell".

Ситуация знакомая: система, которая должна будить on-call, сама деградирует. Инциденты создаются с задержкой, уведомления не доходят, UI тупит, а ты думаешь: "всё хорошо или я просто ослеп?"

И это не абстрактный страх. У PagerDuty есть разбор инцидента 28 августа 2025.
Там проблема в Kafka привела к деградации обработки событий, задержкам уведомлений, webhooks, REST API и chat integrations. Часть событий могла получать 502, а при восстановлении пошёл backlog.

Когда ломается paging-платформа, у вас не "просто не пришла SMS". У вас ломается нервная система production.

Плохая новость: PagerDuty, Opsgenie, incident.io, Slack, SMS-шлюз и ваш любимый webhook - это тоже зависимости.
Хорошая новость: их можно проектировать как зависимости, а не как магическую трубу.

Alerting != paging
Алертинг - это где рождается сигнал: Prometheus, Grafana, Datadog, CloudWatch, Zabbix.

Paging - это как сигнал доезжает до человека: PagerDuty, Opsgenie, Grafana OnCall, самописный бот, SMS, email, Slack, Telegram - или что там у вас.

Если единственный способ понять, что прод горит, - открыть ваш paging tool, то у вас не incident management. У вас single point of panic.

Критичные алерты должны иметь обходной путь
Не надо дублировать каждый warning в пять каналов, иначе on-call начнёт ненавидеть жизнь.

Для P0/P1 должен быть fallback:
- email напрямую из monitoring source;
- резервный Slack/Telegram канал;
- отдельный webhook;
- внешний synthetic check;
- status page watcher для критичных SaaS;
- ручной режим "смотрим главные SLI dashboards".

Звучит дедовски, но когда paging лежит, дедовские методы внезапно становятся enterprise-grade.

Надо мониторить не только сервисы, но и путь алерта
Типичный антипаттерн: сервис мониторится, Prometheus мониторится, Alertmanager мониторится, а дальше сигнал улетает в SaaS: "ну там серьёзные ребята, они сами себя мониторят".

Серьёзные ребята тоже падают.

Минимальный healthcheck:
- тестовый алерт раз в сутки/неделю;
- проверка, что он дошёл до нужного канала;
- проверка escalation policy и schedule;
- алерт, если status page paging-провайдера красная;
- понятный runbook: что делаем, если paging не работает.

Да, получается "мониторинг мониторинга мониторинга". Добро пожаловать в SRE.

При падении paging нужен emergency mode
Не надо героически продолжать обычный день, если вы не уверены, что пейджинг работает.

Нормальная реакция:
- объявить change freeze;
- вручную смотреть ключевые SLI dashboards;
- смотреть критичные user journeys;
- перевести коммуникацию в заранее известный fallback-канал;
- отключить шумные некритичные алерты, чтобы видеть реальный impact;
- после восстановления разобрать не только vendor outage, но и свою слепоту.

Потому что вопрос не "почему PagerDuty упал?". Любой vendor или самописный бот может упасть.

Вопрос: почему его падение сделало вас слепыми?

Vendor redundancy - не серебряная пуля
Можно подключить два paging tools. Можно три. Можно отправлять SMS через двух провайдеров и email через отдельный домен.

Но если все они получают один и тот же кривой шум без SLO, ownership и severity - вы просто построили отказоустойчивую машину для доставки мусора.

Сначала качество сигнала. Потом резервирование доставки.
Моя позиция простая: paging path - это часть production. Его надо проектировать, тестировать и разбирать в постмортемах как базу, очередь или API gateway.

Если вопрос "а что если это упадёт?" задаётся к базе и очереди, он должен задаваться и к on-call tooling.

Иначе однажды будет тихо. Очень тихо. А потом внезапно напишет клиент.

Вопрос к вам: у вас есть backup path для P0/P1, если основной paging внезапно умер?

#sre #oncall #alerts #incidentresponse #observability