Механизм расчета SLA в SCSM 2012 — одно из самых значительных нововведений по сравнению с SCSM 2010. Если раньше мы могли рассчитывать расписание только для инцидентов по расписанию 24/7 по значению приоритета, то теперь нам доступен расчет SLA по любому параметры типа ДатаВремя.

Но в данном цикле статей я не буду описывать в сотый раз как настроить SLA, а постараюсь объяснить как работает механизм SLA “изнутри”. Это поможет вам использовать более сложные сценарии применения SLA, а также откроет некоторые скрытые возможности механизма SLA в SCSM 2012.

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

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

Объекты SLA

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

• Календарь
• Метрика
• Очередь
• Цель уровня обслуживания

Собственно, для того, чтобы создать цель уровня обслуживания, нам необходимо выбрать целевой класс (чаще всего это будут инциденты или запрос на обслуживание, но могут быть любые классы, унаследованные от WorkItem), очередь, и в качестве критерия указать календарь, метрику и целевое и пороговое время для данного SLO. Запомните эти термины, ниже я буду использовать именно их.

Календарь

Календарь задает расписание, по которому будет рассчитываться время для конкретной цели уровня обслуживания. Календарей может быть несколько. За хранение календарей отвечает класс System.Calendar со следующими свойствами:

Как вы видите, не хватает данных о рабочем времени и выходных. За эти данные отвечают другие классы. Класс System.Calendar.WorkDay отвечает за данные о рабочем времени каждого календаря и имеет следующие свойства:

Класс System.Calendar.Holiday отвечает за хранение выходных дней и имеет следующие свойства:

Между этими тремя классами существуют связи:

К примеру, если вы при настройке календаря выбрали стандартную рабочую неделю (с понедельника по пятницу, с 10:00 по 18:00) и указали выходной 1 января и 23 февраля, то будут созданы:

1. Один объект типа System.Calendar
2. Пять объектов типа System.Calendar.WorkDay (отдельно для каждого дня неделя)
3. Два объекта типа System.Calendar.Holiday
4. Связи между объектами 1 и 2, 1 и 3.

Несколько выводов:

• Объекты настройки календаря хранятся в базе данных, поэтому вы можете перенести настройки календарей из одной системы в другую только с помощью SDK (выгрузить информацию в файл из тестовой среды, загрузить на новую)
• Параметр временной зоны хранится в строго определенном формате, поэтому если вы соберетесь создавать календарь с помощью SDK имейте это ввиду. Иначе вы можете получить ошибку  “Значение не может быть неопределенным. Имя параметра: timeZone”

Как пример, вывод списка календарей с моей системе с помощью PowerShell:

Возможность создавать объекты через SDK использует Андерс в своем решении по импорту выходных дней из файла календаря Outlook в SCSM.

Метрика

Метрика отвечает за хранение информации, по каким параметрам типа ДатаВремя мы будет рассчитывать SLA. За хранение информации о метрике отвечает класс System.SLA.DateProperty.TimeMetric (наследуется от System.SLA.Metric) со следующими свойствами:

Несколько выводов:

• Как и календари, метрики хранятся в базе данных. Перенос возможен только с помощью SDK.
• Класс метрики имеет скрытые свойства, но изменение этих свойств официально не поддерживается Microsoft. Об этом подробнее будет описано позже.

Очередь

Очередь в SCSM – это разновидность группы. Физически, очередь это и есть группа, но может содержать только объекты, порожденные от класса System.WorkItem. В связи с этим для каждой очереди создается свой собственный singleton-класс (т.е. класс, который сам по себе является объектом, поэтому в системе может быть только один экземпляр этого класса, и его ID совпадает с ID класса) и правило наполнение (Discovery) (именно по этой причине при создании очереди необходимо указывать пакет управления).

После создания очереди в выбранном пакете управления появляется два новых определения: класс, наследованный от класса System.WorkItemGroup:

<ClassType ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" Accessibility="Public" Abstract="false" Base="WorkItem!System.WorkItemGroup" Hosted="false" Singleton="true" Extension="false" />

и новое отношение, которое определяет, объекты какого типа будут хранится в очереди. Тип объекта определяется при создании очереди. В моем примере это инцидент, что видно по типу Target для отношения:

        <RelationshipType ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident" Accessibility="Public" Abstract="false" Base="WorkItem!System.WorkItemGroupContainsWorkItems">
          <Source ID="ContainedByGroup" MinCardinality="0" MaxCardinality="2147483647" Type="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" />
          <Target ID="GroupContains" MinCardinality="0" MaxCardinality="2147483647" Type="Incident!System.WorkItem.Incident" />
        </RelationshipType>

а также новое обнаружение, отвечающее за наполнение группы. В моем примере это динамическое правило:

<Discovery ID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815.Discovery" Enabled="true" Target="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815" ConfirmDelivery="false" Remotable="true" Priority="Normal">
  <Category>Discovery</Category>
  <DiscoveryTypes>
    <DiscoveryRelationship TypeID="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident" />
  </DiscoveryTypes>
  <DataSource ID="GroupPopulationDataSource" TypeID="SystemCenter!Microsoft.SystemCenter.GroupPopulator">
    <RuleId>$MPElement$</RuleId>
    <GroupInstanceId>$MPElement[Name="WorkItemGroup.8085d7c3a07c468da1ac625247ae2815"]$</GroupInstanceId>
    <MembershipRules>
      <MembershipRule>
        <MonitoringClass>$MPElement[Name='Incident!System.WorkItem.Incident']$</MonitoringClass>
        <RelationshipClass>$MPElement[Name='WorkItemGroup.8085d7c3a07c468da1ac625247ae2815_Contains_System.WorkItem.Incident']$</RelationshipClass>
        <Expression>
          <SimpleExpression>
            <ValueExpression>
              <Property>$Context/Property[Type='Incident!System.WorkItem.Incident']/Classification$</Property>
            </ValueExpression>
            <Operator>Equal</Operator>
            <ValueExpression>
              <Value>{e36c84ea-1903-caf8-c2cf-c1e271a27ca7}</Value>
            </ValueExpression>
          </SimpleExpression>
        </Expression>
      </MembershipRule>
    </MembershipRules>
  </DataSource>
</Discovery>

Несколько выводов:

• Очереди можно переносить между различными инсталляциями SCSM, т.к. их параметры хранятся в пакетах управления.
• В очередях можно использовать более сложные критерии, нежели это позволяет графический редактор. К примеру, анализировать затронутого пользователя, или затронутые КЭ.

Цель уровня обслуживания

Цель уровня обслуживания объединяет в себе все выше перечисленные объекты. Каждая цель уровня обслуживания – это фактически отдельная метрика в вашем договоре на обслуживание. За хранение параметров цели уровня обслуживания отвечает класс  System.SLA.Configuration со следующими свойствами:

Для хранения свойств целевого интервала и интервала предупреждения используется класс System.SLA.TimeTarget (наследуется от System.SLA.Target) со следующими свойствами:

Также существуют следующие связи:

Но тут есть нюанс. Часть настройки цели уровня обслуживания хранится в пакете управления. Точнее будет сказать, что в момент создания цели уровня обслуживания создаются ряд объектов как в БД (описанные выше классы и отношения), так и в пакетах управления. В пакете управления создаются следующие объекты (примечание: внутренние имена всех объектов генерируются автоматически, указано только отображаемое имя (DisplayName), которое хранится в секции DisplayStrings):

1. Группа. Отображаемое имя строится по принципу:
   SLA Group: %ИМЯ_SLO%,
   где %ИМЯ_SLO% – это название вашего объекта SLA в консоли.
2. Цель для рабочего процесса.Отображаемое строится по правилу:
   SLA Workflow Target: %ИМЯ_SLO%
3. Обнаружение (Discovery) для группы 1. Правило для обнаружения следующее: все объекты целевого класса уровня обслуживания (инцидент или запрос на обслуживание), время создания (в UTC) которых больше или равно заданному значению И которые находятся в очереди, выбранной при создании цели уровня обслуживания. Для большего понимания приведу скриншот правила с комментариями (картинка “кликабельна”).
   
4. Два правила (или рабочих процесса в терминах консоли SCSM), источником для которых служит событие создания и удаление (по одному правилу на каждое событие) связи между группой из п.1 и её членом. Отображаемое имя строится по принципу: %ИМЯ_SLO%-AddRelationship и %ИМЯ_SLO%-DeleteRelationship.
5. Два правила, источником для которых служит изменение объекта целевого класса уровня обслуживания (т.е. инцидент или запрос на обслуживание) с критерием для первого правила: “CreatedDate была равно null и стала не равна null”, и для второго правила: “FirstResponseDate была равно null и стала не равна null”, где CreatedDate и FirstResponseDate соответственно имя поля начала отсчета и окончания отсчета метрики. Отображаемое имя строится по принципу: %ИМЯ_SLO%-StartEvent и %ИМЯ_SLO%-EndEvent соответственно.
6. Два правила, источником для которых служит также изменение объекта целевого класса уровня обслуживания (т.е. инцидент или запрос на обслуживание) без дополнительных критериев, при этом оба правила отключены по умолчанию (Enabled=”false”). Отображаемое имя строится по принципу: %ИМЯ_SLO%-PauseEvent и %ИМЯ_SLO%-ResumeEvent.

Именно эти правила (рабочие процессы) и являются сердцем механизма SLA в SCSM 2012.

Вместо заключения

Собственно на этом всё. В следующей статье расскажу, зачем всё это надо и как это работает. Но уже сейчас внимательный читатель без труда ответит на часто возникающие вопросы:

1. Почему SLA не применяется на те инциденты (или другие объекты), которые были созданны до того, как была создана цель уровня обслуживания
2. Как перенести настройки SLA из одной системы в другую.

Tweet