Если вы когда-либо работали с алертами, то наверняка знаете то самое чувство, когда кажется, что у системы уже на каждый чих есть особое уведомление. Вот только вместо полезных сигналов вы получаете бесконечный поток сообщений, в котором временами теряется действительно важная информация.

Когда алертов становится слишком много, это уже не инструмент мониторинга, а хаос. Мы начинаем их игнорировать, ставить чаты в мьют и надеяться, что, если что-то сломается, пользователи сами нам об этом расскажут. Так происходит не только в IT, но и практически везде — даже в медицине и авиации. Порой критические сигналы, которые должны спасать жизни, тонут в информационном шуме. А что делать, когда этот шум начинает мешать работать?

Привет! Я — Кирилл Борисов. Сегодня я расскажу вам о том, как мы в VK боролись с лавиной алертов, какие решения нашли — и, главное, как этот опыт можно применить в любой команде.

Как мы превращаемся в Плюшкиных

Все знают Плюшкина из «Мёртвых душ» — человека, который собирал вещи, но уже не знал, зачем они ему  и как с ними управляться. В какой-то момент я понял, что сам становлюсь таким же, но не с барахлом, а с алертами. Они копятся, заполняют все доступные каналы, и в итоге их становится так много, что я просто перестаю на них реагировать. Знакомая история?

Как так получается? Сценарий классический. Мы начинаем новый проект или работаем с существующим, нам нужно настроить алертинг. Берём список лучших алертов из open-source решений, копируем их, адаптируем — или даже не адаптируем, а просто включаем. Кажется, что всё хорошо, но проходит время, и их количество выходит из-под контроля.

Самая большая проблема — отсутствие процесса ревью. Кто-то, конечно, время от времени садится и решает разгрести этот хаос. Заводит новый чат для критичных алертов, потом ещё один, потом чат для самых критичных алертов — и в итоге всё равно возвращается в тот же хаос.Постепенно мы привыкаем к шуму, усталость накапливается, и единственное решение, которое приходит в голову, — просто выключить уведомления. Выключить мониторинг. А это уже серьёзный риск.

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

Когда сигналы больше не сигнализируют

Усталость от алертов — alert fatigue — это не просто раздражение от слишком большого количества уведомлений. Это состояние, когда человек привыкает к постоянному потоку сигналов и перестаёт на них реагировать.

Определение этой проблемы есть в медицине: когда источники стресса повторяются, тогда люди начинают их игнорировать. Алерты становятся фоном, и даже критические сигналы остаются незамеченными.
В медицине это уже приводит к серьёзным последствиям. Например, однажды пациенту случайно ввели дозу лекарства, превышающую норму в 30 раз, только потому, что врачи проигнорировали системные предупреждения. Медсёстры были перегружены уведомлениями и пропустили критичный алерт. Только чудом пациент выжил.

В IT мы сталкиваемся с точно такой же проблемой. Постепенно алерты становятся просто шумом, который перестаёт привлекать внимание.

Пользователи нам всё равно расскажут, если что-то сломается? Ну может быть. Но это уже не мониторинг, а надежда на случай.

Лекарства от хаоса

Чтобы алерты не превращались в бесполезный поток сообщений, их нужно правильно структурировать. Мы выделили три ключевых подхода:

  1. Критичность — не все алерты одинаково важны. Нужно чётко определить уровни критичности, чтобы различать, какие требуют немедленного реагирования, а какие можно обработать позже.

  2. Каналы доставки — важные алерты должны приходить по назойливым каналам, которые точно привлекут внимание, например, звонок на телефон. Менее критичные можно отправлять в неназойливые рабочие чаты.

  3. Расписание дежурств — алерты должны попадать конкретным ответственным, а не в безликий общий канал, где они теряются.

Эти три решения позволяют привести хаос в порядок, благодаря которому критичные проблемы не теряются, а менее важные сигналы не перегружают мониторинг.

Как правильно определять критичность алертов

Первый шаг к порядку — это приоритизация оповещений по уровням критичности. У нас в VK это выглядит так:

  • Disaster — алерт, который на 100% означает инцидент. Вся цепочка эскалации работает моментально: собирается чат с ответственными, подключаются нужные люди, начинается процесс срочного устранения проблемы.

  • Critical — важный алерт, на который нужно реагировать, но он не требует инцидентного чата. Один ответственный должен разобраться и устранить проблему.

  • High — важный, но не срочный. Если он пришёл ночью, можно спокойно отложить его решение до утра.

  • Warning — кажется, что такие алерты можно игнорировать, но это плохая практика. Любой warning алерт со временем перерастает в disaster, если его вовремя не проработать. Поэтому мы регулярно делаем отчёты по warning сигналам с последующим их разбором.

Такая расстановка приоритетов помогает фильтровать хаос и не перегружать систему срочными сигналами. Она гарантирует, что важные алерты не пропадут и будут обработаны.

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

Если все сигналы приходят одинаково, человек просто перестаёт на них реагировать. Поэтому мы структурировали систему таким образом, чтобы критичные уведомления доходили до нужного исполнителя без потерь, а менее важные не перегружали рабочие процессы.

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

Сейчас для этого используется Grafana OnCall. Она берёт на себя распределение уведомлений, определяет их критичность и направляет по соответствующим каналам. Если проблема серьёзная, то поступает звонок на телефон — его невозможно проигнорировать. Если сигнал важный, но не срочный, то он уходит в корпоративные мессенджеры, чтобы человек мог разобраться с ним, когда появится время.

Когда система только внедрялась, возникали сложности с восприятием. Люди привыкли, что мониторинг работает определённым образом, и сопротивлялись изменениям. Кто-то считал, что новые механизмы слишком сложные, кто-то — что при  прежнем порядке вполне справлялись с задачами. Но без этих изменений ситуация оставалась бы такой же: хаос, игнорирование важных алертов и проблемы, которые замечают только постфактум.

Теперь система работает автоматически. Grafana OnCall формирует цепочку эскалации, проверяет, кто должен получить уведомление, и отслеживает, что с ним происходит дальше. Если первый получатель не реагирует, сигнал передаётся его руководителю, а затем на уровень выше.

Отдельное внимание уделяется формату алертов. Уведомления должны быть читаемыми и понятными сразу, без необходимости разбираться в технических деталях. Один из подходов — адаптировать текст так, чтобы он был ясен даже для человека, которого разбудили посреди ночи. Например, звонок начинается с произвольной фразы, чтобы дать время проснуться, и только потом говорится о проблеме. Если человек понимает её без дополнительных уточнений, то, не подключая ноутбук, он может сразу нажать кнопку «Взять в работу».

Алерт без владельца — не алерт

Какая главная проблема множества оповещений? Они улетают в никуда. Приходит уведомление, его видят десятки людей, но никто не берёт на себя ответственность. В итоге проблему замечают только тогда, когда уже случился реальный инцидент.

Если у алерта нет владельца, он не будет обработан. Поэтому нужно назначить ответственных.

У нас это работает так:

  • Назначены ответственные лица — каждый критичный алерт автоматически направляется конкретному человеку, а не просто в общий чат. Если он не реагирует, то начинается цепочка эскалации.

  • Установлен график дежурств — у каждого сервиса есть ответственные дежурные, которые берут на себя обработку уведомлений. Человек знает, что именно в его задачи входит мониторинг оповещений. Он не надеется на то, что кто-то другой заметит проблему.

  • Есть кнопка «Взять в работу» — если сотрудник принимает алерт, то система фиксирует это, и дальше эскалация не идёт. Если он игнорирует — уведомление переходит к следующему уровню.

Главное правило: алерт без ответственного — это не алерт. Он либо будет обработан вовремя, либо превратится в полноценный инцидент.

Когда система делает всё сама

Чтобы избавить команду от лишней рутины, мы внедрили автоматизацию обработки алертов. Система сама определяет, какой использовать канал и кому направить уведомление. Если алерт — disaster, то он сразу идёт на звонок, а если high, то попадает в отчёт.

Так же работает автоматическая цепочка эскалации. Если сотрудник не реагирует, то уведомление передаётся сначала его тимлиду, а затем на уровень выше, чтобы проблема точно не осталась незамеченной.

Особое внимание уделяется тому, как формируется текст уведомления. Алерты должны быть понятными с первого взгляда, поэтому мы сделали удобные карточки, где сразу есть описание проблемы и инструкции по дальнейшим действиям.

Дополнительно алерты связаны с CMDB. Система автоматически определяет, какой продукт сломался, и сама подбирает нужных людей для инцидентного чата.

После внедрения автоматизации мы замерили показатели и увидели реальные изменения:

  • Среднее время реакции на критичный инцидент уменьшилось на 37%

  • Количество алертов, требующих вмешательства, снизилось на 42% за счёт группировки сигналов

  • Количество шумовых алертов сократилось в 4 раза

  • Теперь 98% критичных уведомлений получают реакцию в течение первых минут после их появления

Как алерты превращаются в управляемую систему инцидентов

Когда случается инцидент, важно не только зафиксировать проблему, но и оперативно собрать команду, которая займётся её решением. Без структурированного процесса алерты просто висят в воздухе — кто-то их увидел, кто-то проигнорировал, а в итоге критическая ситуация остаётся без внимания.

Чтобы этого избежать, мы встроили систему управления инцидентами прямо в процесс обработки оповещений. Всё начинается с интеграции с CMDB. Когда поступает критичный сигнал, система автоматически сопоставляет его с базой данных сервисов, определяя, какие компоненты затронуты и кто отвечает за их работоспособность. Дальше запускается процесс формирования инцидента.

Если это disaster алерт, то процесс идёт по жёсткому сценарию. Формируется чат в корпоративном мессенджере, собираются ответственные специалисты, подключаются инженеры — и начинается экстренное устранение проблемы. Всё это происходит автоматически, без ручного поиска контактов или добавления людей в беседу.

Но важно не только реактивное управление, но и способность прогнозировать проблемы. Если инженер понимает, что текущий сигнал может перерасти в серьёзный инцидент, он может вручную запустить процесс эскалации. Для этого достаточно нажать кнопку «Создать инцидент» прямо из интерфейса алерта. Система сама создаст тикет в Jira, соберёт нужных людей и запустит обсуждение решения проблемы.

Этот подход работает в обе стороны. Если произошёл инцидент, но он не связан с активным алертом, система может задним числом завести соответствующее уведомление и связать его с инцидентом. Это позволяет выстраивать связи между прошлыми сбоями и прогнозировать возможные повторения проблем.

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

Как убрать лишние алерты и снизить шум

Даже после внедрения системы критичности и эскалации алертов всё ещё слишком много. Чтобы решить этот вопрос, нужно уметь правильно группировать сигналы и отфильтровывать ненужные уведомления.

Мы используем несколько подходов для оптимизации. Во-первых, алерты группируются на уровне Alert Manager, который схлопывает повторяющиеся сигналы в единое сообщение. Во-вторых  OnCall позволяет объединять похожие алерты, чтобы вместо сотни отдельных уведомлений получать одно с агрегированной информацией.

При этом мы стараемся избегать ситуации, когда система отправляет сигнал при каждом незначительном отклонении параметров. Если алерт не влияет на стабильность сервиса, то он просто фиксируется в отчёте, вместо того чтобы загромождать рабочие каналы.

Когда система растёт быстрее, чем ожидалось

Чем больше сервисов подключается к системе мониторинга, тем сложнее управлять потоком алертов. Инфраструктура растёт, количество уведомлений увеличивается, и внезапно оказывается, что прежние подходы не выдерживают нагрузку.

Основные сложности при масштабировании связаны с обработкой данных и очередями запросов. Когда количество алертов достигает миллионов, база данных начинает перегружаться, задержки увеличиваются, а система мониторинга перестаёт эффективно работать. Мы решили эту проблему за счёт асинхронной обработки.Все алерты, вместо того чтобы попадать сразу в базу, сначала проходят через очередь сообщений, где фильтруются и группируются. В результате это значительно снижает нагрузку и ускоряет работу системы.

Дополнительно мы внедрили алгоритмы приоритизации. Если поток алертов становится слишком большим, то менее важные уведомления временно откладываются, а критичные сигналы проходят в первую очередь. Благодаря этим изменениям, нам удалось не просто сохранить работоспособность системы, но и подготовить её к дальнейшему масштабированию.

Что мы вынесли из всей этой работы

Алерты — это не просто сигналы, это способ держать инфраструктуру под контролем. Но когда их слишком много, система перестаёт работать. Мы прошли через множество проблем, прежде чем выстроили управляемую систему, которая не мешает, а помогает.

Главное, что мы поняли:

  • Алерты нужно воспринимать как код. Они требуют ревью, улучшений и постоянного пересмотра, иначе быстро превратятся в бесполезный шум.

  • Разделение по уровням критичности — основа порядка. Disaster требует немедленного реагирования, critical важно обработать, но без паники, high можно оставить на потом, а warning важно отслеживать, чтобы не пропустить проблемы в будущем.

  • Каналы оповещений должны работать осмысленно. Телефонные звонки используются только для самых срочных ситуаций, а менее критичные уведомления уходят в удобные мессенджеры.

  • Группировка и автоматизация спасают от хаоса. Мы сгруппировали 1,4 млн алертов и убрали лишний шум. Система эскалации гарантирует, что каждый важный сигнал получит реакцию.

  • Интеграция с CMDB и Jira делает управление инцидентами прозрачным, и они решаются автоматически.

Теперь это не просто поток уведомлений, а управляемая система, которая поддерживает стабильность сервисов и предотвращает проблемы до того, как они станут критическими.

А как вы управляете большим потоком алертов? Делитесь своим опытом в комментариях.


Про то, как вовремя поймать IT-катастрофу, избежать потерь и сохранить репутацию компании рассказал в другой статье по этой ссылке.

Комментарии (18)


  1. Ostrie_Brevna
    09.06.2025 14:21

    А как формулируется цель этой действительно нетривиальной работы? И есть какие-то способы, быстро и точно понять, что всё опять не "сползает в бездну"? Может, метрики, аналитика, дашборды. Как они помогают понять, что сформулированная цель всё ещё достигается?
    Если можно, раскройте на какие индикаторы смотрите: количество false positives/negatives, удовлетворённость дежурных своим сном, что-то посложнее: свойства "трассировок" эскалаций, оценки правильности агрегаций алертов, считающихся связанными и т. п.?


    1. yellowmew
      09.06.2025 14:21

      тоже было бы интересно узнать как ведется мониторинг в целях "неразрастания" для таких объемов

      у нас для неразрастания (хотя конкретно такой цели не ставилось, это была обычная работа над продом)

      1. для новых алертов должно было быть объяснено и записано: почему это надо алертить и кто ответственный за конкретно этот момент. Если никто не берет ответственность (даже если реакция первая должна быть от дежурного - дежурный не эксперт, эксперт - владелец сервиса) то на гильдиях (платформа для инфраструктурных сервисов, дев для сервисов приложения) ищем кто заберет себе. Тот же процесс для легаси алертов, созданных в до введения данного правила: оценка, описание, поиск владельца

      2. для существующих критов и ворнингов - статистика и еженедельная презентация на RnD(все команды продукта), с объяснением что происходило в продукте и какие критические алерты сработали в областях (если что-то было). Отчеты по инцидентам опять же там же

        1. Увеличение количества ворнингов в конкретной области - требовало расследования от команды и тюнинга либо алерта либо починки сервиса. Ибо вроде мелочь, но может привести к неприятным последствиям

        2. Криты - отражение состояния продукта, если в сервисе много критов но с сервисом все хорошо - значит что-то не так с алертом, тоже править или уровень срабатывания или вообще приоритет

        3. Большое колиство инцидентов или валидных критов в конкретной области - сигнал что что-то не так в принципе и надо менять приоритеты команды ответственной за область\сервис на исправление данной ситуации

        Спасибо вообще тем командам(а так же менеджерам): брали в относительно ближайшие спринты всё это править )

      Вообще, получалось держать руку на пульсе, но у нас не было "N тысяч алертов в секунду" - поэтому интересно. Вообще, тысячи алертов в секунду это больно - никто на такое не отреагирует физически. Старались заводить только алерты на которые надо реагировать и воспринимать остальное как информационный шум. Интересный, но все таки шум


  1. BigD
    09.06.2025 14:21

    Grafana Oncall облачная?


    1. silabeer Автор
      09.06.2025 14:21

      Неа, в нашем контуре установленная


  1. savostin
    09.06.2025 14:21

    Берём список лучших алертов из open-source решений

    Поделитесь пожалуйста :)


    1. itcaat
      09.06.2025 14:21

      https://samber.github.io/awesome-prometheus-alerts/ можно начинать отсюда, адаптируя под свои нужды. Также много есть просто поиском на github. Флоу простой: смотрите какие метрики экспортер отдает и ищите в github примеры алертов


      1. silabeer Автор
        09.06.2025 14:21

        Да, самый лучший ресурс, для старта


  1. santjagocorkez
    09.06.2025 14:21

    Наверное, погорячился


  1. AngryAnonymous
    09.06.2025 14:21

    Grafana OnCall потеряет какую либо поддержку в начале 2026 года. Вы уже планируете ей замену и если да, то на что?


    1. silabeer Автор
      09.06.2025 14:21

      Мы с самого начала форкнулись к себе и дорабатываем своими силами. Замену не планируем искать


  1. itcaat
    09.06.2025 14:21

    Возможно, это не тема данной статьи, но, кажется, нужно было раскрыть тему и про этапы калибровки алертов и тестирования. Это всё важные этапы спокойствия дежурных на oncall


    1. silabeer Автор
      09.06.2025 14:21

      Возьму на заметку, спасибо большое


  1. yellowmew
    09.06.2025 14:21

    Использовали такие приоритеты:

    1. Incident - инцидент =), сразу запускается процесс обработки инцидента в продукте (не такой продвинутый, как описанный, конечно). Алерт требует немедленной обработки с оповещениями и подключениями всех заинтересованных согласно процессу.

    2. Critical - алерт должен обработать дежурный, или по цепочке эскалации он уйдет команде ответственной за область (всем, на удачу - вдруг кто-то доступен), затем менеджеру команды, затем техдиру (и тогда будет больно всем). Требует немедленной обработки.

    3. Warning. Работало как High из статьи - Требует обработки, но достаточно и next business day. Кроме того эти алерты зачастую закрываются сами. И их количество тоже мониторилось и в статистике отображалось - если было слишком много от команды в чьей области они происходили требовалось провести работу по снижению (или алерт править или продукт)

    4. А вот Info (непонятно, равнозначен ли он Warning из статьи), просто не пускали даже в общий пайплайн. Этот приоритет был для разработчика. Хочет он помониторить что-то в уже опубликованном коде - может накрутить себе алерт и пустить в слак\тимс канал или вообще себе на почту. Мне немного непонятна разница между Warning и High из статьи

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

    Для инцидента не связанного с алертами был специальный механизм "Аларм" канала. Когда происходит инцидент, дежурный его подтверждает и пишет сообщение в "Аларм" канал об этом - для оповещения всех заинтересованных людей (суппорта, продакта, техдиров, техлидов и т.п.), подписанных на данный канал. Добавление упоминания @alarm бота создавало алерт в системе алертов.

    Уведомления должны быть читаемыми и понятными сразу, без необходимости разбираться в технических деталях

    Золотые слова. Мне так и не удалось донести до наших алертописателей смысл этого, поэтому некоторые алерты были в стиле "Метрика Х на сервисе Y равна 50%"


  1. ded9111
    09.06.2025 14:21

    Интересная практика. У иностранцев в промышленности есть такая процедура ARS (alarm racionalization system), очень похоже.


  1. Z0Om
    09.06.2025 14:21

    Поделитесь стеком: мониторинг, cmdb? Какие приложения используете?


    1. silabeer Автор
      09.06.2025 14:21

      Алерты из разных систем к нам летят(prometheus, Victoria, самоличные), как я уже и говорил мы принимаем в любом json формате, но для универсализации даем шаблон.


  1. x1shn1k
    09.06.2025 14:21

    А есть какая-то гуишка где смотрите/видите текущие алерты? Или они в текстовом виде в чате?


    1. silabeer Автор
      09.06.2025 14:21

      В самом oncall - есть alert groups, там смотрим. Не очень нам нравится, но пока других вариантов не придумали :)