Иллюзия управляемости: почему мониторинг есть, а контроля нет
В ИТ-службе всё выглядит штатно: серверы доступны, процессоры не перегружены, каналы связи работают, показатели SLA находятся в зелёной зоне. В это же время пользователи уже жалуются на задержки, сотрудники вручную повторяют операции, часть транзакций не проходит, а инженеры ЦОДа компенсируют отклонения в системе охлаждения. Система мониторинга при этом не обязательно ошибается. Она просто отвечает на вопросы, которые ей задали.
Проблема в том, что эти вопросы часто заканчиваются на границе инфраструктуры. Работает ли сервер? Доступен ли порт? Не превышен ли порог загрузки диска? Но бизнесу важно не состояние отдельного узла, а возможность выполнить конкретную операцию: принять заказ, провести платёж, отгрузить продукцию или обеспечить работу технологического процесса.
Поэтому само наличие системы мониторинга ещё не означает, что компания управляет ИТ. О том, где заканчивается наблюдение за инфраструктурой и начинается реальная управляемость, почему технические метрики не складываются в целостную картину для бизнеса и как понять, можно ли доверять системе, рассказал Андрей Иванов, менеджер продукта UDV ITM в UDV Group.
Зелёный дашборд может скрывать проблему
Одна система мониторинга обслуживает несколько уровней управления. Регулятору необходимо подтверждение выполнения требований, топ-менеджерам — картина доступности ключевых сервисов, CIO оценивает SLA и сроки восстановления, инженер анализирует метрики, журналы и изменения конфигурации. Проблема начинается, когда управленческий дашборд подменяет эксплуатационную картину. Панель показывает, что SLA соблюден, хотя инженер уже видит рост задержек, повторные перезапуски и увеличение числа ручных операций.
Особенно долго такое расхождение сохраняется при постепенном ухудшении работы сервиса. Если мониторинг настроен преимущественно на пороговые события, система уверенно фиксирует отказ сервиса, заполнение диска или потерю канала связи. Но постепенный рост времени отклика может месяцами оставаться в пределах заданных порогов. Динамика сохраняется в истории метрик, но без анализа трендов и отклонений от базового уровня алерт не формируется. В это время сотрудники начинают чаще повторять операции, вручную сверять данные или перезапускать компоненты, тогда как на управленческой панели сервис по-прежнему выглядит доступным, а связанные с ним затраты и операционные риски продолжают расти.
Слепые зоны проходят по границам ответственности
Объект может влиять на работу сервисов, но не входить в контур наблюдения, поскольку формально относится к другому подразделению или внешнему поставщику. Так чаще всего происходит с SaaS-сервисами, доступность которых обеспечивает провайдер, и с устаревшим оборудованием, для которого уже не определены владелец и порядок сопровождения. Еще один типичный пример — инженерная инфраструктура ЦОДа. Серверы контролирует ИТ-служба, а электропитание и охлаждение находятся в зоне эксплуатации здания, хотя отказ этих систем способен остановить те же бизнес-сервисы.
Из-за такого разделения отдельные метрики не складываются в цепочку зависимостей. Недостаточно контролировать доступность сервера и загрузку его ресурсов. Необходимо видеть, от каких систем электропитания, охлаждения и внешних сервисов зависит приложение и кто должен реагировать на каждом участке этой цепочки. Без модели зависимостей и закрепленных зон ответственности инфраструктура остаётся набором наблюдаемых объектов, а не управляемой системой.
Отдельно нужно контролировать работоспособность самого мониторинга. Канал доставки уведомлений может перестать работать, сертификат агента — истечь, а коллектор — прекратить получать данные от части источников. Поэтому система должна отслеживать доступность собственных компонентов, актуальность данных, число подключенных источников и прохождение синтетических проверок. Пока этот контур не подтверждён, отсутствие алертов нельзя считать свидетельством штатной работы инфраструктуры.
Скорость реакции ≠ устойчивость
Среднее время восстановления, или MTTR, показывает, сколько времени проходит от обнаружения инцидента до возвращения сервиса в рабочее состояние. Метрику можно улучшить за счет перезапуска компонента, переключения на резерв или временного обходного решения. Но если корневая причина не устранена, сбой повторится, а команда снова выполнит те же действия. В этом случае скорость восстановления растет, но устойчивость системы не меняется.
Поэтому MTTR лучше оценивать вместе с результатами анализа инцидентов: для какой доли повторяющихся сбоев установлена корневая причина, какие корректирующие меры выполнены и возникала ли проблема после их внедрения. Иначе сокращение времени восстановления показывает только то, что команда быстрее возвращает систему в прежнее состояние.
Та же проблема возникает в алертинге. Если дежурную смену оценивают прежде всего по количеству ложных вызовов, инженеры повышают пороги, отключают шумные правила и постепенно перестают реагировать на часть уведомлений. Чтобы снижение шума не приводило к пропуску значимых событий, уведомления нужно разделять по требуемой реакции. Критические события сразу передаются дежурной смене, менее срочные регистрируются для разбора в рабочее время, а накопленные изменения анализируются как тренды. В KPI при этом должны учитываться не только ложные вызовы, но и пропущенные инциденты, повторяемость сбоев и результаты анализа их причин.
Даже правильно настроенный алертинг не даёт полной картины, если эксплуатационный мониторинг и средства информационной безопасности работают раздельно. На раннем этапе атака может проявляться ростом нагрузки, изменением сетевого профиля или появлением новых связей между узлами, не вызывая отказа сервиса. Без корреляции технических показателей с событиями ИБ команды видят разные части одного инцидента и могут неверно определить его причину.
Еще один источник потери управляемости возникает при замене платформы мониторинга. При сравнении решений компании обычно оценивают поддержку протоколов, набор метрик, отчеты и интеграции, но за годы эксплуатации в прежней системе накапливаются пороги, правила корреляции, маршруты эскалации, базовые профили нагрузки и сценарии реагирования. При миграции эту операционную логику необходимо инвентаризировать, перенести и повторно проверить: часть правил потребует адаптации к новой модели данных, а некоторые профили придется формировать заново. Без этого новая платформа может быть функционально полноценной, но временно уступать прежней по качеству настроенного мониторинга.
Управляемость начинается со связи с бизнесом
Ключевой разрыв проходит между техническими метриками и показателями бизнеса. ИТ-служба контролирует доступность приложений, задержки и загрузку ресурсов, а бизнес — выручку, число заказов, конверсию и отмененные операции. Эти данные описывают одно событие, но находятся в разных системах и анализируются разными подразделениями. Связать их можно только на уровне управления, где определяются приоритеты, бюджеты и допустимый риск.
Для значимого события необходимо понимать, какой сервис и какие бизнес-операции оно затрагивает, как изменятся потери при сохранении отклонения и сколько пользователей или транзакций окажется затронуто. Тогда алерт становится основанием для решения: вмешаться немедленно, перераспределить ресурсы или перенести устранение в плановое окно.
Такая привязка нужна и при оценке машинного обучения. Количество обнаруженных аномалий само по себе не показывает пользу для эксплуатации. Важно, какие события выявляет модель, как меняется число ложных срабатываний и сокращается ли время обнаружения значимой проблемы. Проверить это можно только на пилоте с данными собственной инфраструктуры. Он покажет, помогает ли аналитика раньше выявлять отклонения или лишь создаёт дополнительный поток уведомлений.
При этом часть инженерной экспертизы не удается сразу превратить в формальное правило. Опытный специалист замечает приближение сбоя по сочетанию метрик, истории работ и поведению связанных систем, тогда как начинающий инженер видит те же графики, но не считывает их контекст. Это похоже на рецепт супа от бабушки: последовательность действий можно записать, но в конце почти всегда остается пропущенный пункт — 10-20 лет у плиты. Поэтому такие наблюдения нужно фиксировать во время разборов инцидентов, проверять на последующих событиях и передавать в совместной работе с опытным специалистом. Иначе вместе с сотрудником компания потеряет способность правильно интерпретировать данные мониторинга.
Проверить, насколько системе можно доверять, руководитель может по нескольким практическим признакам. Когда мониторинг в последний раз обнаружил проблему раньше пользователя? Есть ли разбор последнего повторяющегося инцидента и какие изменения были выполнены по его результатам? Сколько алертов дежурная команда проигнорировала за неделю и почему?
Два практических признака показывают, насколько мониторинг действительно поддерживает управляемость: сводит ли он в единый контур ИТ-системы, АСУ ТП и инженерную инфраструктуру и позволяет ли сохранить накопленную логику при миграции. Перенос шаблонов Zabbix, порогов и правил важен не сам по себе, а потому, что без него команда на время теряет операционную память. В результате новая платформа может быть функционально полноценной, но хуже видеть реальные зависимости и дольше выводить инженеров на причину сбоя.
