В предыдущей статье я кратко изложил общие принципы построения процессов управления в ИТ, а также привел краткий обзор функционала, который предоставляет SCSM для процесса управления инцидентами. Пришло время продемонстрировать пример реализации этого процесса с помощью SCSM 2010 SP1.

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

1. Инциденты регистрируются тремя способами: через портал (основной метод), через почту и с помощью телефона. При этом обращение по телефону допускается только для VIP-пользователей (список прилагается), а также в случае полной неработоспособности компьютера пользователя. Все другие обращения по телефону не регистрируются.
2. Все инциденты из п.1 должны попадать на специалистов Отдела поддержки пользователей. Сотрудники, не входящие в ИТ департамент не должны обращаться на прямую к сотрудникам Отделов сетевых и системных администраторов.
3. Пользователь оповещается о регистрации инцидента и о смене статуса инцидента с помощью почтовых уведомлений.
4. Закрытие инцидента возможно только после звонка пользователю специалистом Отдела поддержки пользователей.
5. Инциденты, пришедшие от OpsMgr, назначаются напрямую на сотрудников Отделов сетевых или системных администраторов, в зависимости от группы устройств.
6. Передачу инцидентов между отделами могут осуществлять только сотрудники Отдела поддержки пользователей.
7. Один из сотрудников Отдела поддержки пользователей является Менеджером Инцидентов. В его обязанности входит проверка соблюдения сроков выполнения всех инцидентов, а также контроль за распределением инцидентов в рамках своего отдела.
8. В каждом отделе выделяется сотрудник, который будет являться координатором, и следить за распределением инцидентов внутри отдела.
9. У компании есть подрядчики, которые осуществляют поддержку нескольких ИТ-систем в компании. Данные об этих компаниях должны присутствовать в SCSM, также должна присутствовать возможность указать, что инцидент передан в компанию-подрядчик.
10. Должна быть возможность назначать инциденты на Отдел.

Итак, как видите, довольно простое ТЗ. Чаще всего п.1 вызывает бурю негодования среди сотрудников компании, т.к. у них пропадает возможность звонить “любимому” администратору. Для того, чтобы это работало, необходимо произвести разъяснительную беседу среди сотрудников ИТ-подразделений, и, возможно, привязать показатели системы ServiceDeskHelpDesk к финансовым показателям (н-р я встречал зависимость премии от кол-ва зарегистрированных инцидентов). В этом случае у сотрудников будет заинтересованность направлять всех в HelpDesk, а не решать проблемы “по старинке”.

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

Реализация регистрации инцидентов

Установка SCSM 2010

Для регистрации инцидентов нам необходимо установить сам SCSM 2010, а также портал самообслуживания. Как это сделать я уже писал ранее.

Первоначальные настройки

После установки нам необходимо настроить следующие параметры:

1. Включить входящую почту для регистрации инцидентов (консоль SCSM, Администрирование –> Параметры –> Параметры инцидента, секция “Входящая электронная почта”)
   
2. Изменить название уровней инцидентов на “Уровень 1”, “Специалисты” и “Подрядчики” (консоль SCSM, Библиотека –> Списки –> Очередь уровня инцидентов):
   
3. Также необходимо заполнить классификатор инцидентов (консоль SCSM, Библиотека –> Списки –> Классификация инцидентов):
   
   Список может быть иерархическим, точно также он будет отображаться и на портале:
   
4. Настроить исходящую почту (консоль SCSM, Администрирование –> Уведомление –> Каналы, “Канал уведомления по электронной почте”):
   

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

Вводим данные:

После еще 2х нажатий кнопок (саммари и результат) получаем результат в виде созданного инцидента:

Наполнение CMDB

Следующим шагом необходимо наполнить CMDB учетными записями пользователей, чтобы SCSM мог указывать их в качестве инициатора, а сотрудники могли выбирать в качестве исполнителей. Для этого необходимо настроить коннектор к Active Directory. Данный коннектор может собирать данные из текущего леса, домена или любого другого домена Active Directory (даже с которым не установлены доверительные разрешения). Необходимо лишь указать путь к LDAP-каталогу, а также учетную запись, имеющую права на чтение объектов в целевом домене. Настроить коннектор можно в консоли SCSM: Администрирование –>Соединители. Синхронизация с AD происходит раз в 30 минут (расписание изменить нельзя), при этом в CMDB попадают только те данные, которые изменились с момента последней синхронизации. Кроме домена целиком, можно указать определенную OU.

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

Замечу, что коннекторы, служащие для наполнения данных в CMDB односторонние. Т.е. изменения, сделанные в SCSM, не передаются в другие системы.

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

Данные пользователи будут отображаться в списке вместе со всеми, поэтому лучше указывать в поле Имя некий общий префикс, а в поле Фамилия – название компании:

Все созданные в консоли пользователи имеют домен SMInternal:

Если список компаний большой, можно использовать функцию импортирования из CSV-файлов (доступна из консоли SCSM в разделе Соединители) или PowerShell-скрипты.

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

Процесс регистрации инцидента

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

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

Рабочие процессы (РП) запускаются по событию создания или изменения элемента (еще существует возможность создания РП по событию удаления или по расписанию, но сделать это можно только с помощью средств разработки SCSM Authoring Tools). РП позволяют применить шаблон к инциденту иили отправить уведомление. При этом в РП мы можем указать фильтр: значение полей, при которых должен срабатывать РП. В нашем случае мы создадим РП, который при создании инцидента будет применять к нему шаблон, в котором в поле Первичный владелец будет указана группа ОПД. Т.к. группу ОПД должна быть указана только для инцидентов, зарегистрированных из консоли, через почту или портал, нам необходимо установить фильтр для этого РП: Источник = Консоль ИЛИ Источник = Почта ИЛИ Источник = Портал.

Перед создание РП нам необходимо создать шаблон. Шаблоны можно создать в консоли SCSM: Библиотека –> Шаблоны. В качестве класса для шаблона необходимо выбрать Инцидент:

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

Т.к. этот же РП будет использоваться и для оповещения, необходимо создать или отредактировать существующий шаблон оповещения. Делается это в консоли SCSM Администрирование –> Уведомления –> Шаблоны. SCSM позволяет вставлять в тело и тему письма значения полей из объектов (кнопка Вставить):

После этого необходимо создать РП, это можно сделать в консоле SCSM: Администрирование –> Рабочие процессы –> Настройка. Необходимо выбрать пункт “Настройка рабочего процесса события инцидента”, а затем в правой части Свойства:

В форме необходимо добавить новый РП, указать понятное имя (н-р “Инцидент – назначение на ОПД при создании”), в поле Описание желательно указать, что делает этот РП:

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

После этого необходимо выбрать шаблон, который будет применяться в рамках данного РП. Пусть вас не пугает, что в списке полей нет поля Первичный владелец, это нормально, т.к. это поле является ссылочным:

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

После этого можно закончить создание РП.

Теперь, после создания РП, будет применен наш шаблон и отправлено уведомление затронутому пользователю. Единственное, что следует помнить – РП запускаются не моментально после события, а помещаются в очередь, которая обрабатывается через определенный интервал времени, по умолчанию равный 100 сек. Итог выполнения РП виден в журнале инцидента:

и на форме:

Также на почту придет уведомление:

Если по какой-то причине у вас не отправляются оповещения, проверьте, заполнено ли поле email в Active Directory, и не связано ли это с особенностями локализации.

Представление данных

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

1. Назначенные на меня или на мою группу
2. Назначенные на мою группу и не распределенные

К сожалению, стандартный редактор представлений не позволяет этого сделать, поэтому воспользуемся расширенным редактором представлений. Достаточно импортировать этот пакет управления и перезапустить консоль SCSM. Создадим представления с помощью новой команды “Создать представление (расширенный)”. В качестве класса нам необходимо выбрать комбинированный класс, который содержит в себе поля Кому назначено, Затронутый пользователь и Первчиный владелец. Т.к. по умолчанию такого комбинированного класса (или type projection) нет, воспользуемся готовым пакетом, в котором есть нужный нам комбинированный класс:

Нам необходимо указать имя представления, выбрать изображение, а также указать критерий (критерий сознательно представлен в виде картинки, т.к. в каждом конкретном случае может отличатся ссылка на пакет управления):

В итоге в представлении будет представлены нужные нам инциденты:

Таким же образом создаем второе представление, но уже с другим притерием:

вот результат:

Также созданы представления для каждой из групп отделов (ОПД, Отдел системных администраторов, Отдел сетевых администраторов). Эти представления будут использоваться ответственными лицами для контроля.

Получение данных из OpsMgr

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

В начале мы настроим получение данных для CMDB. Т.к. по умолчанию импорт сетевых устройств из OpsMgr в SCSM не производится, нам потребуются подготовительные действия:

1. Импортировать пакет управления Microsoft.SystemCenter.NetworkDevice.Library в SCSM (его можно найти в папке C:Program FilesSystem Center Operations Manager 2007 на сервере OpsMgr)
2. Добавить с помощью PowerShell класс сетевых устройств в список разрешенных к синхронизации (класс Microsoft.SystemCenter.NetworkDevice)

После этого мы можем настроить коннектор к OpsMgr из SCSM, указав имя сервера RMS и учетную запись с правами как минимум Оператор в OpsMgr, а также список пакетов управления. В итоге в нашей CMDB будут все устройства, принадлежащие к разрешенным классам, в том числе и сетевые устройства.

Теперь нам необходимо настроить создание инцидентов на базе алертов в OpsMgr. При этом инциденты должны генерироваться только для критических алертов, с приоритетом Medium и High. Алерты от сетевых устройств должны автоматически назначатся на группу Отдела сетевых администраторов, все остальные – на группу Отдел системных администраторов.
Для реализации маршрутизации нам необходимо создать группу в SCSM, в которую будут входить все сетевые устройства. Сделать это можно в консоли SCSM, Библиотека –> Группы. Нам необходимо создать группу, и в качестве условия указать класс SNMP Network Device. Этот класс мы получили из пакета управления OpsMgr:

Можно проверить, что в группу попадают необходимые устройства (это возможно, если синхронизация коннектора OpsMgr завершена):

После этого необходимо создать новый шаблон “Шаблон инцидентов OpsMgr для сетевых устройств” также, как мы делали это для ОПД, в шаблоне указать источник Operations Manager, а первичным владельцем группу Отдел сетевого администрирования. Также сразу указываем категорию и группу поддержки:

Кроме этого, необходимо создать “Шаблон инцидента OpsMgr по умолчанию” и в поле Первичный владелец указать группу Отдела системного администрирования.

Теперь можно приступать к созданию коннектора для получения алертов из OpsMgr. Сделать это можно в консоли SCSM, Администрирование –> Соединители:

1. Создать новый “Соединитель предупреждений Operations Manager”
2. Указать название, имя сервер OpsMgr и логин для доступа. Данная учетная запись должна иметь права администратора в OpsMgr.
3. Добавить правило маршрутизации, указав, что если компьютер входит в группу Сетевые устройства (созданную ранее), то необходимо применить шаблон “Шаблон инцидентов OpsMgr для сетевых устройств”:
   
4. По умолчанию выбрать шаблон “Шаблон инцидента OpsMgr по умолчанию”:
   
5. Указать, нужна ли нам двухсторонняя связь или нет:
   

На этом создание коннектора со стороны SCSM завершено. Теперь необходимо настроить передачу алертов на стороне OpsMgr. Для этого в консоли OpsMgr необходимо открыть коннекторы (Administration –> Product Connectors –> Internal Connectors), найти в списке коннектор “Alert Sync:%ИМЯ_Коннектора_в_SCSM%” и открыть его свойства. Далее необходимо добавить правило подписки, указав следующие параметры согласно ТЗ:

После этого коннектор будет передавать алерты из OpsMgr в SCSM, а также передавать статусы. Результат работы представлен на следующих картинках:
Список инцидентов из OpsMgr:

Видно, что применился шаблон для сетевых устройств:

В затронутые элементы автоматически добавилось устройство, которое сгенерировало алерт:

В OpsMgr мы видим номер инцидента:

Инцидент закрыт в SCSM, статус передался в OpsMgr:

Алерт закрыт в OpsMgr, статус передался в SCSM:

Создание ролевой системы

Согласно ТЗ, закрывать инциденты могут только сотрудники ОПД. Но другим сотрудникам ИТ департамента также нужны права на изменение всех элементов в SCSM. Если внимательно посмотреть в консоль, то мы видим, что закрыть инцидент можно двумя способами: с помощью команды “Закрыть” (1) и с помощью команды “Изменить состояние инцидента” (2):

Если мы заблокируем эти команды, то пользователь не сможет закрыть инцидент, но при этом сможет перевести его на другую линию с помощью команд “Передать на обработку или переместить” или непосредственно из формы.

Для решения этой задачи необходимо создать новую роль. В консоли SCSM, Администрирование –> Безопасность –> Роли пользователя необходимо создать новую роль на базе шаблона “Оператор с расширенными правами”, и в секции “Пакеты управления” выбрать пакет “Библиотека управления инцидентами Service Manager”, а в секции “Задачи” выбрать все задачи, кроме “Закрыть” и “Изменить состояние инцидента”:

В эту роль на вкладке Пользователи добавить группы Отдела системного и сетевого администрирования, или группу всего ИТ-департамента. Т.к. пользователи ОПД будут входить в другую роль, им будут доступны эти задачи – роли в SCSM суммируются. В итоге, пользователи, входящие только в созданную нами роль не увидят команд “Закрыть” и “Изменить состояние инцидента”, но по прежнему смогут разрешать инциденты или передавать их в ОПД:

При этом административно (приказом) вводится запрет на передачу инцидентов на другие группы сотрудниками отделов, не входящих в ОПД.

Оповещения о смене статуса

Выше мы создавали оповещение о создании инцидента. Теперь нам предстоит решить более сложную задачу – оповещение при изменении статуса. Если вы внимательно смотрели настройки РП, то заметили, что мы можем указать лишь пару поле-значение, например “Статус_До_редактирования не равен Разрешен, и Статус_После_редактирования равен Разрешен”. Но мы не можем сравнить состояние До и После редактирования, т.е. мы не можем создать условие “Статус_До_редактирования не равен Статус_После_редактирования”. Но это ограничение является лишь ограничением консоли, а не механизмов SCSM. Для реализации такого условия необходимо:

1. Запомнить, в какой пакет управления вы созраняете этот РП. Для облегчения я создал новый пакет управления “Оповещение пользователей”
2. Создать новый шаблон для оповещения в этом же пакете управления
3. Создать новый РП, указав, что необходимо реагировать на обновлене инцидента, а в условии поставить “Изменен С” Состояние не равное Разрешен, а в “Изменен На” Состояние равно Закрыт.
4. Далее необходимо включить оповещение в этом РП, и добавить шаблон и Затрагиваемого пользователя, и сохранить РП.
5. Затем необходимо экспортировать созданный пакет управления “Оповещение пользователей”, сделать это можно из консоли SCSM, Администрирование-> Пакеты управления, выбрать пакет управления и нажать на команду “Экспортировать”:
   
6. Указать, в какую папку необходимо сохранить пакет управления
7. Открыть в любом текстовом редакторе полученный XML-файл (его имя будет похоже на ManagementPack.ee10111da36e451481f562572b20d0f2.xml)
8. Поиском найти строку, в точности совпадающую с названием РП, и ElementId которой начинается на WorfkflowSubscriotion (строка выше на рисунке относится к названию шаблона) и скопировать целиком значения атрибута ElementId (выделено желтым):
   
9. Найти в тексте по ElementId элемент <Rule>:
   
10. Найти внутри секцию <Criteria>, она дожлна выглядеть примерно вот так:
    
11. Заменить эту секцию, удалив второе условие (<Expression>), а значение в первом поменять на значение из второго, в итоге должно получиться следующее:
    
12. Сохраните файл
13. Импортируйте его в SCSM

В итоге, при любом смене статуса, затронутый пользователь будет получать уведомление:

Надеюсь, что данный пример поможет вам в освоении SCSM 2010, и даст ответы хотя бы на основноые вопросы по этому продукту.