Сейчас трудно определить, кому первому пришла в голову идея отображения сервисных моделей в интерфейсах систем управления ИТ. Явная недостаточность списка актуальных аварийных сообщений и карты сети для отображения взаимного влияния разнородных объектов инфраструктуры заставила производителей искать другие подходы к отображению. Раз уж исправная работа каждого объекта в определённой степени влияет на качество услуги, то логично представить модель в виде иерархического перевёрнутого дерева, в верхней части которого находится символ, олицетворяющий саму услугу (или сервис), а ниже, всё с большей детализацией, располагаются группы и компоненты, работающие на неё. Объекты внизу могут быть самые разные, сетевое и серверное железо, операционные системы, базы данных, прикладные программы – словом всё то, от чего могут приходить аварийные сообщения. Возникла неисправность на сервере, пришла критичная авария — соответствующий объект в сервисной модели покраснел. Степень влияния статуса заданного элемента модели на услугу в целом настраивалась в соответствии с пониманием этой степени самим создателем модели. Идея пришлась по душе заказчикам, и в первую очередь руководителям служб эксплуатации, поскольку их область ответственности по покрытию разнородных технологий, как правило, шире, чем область заботы специалистов.
Рис 1. Интерфейс TBSM в Tivoli Integrated Portal
За годы, прошедшие с момента первой реализации, функции систем сервисного управления существенно расширились. Из вспомогательных, подсвечиваемых авариями картинок, они превратились в настоящие платформы управления услугами, в отдельных случаях с функциями автоматического создания сервисных моделей и контроля соблюдения SLA в реальном времени. Естественно, что разные производители добились разных успехов и признания на рынке.
Наглядным примером и даже образцом такого стремительного функционального развития может служить Tivoli Business Service Manager (TBSM). (см Рис 1)
Не вдаваясь в техническое описание TBSM, перечислим его главные возможности:
— базируясь на ресурсах Netcool OMNIbus как всеобъемлющей системы сбора и обработки аварийных сообщений (Fault Management System), TBSM может подключаться и отображать в своём интерфейсе поведение объектов всех без исключения технологических доменов. Причём речь идёт об объектах как аппаратного, так и программного уровня. Этот способ учета состояний в сервисной модели даёт ответ на вопрос, что именно происходит внутри рабочих компонентов; он даёт оператору дежурной смены точные данные о неисправности и является залогом её скорейшего устранения. Это информация технического уровня.
— в определении состояния элемента сервисной модели могут участвовать практически любые данные, хранящиеся и изменяющиеся во времени в различных СУБД. Например, TBSM может смотреть в таблицу базы данных, где специализированное ПО бизнес уровня постоянно обновляет число транзакций за последнюю минуту. Он сравнивает это с заданными пороговыми значениями и меняет статус сервисного объекта в модели. Как правило, информация этого уровня имеет бизнес характер.
— для любого объекта сервисной модели в TBSM можно включить функцию контроля соблюдения SLA, причём это будет отслеживанием соблюдения в реальном времени, а не только постфактум. Предусмотрены три типа SLA: по длительности простоя, по количеству отказов (или нарушений SLA по длительности) за временное окно и, наконец, по суммарному времени всех простоев услуги за отчётный период. Все три типа могут использоваться вместе и в любых сочетаниях. На символах сервисов предусмотрены наглядные индикаторы не только текущего состояния услуги, но и отдельно для соблюдения каждого типа SLA. Кроме того, есть возможность задать цену несоблюдения SLA прямо в рублях. Операторы и руководители в режиме реального времени видят в интерфейсе TBSM, сколько минут осталось до нарушения SLA; какой показатель исполнения окажется, если проблема будет устранена прямо сейчас; и как набегают штрафные суммы после нарушения. Это удобно для определения приоритетов и очерёдности работ по устранению ИТ аварий. Естественно кроме индикаторов есть функция исторической отчётности позволяющая сделать детальный «разбор полётов» по факту допущенного нарушения SLA. Эта функция хорошо отражалась в самом первом названии продукта, он так и назывался SLAM или SLA Manager.
— после этого продукт назывался RAD или Realtime Active Dashboards, в этом названии особо подчеркивалась функция построения персональных инструментальных панелей, которые отображали ситуацию в реальном времени. На этих представлениях могут располагаться красивые сервисные модели, окна вывода аварийных сообщений в контексте выбранного объекта, суммирующие диаграммы, удобное навигационное дерево по услугам с динамической индикацией состояний и выводом числовых значений, плоттер изменения и сравнения состояний услуг во времени (Timewindow Analyzer) и, наконец, библиотека исторических отчётов. На индивидуальных холстах (Custom canvas), при построении инструментальных панелей, можно использовать «измерительные приборы» по типу спидометров и столбиков термометров. (Рис 2) Элементы сервисов можно представлять и в виде блоков с числовыми значениями интересующих параметров. Это то, что касается презентационного аспекта использования TBSM.
Рис 2 Вспомогательные индикаторы инструментальной панели TBSM
— Построение сервисной модели можно автоматизировать и привязать её обновление к изменяющимся внешним данным. Ядро OMNIbus, которое называется ObjectServer, по своей сути является базой данных, в которой хранятся и оперативно обрабатываются аварийные сообщения. Алгоритмы работы TBSM с ObjectServer и записями во внешних базах данных похожи. Если в аварийном сообщении или во вносимой в таблицу внешней базы записи содержится вся необходимая информация для правильного создания и размещения в сервисной модели объекта, то можно настроить функцию автоматического наполнения (autopopulation) сервисной модели. Представьте, что пришло аварийное сообщение от неизвестного в TBSM объекта, а исходя из полей сообщения TBSM можно решить к какому шаблону (типу объектов) он принадлежит, составить имя создаваемого объекта и определить, кто будет его родительским объектом в модели. Похожим образом новый объект может появиться и при внесении записи о нём во внешнюю базу данных. С внешними базами модель может фактически синхронизироваться. Эта функция часто применяется при привязке сервисной модели к базе инвентаризации и CCMDB. Без этого невозможно поддерживать в актуальном состоянии модели меняющихся ИТ систем с большим количеством элементов.
Выше говорилось о необходимости иметь широкий спектр «датчиков» для оценки объектов, работающих на производство услуги. Но не менее важным и полезным является наличие средств объективного мониторинга качества услуги с точки зрения пользователя, своего рода генераторы искусственных обращений к сервису с оценкой его качества. В Tivoli этим занимается TCAM (Tivoli Composite Application Manager). Логика совместного использования этих двух типов «датчиков» очень простая. К примеру, TCAM регистрирует неудовлетворительное время отклика сервиса или даже его отказ; он докладывает об этом в OMNIbus в формате критичного аварийного сообщения, где объектом является не устройство или сервер, а сам сервис.
В TBSM такие аварийные сообщения привязаны напрямую к сервисам в верхней части моделей. Одновременно «датчики на местах» обнаружили неисправности на объектах инфраструктуры и также прислали сообщения. TBSM привязал эти сообщения к низлежащим элементам модели и просчитал (и отобразил) распространение влияния по топологии модели вверх. Сервисная модель наглядно демонстрирует проблемную ситуацию, а главное – её источник. Спускаясь от «покрасневшего» сервиса вниз по дереву и следуя цветовой индикации, специалист сразу оказывается в точке наиболее вероятной причины. Примечательно то, что TBSM сам отмечает звёздочками объекты — логические причины проблемы. Получается своего рода визуальный анализ первопричины.
В заключение отметим, что поскольку TBSM принадлежит к семейству Netcool, он полностью соответствует требованиям к ПО операторского класса. Его можно использовать в критичных для бизнеса системах OSS. Он поддерживает отказоустойчивые схемы, распределение нагрузки или масштабирование, внешнюю авторизацию и Single Sign-on, работу в рамках единого портала с интерфейсами «OMNIbus Web GUI» и «Tivoli Network Manager». Tivoli Integrated Portal обслуживает контекстные взаимодействия между этими продуктами, что позволяет создавать удобные инструментальные среды с быстрыми переходами между контекстами мониторинга сетевого и телекоммуникационного оборудования, серверов и их операционных систем, хранилищ и баз данных, вэб-серверов и серверов приложений, и, наконец, самих сервисов как объектов мониторинга.
Рис 1. Интерфейс TBSM в Tivoli Integrated Portal
За годы, прошедшие с момента первой реализации, функции систем сервисного управления существенно расширились. Из вспомогательных, подсвечиваемых авариями картинок, они превратились в настоящие платформы управления услугами, в отдельных случаях с функциями автоматического создания сервисных моделей и контроля соблюдения SLA в реальном времени. Естественно, что разные производители добились разных успехов и признания на рынке.
Наглядным примером и даже образцом такого стремительного функционального развития может служить Tivoli Business Service Manager (TBSM). (см Рис 1)
Не вдаваясь в техническое описание TBSM, перечислим его главные возможности:
— базируясь на ресурсах Netcool OMNIbus как всеобъемлющей системы сбора и обработки аварийных сообщений (Fault Management System), TBSM может подключаться и отображать в своём интерфейсе поведение объектов всех без исключения технологических доменов. Причём речь идёт об объектах как аппаратного, так и программного уровня. Этот способ учета состояний в сервисной модели даёт ответ на вопрос, что именно происходит внутри рабочих компонентов; он даёт оператору дежурной смены точные данные о неисправности и является залогом её скорейшего устранения. Это информация технического уровня.
— в определении состояния элемента сервисной модели могут участвовать практически любые данные, хранящиеся и изменяющиеся во времени в различных СУБД. Например, TBSM может смотреть в таблицу базы данных, где специализированное ПО бизнес уровня постоянно обновляет число транзакций за последнюю минуту. Он сравнивает это с заданными пороговыми значениями и меняет статус сервисного объекта в модели. Как правило, информация этого уровня имеет бизнес характер.
— для любого объекта сервисной модели в TBSM можно включить функцию контроля соблюдения SLA, причём это будет отслеживанием соблюдения в реальном времени, а не только постфактум. Предусмотрены три типа SLA: по длительности простоя, по количеству отказов (или нарушений SLA по длительности) за временное окно и, наконец, по суммарному времени всех простоев услуги за отчётный период. Все три типа могут использоваться вместе и в любых сочетаниях. На символах сервисов предусмотрены наглядные индикаторы не только текущего состояния услуги, но и отдельно для соблюдения каждого типа SLA. Кроме того, есть возможность задать цену несоблюдения SLA прямо в рублях. Операторы и руководители в режиме реального времени видят в интерфейсе TBSM, сколько минут осталось до нарушения SLA; какой показатель исполнения окажется, если проблема будет устранена прямо сейчас; и как набегают штрафные суммы после нарушения. Это удобно для определения приоритетов и очерёдности работ по устранению ИТ аварий. Естественно кроме индикаторов есть функция исторической отчётности позволяющая сделать детальный «разбор полётов» по факту допущенного нарушения SLA. Эта функция хорошо отражалась в самом первом названии продукта, он так и назывался SLAM или SLA Manager.
— после этого продукт назывался RAD или Realtime Active Dashboards, в этом названии особо подчеркивалась функция построения персональных инструментальных панелей, которые отображали ситуацию в реальном времени. На этих представлениях могут располагаться красивые сервисные модели, окна вывода аварийных сообщений в контексте выбранного объекта, суммирующие диаграммы, удобное навигационное дерево по услугам с динамической индикацией состояний и выводом числовых значений, плоттер изменения и сравнения состояний услуг во времени (Timewindow Analyzer) и, наконец, библиотека исторических отчётов. На индивидуальных холстах (Custom canvas), при построении инструментальных панелей, можно использовать «измерительные приборы» по типу спидометров и столбиков термометров. (Рис 2) Элементы сервисов можно представлять и в виде блоков с числовыми значениями интересующих параметров. Это то, что касается презентационного аспекта использования TBSM.
Рис 2 Вспомогательные индикаторы инструментальной панели TBSM
— Построение сервисной модели можно автоматизировать и привязать её обновление к изменяющимся внешним данным. Ядро OMNIbus, которое называется ObjectServer, по своей сути является базой данных, в которой хранятся и оперативно обрабатываются аварийные сообщения. Алгоритмы работы TBSM с ObjectServer и записями во внешних базах данных похожи. Если в аварийном сообщении или во вносимой в таблицу внешней базы записи содержится вся необходимая информация для правильного создания и размещения в сервисной модели объекта, то можно настроить функцию автоматического наполнения (autopopulation) сервисной модели. Представьте, что пришло аварийное сообщение от неизвестного в TBSM объекта, а исходя из полей сообщения TBSM можно решить к какому шаблону (типу объектов) он принадлежит, составить имя создаваемого объекта и определить, кто будет его родительским объектом в модели. Похожим образом новый объект может появиться и при внесении записи о нём во внешнюю базу данных. С внешними базами модель может фактически синхронизироваться. Эта функция часто применяется при привязке сервисной модели к базе инвентаризации и CCMDB. Без этого невозможно поддерживать в актуальном состоянии модели меняющихся ИТ систем с большим количеством элементов.
Выше говорилось о необходимости иметь широкий спектр «датчиков» для оценки объектов, работающих на производство услуги. Но не менее важным и полезным является наличие средств объективного мониторинга качества услуги с точки зрения пользователя, своего рода генераторы искусственных обращений к сервису с оценкой его качества. В Tivoli этим занимается TCAM (Tivoli Composite Application Manager). Логика совместного использования этих двух типов «датчиков» очень простая. К примеру, TCAM регистрирует неудовлетворительное время отклика сервиса или даже его отказ; он докладывает об этом в OMNIbus в формате критичного аварийного сообщения, где объектом является не устройство или сервер, а сам сервис.
В TBSM такие аварийные сообщения привязаны напрямую к сервисам в верхней части моделей. Одновременно «датчики на местах» обнаружили неисправности на объектах инфраструктуры и также прислали сообщения. TBSM привязал эти сообщения к низлежащим элементам модели и просчитал (и отобразил) распространение влияния по топологии модели вверх. Сервисная модель наглядно демонстрирует проблемную ситуацию, а главное – её источник. Спускаясь от «покрасневшего» сервиса вниз по дереву и следуя цветовой индикации, специалист сразу оказывается в точке наиболее вероятной причины. Примечательно то, что TBSM сам отмечает звёздочками объекты — логические причины проблемы. Получается своего рода визуальный анализ первопричины.
В заключение отметим, что поскольку TBSM принадлежит к семейству Netcool, он полностью соответствует требованиям к ПО операторского класса. Его можно использовать в критичных для бизнеса системах OSS. Он поддерживает отказоустойчивые схемы, распределение нагрузки или масштабирование, внешнюю авторизацию и Single Sign-on, работу в рамках единого портала с интерфейсами «OMNIbus Web GUI» и «Tivoli Network Manager». Tivoli Integrated Portal обслуживает контекстные взаимодействия между этими продуктами, что позволяет создавать удобные инструментальные среды с быстрыми переходами между контекстами мониторинга сетевого и телекоммуникационного оборудования, серверов и их операционных систем, хранилищ и баз данных, вэб-серверов и серверов приложений, и, наконец, самих сервисов как объектов мониторинга.