Как выбрать систему мониторинга для бизнеса

В компании уже действуют несколько систем инфраструктурного мониторинга. Метрики оборудования в норме: серверы доступны, процессоры не перегружены. Почему тогда ИТ-сервисы работают медленно: wi-fi теряет сигнал, CRM не отвечает, принтер не подключается к сети, личный кабинет сотрудника выдает ошибки?

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

Какие задачи решают системы мониторинга ИТ

Мониторинг IT инфраструктуры чаще всего необходим, когда в компании назревает потребность контролировать состояние оборудования. Для этого внедряются решения инфраструктурного (корневого) мониторинга, которые снимают с объектов ИТ-ландшафта ключевые параметры работоспособности. В ряде таких решений, например, Naumen Network Manager, реализована модель Root Cause Analysis (RCA), которая позволяет находить источник обнаруженных аварий и тем самым быстрее их устранять.

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

Три уровня мониторинга, которые нужны бизнесу

Итак, для решения конечной задачи недостаточно просто собирать метрики с оборудования. Нужно больше данных. Более того, необходимо сопоставлять их между собой. Рассмотрим, какие именно сведения понадобятся.

Мониторинг инфраструктуры

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

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

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

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

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

Мониторинг приложений и сервисов

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

Системы корневого мониторинга способны обращаться к программным ресурсам компании, контролируя время отклика, частоту ошибок в коде, скорость выполнения SQL-запросов и нагрузку на микросервисы. Эти данные обеспечивают представление о том, как работает софт, исправен ли он, выполняет ли свои задачи.

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

Мониторинг бизнес-сервисов

На этом уровне происходит соединение данных всех систем корневого мониторинга между собой, а также с ресурсно-сервисной моделью (РСМ). Она строится на основе Configuration Management Database (CMDB) — базы данных конфигураций. Сведения из РСМ о связях между оборудованием и сервисами помогают связать поступающие сигналы тревоги с конкретным процессом, который может пострадать.

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

Аккумулирование сведений и связь с ресурсно-сервисной моделью происходит за счет интеграции систем корневого и зонтичного мониторинга. Второе решение само по себе не обращается к объектам инфраструктуры. Оно становится интеллектуальным центром, который содержит максимум данных об ИТ-ландшафте, анализирует поступающие сведения и обеспечивает наблюдаемость (оbservability).

Российские системы мониторинга: что изменилось

Уход зарубежных вендоров в 2022 году дал импульс развитию российского рынка систем мониторинга. За несколько лет он прошел путь от осторожных точечных тестирований до массового внедрения.

Если до 2022 года отечественные решения рассматривались как нишевые продукты, то сегодня это полноценные функциональные системы enterprise-уровня. Вектор отношения бизнеса изменился. Раньше компании искали аналоги для ПО, которое стало недоступно. Теперь в приоритете самодостаточные платформы с высокой производительностью, способные обрабатывать сотни тысяч метрик в секунду и взаимодействовать с гибридными ИТ-ландшафтами.

Сегодня российские решения предлагают:

• инфраструктурный и зонтичный мониторинг;
• развитую функциональность;
• предиктивную аналитику, различные модели для прогнозирования;
• соответствие регуляторным требованиям;
• совместимость с отечественными ОС, средствами виртуализации, ITSM-системами.

Такие продукты поддерживаются на русском языке, их проще дорабатывать под заказчиков, они не зависят от санкций и становятся полноценным вариантом импортозамещения. Это позволяет компаниям повышать уровень импортонезависимости и выстраивать безопасную и надежную ИТ-среду. В настоящее время российская система мониторинга способна закрыть самые сложные потребности крупного бизнеса и обеспечить дальнейшее масштабирование.

Критерии выбора системы мониторинга

Решения для корневого мониторинга подбираются под различные секторы технического ландшафта. Выбор системы мониторинга следующего уровня — зонтичного, более сложная задача. Остановимся на ней подробнее и рассмотрим критерии, которые нужно учитывать.

Готовые инструменты интеграции (коннекторы и API). Решение должно быть совместимо с корневыми мониторингами, которые использует компания. Также важно учитывать, есть ли возможность связать его с ITSM и CMDB с ресурсной-сервисной моделью. Если не окажется инструментов для интеграции с уже действующим ПО в ИТ-ландшафте компании, то их придется разрабатывать — а это время и деньги.

Гибкая ресурсно-сервисная модель. РСМ — необходимый элемент в мониторинге для связки «железа» с ИТ-сервисами. Она должна обеспечивать создание необходимых типов связей между элементами ИТ-ландшафта, автоматически обновляться при изменениях, иметь удобное визуальное представление. Чем гибче возможности, тем удобнее работать и тем эффективнее мониторинг. Без качественной РСМ система превращается в хранилище метрик, логов и трейсов.

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

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

Производительность, масштабируемость и отказоустойчивость. При развитии бизнеса ИТ-инфраструктура постоянно расширяется, а значит, растет не только количество метрик, но и объем. Важно, чтобы мониторингу была по силам растущая нагрузка и чтобы он не терял производительность при добавлении в ИТ-ландшафт компании новых объектов или точек обслуживания.

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

Применение AIOps. Это мощные инструменты предиктивной аналитики, которые лежат в основе предотвращения возможных сбоев в работе инфраструктуры. ИИ-модели предназначены для прогнозирования трендов в поведении метрик, выявления аномалий и уведомлении о вероятности проблем. В результате применения предиктивной аналитики оборудование медленнее изнашивается, потому что постоянно контролируется и своевременно обслуживается. Риски сбоев, а значит, простоев в сервисах, сводятся к минимуму.

Частые ошибки при выборе системы мониторинга

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

Изначально самая большая ошибка на старте — воспринимать проект как чисто техническую задачу, без привязки к потенциальным бизнес-возможностям. Рассмотрим, возможные отклонения от курса при внедрении мониторинга.

Ошибка	Последствия	Как избежать
Ориентироваться на чек-лист продвинутых функций	Приобрести функционал, который пока неактуален для компании и неизвестно, когда можно будет его применить. Продублировать те возможности, что уже есть, например, в системах корневого мониторинга. Выбрать инструменты, которые не подходят конкретной компании.	Отталкиваться от текущей ситуации в конкретной организации: что и как уже работает в ИТ-ландшафте, какие функции реализованы и какие необходимы.
Стремление закрыть одной системой все задачи	Универсальные системы часто проигрывают специализированным по специфической функциональности. В результате полученной глубины данных может оказаться недостаточно для полноценного решения задач мониторинга.	Использовать несколько специализированных корневых мониторингов и функциональный зонтичный.
Игнорирование необходимости интеграций	Решение останется изолированным, а значит, существенно потеряет в функциональности и автоматизации. Часть данных понадобится переносить вручную, а это повлечет искажения и ошибки.	На старте внедрения мониторинга учитывать возможности взаимодействия с другими корпоративными системами, чьи данные могут сделать его эффективнее.
Приоритет на здоровье оборудования и устройств	Если мониториться будет только «железо», вне зоны контроля останется качество и доступность ИТ-сервисов. Между тем именно они критически важны для поддержки бизнеса.	Переходить к проактивной модели управления инфраструктурой: связать каждый объект ИТ-ландшафта с ИТ-сервисом и обеспечить контроль последних.
Отсутствие связи с бизнес-показателями	Руководство бизнеса не видит, как мониторинг способствует эффективности и не понимает целесообразности инвестиций в этот инструмент.	Необходимо отслеживать метрики, которые «конвертируют» работоспособную инфраструктуру и ИТ-сервисы в бизнес-показатели. Например, время отклика баз данных — количество брошенных корзин на маркетплейсе. Или доступность ERP-системы — стоимость простоя сотрудника.

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

Как оценить бюджет на систему мониторинга

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

Инфраструктура под решение. Мониторинг нуждается в значительных ресурсах. Это вычислительные мощности для обработки событий и ИИ-алгоритмов. А также возможности для хранения данных — больших объемов метрик за значительные периоды для  ретроспективного анализа и обучения ML-моделей.

Внедрение, кастомизация. Сюда входят трудозатраты для интеграции с действующими корпоративными системами, настройка триггеров и автоматических сценариев, формирование CMDB и РСМ — все то, что делает систему применимой на конкретной ИТ-инфраструктуре для конкретных целей.

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

Скрытые расходы. В этот пункт можно включить ФОТ, который неизбежно возрастет, и затраты на поддержку и обслуживание решения:

• обучение имеющихся специалистов на операторов и администраторов системы, либо найм новых;
• ежегодное продление техподдержки;
• бюджет на «рост» при увеличении объектов мониторинга, усложнении автоматических сценариев — все это может потребовать, например, более дорогостоящих версий ПО.

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

Платформенный подход

Наибольший эффект мониторинг (в связке «корневой + зонтичный») покажет при интеграции с ITAM- и ITSM-системами. В таблице разберем разницу в процессах.

Без интеграции	С интеграцией
Оператор мониторинга самостоятельно определяет нужную услугу и вручную создает заявку в техподдержку. Исполнитель получает заявку и в других системах собирает необходимую информацию по вышедшему из строя объекту инфраструктуры.	Зонтичный мониторинг по полученным метрикам: ● классифицирует состояние оборудования; ● создает заявку в техподдержку, в которой автоматически определяются все необходимые параметры услуги; ● дополняет ее данными из CMDB и ITAM-системы. Сервисный специалист получает заявку со всеми необходимыми для быстрой работы сведениями.
Занимает от нескольких минут до часов.	Занимает от нескольких секунд до минуты.

При выборе продуктов стоит учитывать, что разработанные и действующие на одной платформе интегрируются бесшовно. Например, зонтичный мониторинг Naumen BSM, ITSM-решение Naumen Service Desk и система учета ИТ-активов Naumen ITAM имеют общую основу — Naumen SMP.

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

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

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

План по внедрению системы зонтичного мониторинга

Внедрение мониторинга — это не просто добавление ПО в ИТ-ландшафт компании. Это изменение подхода к управлению инфраструктурой.

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

1. Провести инвентаризацию ресурсов. Это потребуется для формирования CMDB и РСМ, если их еще нет. Если есть — актуализировать информацию перед внедрением мониторинга.
2. Создать CMDB и РСМ, если этого еще не сделано.
3. Определить критичные бизнес-процессы, простои в которых дороже всего обходятся компании, чтобы в первую очередь настраивать мониторинг для них.
4. Сформировать требования к системе мониторинга, учитывая возможности интеграции, построения РСМ, типизации и корреляции событий, визуализации данных, производительность и масштабируемость, использование ИИ-моделей.
5. Сделать необходимые настройки для сбора данных от систем корневого мониторинга, правил обработки, автоматических оповещений и сценариев.
6. Настроить визуализацию данных, например, по типам объектов, сервисам, здоровью услуг и другие.
7. Интегрировать с ITSM-системой и настроить автоматическое формирование заявок.

Следование такому плану поможет заложить базу для ИТ-мониторинга, который в дальнейшем можно будет оптимизировать и трансформировать под новые потребности компании.

К выводам

Внедрение мониторинга — это не столько техническая, сколько бизнес-задача. Чтобы она оптимально решалась, необходимо обеспечить:

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