В предыдущей статье я описал все объекты, которые участвуют в механизме SLA в SCSM 2012. Пришло время рассказать о том, как же всё это работает.

Как я уже говорит, ядром расчета SLA в SCSM 2012 являются рабочие процессы (внутри системы они называются правилами (Rules), но в этой статье я буду использовать термин рабочий процесс), которые создаются в момент создания цели уровня обслуживания (или конфигурации SLO). Чтобы не заставлять вас бегать от одной статьи к другой, продублирую их снова:

1. Два рабочих процесса (или правила), источником для которых служит событие создания и удаления (по одному правилу на каждое событие) связи между группой “SLA Group: %ИМЯ_SLO%” и её членом. Отображаемое имя строится по принципу: %ИМЯ_SLO%-AddRelationship и %ИМЯ_SLO%-DeleteRelationship.
2. Два правила, источником для которых служит изменение объекта целевого класса уровня обслуживания (т.е. инцидент или запрос на обслуживание) с критерием для первого правила: “%ДАТА_НАЧАЛА_ОТСЧЕТА_В_МЕТРИКИ% была равно null и стала не равна null”, и для второго правила: “%ДАТА_ОКОНЧАНИЯ_ОТСЧЕТА_В_МЕТРИКИ% была равно null и стала не равна null”. Отображаемое имя строится по принципу: %ИМЯ_SLO%-StartEvent и %ИМЯ_SLO%-EndEvent.
3. Два правила, источником для которых служит также изменение объекта целевого класса уровня обслуживания (т.е. инцидент или запрос на обслуживание) без дополнительных критериев, при этом оба правила отключены по умолчанию (Enabled=”false”). Отображаемое имя строится по принципу: %ИМЯ_SLO%-PauseEvent и %ИМЯ_SLO%-ResumeEvent.

Тестовая конфигурация SLO

Чтобы объяснение было более наглядным, далее я буду использовать следующую конфигурацию в качестве примера:

1. Очередь: “Все срочные инциденты”. Целевой класс – Инцидент, критерий “Срочность = Высокий”:
   
2. Календарь: “Стандартный календарь” со следующими настройками:
   
3. Метрика “Инциденты — время взятия в работу”, измеряющее время от Даты создания до Даты первого назначения:
   
   которое затем меняется на:
   
4. Цель уровня обслуживания “Test SLO”, объединяющая в себе все вышеперечисленные объекты, и имеющая целевое значение 48 часов и пороговое – 2 часа:
   

Механизм работы SLA

Основным механизмом SLA являются пара рабочих процессов %ИМЯ_SLO%-AddRelationship и %ИМЯ_SLO%-DeleteRelationship. Для начала, давайте разберемся, когда они запускаются. Вы помните, что по условию, рабочие процессы запускаются при добавлении и удалении элемента в\из группы. Но в какой момент это происходит это самое добавление и удаление? Т.к. группа “SLA Group: %ИМЯ_SLO%” наполняется динамически, и правило её выглядит как “все объекты целевого класса, созданные позже цели уровня обслуживания, и находящие в определенной очереди”, то цепочка событий будет выглядеть следующим образом:

1. Объект целевого класса изменяется (или создается), и выполняется условие прописанное в очереди.
2. После пересчет очереди (по умолчанию это происходит раз в 15 секунд) объект добавляется в очередь (происходит событие AddRelationhsip для очереди)
3. Т.к. объект попал в очередь, то после перерасчета группы “SLA Group: %ИМЯ_SLO%” объект добавится в эту группу и произойдет событие AddRelationhsip для этой группы, на который и настроен наш рабочий процесс.

Процесс удаления объект из очереди, а потом и из группы, происходит ровно точно также.

На примере нашей тестовой конфигурации это будет выглядеть следующим образом:

1. Создается инцидент со срочность “высокий”
2. Инцидент попадает в очередь “Все срочные инциденты”
3. Инцидент добавляется в группу “SLA Group: Test SLO”
4. Происходит запуск рабочего процесса “Test SLO-AddRelationship”

Всё это можно увидеть в истории инцидента:

Рабочий процесс SLO%-AddRelationship

Что же делает этот волшебный рабочий процесс? Если в посмотрите его настройки, то увидите, что он запускает рабочий процесс WPF (Windows Presentation Foundation) ApplySLAOnGroupInstance из библиотеки Microsoft.EnterpriseManagement.ServiceManager.SLA.Workflows, и в качестве параметров передает ИД добавленного в группу объекта и ИД объекта цели обслуживания класса System.SLA.Configuration:

Данный рабочий процесс выполняет следующие действия (тут следует сделать примечание, что перед запуском процесса производится анализ типа SLA, но в SCSM 2012 (и SP1) “из коробки” поддерживается только один тип SLA – date property time-based, поэтому речь пойдет о нем):

1. По ИД объекта System.SLA.Configuration рабочий процесс получает все настройки цели уровня обслуживания: календарь, метрику, целевые значения времени.
2. Согласно календарю вычисляется целевое время для данного SLO
3. Создается объект типа System.SLA.Instance.TimeInformation (Сведения о времени экземпляра уровня обслуживания) и заполняются его свойства
4. Созданный объект привязывается к объекту, добавленному в группу (т.е. к инциденту иди запросу на обслуживание).

Как видите, здесь появляется еще один класс объектов: System.SLA.Instance.TimeInformation. Этот класс имеет следующие свойства:

ID	ИД объекта. Задается как “SLAInstanceTimeInformation_” + уникальный GUID
DisplayName	Всегда равен отображаемому имени цели уровня обслуживания
Status	Перечисление типа SLAInstance.Status
IsCancelled	Признак отменено ли данное SLA
TargetEndDate	Рассчитанное целевое время
TargetWarningDate	Рассчитанное время предупреждения
StartDate	Время начала расчета SLA
EndDate	Время окончания расчета SLA
PausedDate	Время последней приостановки расчета SLA

Объекты этого класса – это именно то, что мы видим на вкладке “Уровень обслуживания” в консоли SCSM. Если посмотреть на мою тестовую конфигурацию, то мы увидим, что к инциденту был добавлен объект типа “Сведения о времени экземпляра уровня обслуживания” с именем, совпадающим с именем цели уровня обслуживания:

а на вкладке “Уровень обслуживания” появился новый объект:

И вот все его свойства (не стоит запускать такой же запрос на “живой” среде, т.к. здесь я немного схитрил – у меня SLO новое, поэтому в системе существует только один объект TimeInformation. Если вы запустите такой же запрос в своей среде, он вам выведен все объекты TimeInformation для всех объектов, что у вас есть):

Но тут есть нюанс. Дело в том, что в момент создания объекта TimeInformation обе даты, выбранные для метрики, могут быть не заполнены. Для примера, представим, что мы хотим считать время реакции оператора на инцидент. Для этого мы создаем SLA, которое будет рассчитывать время от даты назначения до даты первого ответа:

Обе эти даты не проставляются по умолчанию для новых инцидентов. Но т.к. условия для очереди соблюдены, то объект TimeInformation всё равно будет создан, но получит состояние “Не готов”:

И только после того, как дата первого назначения будет заполнена, объект TimeInformation будет переведен в состояние Активен и для него начнется отслеживание SLA.

В связи с этим возникает резонный вопрос: т.к. “Дата первого назначения” заполняется с помощью рабочего процесса, что будет, если в рамках одной транзакции пользователь назначит инцидент и установит первый ответ (это вполне логично, если оператор назначает инцидент на себя и тут же проставляет первый ответ) или сначала проставит дату первого ответа, сохранит инцидент, а после назначит инцидент? На самом деле ничего страшного – когда рабочий процесс проставит Дату первого назначения, рабочий процесс SLA запустит механизм отслеживания SLA и сразу проставит состояние “Соответствует”, т.к. дата первого ответа будет явно раньше целевой даты SLO:

Точно также будет выглядеть ситуация, когда дата начала отсчета и дата окончания отсчета проставлены в рамках одной транзакции. К примеру, представим, что у нас метрика, считающая SLA от Даты первого ответа до Даты разрешения. Оператор проставил дату первого ответа, и не закрывая консоль продолжил общаться с пользователем и решил его проблему, проставив соответствующий статус. В этом случае дата начала отсчета и дата окончания отсчета будут проставлены в рамках одной транзакции:

и SLO будет сразу же переведено из состояния “не готов” в состояние “Соответствует”:

Рабочий процесс SLO%-DeleteRelationship

Мы разобрались, что происходит при добавлении элемента в группу. Теперь посмотрим, что происходит при удалении элемента. В нашем примере, допустим, что Срочность инцидента была снижена с Высокий на Средний. При этом инцидент будет удален из очереди, а затем из группы SLO:

а в объекте SLO будет изменено свойство IsCanceled на true. Отслеживание SLA для таких объектов не ведется. При этом свойство IsCanceled изменится вне зависимости от состояния объекта SLO, к примеру вот SLO в состоянии “Соответствует”:

а вот в состоянии “Не готов”:

“Туда-сюда обратно, тебе и мне приятно”

Думаю у всех возникнет резонный вопрос – а что будет, если удалить элемент из очереди, а потом вновь его туда вернуть? Когда целевой объект (инцидент или запрос на обслуживание) вернется в очередь, а соответственно и в группу SLO, запустится рабочий процесс SLO%-AddRelationship, будет заново рассчитано целевое время и состояние объекта SLO.

Отслеживание SLA

Установка времени – это конечно всё хорошо, но пока что не видно, как собственно отслеживается это самое время, ведь состояние SLA должно меняться при нарушении сроков. И вот тут всё крайне просто. В SCSM существует еще один рабочий процесс с внутренним именем “ServiceManager.SLAManagement.Library.SLAInstance.TimeInformation.PeriodicRule”, который раз в 3 минуты получает объекты типа System.SLA.Instance.TimeInformation со следующим фильтром:

(IsCanceled != true)
AND
((TargetEndDate < [Now]) OR (TargetWarningDate<[Now]) AND Status != Warinig)
AND
(Status!=Met AND Status!=Paused AND Status!=NotReady AND Status!=Breached)

и для каждого найденного объекта производит пересчет состояния.

Состояние объекта SLO, привязанного к рабочему элементу, может принимать следующие значения (свойства Status, перечисление SLAInstance.Status):

Не готов	Механизму SLA не хватает данных, чтобы вычислить SLA. В нормальных условиях это означает, что не проставлена дата начала отсчета.
Активен	Проставлена целевая дата окончания и дата предупреждения, механизм SLA следит за временем
Предупреждение	Механизм SLA обнаружил, что дата предупреждения меньше текущего времени, а дата окончания не проставлена
Нарушение	Механизм SLA обнаружил, что целевая дата окончания меньше текущего времени, а дата окончания не проставлена. Это окончательное состояние объекта SLA. Механизм SLA не подразумевает вывод объекта из этого состояния.
Соответствует	Дата окончания проставлена, и её разница меньше, чем рассчитанное целевое время окончания.
Приостановлен	Расчет SLA приостановлен. Это состояние хотя и есть в системе, не поддерживается Microsoft. Т.е. в нормальных условиях объект SLO никогда не перейдет в это состояние.

Служебные рабочие процессы

Кроме стандартных рабочих процессов по отслеживанию объектов SLO, в SCSM 2012 есть один служебное правило (рабочий процесс) для отслеживания изменения метрик. Его внутреннее имя “ServiceManager.SLAManagement.Library.SLATimeMetric.Rule.Update” и запускается он при любом изменении объекта типа Метрика. При запуске данное правило обновляет все объекта конфигурации SLO, где задействована данная метрика. При изменении меняются свойства правил %ИМЯ_SLO%-StartEvent” и “%ИМЯ_SLO%-EndEvent”. Для них устанавливаются новые свойства дат, если они изменились. Т.е. другими словами – вы можете менять метрики, и эти изменения будут отражены во всех конфигурациях SLO, где они задействованы.

Других рабочих процессов в SCSM 2012 нет, из чего можно сделать один вывод – изменение конфигурации SLO влияет только на новые объекты SLO, создаваемые после обновления конфигурации.

“Почему при изменении конфигурации SLO ничего не изменяется в существующих рабочих элементах?”

Этот вопрос задается почти всеми, кто сталкивается с механизмом расчета SLA в SCSM 2012. Как вы помните из первой статьи, применение конфигурации SLO распространяется только на те объекты WorkItem, которые были созданы после создания самой конфигурации SLO (группа “SLA Group: %ИМЯ_SLO%” и её дискавери). Также из рассмотренного выше видно, что изменения конфигурации никак не влияет на старые объекты SLO.

Для того, чтобы объяснить зачем это надо, следует отвлечься от технических аспектов и вспомнить, зачем мы настраиваем SLA. Service Level Aggreement – это в первую очередь соглашение между бизнесом и ИТ-подразделением (не только, но в основном это так), которое регламентирует как и в какие сроки должны выполняться те или иные действия (на самом деле SLA охватывает гораздо б’ольший круг вопросов, но мы сейчас рассматривает SLA в разрезе ServiceDesk). И в связи с тем, что это соглашение, оно не может менять “правила игры“ постфактум. Представьте, что вы взяли кредит в банке под 10% годовых на 3 года. А через год банк присылает вам уведомление, что процентная ставка по вашему договору теперь 15%, и вы должны доплатить 5% за прошлый год. В нормальной юридической практики такого быть просто не может. Точно также и в SLA – правила оказания услуг должны действовать только с момента подписания SLA, это позволит вам иметь в отчетах верную информацию на любой момент времени, когда бы не изменялись ваши конфигурации SLO.

На этом всё. Если у вас есть вопросы – пишите.

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