Мониторинг в ИТ, как организовать работу

Введение

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

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

• Обнаружение исключительной ситуации (раз);
• Как результат – выполнение автоматизированного Действия (два).

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

Еще пара определений:
Заказчик – лицо, заинтересованное в получении услуг мониторинга. Услуга мониторинга – это выполнение задач мониторинга.
Провайдер – лицо, предоставляющее услугу мониторинга.

В конце введения добавлю примеры проблем, которые мне приходилось наблюдать в работе системы мониторинга ИТ:

• Нет понимания, для кого и какие параметры отслеживает система мониторинга;
• Система мониторинга буквально засыпает консоль оператора или почту Заказчика сообщениями, что приводит к игнорированию или пропуску важных сообщений;
• У Заказчика нет доверия качеству предоставляемых услуг мониторинга, как результат попутка организовать мониторинг своими силами или не делать ничего;
• Модели взаимного влияния компонентов инфраструктуры (сервисно-ресурсные) быстро теряют свою актуальность, за-за проводимых инфраструктурных изменениях.

Определение правил игры (регламент)

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

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

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

Заявка

Основным документов взаимодействия меду Заказчиком и Провайдером будет являться Заявка на мониторинг.

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

• Ведение документов в бумажном виде;
• Ведение документов в электронном виде;
• Ведение документов в специализированных системах.

Структура заявки:
Вот тот список атрибутов Заявки, которые мне приходится использовать:
Общее

• Номер
• Версия
• Статус

Ответственный

• ФИО
• Контакты

Конфигурационные единицы (КЕ)

• Уникальное наименование списка КЕ

Условие

Действие

• Тип (Пример: почтовое уведомление, смс уведомление)
• Уникальное наименование действия

Техническое Решение (ТР)

• Наименование конфигурации системы мониторинга

Общее:

Номер – уникальный номер, для однозначной идентификации документа (Правила формирования могут быть определены в регламенте).
Статус – признак, предписывающий выполнять необходимые действия по конфигурированию системы мониторинга в соответствии с данной Заявкой и ТР. Конфигурирование системы мониторинга может происходить непосредственно вручную или с использованием средств автоматизации процессов администрирования. Варианты статусов:

• Активен;
• Не активен;
• Режим обслуживания.

Ответственный

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

Конфигурационные единицы (КЕ)

Конфигурационные единицы (КЕ) – это список объектов, для которых необходимо реализовать условия данной заявки. Информации о КЕ должно быть в полной мере достаточно для ее однозначной идентификации. На этапе проектирования системы мониторинга предлагается разработать план КЕ, их возможные типы и необходимые атрибуты. Пример плана КЕ:

• Сервер (Наименование, Расположение, ОС)
• Экземпляр программного обеспечения (Наименование, Расположение (Сервер*))
• Сервис
• Транзакция

В зависимости от архитектуры системы мониторинга список КЕ в заявке может формироваться вручную или же на основе данных обнаружения инфраструктуры. Так же список КЕ в заявке допускается формировать автоматизировано на основе условия (Например: все сервера принадлежащие определенной подсети, это может быть ссылка на запрос в CMDB).

Условие

Условия – точные формулировки проверок, которые необходимо выполнять для реализации мониторинга. Условие – это результат совместного труда Заказчика и Провайдера. Условие мониторинга сопоставляются с определенным списком КЕ.
Типы условий:

• Проверка параметров ОС;
• Поиск ошибки в лог-файле;
• Расчет SLM;
• ……

Действие

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

• Уведомление по почте;
• Уведомление по смс;
• Заведение инцидента;
• Расчет статуса HI (ETI);
• Расчет KPI для КЕ.

Техническое Решение (ТР)

Техническое решение (ТР)- описание реализации условий Заявки.
ТР должно указывать на конфигурацию системы мониторинга:

• Наименование программного обеспечения;
• Наименование конфигурации, которую необходимо примерить для соответствующего набора КЕ, для выполнения условий Заявки. (Пример: группа, политика мониторинга, группа политик мониторинга).

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

• Конфигурацию выполнения действий;
• Конфигурацию перевода мониторинга в режим обслуживания.

Общая структура заявки приведена на следующем рисунке:

Жизненный цикл

1. Разработка
2. Разработка ТР
3. Тестовая эксплуатация
4. Промышленная эксплуатация

Жизненный цикл заявки приведен на следующем рис:

Итого

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

Автор: SCheprasov

Источник ^[1]