Вы успешно подписались на блог Naumen
Статьи доступны к чтению
Добро пожаловать! Регистрация прошла успешно.
Отлично! Ваш аккаунт активирован, контент доступен.
Success! Your billing info is updated.
Billing info update failed.
Почему необходимо распространять мониторинг на целостные ИТ-услуги

Почему необходимо распространять мониторинг на целостные ИТ-услуги

9 минут чтения

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

Что такое классический ИТ-мониторинг и зачем он нужен

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

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

Naumen Network Manager


Получайте актуальные данные о состоянии инфраструктуры: сетевого и ИТ-оборудования, ПО и других объектов

Почему классический мониторинг недостаточен для управления ИТ-услугами

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

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

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

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

Главная задача классического мониторинга собирать информацию по объектам инфраструктуры и отслеживать по заданным метрикам. А при срабатывании триггера оповестить о событии

В результате формируется целый комплекс проблем. Обозначим основные.

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

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

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

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

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

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

Как обеспечить целостный подход к ИТ-услугам

Чтобы контролировать состояние сервисов и услуг, необходимо понимать, как и с какими объектами инфраструктуры они связаны. Для этого формируются следующие источники информации.

Configuration Management Database (CMDB) — это централизованная база конфигурационных единиц, которая должна обеспечивать исчерпывающие и актуальные данные о каждом элементе ИТ-ландшафта и взаимозависимостях. Она формируется несколькими способами:

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

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

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

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

Эти решения аккумулируют информацию из всех источников и сопоставляют. Результатом становится определение здоровья каждого сервиса.

Что дает комплексный мониторинг ИТ-услуг

Перечислим основные выгоды комплексного мониторинга ИТ-услуг.

Получение сводных данных из разных источников. Собранные в ходе мониторинга сведения концентрируются в едином пространстве. Это дает информационную базу для формирования 360-view целостной ИТ-услуги.

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

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

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

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

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

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

Naumen Business Service Management


Контролируйте здоровье инфраструктуры с помощью предиктивной аналитики

Что может помешать изменить подход к мониторингу

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

  1. Это наша зона ответственности, сами знаем, как правильно.
  2. Менять подход нет времени, поскольку нужно постоянно реагировать на сбои и управлять инфраструктурой.
  3. Все и так нормально работает.

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

Как обосновать необходимость мониторинга ИТ-услуг

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

Другое дело, если менеджер услуг и ИТ-специалист достигнут согласия в этом вопросе и вместе донесут до высшего руководства компании ценность нового подхода. Как же склонить ИТ-специалиста на свою сторону, с помощью каких доводов? Например, выделим такие:

  1. Никто не собирается лезть в чужую зону ответственности и вмешиваться в управление инфраструктурой. Задача — понять, как работает услуга в связке с оборудованием и ПО.
  2. Нехватка времени и аврал в управлении инфраструктурой связаны с отсутствием комплексного мониторинга услуг. В случае прерывания сервисов ИТ-специалистам приходится долго разбираться, где именно произошел сбой.
  3. Даже если в конкретной системе мониторинга все четко налажено, возможны ложные срабатывания и ошибки. Настройка триггеров для метрик в нескольких системах зачастую приводят к повторяющимся или противоречащим друг другу реакциям. Если менеджер услуг будет видеть точную картину по состоянию сервисов, он не станет отвлекать ИТ-специалистов в подобных ситуациях.

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

К выводам

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

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