UDV Group: зеленый дашборд не всегда означает управляемость ИТ
Российский разработчик решений в области киберустойчивости UDV Group рассказал, почему наличие мониторинга не гарантирует контроль над ИТ-инфраструктурой. В авторской статье для CISO Club менеджер продукта UDV ITM Андрей Иванов объяснил, как технические метрики могут расходиться с реальным состоянием бизнес-сервисов и почему компаниям важно связывать мониторинг с процессами, зависимостями и рисками для бизнеса.
В ИТ-службе все может выглядеть штатно: серверы доступны, каналы связи работают, процессоры не перегружены, показатели SLA остаются в зеленой зоне. При этом пользователи уже жалуются на задержки, сотрудники вручную повторяют операции, часть транзакций не проходит, а инженеры компенсируют отклонения в смежных системах. В такой ситуации мониторинг не обязательно ошибается - он просто отвечает только на те вопросы, которые в него были заложены.
В UDV Group отмечают, что ключевая проблема возникает, когда контроль заканчивается на уровне отдельных инфраструктурных объектов. Для бизнеса важна не только доступность сервера, порта или диска, а возможность выполнить конкретную операцию: принять заказ, провести платеж, отгрузить продукцию или обеспечить работу технологического процесса. Если мониторинг не показывает связь между техническим событием и бизнес-последствием, у компании возникает иллюзия управляемости.
Один из типичных признаков такой ситуации - «зеленый» управленческий дашборд при нарастающих эксплуатационных проблемах. Пороговые правила хорошо фиксируют отказ сервиса, заполнение диска или потерю канала связи, но постепенный рост времени отклика может долго оставаться в допустимых пределах. Формально SLA выполняется, а фактически сотрудники тратят больше времени на ручные операции, повторные действия и обходные сценарии.
«Само наличие мониторинга еще не означает, что компания управляет ИТ. Если система видит сервер, но не видит зависимость сервиса от электропитания, охлаждения, внешнего SaaS-провайдера или смежной бизнес-системы, она не дает полной картины. Для руководителя важен не только факт алерта, а понимание, какой процесс затронут, кто должен реагировать и какие потери возникнут, если отклонение продолжится», - отметил Андрей Иванов, менеджер продукта UDV ITM в UDV Group.
Отдельный источник слепых зон проходит по границам ответственности. SaaS-сервис может находиться в зоне внешнего поставщика, инженерная инфраструктура ЦОДа - в зоне эксплуатации здания, устаревшее оборудование - без назначенного владельца. При этом сбой на любом из этих участков способен повлиять на работу тех же бизнес-сервисов. Без модели зависимостей отдельные метрики остаются набором наблюдаемых объектов, а не управляемой системой.
UDV Group также обращает внимание на необходимость контролировать саму систему мониторинга. Канал доставки уведомлений может перестать работать, сертификат агента - истечь, а коллектор - прекратить получать данные от части источников. Поэтому отсутствие алертов нельзя автоматически считать признаком штатной работы инфраструктуры, пока не подтверждена доступность компонентов мониторинга, актуальность данных и прохождение синтетических проверок.
Еще одна распространенная ошибка - оценивать устойчивость только по скорости восстановления. MTTR показывает, как быстро сервис вернулся в рабочее состояние, но не отвечает на вопрос, была ли устранена корневая причина сбоя. Если команда каждый раз перезапускает компонент или переключается на резерв, но проблема повторяется, скорость реакции растет, а устойчивость системы не меняется.
В UDV Group считают, что управляемость начинается с связи технических метрик с бизнес-показателями. ИТ-служба контролирует доступность приложений, задержки и загрузку ресурсов, а бизнес - выручку, заказы, конверсию, отмененные операции и выполнение производственных процессов. Эти данные описывают одно событие, но часто находятся в разных системах и анализируются разными подразделениями. Связать их можно только на уровне управления, где определяются приоритеты, бюджеты и допустимый риск.
При таком подходе алерт становится не просто уведомлением о техническом отклонении, а основанием для решения: вмешаться немедленно, перераспределить ресурсы или перенести устранение в плановое окно. Для этого система мониторинга должна показывать, какой сервис и какие бизнес-операции затронуты, сколько пользователей или транзакций находится под влиянием и как будут расти потери, если проблема сохранится.
Отдельное значение приобретает миграция на новые платформы мониторинга. При выборе решения компании обычно оценивают поддержку протоколов, набор метрик, отчеты и интеграции. Но за годы эксплуатации в прежней системе накапливается операционная логика: пороги, правила корреляции, маршруты эскалации, базовые профили нагрузки и сценарии реагирования. Если не перенести и не проверить эту логику, новая платформа может быть функционально полноценной, но хуже отражать реальные зависимости.
UDV Group рекомендует компаниям оценивать мониторинг не по количеству подключенных источников и числу дашбордов, а по практическим признакам управляемости. Когда система в последний раз обнаружила проблему раньше пользователя? Есть ли разбор последнего повторяющегося инцидента? Какие изменения были выполнены после него? Сколько алертов дежурная команда проигнорировала за неделю и почему? Ответы на эти вопросы показывают, помогает ли мониторинг управлять инфраструктурой или только фиксирует отдельные технические состояния.
В UDV Group подчеркивают, что зрелый мониторинг должен объединять ИТ-системы, АСУ ТП, инженерную инфраструктуру и события информационной безопасности в единую картину. Только тогда компания может видеть не отдельные метрики, а реальные зависимости, оценивать влияние инцидентов на бизнес и быстрее выходить на причину проблемы.