В этой статье я хочу поделиться своим опытом организации работы системы ИТ-мониторинга.
Здесь мы рассмотрим один из возможных вариантов решения конкретно организационных проблем; технические аспекты современных систем мониторинга обсуждаться не будут. Хочу сразу уточнить, что объектами мониторинга в моем случае являются исключительно ИТ-компоненты, это: серверы, операционные системы, базы данных, транзакции и т. д. 
Каждый раз в своей профессиональной деятельности при решении задачи построения комплексной системы ИТ-мониторинга я стараюсь придерживаться такого подхода, который позволяет заказчику получить качественную систему мониторинга.
Подход универсальный, я убежден, что он может найти свое применение не в ИТ-сфере.
Как это происходит
В силу характера нашей деятельности нам часто приходится сталкиваться с системами мониторинга, которые после внедрения равномерно покрываются толстым слоем пыли, и те, для кого системы создавались, удобно забывают об их существовании, и только трудолюбивые серверы добросовестно продолжать потреблять электроэнергию центра обработки данных.И далее! Что примечательно, так это то, что программное обеспечение, используемое в таких «горных» системах, самое современное, самое дорогое, и к техническим недостаткам претензий вообще быть не может. Но сисадмин все равно получает уведомления о сбоях, используя свой проверенный годами скрипт! Картину с администратором могу дополнить следующими знакомыми синдромами:
- Никто не понимает, за кем и какие параметры следит система мониторинга;
- Система буквально забрасывает консоль оператора или электронную почту нашего администратора сообщениями о жутких сбоях.
Попробуйте здесь поймать действительно важное сообщение;
- Нет доверия к качеству предоставляемых услуг мониторинга, в результате каждый решает проблемы самостоятельно или даже не задумывается о мониторинге;
- Модели взаимного влияния между объектами мониторинга со временем теряют свою достоверность; их обновление – просто непосильная задача.
Зачем нужен мониторинг?
Чтобы подготовить читателя к дальнейшему чтению, хочу добавить несколько определений: Система наблюдения – система, которая обнаруживает отклонение наблюдаемого параметра от заданной нормы и в результате выполняет определенное действие.Задачи мониторинга:
- Обнаружение исключений (раз);
- Результатом является выполнение автоматизированного Действия (два).
Еще пара определений: Клиент – лицо, заинтересованное в получении услуг мониторинга.
Поставщик – лицо, оказывающее услугу мониторинга.
Определение правил игры (регламента)
Так кто же Заказчик? Это, как правило, человек, отвечающий за функционирование того или иного сервиса, программного обеспечения или даже просто сервера внутри организации; именно от него спрашивают качество функционирования перечисленных объектов.Провайдер имеет возможность организовать для Заказчика мониторинг необходимых объектов и их параметров для своевременного обнаружения или предотвращения поломок.
Так! Необходимо определить определенные правила взаимодействия между Заказчиком и Провайдером.
Изучение данного вопроса является необходимой мерой для создания комфортной среды взаимодействия, ведь Заказчик является ответственным лицом и ему необходимо понимать, как ответственность будет распределяться между ним и Поставщиком мониторинга.
Еще раз хочу отметить в той или иной форме, но регламент должен быть! Нормативно-правовые акты — документ, определяющий правила взаимодействия и правила распределения обязанностей между Заказчиком и Провайдером.
Вот список вопросов, на которые должны ответить правила:
- Обязанности Поставщика мониторинга по отношению к Заказчику;
- Обязанности Заказчика;
- Определение круга лиц, которые могут выступать Заказчиком;
- Условия разрешения споров в случае конфликта интересов;
- Правила включения объектов в цикл мониторинга;
- Правила перевода объектов мониторинга в режим обслуживания;
- Правила удаления объектов мониторинга из контура мониторинга.
Приложение
Основным документом взаимодействия Заказчика и Провайдера будет Приложение для мониторинга.Приложение – это документ, формализующий все требования Заказчика к задачам, которые он намерен решить с помощью системы мониторинга.
Предлагаю описать в регламенте правила заполнения, согласования, тестирования, ввода в эксплуатацию всего этого, а также перечень лиц, которые имеют право выступать в роли Заказчика.
Приложение представляет собой небольшой договор, соответствующий определенной форме, между Заказчиком и Провайдером; это также будет основным средством разрешения споров между ними, например: «Смог ли мониторинг выполнить поставленную в Заявке задачу!» Способ заполнения заявления зависит от методов документооборота организации:
- Бумажная версия;
- Ээлектронный;
- Специализированная система.
Структура приложения
Я уже говорил о двух самых важных вещах в организации системы мониторинга: Регламент – это одно, Применение – это два.Вот тут-то читатель может воскликнуть: «Всего этого мало!» Отвечу: «Конечно, недостаточно, остальное просто не входит в рамки данной статьи».
Теперь хочу добавить технические подробности, приведу пример структуры Приложения, которое мне пришлось использовать.
А поскольку дальше речь пойдет о технических деталях, приглашаю к обсуждению всех, кто готов дочитать эту статью на этом этапе, буду рад обсудить возникшие вопросы.
Вернемся к структуре приложения; Описать приложение могу расширенно в виде следующих групп:
- Общий
- Ответственный
- Конфигурационные единицы (CU)
- Состояние
- Действие
- Конфигурация
Ответственный обязательный атрибут Приложения; оно может измениться, но не может отсутствовать.
Круг лиц, имеющих возможность инициировать процесс создания Заявления, предлагается определить в Положении.
Конфигурационные единицы (CU) – это список объектов, для которых необходимо реализовать условия данной заявки.
Информации о К? должно быть вполне достаточно для его однозначной идентификации.
На этапе проектирования системы мониторинга предлагается разработать план КУ, их возможные типы и необходимые атрибуты.
В зависимости от архитектуры системы мониторинга список ЭК в приложении может формироваться вручную или на основе данных обнаружения объектов инфраструктуры (существуют специализированные системы, способные провести инвентаризацию всей ИТ-инфраструктуры).
Также список КУ в приложении может формироваться автоматически по условию (Например: все серверы, принадлежащие определенной подсети, это может быть ссылка на запрос к базе данных, где хранится информация об объектах инфраструктуры).
Условия – точная формулировка проверок, которые необходимо провести для осуществления мониторинга.
Условия должны быть тщательно зафиксированы в Заявлении; это будут исходные данные для разработки.
Каждое условие сравнивается со списком КУ или с отдельными экземплярами КУ.
Пример типов условий:
- Проверка параметров ОС;
- Нахождение ошибки в файле журнала;
- расчет УУЗР;
Каждое действие должно иметь уникальное имя (идентификатор).
Этот идентификатор должен быть включен в атрибуты полученного системой мониторинга сообщения, что позволит идентифицировать необходимое действие на стороне системы мониторинга.
В свою очередь, система мониторинга должна иметь настройки, позволяющие выполнять то или иное действие в зависимости от названия действия.
Примеры типов действий:
- Уведомление по почте;
- Оповещение посредством СМС;
- Инициирование инцидента;
- Расчет статуса HI для KE;
- Расчет KPI для К?.
Может содержать следующую информацию:
- Название программного обеспечения;
- Название конфигурации, которую необходимо примерить на соответствующий комплект КУ или отдельное КУ для выполнения условий Заявки.
(Пример: политика мониторинга или группа политик мониторинга).
Также ссылка на конфигурацию позволит вам определить, какое Приложение связано с теми или иными настройками системы мониторинга.
Вот схематическая структура приложения: 
Жизненный цикл приложения
Последнее, на что хотелось бы обратить внимание, это жизненный цикл приложения, я выделю следующие этапы:- Декор;
- Разработка;
- Тестовая эксплуатация;
- Промышленная эксплуатация.
Разработка Здесь все просто! Создание конфигураций в системе мониторинга в соответствии с условиями Приложения и переход на следующий этап – тестовую эксплуатацию.
Мы не исключаем возможности возврата Приложения на стадию регистрации для уточнения или переопределения условий мониторинга.
Тестовая эксплуатация Здесь мы решаем тонкий политический вопрос: «Кто готовит тестовую среду» и проводим все необходимые мероприятия, связанные с тестированием Приложения.
По результатам тестирования возможен возврат Приложения на стадию регистрации или разработки в зависимости от выявленных проблем.
После успешного завершения опытной эксплуатации следующим этапом является промышленная эксплуатация.
Промышленная эксплуатация Здесь все серьезно: система работает, инциденты выявляются, уведомления отправляются.
На этапе промышленной эксплуатации предусматриваю возможность внесения изменений в Приложения, например изменения:
- Незначительный;
- Главный.
При незначительных изменениях я не меняю версию Requests. Главный – изменения, требующие возврата на стадию разработки, например, изменение условий мониторинга.
В случае существенных изменений мы меняем статус версии Приложения; предыдущие версии должны быть выведены из эксплуатации.
И, наконец, из коммерческой эксплуатации Приложение может быть выведено из эксплуатации или переведено в режим обслуживания.
Режим технического обслуживания – это тот случай, когда необходимо временно отключить мониторинг для проведения технических мероприятий.
Схематически представлю этапы жизни Приложения на следующем рисунке: 
Общий
Подводя итог, хочу сказать, что успешную работу системы мониторинга я основываю на трёх китах: Регламент, Применение и технические возможности самой системы.Хорошей практикой будет создание определенного количества Приложений, содержащих стандартные условия мониторинга.
Для таких приложений достаточно просто идентифицировать объекты мониторинга, определить получателей уведомлений и перейти к этапу промышленной эксплуатации.
Это все, что я хотел сказать в этой статье, рад пригласить вас к дискуссии, готов ответить на вопросы.
Теги: #It #мониторинг #управление операциями #управление системой #проектирование и рефакторинг
-
Космические Похороны
19 Oct, 24 -
Старение - Программа
19 Oct, 24 -
Открытое Производство - Мотивационный Аспект
19 Oct, 24
