Уведомления и алерты

Что такое нотификация

Нотификация (от англ. notification, «уведомление») — сообщение, которое система сама отправляет пользователю или другой системе, когда произошло значимое событие. Ключевое здесь — инициатива на стороне системы: не пользователь спрашивает «что нового», а система сообщает сама. Пришло письмо, списались деньги, закончилось место на диске — все эти сообщения нотификации.

Слово пришло из интерфейсов и прижилось в русском IT-жаргоне как есть; «нотификации» и «уведомления» в разговоре взаимозаменяемы.

Технически доставка бывает двух видов:

• Push — сервер сам инициирует доставку в момент события. Быстро, но требует постоянного соединения или сервиса доставки (APNs, FCM, WebSocket).
• Pull (polling) — клиент периодически спрашивает сервер, нет ли новостей. Проще, но либо запаздывает, либо нагружает сервер лишними запросами.

Пуш-код в обиходе — одноразовый код подтверждения, доставленный push-уведомлением в приложение вместо SMS. Для банков и сервисов это дешевле SMS и безопаснее: код не перехватить подменой SIM. По сути это обычная двухфакторная аутентификация, просто с другим каналом доставки.

Что такое алерт

Алерт (alert, «тревога») — уведомление о проблеме, которое требует чьей-то реакции. Это подвид нотификации, но с жёстким дополнительным условием: на алерт кто-то должен что-то сделать. Если на сообщение реагировать не нужно, это лог или метрика, а не алерт.

Разница не формальная: как только в канал алертов попадают сообщения «всё хорошо», канал перестают читать — и вместе с шумом пропускают настоящую аварию.

Как устроен алертинг

Схема одинакова у Prometheus, Zabbix и облачных мониторингов:

Метрики / логи / health check
    ↓
Правило (условие + длительность)
    ↓
Alert: pending → firing
    ↓
Маршрутизация: группировка, дедупликация, silence
    ↓
Каналы: Telegram, email, SMS, звонок, PagerDuty
    ↓
Эскалация, если не подтвердили за N минут

Правило в Prometheus выглядит так:

groups:
  - name: gpu
    rules:
      - alert: GPUMemoryAlmostFull
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.95
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "VRAM на {{ $labels.instance }} занята более 95% уже 10 минут"

Параметр for здесь — самое важное. Без него алерт сработает на любой секундный всплеск. Условие должно держаться заданное время, иначе это не проблема, а шум.

Severity: как расставлять уровни

Простой критерий разделения: если на сообщение не нужно вставать ночью — это не critical. Если по нему вообще ничего не делают — уровня Info для него не существует, такое правило надо удалять.

Alert fatigue: главная проблема

Усталость от алертов — состояние, когда инженер получает столько уведомлений, что перестаёт их различать и пропускает важное. Это не проблема дисциплины, а проблема настройки: человек физически не может внимательно читать сотое сообщение за смену.

Что помогает:

• Алертить по симптомам, а не по причинам. «Ошибок 5xx больше 5%» полезнее, чем «CPU 90%»: высокая загрузка процессора сама по себе не проблема, если пользователям хорошо.
• Группировка. Упал узел — один алерт, а не сорок от каждого сервиса на нём.
• Дедупликация и silence. Повторы схлопываются, на время плановых работ алерты глушатся заранее.
• Правило одного действия. К каждому алерту привязан runbook — что конкретно делать. Нет ответа — алерт не нужен.
• Регулярная чистка. Правило, которое за квартал сработало 200 раз и ни разу не привело к действию, удаляют.

Каналы доставки

• Чат (Telegram-бот, Rocket.Chat, Slack) — основной канал для warning. Дёшево и мгновенно, но легко тонет в потоке.
• Email — годится для отчётов и info, для критики бесполезен: почту ночью никто не читает.
• SMS и звонок — только для critical. Единственный канал, который реально будит.
• Webhook — универсальный способ отдать алерт в свою систему, тикетницу или автоматику самовосстановления.
• SIEM — куда идут алерты безопасности, там их разбирает SOC.

Практика дежурства: у каждого critical-алерта есть on-call с телефоном и эскалация — если за 10–15 минут никто не подтвердил, звонят следующему в списке. Алерт без адресата бесполезен, даже если технически он корректен.

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

• Prometheus — сбор метрик и правила алертов
• Zabbix — классический мониторинг с триггерами и оповещениями
• health check — простейший источник алертов о недоступности
• SLA и отказоустойчивость — что именно защищает алертинг
• APM и трейсинг — где искать причину после срабатывания алерта
• Инцидент ИБ — алерты безопасности и их разбор