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