В команде алерты срабатывают по 20-30 раз в день, большинство — ложные или несущественные. Как снизить "шум" без риска пропустить реальный инцидент?

Короткий ответ

Нужно пересмотреть алерты так, чтобы они срабатывали на отклонение от SLO/пользовательского влияния (симптомы), а не на каждое техническое отклонение (причины), настроить разумные пороги и задержки (debounce), и ввести разные уровни серьёзности с разными каналами уведомления.

Как это работает подробнее

алерты "по симптомам" (например, "доля ошибок выше X% дольше Y минут", основанные на error budget burn rate) обычно надёжнее алертов "по причинам" (например, "CPU выше 80%"), потому что высокий CPU сам по себе не всегда означает проблему для пользователя. Каждый алерт должен быть actionable — если дежурный получает алерт и не может/не должен ничего делать, это кандидат на удаление или понижение уровня.

Пример / кейс

Ожидаемое поведение: такой алерт срабатывает только когда реальная доля ошибок угрожает SLO в ускоренном темпе, а не на любое кратковременное колебание CPU — количество ложных срабатываний должно заметно снизиться при сохранении чувствительности к реальным деградациям.

Пример кода

example.yamlКопировать

# Пример alerting-правила на burn rate error budget вместо сырого CPU
- alert: ErrorBudgetFastBurn
  expr: |
    (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])))
    > (14.4 * 0.001)  # SLO 99.9%, порог быстрого сгорания бюджета
  for: 5m
  labels:
    severity: critical

Что использовать на практике

• Практический подход. Проводят аудит существующих алертов — для каждого смотрят историю срабатываний за последний месяц и результат (было ли реальное действие дежурного); алерты без action переводят в разряд информационных (без пейджинга, только в дашборд/тикет) или удаляют; вводят burn rate алерты на error budget (быстрое сгорание бюджета — критический алерт, медленное — информационный).

Подводные камни

• Частые ошибки. Снижать "шум" просто повышая пороги без анализа, что приводит к пропуску реальных инцидентов; алертить на каждую отдельную метрику ресурса вместо агрегированного влияния на пользователя; не разделять каналы оповещения по severity, из-за чего дежурный одинаково реагирует (или одинаково игнорирует) на критичные и мелкие алерты.