Какие знаешь правила для алертов?

Моя философия построения эффективных алертинговых систем

В основе моего подхода лежит принцип «алерты должны требовать действий, а не просто информировать». За 10+ лет работы с системами мониторинга я выработал набор правил, которые превращают алертинг из источника стресса в мощный инструмент поддержания стабильности.

Золотые правила алертинга

1. Правило действия (The Rule of Action)

Каждый алерт должен отвечать на вопрос «Что я должен сделать?». Алерт без четкого действия — это шум. При проектировании проверяю:

# ПЛОХО: CPU usage > 80%
# ХОРОШО: CPU usage > 80% for 5min - проверьте очередь обработки и автомасштабирование

2. Правило 3-2-1 для эскалации

• 3 минуты — время реакции первичной команды
• 2 эскалации — максимум до уведомления ответственного инженера
• 1 человек принимает решение о дальнейших действиях

3. Градация по критичности

Я использую четыре уровня, каждый со своим SLA и процедурой:

4. Правило подавления шума

Любой алерт, который срабатывает чаще 3 раз в сутки без реальных инцидентов, требует пересмотра порогов или логики. Использую алгоритмы подавления:

# Пример подавления частых срабатываний
from datetime import datetime, timedelta

class AlertThrottler:
    def __init__(self, max_alerts_per_hour=3):
        self.alert_times = []
        self.max_alerts = max_alerts_per_hour
    
    def should_alert(self):
        now = datetime.now()
        hour_ago = now - timedelta(hours=1)
        
        # Удаляем старые алерты
        self.alert_times = [t for t in self.alert_times if t > hour_ago]
        
        if len(self.alert_times) >= self.max_alerts:
            return False  # Подавляем алерт
            
        self.alert_times.append(now)
        return True

5. Контекстное обогащение

Каждый алерт должен содержать достаточно информации для диагностики. Мой минимальный набор данных:

• Что сломалось? (конкретный сервис, компонент)
• Где? (регион, датацентр, хост)
• Когда? (время начала и продолжительность)
• Насколько плохо? (процент отклонения от нормы)
• Связанные метрики (коррелирующие показатели)
• Возможные причины (последние изменения)

6. Автоматическое восстановление vs. алерт

Если проблему можно исправить автоматически, она не должна генерировать алерт для человека. Например:

• Автоскейлинг реагирует на нагрузку
• Перезапуск зависших процессов по health check
• Переключение трафика на здоровые инстансы

7. Руководство по порогам

Статические пороги работают плохо. Я предпочитаю динамические:

• Процентное отклонение от базовой линии (например, +30% от нормы)
• Скользящие окна для сезонных паттернов
• Аномалии на основе ML, если система позволяет

# Пример динамического порога в Prometheus
- alert: HighRequestLatency
  expr: |
    # Сравниваем с недельной историей
    histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
    > 
    avg_over_time(
      histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))[7d]
    ) * 1.5  # Превышение на 50% от исторической нормы
  for: 10m

8. Обязательные ревизии

Раз в квартал проверяю:

• False positive rate (должен быть < 5%)
• Alert fatigue (кто и как часто игнорирует алерты)
• Среднее время восстановления для каждого типа алерта
• Эффективность эскалаций

9. Принцип единственного источника истины

Все алерты должны сходиться в единой панели управления. Я избегаю ситуаций, когда:

• Разные команды получают разные алерты на одну проблему
• Нет единого взгляда на состояние системы
• Сложно определить root cause из-за разрозненных данных

Практическая реализация

В реальных проектах я создаю Alert Playbooks — живые документы, которые содержат:

1. Условия срабатывания с примерами
2. Пошаговую диагностику
3. Стандартные методы восстановления
4. Контакты ответственных
5. Историю инцидентов и уроки

Главный показатель эффективности алертинга — не количество алертов, а время между их получением и полным пониманием ситуации. Хорошая система алертинга превращает инциденты из катастроф в управляемые рабочие процессы, где каждый знает свою роль и последовательность действий.