Компьютерщик на все руки: Полная автоматизация управления заявками

System Center Service Manager 2012 позволяет автоматизировать процесс управления заявками на услуги.

Грэг Шилдс

Заявки на услуги — то, что отравляет жизнь любого ИТ-профессионала и, в то же время, является причиной его существования. С течением лет они превращаются в то, что мы и любим, и ненавидим. С одной стороны, они всегда являются поводом доказать свою значимость. С другой стороны, добавляется еще одна задача, с которой мы должны справляться за предсказуемое время.

Сами по себе заявки — не такая уж проблема. Однако платой за их выполнение является то, что нам приходится предоставлять ИТ-услуги и управлять ими. Нас «достает» то, что такие запросы, в соответствии с их природой, приходится выполнять в значительной степени вручную. Даже в современном мире, где повсеместно присутствует Windows PowerShell и имеется несметное количество консолей управления, крайне сложно добиться по-настоящему полной автоматизации рабочих процессов — от начала и до конца. Или это все-таки возможно?

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

Сначала заявка, потом выполнение

Сам по себе Service Manager, в принципе, не отличается от типичной системы, отслеживающей выполнение повседневной работы. Откройте его консоль и перейдите на панель Work Items — вы увидите список видов деятельности, который словно взят прямо из стандартной библиотеки любителя IT Infrastructure Library (ITIL).

В Service Manager имеется шесть основных видов деятельности (work items): Activity Management (управление операциями), Change Management (управление изменениями), Incident Management (управление инцидентами), Problem Management (управление проблемаи), Release Management (управление версиями) и Service Request Fulfillment (выполнение заявок на услуги) (рис. 1). Эти шесть видов деятельности определяют повседневное функционирование ИТ-отдела. Теперь еще немного пощелкайте их мышкой, и вы придете к выводу, что Service Manager просто ужасен.

Рис. 1. Шесть видов деятельности, доступных в System Center Service Manager 2012.

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

Но в данном случае большие сложности означают мощные возможности. Если вы не пожалеете ресурсов на предварительные усилия, вашей наградой будет полная автоматизация обработки заявок. Это преимущество проявится в тот момент, когда вы интегрируете Service Manager с «клеем» System Center Orchestrator. (Об использовании Orchestrator  можно прочитать в первой статье моей серии.)

Перейдите на панель Service Manager Administration, и вы увидите ссылку Connectors. Connector (соединитель) — это точка интеграции Service Manager и других компонентов System Center. На рис. 2 можно видеть, что Service Manager интегрирован с Orchestrator, System Center Virtual Machine Manager (VMM) и Active Directory.

Рис. 2. Соединители связывают System Center Service Manager с другими компонентами System Center

Большинство из нас живет в мире, в котором нет автоматизации, подобной предоставляемой Orchestrator. В этом ужасно «ручном» мире, рабочий процесс, связанный с обработкой заявки, выглядит примерно так:

1. Кто-то подает заявку на новую услугу.
2. Кто-то еще одобряет его заявку.
3. Генерируется карточка заявки (ticket), которая назначается администратору.
4. Администратор предоставляет услугу и закрывает карточку.

В каждой организации этот процесс автоматизируется по-своему. У вас эти четыре этапа наверняка документируются не так, как у других. Однако даже самые автоматизированные организации все равно имеют трудности с автоматизацией этапа 4: собственно выполнением работы. При преодолении этого ограничения связка Service Manager и Orchestrator проявляет себя во всем блеске.

Автоматизация заявки на новую VM, шаг за шагом

В первой части моей серии из двух статей утверждалось, что Orchestrator служит «клеем» для других частей System Center. Связывая между собой объекты операций, доступные в Orchestrator, можно создавать мощные механизмы автоматизации систем платформ и приложений для регулярно выполняемых заданий. Причем при создании большинства таких механизмов не требуется писать сценарии.

Orchestrator превосходно интегрируется не только с Service Manager, но и с остальными компонентами System Center. Благодаря этому в вашем распоряжении имеется «зверинец» высокоуровневых объектов-операций, позволяющих выполнять задания, обращаясь к другим компонентам System Center. Одной из важных интеграционных связей является интеграция Orchestrator и VMM. Благодаря взаимодействию этих двух компонентов в Orchestrator можно формировать наборы заданий, использующие всевозможные операции VMM.

Автоматизация — это, конечно, приятно, но было бы интересно знать, как она осуществляется. Давайте предположим, что вы создали свой собственный набор заданий Deploy VM (развертывание VM). В нем вы определили два параметра — Cloud (облако) и VMName (имя VM). Таким образом, пользователь, подающий заявку, может выбрать облако VMM и имя VM. Кроме того, вы настроили необходимые для набора соединители Service Manager, Orchestrator и VMM. Ваша последняя задача — создать обработчик заявок, который будет автоматизировать требуемые согласования заявок и (после согласования) автоматически заводить VM.

Для выполнения такой задачи в Service Manager требуется создать несколько уровней объектов  (рис. 3). На каждом таком уровне определяется некоторый элемент заявки, который с помощью настроек связывается с вышестоящим уровнем.

Рис. 3. Уровни System Center Service Manager 2012.

В центре находится сам набор заданий Orchestrator — объект, который, собственно, и выполняет всю работу. Для связывания всех этих уровней требуется выполнить строго определенную последовательность действий.

Этап 1. Синхронизация Service Manager с Orchestrator. После соединения потребуется какое-то время для отображения наборов заданий в Service Manager. Зайдите в Library | Runbooks и, перед тем как перейти к следующему этапу, убедитесь, что ваш набор заданий там присутствует.

Этап 2. Создайте Runbook Automation Activity Template (шаблон операции автоматизации набора заданий). Укажите имя шаблона (рис. 4) и создайте Management Pack (MP, пакет управления). На каждом из последующих этапов сохраняете, все, что вы создаете, в MP. В таком случае ваш пакет автоматизации будет переносимым. Кроме того, так будет проще удалить ваши объекты, если они устареют. Щелкните OK, чтобы загрузить форму шаблона.

Рис. 4. Создание Runbook Automation Activity Template.

Введите название Runbook Activity и установите флажок «Is Ready For Automation» (рис. 5). Этот флажок определяет, что будет происходить — просто создание заявки или автоматическое создание VM по этой заявке через набор заданий Orchestrator. Выберите в окне редактирования шаблона вкладку Runbook и проверьте корректность сопоставления параметров, которые вы видите в Orchestrator Runbook Designer.

Рис. 5. Укажите название вашей Runbook Activity и активизируйте автоматизацию

Этап 3. Создайте Service Request Template (шаблон заявки на услугу). Щелкните правой кнопкой Library | Templates, затем щелкните Create Template. Укажите имя шаблона и выберите класс Service Request (рис. 6). Затем свяжите шаблон с ранее созданным MP. Щелкните ОК, чтобы открыть форму шаблона.

Рис. 6. Создайте Service Request Template

Выберите в окне редактирования шаблона вкладку Activities. На ней потребуется связать операцию согласования с процессом автоматизации, определяемым набором заданий. Щелкните значок «плюс», чтобы добавить операцию и выберите Default Review Activity. Введите имя операции и настройте Approval Condition (условие согласования) и Reviewers (ответственные за согласование) (рис. 7).

Рис. 7. Введите название Review Activity и задайте Approval Condition и Reviewers

Щелкните OK, чтобы закрыть форму. Затем снова щелкните значок «плюс» и добавьте еще одну операцию. Этой операцией будет Runbook Automation Activity, созданная на этапе 2 (рис. 8). Поскольку эта операция уже настроена нами, можно щелкнуть OK, чтобы закрыть шаблон.

Рис. 8. Добавление второй операции в Service Request Template

Этап 4. Создайте Request Offering (информация по заявке). Щелкните правой кнопкой Library | Service Catalog | Request Offerings и выберите Create Request Offering. Информация по заявке — это информация, которую вы будете запрашивать у подающего заявку пользователя или предоставлять ему. Когда откроется окно ввода шаблона, укажите его имя и свяжите его с Service Request Template, созданным на этапе 3.

В последующих окнах мастера потребуется указать текст приглашений для пользователя (рис. 9) и сопоставить их параметрам набора заданий. Таким образом, мы определим вопросы, которые будут задаваться пользователю, когда он подает заявку, а ответы на эти вопросы будут направляться напрямую процессу автоматизации набора заданий. Когда вы будете готовы развернуть функциональность обработки заявок в производственной среде, измените статус Offering на Published.

Рис. 9. Задайте приглашения для ввода информации по заявке

Этап 5. Создайте Service Offering (информация по услуге). Во многом аналогично тому, как каталог содержит описания продаваемых товаров, Service Offerings содержит Service Request. Щелкните правой кнопкой Library | Service Catalog | Service Offerings и выберите Create Service Offering. Введите имя и MP, а затем добавьте Request Offering, созданный нами на этапе 4 (рис. 10). Как и в предыдущем случае, измените статус Offering на Published, когда будете готовы к развертыванию в производственной среде.

Рис. 10. Создайте Service Offering

Все эти конфигурации состыкуются между собой и будут доступны конечным пользователям, когда вы опубликуете свои Service Offering и Request Offering. При публикации они становятся доступными на Service Manager Self-Service Portal (портал самообслуживания для Service Manager). В результате у пользователей, которые хотели бы подать заявку, появляется место для документирования заявок. Два вопроса, которые мы определили ранее, будут заданы на этапе Provide Information (предоставьте информацию) операции (рис. 11). После отправки и согласования заявки процесс обработки заявки автоматически вызовет набор заданий Orchestrator, который сгенерирует новую VM.

Рис. 11. System Center Service Manager Self-Service Portal

Автоматизация, ограниченная только воображением

В нашей отрасли уже давно мечтали об автоматизации, ограниченной только нашим с вами воображением. В большинстве случаев это так и оставалось мечтой. Мы в определенной степени ограничены доступными нам технологиями. Это подтверждается и тем, что для осуществления мечты о полной автоматизации пришлось дождаться такого революционного и высокоразвитого продукта как System Center.

Чтобы в полной мери воспользоваться плодами такой автоматизации, сначала придется приложить немало усилий. Всякий раз, когда мы создаем очередной компонент, мы инвестируем в будущую автоматизацию. Начните это делать прямо сейчас, ведь то, что мы видим в System Center сегодня, — это то, что ожидают от вашей ИТ-среды в будущем.

Грэг Шилдс (Greg Shields) — носит звание MVP и является партнером в компании Concentrated Technology. Другие советы и подсказки Грега из рубрики «Компьютерщик на все руки» вы найдете на сайте ConcentratedTech.com.