Автоматизация и самообслуживание незаметно, но прочно вошли в нашу жизнь, хотя мы даже не задумываемся об этом. Мы самостоятельно покупаем товары на eBay вместо того, чтобы общаться с продавцом в магазине, заказываем билеты в кино через мобильное приложение и проводим множество других операций, которые в «старом добром доцифровом мире» потребовали бы вовлечения множества людей, ресурсов и времени.

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

Интеграция между мониторингом и ITSM

Простейшим (и тем не менее не так часто используемым) вариантом автоматизации является интеграция между решениями мониторинга и ITSM.

Отступление 1 (терминологическое)

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

ITSM-система — это инструмент для ведения всех IT и не только IT-процессов стандартизированным способом. Грубо говоря, ITSM помогает описать процесс от начала и до конца, т.е. имея точку входа — мы знаем точно к какому (им) результату придем.

Примеры процессов:

• Управление инцидентами
• Управление проблемами
• Управление изменениями
• Управление конфигурациями
• Управление проектами
• …
• Управление кадрами
• Custom-процесс

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

Отступление 2 (лирическое)

Пример:
У вашего заказчика в дата-центре на одном из серверов не выполнился бэкап приложения/базы данных/любимого фильма важного отчета. В системе мониторинга появилось событие об этом. Если интеграции с ITSM нет, то это событие ответственный инженер увидит только в консоли (или может быть в почте, опять же если настроена пересылка на почту). Потом нужно потратить время на то, чтобы данное событие зарегистрировать в ITSM и приступить к решению инцидента.

Впрочем, интеграция мониторинга и ITSM, пожалуй, тема для отдельной статьи (если интересно — пишите в комментариях). Сегодня же мы представляем другой пример интеграции систем, а именно создание портала самообслуживания на примере интеграции системы управления и автоматизации (в качестве которой выступит Microsoft System Center Configuration Manager) и системы ITSM.

Отступление 3 (и опять терминология)

Система управления конфигурациями и автоматизации — это инструмент, позволяющий выполнять управление инфраструктурой, выполняя задачи, такие как:

• инвентаризация аппаратного и программного обеспечения;
• развертывание операционных систем;
• развертывание приложений;
• управление обновлениями;
• удаленное управление;
• наполнение базы данных информацией о конфигурационных единицах;
• проверка соответствия систем политикам и наборам условий.

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

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

Одной из самых часто встречающихся задач в поддержке инфраструктур любого уровня, от офиса на 10 пользователей до «кровавого энтерпрайза», является задача по установке различного ПО на системы пользователей. И если в маленьком офисе «человек с флешкой» успешно справляется сам, то с ростом количества пользователей сначала появляется необходимость в системе управления конфигурациями, а потом и вовсе выясняется, что процесс установки ПО занимает бОльшую часть рабочего времени, и при этом затягивается на многие дни.

Что же происходит?

Рассмотрим обычную схему установки ПО в некотором круглом офисе в вакууме (а в реальности может быть еще хуже), на примере установки, скажем, программы обработки цифровых изображений «Фотолавка».

1. Пользователь, которому необходима «Фотолавка», запрашивает его установку.
2. Для упрощения допустим, что запрос формализован в ITSM-системе и система автоматически отправляет запрос в нужную группу (что на практике далеко не всегда так).
3. Получив запрос, инженер поддержки запрашивает у ответственных лиц разрешение на установку. Но инженер занят и запрашивает только на следующий день.
4. Ответственные лица были очень заняты, и на согласование ушло 2 дня.
5. Запрос согласован, и теперь необходимо понять, есть ли в наличии нужные лицензии. Но задач у инженера много, и он отложил это на завтра. Еще минус один день.
6. Наконец инженер проверил лицензии и приступил к установке. Чтобы убедиться, что установка прошла как надо, наш инженер выполняет следующие шаги:

• проверка пререквизитов;
• собственно установка;
• проверка результата установки.

И на все это уходит еще несколько часов. Итого задача установки заняла несколько рабочих дней. Знакомая ситуация?

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

1. Пользователь на портале ITSM-системы нажимает кнопку «Установить» у выбранного приложения.
2. ITSM-система автоматически поднимает запрос на подтверждение установки у ответственного лица (а в случае приложений, заранее одобренных к установке, сразу переходит к шагу 4).
3. Ответственное лицо в командировке, но благодаря мобильному клиенту ITSM-системы видит запрос вовремя и одобряет установку.
4. Система автоматически проверяет наличие лицензий, пре-реквизиты для установки и запускает установку софта.
5. Админ на минутку отвлекается от чтения (ну, вы поняли) и проверяет, что установка завершилась успешно.

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

Бенефиты:

• Автоматизация рутинных задач;
• Мониторинг процесса установки;
• Автоматическое поднятие инцидента в случае ошибок;
• Стандартизация установки приложений;
• Процесс работает даже вне офисного времени.

Рассмотрим, процесс разработки портала на примере одного из наших заказчиков.

Инфраструктура заказчика содержит более 10000 клиентских машин, 4000 серверов, поэтому количество запросов на установку ПО было огромным, и порой парализовало работу совсем не маленькой группы поддержки.

Заказчик использовал для ITSM-систему ServiceNow для ITIL-процессов и MS SCCM для удаленной установки приложений. Решено было интегрировать эти две системы для создания self-service портала на основе ServieNow.

Этап 1. Анализ данных

Был организован workshop meeting, где были собран заинтересованный круг лиц (stakeholders) для обсуждения этого проекта

В итоге было принято решение об изменении существующего workflow:

• Без изменения формы запроса.
• Исключить из процесса приложения, требующего лицензии. Об этом подробнее расписано ниже.
• Исключить из процесса тонкие клиенты в связи с тем, что доступ к приложениям управляется через политики Citrix.
• Исключить из процесса приложения, которые не являются пакетами.
• Был рассмотрен и согласован список приложений, которые будут использованы для автоматической установки.
• Процесс одобрений остается без изменений.

Отступление 4 (Что такое пакет, с точки зрения системы управления приложениями)

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

Этап 2. Разработка

Для обеспечения полноценной интеграцией одним из важных требований является актуальность данных в CMDB. Это основная задача процесса Asset management, но так как мы являемся командой, нацеленной на автоматизацию всего, что движется, то мы выполнили интеграцию CMDB SCCM и Service Now путем периодической загрузки данных.

Немного поподробнее:
Microsoft System Center Configuration Manager (SCCM) интегрируется с CMDB ServiceNow через односторонний импорт данных из SCCM. Импорт данных по расписанию выгружает соответствующие данные из таблиц SCCM в CMDB и сопоставляет их с экземпляром ServiceNow. Возможен перенос всех данных из выбранных таблиц, либо только данных, в которых произошли изменения. Подключение к базе данных и выгрузка достигается с помощью JDBC-коннектора, который установлен на MID-сервере.

Периодическое расписание в базе данных SQL импортирует данные SCCM Microsoft в таблицу SCCM Computer Identity [imp_sccm_computer_identity]. Это настраиваемый параметр в ServiceNow. В этой таблице производится объединение данных из различных представлений базы данных SCCM.

Вот список таблиц, из которых импортируются данные:

• v_GS_COMPUTER_SYSTEM
• v_GS_SYSTEM
• v_GS_OPERATING_SYSTEM
• v_GS_SYSTEM_ENCLOSURE
• v_GS_WORKSTATION_STATUS
• v_GS_PC_BIOS
• v_GS_COMPUTER_SYSTEM_PRODUCT
• v_GS_BASEBOARD

ServiceNow по расписанию импортирует данные из этих таблиц в таблицу Computer Identity. Все данные должны быть загружены в эту таблицу в первую очередь, т.к. очень важно определить принадлежность полученной конфигурационной единицы (КЕ). Другими словами, основываясь на имени, серийном номере, модели и т.д., логика преобразования или создаст новую КЕ, если ее не существует, или обновит существующую, если она уже есть в CMDB.

После импортирования данных в Computer Identity, ServiceNow производит импорт следующих данных по расписанию из базы данных SCCM:

• Операционная система: версия, установленный сервис пак.
• Процессор: количество процессоров, ядер, потоков, частота, разрядность, производитель.
• Дисковая подсистема: количество и тип дисков, описание, id, размер диска.
• Сеть: mac-адрес, имя, ip-адрес, сетевая маска, шлюз по умолчанию.
• Программное обеспечение: установленное ПО.

Со стороны MS SCCM необходимо было создать или использовать существующую коллекцию установки приложения. Команда поддержки MS SCCM рассмотрела список приложений и предоставила Collection ID для каждого приложения. Эта информация была загружена в CMDB Service Now.

Так же команда написала 2 PowerShell скрипта, которые:

• добавляли приложение в коллекцию;
• получали статус установки приложения в коллекции.

Суть скриптов достаточно проста. На системе, где установлена служба MID, расположены скрипты, которые выполняют определенный SQL-запрос в базу SCCM. Mid-сервер, в свою очередь, запущен из служебной учетной записи, которая имеет доступ.

Форма запроса не была изменена и осталась в первозданном виде



Пользователь заполняет:

1. Для кого запрашивается приложение. Это поле автоматически заполняется текущим пользователем и может быть вручную изменено.
2. Желаемое время исполнения.
3. Компьютер, на который требуется установить приложение. Это поле автоматически заполняется компьютером из CMDB, назначенного пользователя из пункта 1. В случае нескольких компьютеров, может быть выбран вручную другой.
4. Приложение. Для запроса нескольких приложений, необходимо создать отдельный запрос (1 приложение = 1 запрос).
5. И несколько дополнительных полей, полезных для менеджеров для решения одобрения установки.

После запроса создаются Approval-задачи для менеджеров согласно процессу одобрений компании.

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

Авторы: vkuptsov, siaint