System Center Service Manager 2010 — загадка для большинства пользователей. Что такое система билетов? Система управления изменениями? Механизм рабочего процесса? В действительности продукт предоставляет все перечисленные и многие другие функции.

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

Прежде чем приступить к подробному рассмотрению Service Manager, важно понять, что в основе работы диспетчера лежат ключевые концепции IT Infrastructure Library (ITIL). Это не обязательное требование, но я рекомендую изучить основные принципы ITIL, прежде чем внедрять Service Manager. А пока определим несколько основных терминов.

  • Управление инцидентами (incident management). Инцидент — событие, которое не является частью стандартных операций и может влиять на предоставление служб. Процесс управления инцидентами по возможности быстро возвращает службу в нормальное состояние, снижая влияние инцидента. Пользователь или система сообщает об инцидентах (регистрирует инцидент). Инцидент может повести к запросу на изменения или созданию билета проблемы.
  • Управление изменениями (change management). Процесс управления изменениями обеспечивает применение стандартных методов и процедур к любым действиям, связанным с изменениями. Запросы на изменения обрабатываются в процессе управления изменениями.
  • Управление проблемами (problem management). Процесс управления проблемами определяет причины инцидентов и предотвращает повторение проблем.
  • Элементы конфигурации (configu­ra­tion items). На языке ИТ-специалистов элементом конфигурации называется объект, такой как компьютер или пользователь.
  • Рабочие элементы (work item). Рабочий элемент — обозначение чего-то, подлежащего обработке. Это может быть инцидент, запрос на изменения или проблема.

Освоив терминологию, применяемую в Service Manager, рассмотрим, что представляет собой продукт, что необходимо для его развертывания и как им следует пользоваться.

Принципы организации

Основа функциональных возможностей Service Manager — база данных управления конфигурацией (change management database, CMDB) и интеграция продукта с другими ИТ-системами. CMDB привязывается к ИТ-системам и хранит информацию о них. Service Manager предоставляет различные порталы и рабочие процессы для доступа к информации в CMDB.

Без дополнительной настройки Service Manager интегрируется с Active Directory (AD), System Center Operations Manager и System Center Configuration Manager (SCCM). Благодаря этому в распоряжении Service Manager оказываются знания о системах, людях, оборудовании и программном обеспечении. Можно объединить Service Manager и с другими продуктами семейства System Center (например, Opalis) и Microsoft Exchange. Кроме того, возможно подключение к сторонним системам с использованием PowerShell. На рисунке показаны полная архитектура и возможности интеграции Service Manager.

 

Рисунок. Основные компоненты Service Manager

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

  • Если Operations Manager выдает предупреждение, Service Manager может автоматически зарегистрировать инцидент, за которым последует заранее определенный рабочий процесс. Рабочий процесс может состоять из нескольких шагов, таких как оповещение рабочих групп по электронной почте с предупреждением, запрос ввода данных от аналитика и выполнение действия через SCCM. При этом пользователь может самостоятельно определять глубину автоматизации. Чем больше операций автоматизировано, тем выше стандартизация, меньше нагрузка на администраторов и выше соответствие законодательным актам. Даже без автоматизации можно использовать консоль Service Manager для управления предупреждениями Operations Manager и просмотра информации, связанной с инцидентом. Возможность получать информацию из всех систем управления (например, AD, SCCM), а не только из Operations Manager, поможет раскрыть детали, полезные для расследования причин инцидента.
  • Если Service Manager интегрирован с SCCM, ему доступны весь инвентарный список и вся информация о коробочных продуктах. В результате можно внедрить рабочие процессы, обеспечивающие доступ пользователей к порталу самообслуживания Service Manager, чтобы запросить установку программного обеспечения. Пользователям предоставляется список программных продуктов, автоматически заполняемый с использованием инвентарного списка и информации о коробочных продуктах в SCCM. Если пользователь выбирает программный продукт, для которого требуется лицензия, Service Manager может отправить по электронной почте его руководителю уведомление с просьбой разрешить установку программы. Получив разрешение, рабочий процесс Service Manager добавляет пользователя или его основной компьютер (определяемый на основе анализа ресурсов SCCM) в коллекцию SCCM (группу компьютеров, используемых в качестве места назначения для развертываний), чтобы выполнить установку программного обеспечения.
  • В SCCM есть очень удобная функция, именуемая управлением требуемой конфигурацией Desired Configuration Management. С ее помощью можно задать базовую конфигурацию системы, с указанием файлов, параметров реестра, программных пакетов и настроек. Базовая конфигурация обеспечивает стандартизацию и соответствие компьютеров требованиям нормативных актов. SCCM сообщает о любых отклонениях от базовой конфигурации. Однако SCCM не предпринимает никаких действий, чтобы привести систему в желаемое состояние. Этот пробел устраняется благодаря Service Manager. Например, если конфигурация компьютера отличается от желаемой, Service Manager может зарегистрировать инцидент, запускающий рабочие процессы, которые вернут компьютер в исправное состояние. Как правило, изменения вносятся во взаимодействии с SCCM, путем переустановки программных продуктов или возврата к исходной конфигурации.

Требования

Прежде чем продолжить, рассмотрим серверы и программные продукты, необходимые для внедрения Service Manager. В первую очередь требуются, по крайней мере, два сервера Service Manager, которые могут быть физическими или виртуальными. Серверам Service Manager назначаются различные роли: один становится сервером управления Service Manager, а другой — сервером управления хранилищем данных. Для обоих серверов требуется 64-разрядная версия Windows Server 2008 с пакетом обновления SP1 или более новым.

Сервер управления Service Manager — мозг Service Manager. Он управляет подключениями, интеграцией с другими системами, выполняет рабочие процессы и любые другие необходимые действия. У этого сервера есть собственная база данных, размещаемая только на 64-разрядной платформе SQL Server 2008 SP1 или более новой версии.

Обычно сервер управления Service Manager может обслуживать одновременно до 80 активных сеансов консоли. Если требуется обслуживать больше активных сеансов консоли, можно добавить серверы и сформировать группу управления Service Manager. База данных для серверов группы может быть общей.

Сервер управления хранилищем данных обеспечивает размещение и управление хранилищем данных, состоящим из трех баз данных, совместимых с 64-разрядной версией SQL Server 2008 SP1 или более новой. Хранилище данных используется для долгосрочного архивирования информации, созданной или собранной Service Manager. Кроме того, все отчеты основываются на хранилище данных. После того, как создан сервер управления хранилищем данных, он подключается к серверу управления Service Manager, чтобы обеспечить передачу данных в хранилище данных и установить связь с консолью Service Manager.

Для подготовки отчетов в Service Manager используются службы SQL Server Reporting Services (SSRS). Как правило, службы SSRS запускаются на сервере управления хранилищем данных, но это не обязательное условие. Отчеты можно готовить из консоли Service Manager или в доступном через браузер интерфейсе SSRS.

Не обязательно, чтобы сервер управления хранилищем данных был постоянно активен в тестовой среде. Его можно запускать один раз в день, чтобы выполнять задания, извлекающие данные из базы данных Service Manager в хранилище данных, и если нужно подготовить отчеты. Данные, поступающие в хранилище данных, не удаляются из базы данных, так как они необходимы для операций Service Manager. Процессы очистки периодически применяются к базе данных Service Manager, при этом удаляются данные с учетом состояния рабочих элементов и даты и времени последнего изменения.

Подробные инструкции по установке Service Manager опубликованы в руководстве по развертыванию System Center Service Manager 2010 SP1 по адресу technet.microsoft.com/en-us/library/ff460909.aspx.

Использование Service Manager

Существует три основных категории пользователей Service Manager.

  • Архитекторы и администраторы Service Manager. Они проектируют и внедряют экземпляры Service Manager, настраивают рабочие процессы и формы и управляют интеграцией Service Manager с другими системами в ИТ-инфраструктуре.
  • Аналитики. Они используют Service Manager для управления и работы с инцидентами и запросами на изменения. Часто это бывают сотрудники ИТ-подразделений и службы технической поддержки. Иногда это менеджеры и инспектора отделов кадров, которым необходимо разрешить действия определенного типа.
  • Конечные пользователи. С помощью Service Manager они запрашивают программы, изменяют пароли, ведут поиск в базе знаний (библиотеке) статей, которые могут быть полезными при разборе инцидентов и неполадок, регистрируют новые инциденты, следят за объявлениями и выполняют другие действия.

Соответственно Service Manager изначально располагает тремя пользовательскими интерфейсами.

  • Консоль Service Manager. Как и консоли для других продуктов System Center, консоль Service Manager построена на основе интерфейса Service Manager, а не Microsoft Management Console (MMC). Существенные преимущества интерфейса Service Manager — гибкость и возможность показывать только элементы, для доступа к которым у пользователя есть разрешения. В результате пользователи, имеющие определенные права для доступа к тем или иным группам объектов, получают гораздо более аккуратный интерфейс. Консоль Service Manager в основном используется администраторами, аналитиками и сотрудниками, готовящими отчеты.
  • Портал самообслуживания на основе IIS. Портал самообслуживания обеспечивает два отдельных веб-узла. Первый веб-узел предназначен для конечных пользователей. На нем они могут выполнять поиск в базе знаний, проверять состояние запросов на изменение, фиксировать новые инциденты и выполнять другие действия. Второй веб-узел — для аналитиков. На нем аналитики могут утвердить запросы на изменение, просмотреть назначенные им рабочие элементы и т. д.
  • Портал самообслуживания на основе SharePoint. Задача этого портала такая же, как у портала самообслуживания на основе IIS. Однако в нем используются веб-части SharePoint, благодаря которым веб-интерфейс Service Manager интегрируется с существующей инфраструктурой SharePoint.

Есть и другие интерфейсы, но они используются в основном для специализированных форм и рабочих процессов. С помощью инструмента Service Manager Authoring Tool можно создавать специальные формы, рабочие процессы и другие компоненты. Чтобы воспользоваться этим инструментом, не обязательно иметь глубокие знания, так как в нем применяется функциональность drag-and-drop. Инструмент Authoring Tool можно загрузить с сайта по адресу tinyurl.com/SCSMAuthoringTool. Дополнительные сведения о настройке Service Manager на конкретные случаи применения можно найти в руководстве System Center Service Manager 2010 SP1 Authoring Guide (technet.microsoft.com/en-us/library/ff597545.aspx).

Консоль Service Manager крупным планом

Самый простой способ получить представление об использовании и возможностях Service Manager — взглянуть на консоль Service Manager. Как показано на экране 1, в консоли имеется шесть рабочих областей, соответствующих шести основным функциональным областям Service Manager: Administration (Администрирование), Library (Библио­тека), Work Items (Рабо­чие элементы), Configuration Items (Элементы конфигурации), Data Warehouse (Хранилище данных) и Reporting (Отчеты). Прежде чем рассмотреть основные характеристики каждой рабочей области, отмечу, что на экране 1 я зарегистрирован с полными административными правами, поэтому здесь отображаются все рабочие области и параметры. Конечный пользователь увидит в консоли только рабочие области и параметры, доступ к которым ему разрешен. Управление доступом на основе ролей — важная характеристика Service Manager и остальных продуктов System Center.

 

Экран 1. Консоль Service Manager

Администрирование. Рабочая область Administration — отправная точка для каждого нового развернутого экземпляра Service Manager. В ней можно настроить интеграцию Service Manager с другими системами, такими как AD, SCCM и Operations Manager. Безусловно, полезно соединить Service Manager с AD, так как это позволит импортировать объекты «пользователь», «группа», «принтер» и «компьютер» вместе с назначенными им атрибутами.

Обратите внимание, что коннектор с AD — однонаправленный. Поэтому, если изменять атрибуты элементов конфигурации (объектов) в Service Manager, также необходимо изменить атрибуты в AD. В противном случае в следующий раз при синхронизации с Service Manager AD перезапишет внесенные изменения. Можно настроить Service Manager на синхронизацию всего пространства имен AD или его части (в этом случае нужно указать типы объектов для синхронизации).

Помимо настройки интеграции, необходимо назначить роли пользователям в области безопасности рабочей области Administration. По умолчанию существует 11 ролей: Activity Implementers (исполнители действий), Administrators (администраторы), Advanced Operators (операторы с расширенными правами), Change Initiators (инициаторы изменений), End Users (конечные пользователи), Read-Only Operators (операторы только для чтения), Authors (авторы), Problem Analysts (аналитики проблем), Workflows (рабочие процессы), Incident Resolvers (распознаватели инцидентов) и Change Managers (диспетчеры изменений). Если эти роли не соответствуют нуждам компании, можно создать собственные пользовательские роли.

Еще одна полезная настройка — установить сроки хранения данных в базе данных Service Manager. Сделать это можно в области Settings рабочей области Administration. Здесь же настраиваются параметры для инцидентов. Например, можно дополнить префиксом формируемые идентификаторы инцидента, указать метод расчета приоритета для инцидента и установить ограничения для файлов, придаваемых пользователями к формируемым ими инцидентам (например, разрешить только два присоединенных файла по 512 Кбайт каждый).

Настройки — не единственная задача, которую можно выполнять в рабочей области Administration. Можно выполнять различные другие задачи, в том числе создавать объявления и импортировать пакеты управления. Область Announcement — место создания объявлений, которые отображаются в портале самообслуживания. Можно задать дату истечения срока действия, поэтому не нужно беспокоиться об удалении объявлений, потерявших актуальность.

Пакеты управления представляют собой XML-файлы, которые определяют формы, рабочие процессы, классы, представления и отчеты в Service Manager. Например, при создании нового рабочего процесса создается новый пакет управления. Для импорта этого пакета управления в Service Manager используется функция импорта рабочей области Administration.

Библиотека. В рабочей области Library представлены различные элементы данных конфигурации системы Service Manager, которые используются во всех компонентах продукта. Например, можно легко изменить все параметры, отображаемые при создании инцидента, путем изменения соответствующего элемента списка, о котором будет подробнее рассказано ниже. Можно определить группы элементов конфигурации, очень похоже на создание контейнеров для объектов в AD.

В разделе Knowledge рабочей области Library можно создать и обслуживать базу знаний. Статьи базы знаний — основное средство распространения знаний. Когда пользователи обращаются к порталу самообслуживания, автоматически строится и отображается на начальной странице список наиболее актуальных статей базы знаний.

Другой важный раздел рабочей области Library — Lists. Когда пользователи создают и изменяют рабочие элементы, им часто предоставляются раскрывающиеся списки, из которых можно выбрать тип проблемы и круг затронутых систем. Если нужно изменить пункты раскрывающегося списка, следует перейти в соответствующий список и добавить или удалить элементы, как показано на экране 2. На экране 3 мы видим этот раскрывающийся список в форме.

 

Экран 2. Список классификации инцидентов

 

Экран 3. Список классификации инцидентов в форме

Шаблоны — еще один превосходный элемент рабочей области Library. Помимо работы через портал самообслуживания, пользователи могут докладывать об инцидентах и изменениях по электронной почте и телефону. Аналитику не придется терять время на многократный ввод одинаковой информации и параметров; можно быстро применить шаблон, в котором заполнено большинство типовых полей для разнообразных видов запросов. Шаблоны также могут автоматически применяться рабочими процессами для маршрутизации и классификации рабочих элементов на основе определенных условий.

Рабочие элементы. Аналитики часто используют рабочую область Work Items, в которой содержатся нужные им элементы инцидентов, проблем, изменений и действий. В каждом разделе рабочей области (например, управления изменениями или управления инцидентами) имеется несколько представлений по умолчанию. Например, на экране 4 показаны представления по умолчанию для управления инцидентами (все инциденты, все открытые инциденты, все открытые инциденты портала). Обратите внимание на панель задач справа. Каждое представление содержит задачи, доступные для рабочего элемента данного типа. В нашем случае показано множество доступных задач для инцидентов. Например, аналитик может изменить состояние инцидента, создать запрос на изменение на основе инцидента, эскалировать (передать по инстанциям выше) инцидент и даже выполнить определенные действия для разрешения инцидента, например проверку связи. Любая выполненная задача автоматически записывается в журнал инцидента. Таким образом удается составить полную картину предпринятых действий и хода выполнения. По умолчанию конечные пользователи могут увидеть журнал зарегистрированных ими инцидентов. Однако аналитики могут отметить определенные элементы журнала (например, комментарии) как частные, и они окажутся невидимыми для конечных пользователей. Также аналитики могут строить особые представления.

 

Экран 4. Стандартные представления управления инцидентами

Элементы конфигурации. Рабочая область Configuration Items обеспечивает доступ к компьютерам, принтерам, пользователям, программам, обновлениям программ, бизнес-службам и любым другим типам определенных или импортированных элементов конфигурации внутри организации. В большинстве сред не приходится широко применять ручное управление элементами конфигурации в Service Manager. Управление производится через соответствующие подключенные системы (например, AD, SCCM, Operations Manager).

Рабочая область Configuration Items не дает «неинтеллектуального» представления элементов конфигурации, реплицированных из различных источников. Элементы конфигурации из подключенных систем консолидируются в CMDB, и их связи проверяются. Поэтому, рассматривая элемент конфигурации в рабочей области, пользователь увидит сведения об элементе из AD, SCCM и Operations Manager как единую сущность, что облегчает анализ. Например, исследуя программный пакет, пользователь увидит все связанные с ним запросы на изменение и инциденты.

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

Отчеты. В рабочей области Reporting отображаются все доступные отчеты, запускаемые на экземпляре SSRS. Можно также формировать отчеты непосредственно на экземпляре SSRS, как показано на экране 5. Можно создать собственные специализированные отчеты и отображать их в рабочей области Reporting, следуя инструкциям, опубликованным в блоге группы SCSM Engineering «How to create a custom report and display it in the console» (tinyurl.com/SCSMCustomReport).

 

Экран 5. Отчеты Service Manager на экземпляре SSRS

Портал самообслуживания крупным планом

Конечные пользователи и аналитики взаимодействуют с Service Manager через портал самообслуживания. На веб-узле конечного пользователя легко создать инцидент, запросить новый программный продукт и запросить изменения других типов. Затем в портале удобно просматривать состояние всех открытых и обработанных инцидентов и запросов. Возможность конечных пользователей самостоятельно решать проблемы, выполняя поиск известных неисправностей в базе знаний, поможет уменьшить количество инцидентов, регистрируемых пользователем, и сократит нагрузку на сотрудников службы поддержки.

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

На экране 6 показан портал на основе IIS с параметрами по умолчанию, в которые не внесено никаких изменений. Имеется исходный текст портала самообслуживания, поэтому можно изменить внешний вид, функциональность и реакцию портала на действия пользователей. Дополнительные сведения о возможных настройках приведены в статье «Service Manager Portal Source Code Released!» (blogs.technet.com/b/servicemanager/archive/2011/03/02/service-managerportal-source-code-released.aspx).

 

Экран 6. Портал самообслуживания на основе IIS

Как уже отмечалось, пользователям SharePoint не обязательно использовать портал на основе IIS. Для них вполне приемлем портал на основе SharePoint. Можно даже разместить веб-части Service Manager в разделе My Sites пользователей, чтобы предоставить им простой доступ к информации Service Manager.

Больше, чем система билетов

Важно не рассматривать Service Manager как систему билетов. Конечно, в продукте есть удобные функции управления билетами, но его главное достоинство — в интеграции с остальной ИТ-инфраструктурой и в CMDB, что позволяет отдельным системам взаимодействовать в рабочих процессах. Выпущена первая версия Service Manager, но у продукта уже есть поддержка развитой сети партнеров, включая компанию Provance, благодаря которой Service Manager дополняется функциями управления ресурсами.

Мне приходилось беседовать со специалистами, уже внедрившими Service Manager, и все они выражали удивление, насколько быстро удалось достичь таких результатов. Блог группы SCSM Engineering (blogs.technet.com/b/servicemanager) оказался очень полезен во многих случаях внедрения Service Manager. В нем опубликовано множество интересных материалов по использованию Service Manager.

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP