Alerting — когда бить тревогу

Alerting в контексте производительности — автоматическое уведомление команды при выходе метрик (LCP, TTFB, error rate, conversion) за пороговые значения, что позволяет реагировать на деградацию до того, как её заметят пользователи.

Зачем нужно

Без алертов деградация производительности обнаруживается через жалобы пользователей — в среднем через 6+ часов. Правильно настроенные алёрты позволяют реагировать за минуты. Ключевой принцип: алёрт только тогда, когда требуется действие человека.

Где используется

  • Мониторинг Core Web Vitals: LCP > 2.5s, CLS > 0.1, INP > 200ms
  • Инфраструктурные метрики: CPU, Memory, disk I/O
  • Бизнес-метрики: конверсия, error rate, latency API
  • Uptime monitoring: availability < 99.9%

Основной контент

Уровни алертов (severity)

P1 Critical  → Немедленное действие, 24/7 on-call (сервис недоступен)
P2 High      → Реакция в рабочее время (деградация >50%)
P3 Medium    → Планирование на следующий день (тренд ухудшения)
P4 Low       → В backlog следующего спринта

Пороговые значения для производительности

# Примерная конфигурация алертов

# Core Web Vitals (75-й перцентиль)
lcp_p75:
  warning: 2500ms    # "Needs Improvement"
  critical: 4000ms   # "Poor"

cls_p75:
  warning: 0.1
  critical: 0.25

inp_p75:
  warning: 200ms
  critical: 500ms

# Инфраструктура
api_latency_p99:
  warning: 1000ms
  critical: 3000ms

error_rate_5xx:
  warning: 1%       # 1% запросов с ошибками
  critical: 5%

availability:
  critical: 99%     # SLA нарушен

Grafana Alert Rule (YAML)

# Grafana Alerting rule
apiVersion: 1
groups:
  - name: performance
    rules:
      - alert: HighLCP
        expr: |
          histogram_quantile(0.75,
            sum(rate(web_vitals_lcp_bucket[5m])) by (le, page)
          ) > 2500
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "LCP p75 > 2.5s on {{ $labels.page }}"
          description: "Current value: {{ $value }}ms"
          runbook: "https://wiki.example.com/runbooks/lcp"

Alert fatigue — борьба с шумом

Правила хорошего алёрта:
✓ Требует действия человека
✓ Actionable — понятно, что делать
✓ Ссылка на runbook
✓ Правильный получатель (не "весь slack канал")

Признаки плохого алёрта:
✗ Срабатывает чаще 1 раза в 24h без действий
✗ Нет runbook или описания
✗ Автоматически разрешается без действий
✗ Дублирует другой алёрт

Частые ошибки

  • Слишком чувствительные пороги — alert fatigue, команда игнорирует алёрты
  • Алёрты без runbook — никто не знает, что делать при срабатывании
  • Алёрты по средним значениям вместо перцентилей — среднее скрывает проблему хвоста
  • Отсутствие on-call ротации — один человек получает все ночные алёрты

Связанные темы

Ресурсы