Как понять, что мониторинг в ЦОДе шумит

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

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

К утру инфраструктура так и не полыхнула синим пламенем, зато система оповещений просто разрывалась. Так я впервые узнал об «усталости от алертов» и начал искать способ справиться с этой проблемой.

Привет, Хабр! Меня зовут Александр Мерненко. Я хочу поделиться своими наблюдениями и идеями.

В чём проблема и почему это дорого

Мониторинг в ЦОДе чаще «ломается» не из-за количества метрик, а из-за шума. Избыток уведомлений снижает доверие к сигналам и повышает риск пропустить что-то критичное. По данным Uptime Institute (Annual Outage Analysis 2025), доля операторов, сообщающих о значимых простоях за последние три года, снижается: 69% в 2021 году, 60% в 2022-м, 55% в 2023-м и 53% в 2024-м. При этом темпы улучшения замедляются. В 2024 году снижение составило всего 2% по сравнению с предыдущим годом.

Но если инциденты всё-таки происходят, они по-прежнему стоят дорого. 54% респондентов оценили последний серьёзный простой дороже $100 000, а около 20% — дороже $1 миллиона.

При этом около 80% операторов считают, что их последний простой можно было предотвратить улучшением процессов или управления. Среди причин человеческих ошибок на первом месте оказалось банальное невыполнение процедур. На него приходится около 58% инцидентов. Среди причин простоев по-прежнему лидирует питание (54%). Далее идут охлаждение (13%). Сеть (12%) и ИТ-системы (11%), их доля постепенно растёт.

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

Ночной тест

Есть простой способ проверить любое оповещение. Надо задать вопрос: «Если это сработает посреди ночи, например, в 03:17, вы действительно хотите разбудить дежурного?».

Если ответ «нет», значит это не ночной будильник, а уведомление, и его место в дашборде, дневных задачах или отчёте о тенденциях. В английском даже появилось выражение no need to respond / need not respond (NNR), то есть, «отвечать не нужно».

Численный критерий качества

Для грубой диагностики удобно считать коэффициент ночного шума.

NNR = (количество ночных страниц / звонков / пушей)
/ (количество ночных инцидентов, где реально требовалось действие)

Интерпретация простая:

• NNR > 3–5 — мониторинг шумит, доверие падает, а риск пропустить реальную проблему растёт.

• NNR ≈ 1–2 — признак зрелой системы оповещений: если разбудили, значит есть работа.

Это не академический порог, а быстрый диагностический тест. Если NNR высокий, чиним правила оповещений, а не добавляем новые датчики.

Шум против сигнала

Типичные примеры шума, который почти никогда не должен будить ночью:

• CPU «выше 80%» без учёта длительности и признаков насыщения;

• разовый скачок температуры без тренда по коридору или ряду;

• единичное предупреждение SMART без деградации массива;

• потери пакетов «0.1% на пару минут» без роста задержки и ошибок интерфейса;

• отвалился один вентилятор или блок питания при сохранённом резервировании.

Типичные примеры сигнала, когда будить нужно:

• потеря резервирования питания (N+1 → N), просадки, перекосы или аварийные переключения;

• устойчивый рост базовой температуры по холодным или горячим коридорам;

• рост задержек чтения или записи (I/O latency) в p95/p99 — именно эти «хвосты» чаще всего чувствуют пользователи;

• устойчивая деградация сети: потери пакетов вместе с ростом задержки, flapping линков, CRC-ошибки, потеря агрегации или магистрали.

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

Четыре зоны ЦОДа через призму ночного теста

Электропитание

Питание остаётся главным источником серьёзных простоев (54% в опросе Uptime), поэтому правила оповещений здесь должны быть особенно строгими.

Не будим ночью:

• отказ одного вентилятора ИБП при сохранённом резервировании;

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

Будим ночью:

• потеря резервирования (N+1 → N), отключение ветки питания или срабатывание защит;

• реальные просадки или нестабильность питания, проблемы при переходе на батареи или ДГУ;

• перегрузка по PDU или фидерам с риском каскадного отключения.

Важно будить не из-за факта «один ИБП упал», а когда из-за этого действительно теряется резерв или критичные системы оказываются на одной ветке питания.  Хороший пример описан в отчёте регулятора OFCA по инциденту у China Mobile Hong Kong. Отказ одного из UPS в ЦОДе обесточил несколько серверов, включая RADIUS-систему авторизации мобильных данных. Это вызвало сбои мобильного интернета и VoLTE-звонков. Устройства начали массово повторять попытки подключения, что перегрузило часть ядра сети. Некоторые критичные системы были подключены только к одной ветке питания. После инцидента их перевели на независимые линии и изменили конфигурацию сети так, чтобы она могла работать даже при отказе RADIUS-сервера.

Охлаждение

В большинстве ЦОДов температуру отслеживают датчики в холодных и горячих коридорах, а также в инженерных помещениях. Именно по этим данным видно, что система начинает работать на пределе. Охлаждение редко ломается мгновенно, а чаще постепенно деградирует. Поэтому ночью важны не разовые скачки температуры, а тренды.

Не будим ночью:

• разовый скачок температуры на 1–2 °C без тренда и без роста по ряду.

Будим ночью:

• потеря резервирования по охлаждению (N+1);

• отказ чиллера или прецизионного кондиционера с потерей резерва;

• устойчивый рост температуры в холодных коридорах;

• перегрев воздуха на входе в серверы (inlet).

У меня на домашнем компьютере, особенно в летнюю жару, происходит то же самое. Вентиляторы начинают шуметь сильнее, температура медленно растёт, процессор сбрасывает частоты, но система продолжает работать. В ЦОДе всё примерно так же, только в гораздо большем масштабе.

Система хранения

Системы хранения ломаются «тихо». Сервис может долго оставаться доступным, но начинает заметно тормозить.

Не будим ночью:

• единичное предупреждение SMART без роста задержек и без деградации массива.

Будим ночью:

• деградация RAID или дисковой полки;

• рост ошибок контроллера;

• аномально долгий rebuild массива (восстановление после отказа диска);

• рост p95/p99 задержек I/O.

Среднее значение часто выглядит нормально, а вот редкие, но долгие операции в итоге бьют по пользователям. Один из самых известных случаев связан с инфраструктурой Amazon Web Services (AWS). проблемы с системой хранения EBS вызвали рост задержек и ошибок при работе с томами, из-за чего сервисы вроде Reddit и Quora начали деградировать и частично перестали работать. Причиной был каскадный процесс восстановления и репликации дисков, который перегрузил инфраструктуру хранения.

Сеть

Это классический мультипликатор проблем. Пользователь видит, что «всё тормозит», но настоящая причина может быть где угодно.

Не будим ночью:

• кратковременные потери пакетов без роста задержки и без ошибок интерфейсов.

Будим ночью:

• устойчивая деградация: потери пакетов вместе с ростом задержки или джиттера;

• flapping линков (частые up/down) или рост CRC-ошибок;

• падение магистрали или агрегации с потерей резервирования.

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

Есть старая английская поговорка: «Из-за гвоздя потеряли подкову, из-за подковы потеряли коня, из-за коня потеряли всадника, из-за всадника проиграли битву». В распределённых системах сеть иногда работает так же. Поэтому задача мониторинга не только в том, чтобы заметить проблему. Если система так чувствительна, оповещения нужно правильно проектировать.

Дизайн оповещений: уровни, корреляция, действие

Состояние против тенденции

Пороговые алерты отвечают на вопрос: «плохо ли сейчас?», но для ЦОДа важнее: «станет ли плохо и когда именно?». Ведь когда диск уже занят на 99,9% поздно что-то менять. Но если алерт приходит, когда диск растёт и заполнится через 8 часов, это уже операционная задача, а не пожар. Тренды позволяют поймать момент, когда система начинает уходить из нормального режима.

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

Уровни и корреляция

Минимально рабочая схема обычно включает три уровня:

CRITICAL — будим ночью, нужен немедленный шаг.

WARNING — будим днём, запас по времени ещё есть.

INFO — только в дашборд или журнал.

Это напоминает один из принципов современного UX-дизайн — design for action. Интерфейс должен подталкивать к действию, а не просто показывать информацию. В хорошем интерфейсе минимум текста, один понятный следующий шаг и как можно меньше когнитивной нагрузки. С алертами тоже самое. Хороший сигнал отвечает сразу на три вопроса:

• что произошло,

• где смотреть,

• что делать.

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

Помимо этого важно, чтобы один инцидент не превращался в десятки сообщений. Для этого сигналы агрегируют, коррелируют и отсекают случайные выбросы. В некоторых SRE-командах даже вводят noise budget — бюджет шума. Если алертов становится слишком много, новые запрещено добавлять, пока команда не сократит существующий шум.

runbook

Это короткая пошаговая памятка, которая говорит, что проверить, что сделать и куда эскалировать.

Для CRITICAL-сигналов без runbook хаос почти неизбежен. Ночью, в состоянии стресса и дефицита времени, дежурному сложно быстро принять правильное решение. Он начинает думать и выбирать вариант действий, а это самый дорогой режим реакции. Поэтому во многих командах действует простое правило:

Алерт без понятного действия — не алерт.

Здесь полезен ещё один принцип продукт-дизайна — progressive disclosure, раскрытие информации по мере необходимости. Пользователю сначала показывают главный сигнал, а детали открываются дальше.

В мониторинге всё тоже самое. Сначала дежурный получает агрегированный сигнал, а уже в карточке раскрываются детали инцидента: графики, логи, диагностика. Иначе один инцидент может превратиться в двадцать алертов.

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

Чек-лист

1. Посчитайте NNR за последние 30 дней и сравните с порогом 3–5. Если выше — это не промышленный алертинг, а «будильник-генератор».

2. Найдите топ-10 ночных алертов по частоте и прогоните каждый через «Ночной тест».

3. Переведите всё не требующее немедленного действия в INFO или дашборд.

4. Замените пороги на тенденции и прогнозы: диск «закончится через X», температура «растёт Y °C/час».

5. Склейте симптомы в один инцидент (корреляция) и уберите повторы (дедупликация).

6. Добавьте runbook для каждого CRITICAL и пересматривайте правила после каждого постмортема.

Вывод

Хорошая система оповещений большую часть времени молчит.

Ночной тест — самый честный аудит.

Если ночью приходит больше одного-двух осмысленных сигналов, проблема не в инфраструктуре, а в мониторинге. Зрелый мониторинг — это не «слышать всё», а отделять шум от сигналов, по которым нужно действовать.