Хороший алертинг работает как пожарная сигнализация: срабатывает, когда есть пожар, и молчит, когда в кухне просто дымит тостер. Это система оповещения (alerting), которая превращает собранные метрики в действие — будит нужного человека в нужный момент и не дергает остальных по пустякам. Разберем принципы, на которых строят оповещения, что именно алертить на серверах, какие каналы и схемы эскалации работают, как организовать дежурства и победить усталость от ложных тревог.
Что такое алертинг и зачем он нужен
Мониторинг собирает и показывает данные, алертинг — реагирует на них. Можно иметь идеальные дашборды, но если на них никто не смотрит круглосуточно, проблему заметят по жалобе. Алертинг закрывает этот разрыв: он сам находит отклонение и шлет уведомления, не дожидаясь, пока кто-то откроет график. Цель у него узкая и конкретная — доставить сигнал тому, кто может починить, и тогда, когда это еще важно, ведь алерт не тому адресату или с опозданием на час бесполезен.
Алертинг напрямую влияет на ключевые метрики надежности. SLA — договорная гарантия доступности перед клиентом, SLO — внутренняя цель команды с запасом до нее. Время восстановления после сбоя измеряют через MTTR, и быстрый точный алерт сокращает именно его: чем раньше пришел сигнал, тем меньше простой.
Принципы хорошего алертинга
За годы эксплуатации крупные команды вывели несколько правил, которые отличают рабочий алертинг от генератора шума, и основной их источник — материалы Google SRE. Главный принцип: каждый алерт это работа для человека, и если на оповещение нечего ответить или проблема чинится автоматически, это не алерт, а запись в журнал. Приоритет отдают алертам по симптомам, которые ловят то, что чувствует пользователь (сервис медленный, страница не открывается), а не по причинам вроде высокой загрузки CPU — высокая загрузка сама по себе не проблема, если пользователи не страдают.
Продвинутый подход — алерты на основе бюджета ошибок SLO: метод burn rate сравнивает скорость расходования этого бюджета за разные окна, например за час и за шесть часов, и так отличает короткий всплеск от устойчивой деградации. Каждому алерту задают уровень важности severity, от которого зависит канал и скорость реакции: priority P1 это критический инцидент с дозвоном и ответом за минуты, P2 — важное без потерь с реакцией в течение часа, P3 — предупреждение с разбором в рабочее время. Без градации все тревоги выглядят одинаково срочными.
Что алертить на сервере
Объекты наблюдения раскладывают по слоям — от железа до приложения. Под надежную основу мы подбираем серверы с контроллером управления, который отдает аппаратные события даже при выключенной ОС. Самые ранние сигналы приходят с контроллера BMC — записи журнала событий аппаратуры, деградация диска в массиве, перегрев и сбой блока питания, и эти алерты заводят в первую очередь, потому что они ловят отказ оборудования до того, как он уронит систему.
На уровне операционной системы алертят занятость дисков, исчерпание памяти со срабатыванием OOM-killer, уход в swap и устойчивую перегрузку CPU — здесь важны именно устойчивые состояния, а не мгновенные пики. Сетевой слой дает алерты по потере линка и росту потерь пакетов, уровень сервисов проверяет, жив ли процесс и отвечает ли порт, а прикладной слой ловит рост ошибок 5xx, всплеск задержек и переполнение очередей — то, что напрямую чувствует пользователь.
Каналы доставки
Сигнал нужно доставить туда, где его заметят, а критичный — гарантированно. В РФ основным каналом стали Telegram-боты: бесплатно, быстро и интегрируется почти с любой системой мониторинга — через bot API алерты шлют и из Zabbix, и из Alertmanager. Email через SMTP-relay подходит для некритичных уведомлений, командные мессенджеры Mattermost, Slack и Microsoft Teams встраивают алерты в рабочие чаты, а когда сигнал нельзя пропустить, добавляют каналы с дозвоном — голосовой звонок или SMS будят дежурного ночью надежнее, и их резервируют под уровень P1.
С платформами дежурств в РФ ситуация особая. Зарубежные PagerDuty и OpsGenie официально недоступны с 2022 года, а OpsGenie вдобавок сворачивается самой Atlassian: продажи прекращены, поддержка завершается в апреле 2027 года. Поэтому российские команды строят дежурства на самописных ботах, встроенном управлении инцидентами GitLab или отечественных on-call сервисах.
On-call ротация и эскалация
Круглосуточное реагирование держится на расписании дежурств и понятной схеме передачи сигнала вверх. Дежурство строят в два уровня: основной дежурный primary принимает алерты первым, резервный secondary подхватывает, если основной не ответил — это страхует от ситуации, когда единственный дежурный спит или вне зоны доступа. Если на критичный алерт не отреагировали за пять минут, он уходит резервному, через пятнадцать руководителю смены, через тридцать выше, и эта лестница гарантирует, что инцидент не зависнет на одном недоступном человеке.
Дежурства ведут по календарю с понятными интервалами — типично неделя основного и неделя резервного. Дежурство вне рабочего времени компенсируют отгулами или доплатой: без этого ротация быстро выгорает, а вместе с ней разрушается и весь алертинг.
Группировка, дедупликация, silences
Сырой поток алертов почти всегда избыточен: один сбой порождает десятки сообщений, и несколько механизмов сворачивают этот поток до осмысленного. Связанные алерты собирают в одно сообщение через group по сервису или региону, а повторы одного события убирают дедупликацией dedup — вместо сотни писем об одном отказе команда получает один сводный сигнал. На время обновлений и техобслуживания оповещения временно глушат через silence по меткам затронутых систем, чтобы плановые работы не сгенерировали вал ложных тревог.
Inhibition подавляет дочерние алерты при срабатывании родительского: упал дата-центр — сообщения по каждому сервису внутри него гасятся. А throttling ограничивает частоту повторных уведомлений, чтобы один долгий инцидент не слал одно и то же каждую минуту.
Runbook к каждому алерту
Алерт говорит, что сломалось, но не что делать, и этот пробел закрывает runbook — короткая инструкция по реакции. Она описывает конкретные шаги: что проверить, какие команды выполнить, кого привлечь, чтобы дежурный в три часа ночи не вспоминал порядок действий, а открывал готовый сценарий — это прямо сокращает время восстановления MTTR. Ссылку на runbook вставляют в само сообщение алерта через аннотации; в Prometheus это штатная практика, и дежурный из уведомления в Telegram сразу попадает на инструкцию, не разыскивая ее по вики.
У каждого алерта есть владелец, который отвечает за его актуальность и знает, кому эскалировать. После крупного инцидента проводят разбор post-mortem без поиска виноватых и обновляют runbook, чтобы в следующий раз реакция была быстрее.
Борьба с alert fatigue
Усталость от тревог alert fatigue — главный враг алертинга: когда оповещений слишком много, их перестают замечать, и система защиты тихо отключается в головах людей. Понять, какие узлы действительно критичны и заслуживают приоритетного алерта, помогает аудит безопасности: он отделяет ключевые точки инфраструктуры от второстепенных. Раз в квартал пересматривают все настроенные оповещения — какие срабатывали, на какие реагировали, какие игнорировали, ведь набор алертов это живая система, которая без ревизии зарастает мусором так же, как код без рефакторинга.
Алерты уровня warning, на которые никто никогда ничего не делал, удаляют без сожаления: это известная проблема alert fatigue, описанная в практиках Google SRE — при десятке с лишним оповещений в день инженеры начинают игнорировать новые, поэтому разумный ориентир это меньше пяти осмысленных алертов в сутки на человека. Качество оповещений измеряют через долю шумовых срабатываний noise ratio и время до подтверждения, а пороги на основе SLO и burn rate заменяют грубые абсолютные значения и сами снижают число ложных тревог.
Реализации в популярных стеках
Принципы одинаковы, но настройка отличается по системам — подобрать стек под инфраструктуру и проверить его помогает аудит ИТ-инфраструктуры. В Zabbix оповещения строят через Actions и media types: действие по триггеру отправляет сообщение в заданный канал, эскалацию задают шагами с задержками, а severity триггера определяет срочность — все настраивается в одном интерфейсе без внешних компонентов. В стеке Prometheus правила тревог живут в движке метрик, а обработкой занимается Alertmanager — эталонная реализация описанных выше принципов группировки и маршрутизации. Checkmk предлагает развитую систему Notifications с правилами по объектам, а облачные сервисы вроде Yandex Cloud Monitoring дают алерты как управляемую функцию, но с привязкой к платформе провайдера.
Типовые ошибки
Три ошибки повторяются в большинстве команд и обесценивают весь алертинг. Сотни оповещений настроены, потому что так положено, но реагировать на них никто не собирается — такой алертинг создает иллюзию контроля и приучает игнорировать сигналы, и лучше десять работающих алертов, чем триста декоративных. Оповещения без уровня важности и без runbook заставляют дежурного гадать, насколько все серьезно и что делать, поэтому минимальный стандарт для каждого алерта это заданный severity и ссылка на сценарий реакции. А когда вместо схемы дежурств любой инцидент эскалируют звонком руководителю, система не масштабируется и быстро всех изматывает — эскалация это формальная лестница ролей с интервалами, а не паника по личным контактам.
Сравнение уровней severity
Сводка помогает единообразно классифицировать алерты и выбрать под них канал.
Заключение: с чего начать
Рабочий алертинг строят не с числа правил, а с дисциплины. Короткий план:
- на каждый алерт ответить на вопрос, какое действие он требует, и удалить те, где ответа нет;
- расставить severity и под каждый уровень закрепить канал — от дашборда до дозвона;
- к каждому критичному алерту привязать runbook и положить ссылку прямо в сообщение;
- настроить группировку, дедупликацию и silence, чтобы один сбой не порождал лавину;
- организовать дежурства в два уровня с понятной эскалацией и компенсацией;
- раз в квартал проводить аудит, вычищая шум.
Алертинг, собранный по этим правилам, будит дежурного только тогда, когда без него действительно не обойтись.
Часто задаваемые вопросы
Чем алертинг отличается от мониторинга?
Мониторинг собирает и показывает метрики, алертинг реагирует на них и шлет уведомления ответственным. Можно иметь полные дашборды без алертинга — но тогда проблему заметят по жалобе, а не по сигналу системы.
Какие каналы для алертов лучше?
В РФ массовый выбор — Telegram-боты за скорость и доступность. Email подходит для некритичного, командные мессенджеры — для совместного разбора. Под критичные инциденты P1 добавляют каналы с гарантированным дозвоном: голос или SMS.
Что такое SLO-based алерт?
Это оповещение на основе расходования бюджета ошибок, а не абсолютного порога. Метод burn rate сравнивает скорость сгорания бюджета за разные окна и отличает короткий всплеск от устойчивой деградации, снижая число ложных тревог.
Сколько алертов в день — это норма?
Ориентир — меньше пяти осмысленных алертов в сутки на человека. После десятка оповещений в день инженеры начинают игнорировать новые. Если тревог больше, это сигнал чистить шум, а не повод нанимать дежурных.
Что такое runbook?
Это короткая инструкция по реакции на конкретный алерт: что проверить, какие команды выполнить, кого привлечь. Ссылку на runbook кладут прямо в сообщение, чтобы дежурный не искал ее и быстрее восстанавливал сервис.
Как организовать on-call ротацию?
Заводят календарь дежурств в два уровня — основной и резервный, типично по неделе. Настраивают эскалацию по времени и компенсируют дежурства отгулами или доплатой. Без компенсации ротация выгорает и перестает работать.
Какая разница между silence и inhibition?
Silence вручную глушит конкретные алерты на время, например на плановые работы. Inhibition автоматически подавляет дочерние оповещения при срабатывании родительского — упал дата-центр, и алерты по его сервисам гасятся сами.
Можно ли отправлять алерты в Telegram?
Да, это самый популярный канал в РФ. Создают бота, получают токен и подключают его как получателя в Zabbix или Alertmanager. Через bot API сообщения уходят за секунды, а настройка занимает около десяти минут.
Спроектируем алертинг под ваш стек
Внедряете алертинг с нуля или тонете в ложных тревогах? Инженеры Serverzilla спроектируют SLO-based оповещения, схему on-call дежурств и runbook-и, настроят интеграцию с Telegram и вашим стеком (Zabbix, Prometheus, Checkmk). Поможем подобрать сервер под задачу под систему мониторинга. Оставьте заявку.
