Что такое мониторинг ИТ-инфраструктуры

97% компаний пострадали от непредвиденных сбоев в ИТ-системах в 2022 году, данные Veeam Data Protection Trends. Для бизнеса поломки имели разные последствия: выход из строя терминала в магазине грозил максимум потерей нескольких клиентов, которые не взяли с собой наличку. А вот простой на промышленном предприятии приводил к миллионным убыткам, сбой в банке — еще и к утечке данных.

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

Больше цифры — выше риски

Уровень цифровой зрелости бизнеса неуклонно растет. Согласно исследованию «Т1» уровень цифровизации в России достиг 30% в электроэнергетике и розничной торговле, 25% — в металлургии, транспорте и логистике, 23% — в строительстве. По статистике, компания со штатом 1000 сотрудников в среднем использует 200 приложений, и 8 разных приложений приходится на одного сотрудника.

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

ИТ-мониторинг для безопасности и работоспособности систем

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

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

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

Тип мониторинга: инфраструктурный

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

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

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

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

Инфраструктурный мониторинг собирает данные и отслеживает их по преднастроенным метрикам. Если срабатывает триггер,
система оповестит о произошедшем событии

Проблемы классического мониторинга

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

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

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

2. Отсутствуют специалисты, которые рассматривают сбои в ИТ-инфраструктуре в целом.

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

3. Отсутствует приоритизация услуг, отсутствует SLA. Нет понимания, какие услуги и ИТ-объекты нужно поддерживать в первую очередь, так как от их доступности зависит непрерывность бизнеса.

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

4. Отсутствует возможность реагировать на инциденты проактивно.

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

5. Отсутствуют алгоритмы решения инцидентов.

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

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

Тип мониторинга: зонтичный

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

Если мы говорим о наблюдении за состоянием объектов ИТ, а не за какими-либо бизнес-метриками, то внедрить зонтичный мониторинг без инфраструктурного не получится. Поскольку системы инфраструктурного мониторинга типа Prometheus (для микросервисов), Zabbix (для классических статичных инфраструктур), Jager (для оценки производительности приложений) или Naumen Network Manager (универсальная система) выступают источниками данных для зонтичных решений.

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

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

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

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

Преимущества зонтичного мониторинга

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

Зонтичный подход несет множество выгод. Основные:

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

Какие инструменты мониторинга нужны бизнесу

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

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

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

Что еще интересного