Антипаттерн: мониторинг, который никто не смотрит

MAATRIX

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

Как именно это происходит

Сценарий почти всегда один и тот же, независимо от масштаба проекта. На старте — воодушевление: команда только что подняла сервис, кто-то в первую неделю разворачивает Prometheus и Grafana, рисует дашборд с десятком графиков, настраивает Alertmanager на пересылку в отдельный Slack-канал или на email рассылку. Первые недели за этим действительно следят: смотрят на графики после каждого деплоя, разбирают каждый алерт, донастраивают пороги.

Дальше происходит постепенный дрейф. Сервис работает стабильно, серьёзных инцидентов нет, и внимание команды естественным образом переключается на текущие задачи — фичи, баги, дедлайны. Slack-канал с алертами продолжает получать сообщения: скачок использования CPU при плановой задаче, кратковременный всплеск задержки при пиковой нагрузке, разовая ошибка коннекта к базе, которая сама восстановилась через 30 секунд. Ни одно из этих сообщений не требует немедленной реакции — и человек, который в первую неделю разбирал каждое, постепенно перестаёт открывать канал вообще. Психологически это рационально: разбор алерта отвлекает от текущей задачи, а цена ошибки (пропустить один неважный алерт) кажется ниже цены постоянного отвлечения.

Проблема в том, что канал не различает «неважно» и «критично». Через полгода в него попадает алерт о том, что диск заполнен на 95%, или о том, что сертификат TLS истекает через сутки — и тонет в том же потоке, что и сотня прошлых ложных срабатываний. Дашборд при этом физически продолжает работать: метрики собираются, панели рисуются, алерты уходят строго по правилам, которые задали полгода назад. С точки зрения системы всё исправно. С точки зрения бизнеса — сигнал никуда не доходит, потому что дошёл до человека, который его больше не читает.

Момент запуска:                      Через полгода:
Grafana дашборд ──► открывают        Grafana дашборд ──► никто не открывает
     после каждого деплоя                  (есть, но не нужен)

Alertmanager ──► Slack #alerts       Alertmanager ──► Slack #alerts
     каждое сообщение разбирают            200 непрочитанных, канал не читают

Итог: мониторинг технически жив,     Итог: мониторинг технически жив,
сигнал доходит до человека           сигнал никуда не доходит

Мониторинг без человека — то же самое, что его отсутствие

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

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

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

# быстрая диагностика: когда последний раз кто-то реально смотрел на алерты
# для Slack — экспортом истории канала можно оценить, отвечал ли кто-то на сообщения бота
# для email — по факту наличия непрочитанных писем от рассылки мониторинга

# для Alertmanager полезно смотреть не только "алерт отправлен",
# но и "алерт подтверждён" (acknowledged), если это поддерживается интеграцией
curl -s http://alertmanager:9093/api/v2/alerts | jq '.[] | {alertname: .labels.alertname, startsAt: .startsAt, status: .status.state}'

Если статус большинства алертов годами «active» и никогда не переходит в «suppressed»/«acknowledged» вручную — это не значит, что все инциденты реальны, но точно значит, что никто не подтверждает их разбор.

Ложное чувство защищённости

Второй эффект тоньше и опаснее первого. Когда мониторинг настроен, команда искренне считает, что риск закрыт: «у нас есть Grafana, мы узнаем о проблеме». Это убеждение снижает бдительность во всех смежных местах — реже проверяют логи руками, реже делают ручные проверки после релиза, реже задают себе вопрос «а что если что-то сломалось незаметно», потому что «мониторинг же скажет».

В результате разрыв между воспринимаемой защищённостью и реальной не остаётся постоянным — он растёт. Чем дольше мониторинг числится «настроенным, но не читаемым», тем больше решений принимается исходя из ложной предпосылки, что сигнал дойдёт вовремя. Команда постепенно убирает другие способы узнать о проблеме (например, регулярный ручной обход ключевых страниц или отчётов), потому что «зачем, у нас же есть алерты» — а алерты в это время падают в непрочитанный канал. Разбор именно этого механизма — почему сам факт наличия мониторинга ничего не гарантирует, и какие ещё слепые зоны у него есть даже при активном использовании — подробно разложен в статье про миф «мониторинг — я узнаю первым»; в отличие от неё, здесь речь не о технических слепых зонах мониторинга, а именно об организационном разрыве: система работает исправно, но никто не читает то, что она присылает.

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

Антипаттерн этой статьи — именно второй случай, и он опаснее первого, потому что маскируется под благополучие: в отчётах и на планёрках можно честно сказать «у нас есть мониторинг», не уточняя, что фактически на него никто не реагирует уже несколько месяцев.

Как незаметно накапливается технический долг

Третий эффект — самый медленный и потому самый коварный. Часть алертов не сигнализирует о резком падении сервиса — они сигнализируют о постепенной деградации: рост использования диска на несколько процентов в неделю, медленное увеличение времени ответа базы данных, постепенное исчерпание квоты на inodes, растущее число ошибок в логах, которые пока не критичны. Такие сигналы по своей природе не создают ощущения срочности в моменте — ни один отдельный алерт «диск заполнен на 62%» не выглядит как повод бросить текущие задачи.

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

Практическое следствие: если у вас есть алерты, рассчитанные на раннее предупреждение о деградации (диск, память, время отклика, размер очереди), а не только на аварийные пороги, — их полезность целиком зависит от регулярности просмотра. Аварийный алерт «диск заполнен на 100%» сработает и будет замечен рано или поздно, потому что сервис уже упал и кто-то полезет разбираться. А предупреждающий алерт «диск заполнен на 70%, растёт на 2% в неделю» не создаёт такого давления — и именно он первым выпадает из внимания, хотя именно он даёт время среагировать без простоя.

Почему так происходит: экономика внимания, а не лень

Стоит отдельно проговорить, что это не история про безответственных инженеров. Причина системная: разбор каждого алерта конкурирует за внимание с задачами, у которых есть видимый дедлайн и видимый спрос со стороны бизнеса. У непрочитанного алерта в Slack нет ни того, ни другого — по крайней мере, до тех пор, пока он не превратится в инцидент. Рациональный с точки зрения отдельного человека выбор в моменте («доделаю фичу, алерт подождёт») в сумме за месяцы даёт нерациональный результат для команды в целом.

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

Что делать: конкретные меры

Первая и самая дешёвая мера — назначить ответственного за периодический просмотр дашборда, пусть даже неформально, без отдельной роли в оргструктуре. Это может быть еженедельная ротация: «в понедельник Иван проверяет Grafana и отвечает на непрочитанные алерты за неделю», зафиксированная в календаре или таск-трекере, а не только на словах. Ключевое отличие от «мониторинг настроен на весь отдел» — конкретное имя и конкретный день, за который спрашивают на следующей планёрке.

Вторая мера — развести каналы по критичности так, чтобы критичное физически не могло затеряться среди информационного шума:

# пример маршрутизации в Alertmanager: разделение по severity
route:
  receiver: 'slack-info'
  routes:
    - match:
        severity: critical
      receiver: 'personal-telegram'
      continue: false
    - match:
        severity: warning
      receiver: 'slack-info'

receivers:
  - name: 'personal-telegram'
    telegram_configs:
      - bot_token: '<TOKEN>'
        chat_id: <личный_chat_id_дежурного>
        message: '{{ .CommonAnnotations.summary }}'
  - name: 'slack-info'
    slack_configs:
      - api_url: '<WEBHOOK_URL>'
        channel: '#monitoring-info'

Идея простая: критичные алерты (падение сервиса, диск на 95%+, истекающий через сутки сертификат) идут не в общий забытый канал, а личным сообщением конкретному дежурному — туда, где сообщение физически невозможно пропустить, потому что личные уведомления в Telegram проверяют почти все и почти сразу, в отличие от рабочего Slack-канала, который открывают по остаточному принципу. Информационные и низкоприоритетные алерты можно оставить в общем канале — там их отсутствие внимания не так критично. Практическая настройка именно личных Telegram-уведомлений для VPS — от создания бота до готового скрипта — разобрана в статье про настройку алертов в Telegram на VPS.

Третья мера — снизить количество ложных срабатываний, которые и порождают привычку не читать канал. Если 8 алертов из 10 не требуют действия, дешевле почистить пороги и группировку, чем продолжать слать их людям, которые всё равно перестанут реагировать:

• поднять пороги там, где кратковременные всплески не критичны (гистерезис: срабатывание только при устойчивом отклонении, а не по одному пику);
• группировать однотипные алерты в один инцидент вместо потока сообщений о том же самом;
• явно удалять правила, которые за последние месяцы ни разу не указали на реальную проблему.

Периодический аудит вместо разового запуска и забвения

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

1. Кто-нибудь открывал дашборд за последний месяц — и можете ли вы это проверить (по логам доступа Grafana, если они включены)?
2. Сколько алертов за квартал остались без явной реакции человека (без ответа в канале, без отметки acknowledged)?
3. Соответствуют ли ещё пороги реальной нагрузке проекта, или сервис вырос/изменился, и старые значения давно не имеют смысла?
4. Есть ли алерты, которые срабатывают чаще раза в неделю, но никогда не указывали на реальную проблему — кандидаты на удаление или пересмотр?
5. Проверяется ли критичная ветка бизнес-логики (оплата, регистрация, отправка писем), а не только «сервер жив»?

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

Частые вопросы