Управление ИТ-услугами

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

По сути, метрика - это систематизированное измерение. С помощью пакета Metrics Package AggreGate предоставляет простую, но мощную модель измерения, описанную ниже.

Метрика

Здесь и далее мы различаем термины "мера" и "метрика".

  • Мера - это данные, полученные AggreGate Network Manager от устройств, программных компонентов и других ресурсов.
  • Метрика - это интерпретация одной или нескольких мер, собранных в целях управления ИТ.

Рассмотрим следующий пример:

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

Далее предположим, что сервер используется для запуска приложения. Тогда значение "Здоровье" сервера может быть использовано (вероятно, вместе с метриками некоторых других компонентов, необходимых приложению) для оценки "Здоровья" приложения.

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

Пакет Metrics представляет метрики как экземпляры инстанцируемой модели Metric. Эта модель содержит всю информацию и поведение, необходимые для определения и измерения метрики.

В приведенном выше примере значения здоровья сервера, здоровья приложения, здоровья сети и здоровья ИТ-сервиса можно смоделировать как единую метрику Health. Затем будет создан экземпляр модели Metric, который описывает концепцию 'Health' и определяет все необходимое для применения этой метрики к различным объектам в домене управления ИТ.

Оценка метрик

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

Важной деталью здесь является то, что вы не можете измерить саму метрику. Чтобы получить значение, необходимо обратиться к сущности, к которой применяется метрика.

Учитывая пример, который мы обсуждали ранее, мы не можем измерить саму метрику Health. Чтобы ее можно было измерить, "Здоровье" должно относиться к определенному объекту: серверу, приложению, сервису и т. д.

Поскольку пакет измерений зависит от базы данных управления конфигурациями (CMDB) и расширяет ее, мы используем термин Configuration Items(CIs) для обозначения объектов, с которыми могут быть связаны метрики.

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

Таким образом, чтобы измерить метрику, мы должны указать CI, для которого она рассчитывается. Каждый CI имеет уникальный идентификатор (ID).

Поэтому, чтобы рассчитать метрику для CI, необходимо вызвать набор правил измерения в контексте метрики, указав в качестве параметра идентификатор CI.

Пример: Чтобы рассчитать здоровье ИЦ с идентификатором = 3, выполните следующее выражение: cell( {measure.health:measure(3)} )

Методы оценки метрики

Возвращаясь к примеру с метрикой Health, необходимо заявить, что показатели здоровья сервера, здоровья приложения и здоровья службы представляют собой по сути одну и ту же характеристику разных объектов. Если мы определим, что все эти показатели имеют одинаковое значение для всех CI, к которым они применяются, измерим их в одной и той же шкале с использованием одних и тех же единиц, то можно сказать, что все они относятся к одной метрике под названием Health.

Например, Здоровье можно определить как дискретную метрику с четырьмя значениями:

  • 0 означает, что ИЦ "в порядке", т. е. функционирует нормально и проблем не обнаружено.
  • 1 означает, что ИЦ "Деградировал", т.е. он функционирует, но обнаружены некоторые проблемы, которые могут повлиять на его функциональность в ближайшем будущем.
  • 2 означает, что КИ "Неисправен", то есть работает не так, как ожидалось.
  • 3 означает, что состояние CI "Неизвестно", то есть информация о состоянии CI отсутствует.

Хотя метрика Health имеет одинаковое значение для разных ИЦ, способ вычисления ее значения может существенно отличаться.

Собственно, это уже показано на примере выше:

  • Здоровье сервера оценивается с помощью показателей загрузки процессора и использования памяти.
  • В то время как здоровье ИТ-сервиса оценивается по здоровью его компонентов: приложения, кластера баз данных высокой доступности, сети и т. д.

В целом процедура оценки обычно зависит от характеристик ИЦ, данных, которые он предоставляет, и роли, которую он играет в бизнес-процессах. Оценка может отличаться даже для одного и того же "типа" ИЦ, если они предоставляют разные наборы показателей. Например, оценка здоровья сетевого устройства может зависеть от протоколов, которые поддерживает устройство, и отличаться для устройства с поддержкой SNMP от простого устройства, которое обеспечивает только ответы ping.

Таким образом, может существовать несколько методов оценки метрики, каждый из которых применяется к подмножеству CI, для которых определена метрика.

В пакете Metrics метод оценки - это именованное выражение, заданное в контексте метрики.

Это поддерживается введением переменной methods в контексте модели метрики. Переменная methods определяется в следующем формате:

Имя

Описание

Тип

Комментарий

имя

Имя

Строка

Краткое название метода

описание

Описание

Строка

Полное описание метода

выражение

Выражение

Строка

Выражение, используемое для оценки значения метрики

Экземпляры модели метрики хранят свои методы оценки в виде строк в этой переменной.

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

Присвоение метрики CI

Когда мы связываем метрику с CI, мы должны указать модель метрики и метод оценки, который будет использоваться.

Обычный способ связать существующую метрику с CI - это панель CI Details. Найдите целевой CI, например, через панель CMDB, и откройте панель CI Details.

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

Зависимости метрики

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

Например:

  • здоровье сетевого устройства можно оценить с помощью его показателей, полученных по протоколам ping, SNMP или любому другому протоколу, поддерживаемому устройством
  • здоровье ИТ-сервиса оценивается по значениям здоровья CI, от которых он зависит: приложение, кластер баз данных, сеть и т. д.

Последнее является примером так называемой "составной метрики".

Составная метрика - это метрика, которая рассчитывается над явно определенным набором CI.

Это важный аспект пакета Metrics, поэтому давайте рассмотрим составные метрики более подробно на следующих примерах.

Как предполагается в нашем примере выше, ИТ-сервис зависит от нескольких основных компонентов:

  • приложение
  • кластер баз данных высокой доступности
  • сегмент сети, соединяющий их вместе.

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

Рассмотрим еще один элемент нашей примера ИТ-системы - кластер баз данных высокой доступности.

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

  • Состояние кластера равно 'Unknown'(3), если состояние любого компонента равно'Unknown'. В этом случае мы не можем с уверенностью определить состояние кластера.
  • Состояние кластера -'OK'(0), если все компоненты впорядке.
  • Состояние кластера -'Failed'(2), если все компоненты'Failed'.
  • В противном случае состояние кластера -'Degraded'(1).

Общим в этих двух примерах является то, что результирующее значение метрики оценивается как совокупность метрик нескольких компонентов. Это можно описать как зависимость.

В нашем примере

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

Объекты, от которых зависит метрика CI, мы называем импакторами.

В обоих случаях у нас есть "аккумулятор", в котором мы накапливаем агрегированное значение (Health). Агрегация выполняется в виде функции, которая принимает входящее значение метрики следующего импактора и текущее значение аккумулятора. Результат, полученный функцией, принимается в качестве нового значения аккумулятора, которое будет использоваться на следующем шаге итерации, или в качестве конечного результата, если все импакторы были агрегированы.

Разница между этими двумя примерами скрыта в функции агрегирования:

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

Таким образом, способ агрегирования метрики может отличаться для разных CI. Это очень похоже на методы, описанные ранее. Как и методы, агрегаторы являются именованными выражениями, указанными в контекстах экземпляров модели Metrics. Как и для методов, это поддерживается введением переменной, которая хранит агрегаторы в метриках. Переменная называется aggregators и имеет формат, аналогичный формату переменной methods:

Имя

Описание

Тип

Комментарий

имя

Имя

Строка

Краткое название агрегатора

описание

Описание

Строка

Полное описание агрегатора

выражение

Выражение

Строка

Агрегационное выражение

Текущее значение накопителя и входящие значения метрики передаются в агрегирующее выражение в однорядной таблице по умолчанию в полях currentValue и newValue соответственно.

Изначально, при первом вызове, значение currentValue будет равно nil.

Примеры и некоторые дополнительные сведения об определении агрегаторов приведены ниже.

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

Настройка зависимостей

Чтобы настроить метрические зависимости для CI, найдите целевой CI, например, с помощью панели CMDB, и откройте на нем панель CI Details. Таблица Dependencies содержит импакторы для всех метрик, определенных для CI.

Чтобы добавить импактор, создайте новую строку в таблице Dependencies и укажите метрику, CI импактора и Aggregation Expression, нажав на соответствующее поле и выбрав нужную сущность из списка.

Создание новой метрики

Чтобы создать новую метрику, необходимо:

1. Создайте новый экземпляр модели Metric и задайте его имя и описание.

2. Определить методы оценки метрики, которые будут использоваться для вычисления значения метрики в различных обстоятельствах.

3. Если метрика имеет составные значения, укажите функции агрегирования.

Первый пункт здесь довольно тривиален. За подробностями обратитесь к разделу "Инстанцируемые модели".

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

Определение методов оценки метрики

Метод оценки метрики - это именованное выражение, определяемое строкой переменной methods в экземпляре модели Metric. Выражение принимает целевой идентификатор CI в качестве единственного значения (поле '0') в таблице данных по умолчанию. Прямым способом обращения к идентификатору CI является ссылка {0}, например:

cell(

getVariable(

cell(

cell({users.admin.models.cmdb:get({0})}, "data")

, "source_context"

)

, "measure"

)

)

Метод оценки здесь просто берет значение из переменной (в данном примере с именем measure ) в контексте, с которым связан целевой CI. Идентификатор CI передается функции get (набор правил) в модели CMDB. Функция get извлекает и возвращает таблицу CI из хранилища. Данные CI хранятся в поле данных таблицы. Мы извлекаем их и получаем путь к контексту, связанному с CI, из source_context.

Распространенной практикой является извлечение сложных методов оценки в другие компоненты AggreGate.

Например, этот метод оценивает Health как составную метрику:

{metric.availability:compoundHealth(dt())}.

Здесь мы просто ссылаемся на процедуру оценки, которая предопределена из коробки пакетом Metrics Package в наборе правил compoundHealth в модели Metric.

Определение агрегатора метрики

Агрегатор метрики - это именованное выражение, определяемое строкой переменной aggregators в экземпляре модели Metric. Оно используется для накопления составного значения метрики при итерации по ее импакторам. Выражение принимает два параметра в качестве полей однорядной таблицы по умолчанию:

  • {currentValue} - текущее значение аккумулятора.
  • {newValue} - метрическое значение следующего импактора, подлежащее накоплению.

Чтобы проиллюстрировать эту процедуру, мы воспользуемся примерами IT Service Health и High-Availability Database Cluster Health, рассмотренными ранее.

Напомним, что Health определяется как дискретная метрика с четырьмя значениями:

  • ОК (0)
  • деградировано (1)
  • Неисправен (2)
  • Неизвестно (3)

Агрегатор здоровья ИТ-службы

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

Определив их, мы можем оценить здоровье ИТ-сервиса как максимальное из значений здоровья его импакторов. Также следует учесть, что изначально накопитель равен нулю. Таким образом, выражение агрегатора может быть таким: {currentValue} == nil ? {newValue} : max({currentValue}, {newValue})

Агрегатор здоровья кластера баз данных высокой доступности

Оценка здоровья кластера баз данных высокой доступности немного сложнее.

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

  • 'Unknown' (3), если состояние любого компонента - 'Unknown'.
  • 'OK' (0), если все компоненты находятся в состоянии 'OK'.
  • 'Failed' (2), если все компоненты находятся в состоянии 'Failed'.
  • 'Degraded' (1), в противном случае.

Выражение, реализующее эти правила, будет довольно длинным и нечитабельным. Хорошей практикой в среде AggreGate является извлечение длинных и сложных выражений в модели в виде наборов правил. В нашем случае это можно реализовать как набор правил в модели Metric.

Тогда выражение будет иметь вид:

{ metric.availability:aggregateOptionalHealth( {currentValue}, {newValue} ) }

где набор правил aggregateOptionalHealth может быть определен следующим образом:

Цель

Выражение

Условие

Итоговый

ячейка({1})

cell({0}) == null

Конечная

3

cell({0}) == 3 || cell({1}) == 3

Итоговый

2

клетка({0}) == 2 && клетка({1}) == 2

Окончательный

0

ячейка({0}) == 0 && ячейка({1}) == 0

Окончательный

1