От оборудования к Observability. Почему первый шаг самый важный?

Observability (наблюдаемость) и AIOps сегодня рассматривают как новый этап развития мониторинга. Компании хотят видеть не только аварии, но и причины деградации сервисов, прогнозировать сбои, сокращать время реакции и использовать искусственный интеллект для анализа инфраструктуры. Однако нельзя забывать: Observability не возникает на пустом месте. Ее фундамент — корректный, полный и регулярный сбор данных с оборудования и инфраструктурных компонентов.

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

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

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

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

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

Ошибка многих проектов заключается в том, что Observability пытаются внедрить «сверху»: сначала обсуждаются дашборды, искусственный интеллект, корреляция событий и предиктивную аналитику. Но если не все оборудование заведено в систему мониторинга, часть параметров не нормализована, а события от разных производителей приходят в разном виде, то верхний уровень не получает единой основы для анализа.
В результате AIOps может группировать события, но не видеть реальную цепочку зависимости. Может искать аномалии, но опираться на неполную статистику. Может предлагать вероятную причину, но не учитывать устройство, с которого вообще не поступают метрики. Для алгоритма отсутствие данных не всегда выглядит как проблема, но на практике создается слепая зона.

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

Для сетевого оборудования имеют значение не только статусы «доступен / недоступен». Нужны данные по интерфейсам, загрузке, ошибкам, потере пакетов, состоянию модулей, питанию, температуре, резервированию. Для серверной инфраструктуры — доступность, загрузка ресурсов, состояние сетевых подключений и аппаратных компонентов. Для систем хранения — емкость, производительность, ошибки, состояние контроллеров и дисковых групп. Такой подход позволяет перейти от формального мониторинга к инженерно-полезной картине. Не просто «устройство отвечает», а "устройство работает в допустимом режиме, ключевые параметры стабильны, риски деградации видны заранее".

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

Для бизнеса это особенно важно в сервисных сценариях. Пользовательская операция может зависеть от десятков компонентов: сети, балансировщика, сервера приложений, базы данных, очереди сообщений, внешнего API. Если один из инфраструктурных элементов выпадает из поля зрения, сквозная диагностика становится неполной. Команда видит симптомы, но не видит всей цепочки. Именно поэтому первый шаг — инвентаризация, подключение оборудования, настройка сбора метрик и нормализация событий — часто важнее, чем кажется. Это не подготовительная работа, а основа для всех последующих уровней: сервисного мониторинга, Observability, AIOps и управления качеством цифровых сервисов.

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

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

В экосистеме Теком такую роль выполняет флагманский продукт ЦИСУСС «NB XT EM» — платформа для централизованного мониторинга и управления сетями связи и ИТ-инфраструктурой. Она обеспечивает сбор, хранение и обработку эксплуатационных данных от оборудования и внешних систем, анализирует параметры работы инфраструктуры и формирует единое информационное пространство для эксплуатации. Поддержка типовых сетевых протоколов, специализированных интерфейсов, интеграций с EMS-системами производителей и сторонними информационными системами позволяет получать достоверные данные из разнородной инфраструктуры. Именно такой уровень становится фундаментом, без которого невозможно построить корректную сервисную и аналитическую надстройку.