Когда on-call канал переполнен, первая просьба обычно звучит так: давайте настроим thresholds. Иногда это убирает очевидную ошибку. Но редко лечит alert fatigue надолго, потому что усталость — не число в PromQL. Это результат размытой ответственности, смешанных приоритетов и pages, которые не соответствуют решению.
Я перестраиваю alerting от ожидаемой реакции. Rule появляется последним. Сначала нужно определить, какое обещание сервиса под угрозой, кто способен действовать и насколько быстро требуется решение человека.
Каждое уведомление я классифицирую по действию
Page прерывает человека и поэтому должен иметь высокий порог. Он означает заметный user impact или непосредственную угрозу ему, требует своевременного действия и приходит владельцу, который может изменить исход. Остальное должно стать ticket, dashboard, automated remediation или быть удалено.
Такая классификация часто убирает больше шума, чем настройка threshold, потому что обнаруживает alerts, созданные только из-за существования метрики. Рекомендации Prometheus формулируют тот же принцип: alerts должны быть простыми, сообщать о симптомах и не будить человека, если действий нет.
- Page: срочно, влияет на пользователя, требует действия сейчас
- Ticket: нужен владелец, но не прерывание
- Dashboard: контекст для расследования
- Delete: от сигнала не зависит ни одно решение
Ownership — часть определения alert
Маршрут в общий канал не является ownership. Я требую accountable service team, severity, первое действие и review date. Если ни одна команда не может владеть реакцией, организация нашла проблему границ сервиса, а не проблему alert routing.
Я также разделяю platform symptoms и product symptoms. Событие на Kubernetes node может быть полезным контекстом, но page обычно должен описывать обещание сервиса, которое оказалось под угрозой. Иначе первые минуты on-call переводит инфраструктурное условие в возможное влияние на клиента.
SLO дает paging понятную рамку
Для критичных сервисов я связываю paging с service level objectives и расходованием error budget. Burn-rate alert отвечает на более полезный вопрос, чем статический resource threshold: расходуется ли reliability budget настолько быстро, что человек должен вмешаться сейчас?
Я не применяю один SLO template ко всем сервисам. Indicator, target и response window должны соответствовать обещанию продукта. Multi-window, multi-burn-rate alerting позволяет заметить быстрый ущерб и подтвердить его устойчивость, а также увидеть медленную потерю budget без чрезмерной чувствительности срочного канала.
SLO полезен, когда меняет приоритет. Процент на слайде еще не является operating model.
Только затем я настраиваю и тестирую rules
После определения политики threshold и duration становятся понятной инженерной настройкой. По возможности я воспроизвожу недавние инциденты, проверяю поведение предлагаемых rules и провожу контролируемые failure tests. В review входят и пропущенные pages: тишина не является успехом, если реальный user impact стал невидимым.
У каждого page появляется owner и expiry или review date. Сервисы и трафик меняются, alerts деградируют. Небольшое регулярное review дешевле очередной большой очистки после того, как канал снова перестал работать.
Результат — доверие, а не ноль уведомлений
Я не пытаюсь сделать on-call канал пустым. Я хочу, чтобы прерыванию доверяли. Когда инженер знает, что page означает реальное решение, реакция ускоряется, а reliability можно обсуждать на одном языке.
Это доверие возникает из явного контракта между product risk, service ownership и operational action. PromQL реализует контракт, но не заменяет его.
