Что нового в System Center 2012 Service Manager SP1

Иногда предназначение Service Manager по отношению к другим компонентам System Center 2012 понимают неверно: некоторые думают, что Service Manager – это исключительно «система отслеживания ошибок». На самом деле Service Manager является центральной док-станцией для всей системы System Center 2012 и всей информационной инфраструктуры в System Center 2012. Если вам приходилось видеть графическое представление компонентов System Center 2012, вы знаете, что Service Manager обычно изображен посередине (как показано на рисунке). Это подчеркивает его центральную позицию по отношению ко всему комплексу System Center 2012.

Рисунок. Взаимосвязь компонентов System Center 2012

Надо сказать, что для описания Service Manager больше подходит слово «компонент», а не «продукт». Помните, что System Center 2012 является единым продуктом, который включает в себя множество компонентов. До этой версии части System Center были самостоятельными, отдельно приобретаемыми продуктами. Теперь если вы покупаете System Center 2012, то владеете всеми этими компонентами.

Я воспринимаю Service Manager как хранилище информации об управлении Configuration Management Database (CMDB) для всей организации. Поскольку Service Manager имеет связь с большинством других компонентов System Center, он «знает» то, что «знают» эти компоненты, и консолидирует эту информацию в единое хранилище метаданных. Когда вы смотрите на элемент Configuration Item в Service Manager, вы видите его аппаратное и программное обеспечение, его статус исправлений, информацию в Directory (AD) о нем, предупреждения от службы мониторинга, которые относятся к нему, информацию о виртуализации и т.д. Вы видите все. Хранилище метаданных Service Manager 2012 позволяет включать в него данные и из пользовательских источников, разрешая сбор данных из ресурсов вне System Center. Рабочие элементы, такие как инцинденты, запросы на изменения, записи о проблемах, записи управления версиями и запросы служб, понятны для Service Manager.

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

Интеграция с Orchestrator И Virtual Machine Manager

Задумайтесь о комплексе действий, который вам приходится выполнять на всех системах и панелях управления, которые вы используете. Поразмышляйте над логикой ваших действий и всеми сложными процедурами, которые должны быть выполнены. О чем бы вы ни думали, предоставленный набор действий должен быть доступен по API и взаимодействовать с PowerShell, SSH, командами, REST, пакетами Integration Pack и т.д. — все может быть автоматизировано как последовательность задач внутри System Center Orchestrator. Оцените, какие возможности дает Orchestrator и насколько просто создавать последовательности задач посредством графического интерфейса, и Orchestrator станет для вас компонентом System Center, без которого вы уже не сможете обойтись. С его помощью вы научитесь создавать последовательности задач и сможете автоматизировать процессы, выполняемые вручную.

Service Manager 2012 тесно интегрирован с Orchestrator; он поддерживает синхронизацию всех определенных последовательностей задач в базу данных Service Manager 2012 с помощью встроенного коннектора к Orchestrator. Замечу, что код существующей последовательности задач не синхронизируется, а для запуска каждой последовательности задач передается список имеющихся последовательностей задач и параметры инициализации. Это позволяет Service Manager запускать на исполнение последовательности задач в удаленном режиме, передавая нужные параметры. Используя этот подход, можно создавать автоматические шаблоны последовательностей задач, которые впоследствии могут быть использованы в общем процессе для различных типов рабочих элементов с целью автоматизации процесса (или некоторых его частей).

Virtual Machine Manager (VMM) также интегрируется с Service Manager, а через встроенный коннектор посылается информация о виртуальной среде в Service Manager. VMM включает в себя такие объекты, как виртуальные машины, шаблоны виртуальных машин, сети, хосты и «облака». Некоторые из этих функций выполняются и через Operations Manager. Предоставление Service Manager информации о виртуальной инфраструктуре активирует ряд частных сценариев управления, таких как запросы на создание виртуальных машин и целых «облаков», которые осуществляются через Service Manager. Дальнейшее изменение в Service Manager SP1 – это тарификация виртуальных машин. Система тарификации является новым набором объектов в Service Manager, который позволяет осуществлять ценообразование для различных ресурсов виртуализации, таких как виртуальные машины, процессоры, память или хранилище. Поскольку бизнес-подразделения используют виртуальные машины, отчеты могут быть сгенерированы так, чтобы показывать, на что был потрачен каждый рубль при приобретении ресурсов виртуализации, которыми пользовалось каждое бизнес-подразделение. На экране 1 показан пример страницы стоимости для каждого объекта в Service Manager. Заметьте, что параметры включают не только стоимость общих ресурсов, таких как процессор, память и хранилище, но и более специфические ресурсы, такие как использование функций высокой готовности и статический IP-адрес.

Экран 1. Новая страница стоимости ресурсов System Center 2012 SP1

Предложения запроса, предложения службы и каталог служб

Service Manager 2012 вводит для пользователей ряд возможностей, которые относятся к предложениям служб – ключевой строительный блок для организации предоставления услуг ИТ в качестве поставщика служб в своей организации. Первый шаг в предложении службы – это создание предложения запроса. Каждое предложение запроса основывается на либо шаблоне инцидента, либо на шаблоне запроса службы. И тот, и другой определяют некоторые значения по умолчанию, такие как название, срочность и группа, которые будут назначены, когда пользователь сделает запрос. Эти шаблоны также определяют процесс, который должен быть исполнен для того, чтобы выполнить запрос. Возьмем простой пример: шаблон может быть двухшаговым процессом, то есть за два шага будет получено одобрение от сотрудника, запрашивающего службу. Затем выполняется последовательность задач в Orchestrator для создания новой виртуальной машины. Запросу на предложение может быть присвоено название, изображение размером 32х32 пиксела и описание. Затем администратор может определить количество вопросов к пользователю для получения более детальной информации. Далее администратор определяет, как каждый ответ пользователя соотносится с итоговым запросом службы или реакциями на инцидент.

На экране 2 показан образец запроса о новом имени виртуальной машины, ее владельце, «облаке», которое надо развернуть, и о том, какой шаблон виртуальной машины следует использовать. Вместо обычных текстовых полей вы можете создавать для пользователей списки, из которых они будут выбирать. На экране 2 для выбора «облака» и шаблонов я использую список. Вы могли бы сделать это и в Query Result, который бы показал список вариантов, основанных на том, какие именно параметры из VMM были переданы в Service Manager CMDB. В моем сценарии, который вызывает последовательность задач, некоторые пользовательские ответы могли быть сопоставлены входным параметрам для последовательности задач. При создании предложения запроса важно установить статус Published в разделе Publish, который находится в Request Offering. В противном случае эти предложения не будут видимы пользователю и не будут доступны для размещения на следующем шаге — предложении службы.

Экран 2. Предложение запроса

Предложение службы позволяет логически сгруппировать предложения запроса. Как и предложение запроса, предложение службы имеет название, собственные значок и описание, категорию и информацию, такую как SLA и стоимость. Предложения запроса добавляются в предложение службы, как показано на экране 3. В своем примере я создал предложение службы виртуализации и добавил все предложения запросов, связанные с виртуализацией. В обязательном порядке вы определяете тип службы, а предложения запроса являются действительными службами, к которым пользователь может обратиться. Итак, виртуализация является службой, поскольку создание виртуальной машины, смена владельца виртуальной машины и изменение квот являются службами, которые пользователь может запросить.

Экран 3. Добавление предложений запроса в ?предложение службы

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

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

В предыдущем разделе я говорил о том, как сделать предложения доступными для пользователей. Но как пользователи могут получить доступ к ним? У Service Manager 2010 был веб-портал самообслуживания, но его функции были ограничены. В Service Manager 2012 реализован обновленный портал самообслуживания, построенный на базе SharePoint 2010. Да, даже в случае с Service Manager 2012 SP1 может использоваться только SharePoint 2010, а это означает, что хотя каждый компонент System Center 2012 SP1 поддерживает Windows Server 2012, веб-портал для нужд Service Manager нужно запускать на Windows 2008 R2. Однако ситуация вскоре изменится. Новый портал использует Silverlight, значит, любые пользовательские настройки SharePoint для этого портала могут быть выполнены. Кроме того, веб-части, которые составляют веб-портал Service Manager 2012, могут быть интегрированы в существующие фермы SharePoint. На экране 4 показана домашняя страница портала самообслуживания и акцент на каталоге служб очевиден: все предложения службы, которые вы создали, представлены по умолчанию в Category view. Существует также List view (см. экран 5), где отражены все созданные предложения запросов. Таким образом, Category view удобнее для пользователей, поскольку позволяет выбрать тип службы, которая их интересует. Выбрав ее однажды, они видят все предложения запросов для этой службы, как показано на экране 6.

Экран 4. Портал самообслуживания Service Manager 2012

Экран 5. Просмотр в представлении List

Экран 6. Форма для предложения службы

Когда пользователь выбирает специфический запрос предложения, он направляется на новую страницу, показывающую любые связанные со службой технической помощи статьи и предложения службы. Одной кнопкой можно попасть на форму запроса. Пользователи часто просят удалить эту страницу, поскольку она замедляет им доступ. Однако цель этой страницы в том, чтобы показать пользователям информацию о предложениях, и, возможно, им не нужно будет заполнять запрос. На экране 7 показана форма актуального предложения запроса. Помните поля, которые были настроены в предложении запроса на экране 2? Это то, что пользователь видит в качестве результата информационных подсказок. Один раз пользователь заполняет эти поля, а затем направляется на экран представления, когда на запрос делается подписка, и ему дается ID нового запроса службы.

Экран 7. Форма для предложения запроса

Обратите внимание на ссылки на левой панели портала самообслуживания. Homelink направляет вас на домашнюю страницу каталога служб. При помощи ссылки Help Articles можно осуществлять поиск нужной документации. My Requests позволяет вам видеть открытые запросы и обновлять их: например, добавлять больше информации. My Activities показывает только те действия, которые необходимо сделать, такие как выполнение определенной задачи или одобрение чьего-либо запроса. Возвращаясь к сценарию создания виртуальной машины, в котором менеджер должен одобрить запрос раньше реального создания виртуальной машины, напомню, что это одобрение является действием просмотра, назначенного данному менеджеру. Менеджер может зарегистрироваться на портале самообслуживания, тогда заявки на проведение экспертизы перечисляются в My Activities. Предположим, что менеджер одобрит запрос после его просмотра, и Service Manager запустит автоматическую последовательность задач в Orchestrator для создания виртуальной машины.

Что мы получаем?

Когда вы соединяете рассматриваемые три шага, у вас появляется возможность предоставить пользователям каталог нужных им служб. Поскольку информация от пользователя принимается в структурном виде и маршрутизируется либо в Service Request, либо в Incident, вы можете передать эти данные в последовательность задач Orchestrator для автоматического выполнения всех частей запроса.

У пользователей есть единое место для запроса любой службы. Это может быть новая виртуальная машина, запускающая последовательность задач Orchestrator, которая приводит в действие VMM. Это может быть запрос на приложение, запускающий последовательность задач Orchestrator, который активирует действия в Configuration Manager (и вы можете загрузить Application Approval Workflow (http://www.microsoft.com/en-us/download/details.aspx?id=29687)). Это может быть переустановка Apache на 20 серверах Linux, которая активирует Orchestrator на загрузку нескольких команд SSH на целевых серверах. Таким образом, владельцы могут управлять своим приложением самостоятельно, а не беспокоить администраторов. Это может быть запрос нового кресла, который создаст билет запроса в Service Manager.

Помимо рассмотренных возможностей, есть еще и многие другие. Здесь я только поверхностно упомяну о них. Я сказал о SLA чуть раньше. Это концепция была представлена в Service Manager 2010, но SLA сложно было использовать, поскольку по существу они запускали таймер, а когда проходило определенное количество времени, реализовывалось ограничение по SLA. Это было неудобно, если заявка была открыта в 17.00 в пятницу. В Service Manager 2012 можно создавать календари, а различные календари назначаются различным группам рабочих элементов. Обычные рабочие элементы могут отслеживаться в течение часов работы, но особые группы элементов SLA могут отслеживаться и допоздна.

Service Manager 2012 вводит новый тип рабочего элемента — запись версии. Он может быть использован для координации процесса управления версиями бизнес-приложения или применения изменений в период технического обслуживания. Service Manager также позволяет создавать взаимоотношения «родитель – ребенок» для инцидентов, изменения и рабочих элементов при управлении версиями. При помощи такого типа взаимоотношений инциденты могут быть связаны с существующим родительским инцидентом. Это означает, что когда родительский инцидент закрывается, все проблемы с дочерними инцидентами также будут разрешены. Это очень удобно, когда ваш почтовый сервер перестает работать и у вас есть 500 билетов, связанных со сбоем почтовой службы. Теперь, когда вы восстанавливаете почтовый сервер и решаете проблему, связанную с родительским инцидентом, все эти билеты закрываются автоматически.

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

Обратите внимание, что Service Manager 2012 SP1, как и System Center 2012 SP1, сегодня поддерживает Windows Server 2012 и SQL Server 2012, что позволяет разворачивать его на новейших версиях операционной системы и SQL Server. Обратите также внимание, что Service Manager не поддерживает установку в режиме Server Core, как было указано TechNet (http://technet.microsoft.com/en-us/library/jj628210.aspx).

Для большинства организаций новая функция каталога служб доступна на веб-портале и сопровождается тесной интеграцией с Orchestrator. Однако многие организации до сих пор даже не пробовали использовать Service Manager. Я надеюсь, моя статья будет способствовать тому, чтобы вы начали планировать развертывание Service Manager в своей организации.