SLA в SCSM 2012. Часть 3. Показать то, что скрыто

10.01.2013 FreemanRU 11 комментариев

В двух предыдущих статьях я рассказал о том, как хранятся настройки SLA в SCSM 2012 и как работает механизм отслеживания SLA. В сегодняшней статье речь пойдет о тех возможностях механизма SLA, которые есть “из коробки”, но которые не так очевидны. Часть из них полностью поддерживается Microsoft, часть – нет.

Очереди, или “вас тут не стояло!”

Главное назначение любого механизма SLA – отслеживать соответствие заданных в договоре параметров. И основополагающим критерием является то, на каких элементах нам необходимо отслеживать соблюдение SLA. И если основные параметры отслеживания SLA в SCSM 2012, такие как метрики, календари и цель уровня обслуживания, довольно банальны и не имеют широких возможностей по настройке, то вот очереди – это мощнейший механизм применения SLA в SCSM 2012. Именно очереди определяют, на какие элементы будут применятся те или иные параметры SLA. Очередям в SCSM 2012 можно (и нужно) посвятить отдельную статью, здесь же я лишь опишу те моменты, которые относятся к SLA.

Очередь – это группа

… и это необходимо помнить всегда. Из этого определения следует сразу несколько выводов:

Элементы в очередь можно добавлять как динамически (т.е. по некоторому правилу), так и статически
Для элементов в очереди могут быть исключения
Количество очередей и сложность правил их наполнения напрямую влияет на производительность сервера SCSM

Правила для очередей

Как я уже говорил, при динамическом наполнении элементов очереди используются правила. Правила – это фактически набор критериев, по которым SCSM будет добавлять элементы в очередь. К сожалению, в большинстве случаев создатели правил для очередей сводят всё к банальному “Срочность=Высокая и Влияние=Высокая” или подобным. Но правила позволяют использовать любые отношения целевого элемента, просто выберите нужный комбинированный класс в качестве цели для очереди, а это дает вам простор для творчества. Хотите создать очередь, в которую попадут все инциденты, созданные для VIP-пользователей? Не проблема – используйте комбинированный класс “Инцидент (типовой)” и отношение “Затрагиваемый пользователь” и любые свойства классов, порожденных от System.User (Пользователь) в качестве фильтра. Хотите создать очередь, в которую попадут все запросы на обслуживание для определенной службы? Тоже не проблема – создайте свой собственный комбинированный класс и в правиле используйте его и отношение “Затронутые конфигурационные элементы”.

Т.к. в очередях используются комбинированные классы, то мы можем использовать любой уровень вложенности (теоритически). К примеру, мы можем создать комбинированный класс, который будет включать в себя компонент “Затронутые конфигурационные элементы” с ограничением по классу “Бизнес-Услуга” и дочерний компонент “Владелец услуги”. В этом случае мы сможем создать очередь, в которую включить инциденты, относящиеся к услугам, у которых владелец находится в OU “Аффилированные компании”.

Нужно так же помнить, что отношения можно использовать не только “сверху вниз” (от источника к цели), но и наоборот. К примеру, вы можете создать комбинированный класс, в котором добавить отношение “Имеет родительский элемент”, но пометить, что вы хотите получать связь от цели к источнику (SeedRole=”Target”). В результате вы можете создать очередь, в которую попадут все инциденты, у которых есть родительские инциденты со срочностью “Высокий” (ну или использовать любые другие свойства родительского инцидента).

Как вывод из всего выше изложенного: если вас не устраивают комбинированные классы “из коробки” (а когда вы научитесь использовать их, вы поймете, что хотите большего), то в общем случае алгоритм создания будет такой:

Создаем комбинированный класс (type projection в терминах объектной модели SCSM) с нужными отношениями и ограничениями. Сделать это можно с помощью любого текстового редактора.
Импортируем пакет с созданным комбинированным классом
Создаем очередь, в качестве цели выбираем созданный ранее комбинированный класс

Для примера представим такую ситуацию. У нас есть OU в домене, в этом OU содержатся все учетные записи руководителей нашей компании. Нам необходимо создать очередь, в которую должны попадать все инциденты, возникшие у этих руководителей. Для этого необходимо:

Создать новую очередь, в качестве целевого класса выбрать комбинированный класс “Инцидент (Типовой)”
В Критерии выбрать отношение “Затрагиваемый пользователь” и добавить критерий для свойства “Различающееся имя”. Т.к. это свойство содержит полный LDAP-путь объекта в формате “CN=….,OU=…..,DN=…,DN=”, то нас вполне устроит оператор “Содержит” и фильтр “OU=Руководство компании,OU=SystemCenter Inc,DC=syscenter,DC=local”. В этом случае в очередь попадут все инциденты, у которых затронутый пользователь находиться в OU “SystemCenter Inc\Руководство компании” и нижележайших OU:

и структура в AD:

Чтобы проверить, правильно ли вы создали очередь, можно воспользоваться скриптом, который я публиковал ранее. Но следует помнить, что т.к. очередь – это группа, обработка её правила может занять некоторое время.

К сожалению, это все возможности, которые предоставляет нам интерфейс консоли SCSM. Но если вы откроете правило наполнения очереди в пакете управления, перед вами открываются огромные возможности, такие как:

Использовать исключения
Использовать сложные операторы – Contains/NotContains, Contained/NotContained
Несколько правил для одной очереди

Одним словом, весь спектр возможностей по написанию правил для динамического членства в группах, которые предоставляет нам движок SCSM\OpsMgr. К сожалению, рамки данной статьи не позволяют продемонстрировать все возможности этих правил, но я постараюсь вернуться к этой теме.

Очереди и производительность

В связи с тем, что очередь – это группа, на очереди накладываются те же проблемы, что и на группы. Первое, что нужно помнить (и как бы не странно это звучало) – используйте как можно меньшее количество очередей.

Планируйте их так, что бы использовать одну и ту же очередь максимальное число раз – в SLA, в ролевой модели, в оповещениях
Удаляйте не использующие группы

Второе правило – используйте в качестве целевого класса комбинированные классы с минимально необходимым числом компонентов. И никогда не используйте комбинированные класс “* (типовой)”.

Если число очередей перевалило за 100, имеет смысл увеличить интервал обсчета групп, но нужно понимать, что это напрямую затронет механизм SLA, т.к. пересчет целевого времени запускается при добавлении элемента в группу.

Приостановка SLA

ВНИМАНИЕ! Всё, о чем пойдет речь далее ни в каком виде не поддерживается компанией Microsoft и\или автором этой статьи. Автор не несет ответственности за потерю информации в результате использования приведенных рекомендаций. Вся информация представлено исключительно для ознакомления.

Уже довольно давно я опубликовал заметку про то, что встроенный механизм SLA в SCSM имеет возможность приостанавливать свою работу. Эта заметка вызвала большой резонанс, но т.к. у меня есть определенные обязательства перед компанией Microsoft, я не мог опубликовать информацию об этом до одобрения Microsoft. Не так давно я получил добро на публикацию.

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

Критерий приостановки и запуска

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

Начну сразу с примера. Одно из самых распространенных требований – при расчете SLA не учитывать время, когда инцидент находился в состоянии “Ожидание”. Для реализации данного требования нам необходимо два условия:

Приостановка SLA: Состояние_ДО != “Ожидание” И Состояние_ПОСЛЕ = “Ожидание”
Возобновление SLA: Состояние_ДО = “Ожидание” И Состояние_ПОСЛЕ != “Ожидание”

Далее я подразумеваю, что у вас уже есть работающий настроенный механизм SLA, и вам необходимо лишь приостановить\возобновить его работу.

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

<Rule ID="NotificationSubscription_da22181e_fb15_444c_b21b_ef45ca49b11c" Enabled="true" Target="SystemCenter!Microsoft.SystemCenter.SubscriptionWorkflowTarget" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>System</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="SystemCenter1!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
            <Subscription>
              <InstanceSubscription Type="a604b942-4c7b-2fb2-28dc-61dc6f465c68">
                <UpdateInstance>
                  <Criteria>
                    <Expression>
                      <And>
                        <Expression>
                          <SimpleExpression>
                            <ValueExpression>
                              <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']/Status$</Property>
                            </ValueExpression>
                            <Operator>NotEqual</Operator>
                            <ValueExpression>
                              <Value>{b6679968-e84e-96fa-1fec-8cd4ab39c3de}</Value>
                            </ValueExpression>
                          </SimpleExpression>
                        </Expression>
                        <Expression>
                          <SimpleExpression>
                            <ValueExpression>
                              <Property State="Post">$Context/Property[Type='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']/Status$</Property>
                            </ValueExpression>
                            <Operator>Equal</Operator>
                            <ValueExpression>
                              <Value>{b6679968-e84e-96fa-1fec-8cd4ab39c3de}</Value>
                            </ValueExpression>
                          </SimpleExpression>
                        </Expression>
                      </And>
                    </Expression>
                  </Criteria>
                </UpdateInstance>
              </InstanceSubscription>
              <PollingIntervalInSeconds>60</PollingIntervalInSeconds>
              <BatchSize>100</BatchSize>
            </Subscription>
          </DataSource>
        </DataSources>
        <WriteActions>
<!-- остальной код правила вырезан -->

Включение механизма приостановки\возобновления SLA

Теперь необходимо этот критерий вставить в соответствующие правила расчета SLO. Для вставки в правило SLA вам необходимо скопировать секцию <UpdateInstance> целиком. После этого вам необходимо найти в пакете правило %ИМЯ_SLO%-PauseEvent (см. Часть 1 о принятых сокращениях) и заменить <UpdateInstance /> на скопированный выше критерий, а также заменить Enabled=”false” на Enabled=”true”. В результате у вас должно получиться нечто подобное:

      <Rule ID="WorkflowSubscription_1ce1859c_73c0_43ad_bd76_87616e00ad96" Enabled="true" Target="SLAWorkflowTarget_bcae34c368294fdcb14f80d4111ee005" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>System</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="SystemCenter1!Microsoft.SystemCenter.CmdbInstanceSubscription.DataSourceModule">
            <Subscription>
              <InstanceSubscription Type="a604b942-4c7b-2fb2-28dc-61dc6f465c68">
                <UpdateInstance>
                  <Criteria>
                    <Expression>
                      <And>
                        <Expression>
                          <SimpleExpression>
                            <ValueExpression>
                              <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']/Status$</Property>
                            </ValueExpression>
                            <Operator>NotEqual</Operator>
                            <ValueExpression>
                              <Value>{b6679968-e84e-96fa-1fec-8cd4ab39c3de}</Value>
                            </ValueExpression>
                          </SimpleExpression>
                        </Expression>
                        <Expression>
                          <SimpleExpression>
                            <ValueExpression>
                              <Property State="Post">$Context/Property[Type='CustomSystem_WorkItem_Incident_Library!System.WorkItem.Incident']/Status$</Property>
                            </ValueExpression>
                            <Operator>Equal</Operator>
                            <ValueExpression>
                              <Value>{b6679968-e84e-96fa-1fec-8cd4ab39c3de}</Value>
                            </ValueExpression>
                          </SimpleExpression>
                        </Expression>
                      </And>
                    </Expression>
                  </Criteria>
                </UpdateInstance>
              </InstanceSubscription>
              <PollingIntervalInSeconds>60</PollingIntervalInSeconds>
              <BatchSize>100</BatchSize>
            </Subscription>
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="WA" TypeID="SystemCenter1!Microsoft.EnterpriseManagement.SystemCenter.Subscription.WindowsWorkflowTaskWriteAction">
            <Subscription>
              <VisibleWorkflowStatusUi>false</VisibleWorkflowStatusUi>
              <EnableBatchProcessing>true</EnableBatchProcessing>
              <WindowsWorkflowConfiguration>
                <AssemblyName>Microsoft.EnterpriseManagement.ServiceManager.SLA.Workflows</AssemblyName>
                <WorkflowTypeName>Microsoft.EnterpriseManagement.ServiceManager.SLA.Workflows.ModifySLAOnInstanceUpdate</WorkflowTypeName>
                <WorkflowParameters>
                  <WorkflowParameter Name="WorkflowMode" Type="string">PauseEvent</WorkflowParameter>
                  <WorkflowArrayParameter Name="InstanceIds" Type="guid">
                    <Item>$Data/BaseManagedEntityId$</Item>
                  </WorkflowArrayParameter>
                  <WorkflowParameter Name="SLAConfigObjectId" Type="guid">7b1505b3-fd95-06f1-f10e-d69d00dfbe1c</WorkflowParameter>
                </WorkflowParameters>
                <RetryExceptions />
                <RetryDelaySeconds>60</RetryDelaySeconds>
                <MaximumRunningTimeSeconds>7200</MaximumRunningTimeSeconds>
              </WindowsWorkflowConfiguration>
            </Subscription>
          </WriteAction>
        </WriteActions>
      </Rule>

Точно также надо изменить и правило %ИМЯ_SLO%-ResumeEvent. Единственное, что необходимо исправить в критерии – поменять местами операторы Equal и NotEqual (или вставить другой критерий).

Напомню параметры моего тестового SLO:

Имя: Test SLO
Метрика: От даты первого назначения до даты первого ответа
Календарь: Понедельник-Пятница, с 10:00 до 19:00
Целевое время: 1 час
Пороговое время предупреждения: 50 минут

Инцидент назначен в 04:13, соответственно целевое время будет равно 11:00 (отсчет начнется в 10:00, плюс один час – получаем 11:00):

После этого инцидент был переведен в состояние “Ожидание”, в результате чего сработает правило PauseEvent и SLO будет приостановлено (обратите внимание, что Целевая дата окончания не меняется):

В 12:55 изменился состояние инцидента на Активен:

В результате, SLO будет пересчитан с новой целевой датой окончания и запущен заново:

При возобновлении SLO время, которое уже прошло, учитывается. Т.е. если в момент приостановки SLA до нарушения оставалось 30 минут, то в момент возобновления также останется 30 минут.

Как быстро найти правила (рабочие процессы) по запуску и остановки для SLO

Для облегчения задачи поиска внутренних имен правил я сделал небольшой скрипт на PowerShell:

param([string]$SLADisplayName)

if(!$SLADisplayName)
{
	write-host ""
	write-host "Usage:"
	write-host "Get-SCSMSLAWorkflows.ps1 ""SLO Display Name"""
	write-host ""
	return
}

import-module SMLets

$SLAConfigObject = Get-SCSMObject -Class (Get-SCSMClass -Name "System.SLA.Configuration") -Filter "DisplayName = '$SLADisplayName'"
if($SLAConfigObject)
{
    [guid]$SLAConfigObjectId = $SLAConfigObject.Get_Id()

    $pauseRule = Get-SCSMRule | ? {$_.DisplayName -eq ($SLADisplayName + "-PauseEvent")}
    $resumeRule = Get-SCSMRule | ? {$_.DisplayName -eq ($SLADisplayName + "-ResumeEvent")}
	write-host ""
    write-host "Pause and resume workflows for SLO '$SLADisplayName':"
    write-host ("`tPause workflow: `t" +  $pauseRule.Name)
    write-host ("`tResume workflow: `t" +  $resumeRule.Name)
    write-host ("`tManagement Pack: `t" +  $resumeRule.ManagementPack.DisplayName + " [Name: " + $resumeRule.ManagementPack.Name + "]")
	write-host ""
}
else
{
    write-error "SLO '$SLADisplayName' not found!"
}

Сохраните его с именем Get-SCSMSLAWorkflows.ps1 и запустите, в качестве аргумента указав отображаемое имя целевого уровня обслуживания (как вы его видите в консоли). Пример вывода для моего тестового SLO:

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

Приостановка SLA. Эпилог.

Итак, для приостановки SLA нам необходимо:

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

В качестве критерия приостановки\возобновления вы можете использовать любое условие, что дает вам не ограниченное поле для реализации самых сложных сценариев. Главное – не перестараться с этой самой сложностью.

Кроме этого есть еще один способ, но я его не тестировал – критерии приостановки и возобновления можно записать в свойства PauseEventCriteria и ResumeEventCriteria объекта метрики с помощью SDK. В этом случае этот критерий будет использоваться для всех SLO, в которых применяется данная метрика (и для вновь создаваемых целей тоже).

И еще раз хотел бы отметить, что механизм приостановки SLA не поддерживается Microsoft, а значит вам необходимо тестировать каждый сценарий перед тем, использовать его в боевой среде. Проверяйте все возможные комбинации состояний, применение нескольких SLO и так далее.

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

Данная статья не является пошаговым руководством – про SLA в SCSM 2012 можно написать отдельную книгу. Механизм отслеживания SLA затрагивает многие компоненты SCSM, и является мощнейшим инструментом по анализу работы вашей ИТ-службы. Вы можете использовать этот механизм не только по прямому назначению, но и, скажем, для установки крайних сроков по согласованию или выполнению действий. Например, можно настроить SLO для действий согласования, указав как метрику дату начала и дату окончания. А при нарушении SLO (т.е. переходе объекта SLO в состояние “Нарушение”) запускать рабочий процесс, который будет автоматически утверждать действие согласования (или делать любые другие действия).

При этом мы рассмотрели только один тип SLO в SCSM – основанный на свойствах типа DateTime. В самом SCSM есть механизм SLO основанный на событиях, а также возможность добавить свой кастомный механизм расчета SLO. Но обе эти возможности не поддерживаются Microsoft, да и могут быть интересны только разработчикам.

Что же касается стандартных возможностей – не бойтесь экспериментов.

Решения для SCSM: разработка, администрирование…

SLA в SCSM 2012. Часть 3. Показать то, что скрыто

Очереди, или “вас тут не стояло!”

Очередь – это группа

Правила для очередей

Очереди и производительность

Приостановка SLA

Критерий приостановки и запуска

Включение механизма приостановки\возобновления SLA

Как быстро найти правила (рабочие процессы) по запуску и остановки для SLO

Приостановка SLA. Эпилог.

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

Поделиться в соц. сетях

Очереди, или “вас тут не стояло!”

Очередь – это группа

Правила для очередей

Очереди и производительность

Приостановка SLA

Критерий приостановки и запуска

Включение механизма приостановки\возобновления SLA

Как быстро найти правила (рабочие процессы) по запуску и остановки для SLO

Приостановка SLA. Эпилог.

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

Поделиться в соц. сетях

Добавить комментарий Отменить ответ

Primary Sidebar