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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В обоих случаях у нас есть "аккумулятор", в котором мы накапливаем агрегированное значение (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}, например:

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

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

Здесь мы просто ссылаемся на процедуру оценки, которая предопределена из коробки пакетом 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), в противном случае.

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

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

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

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