Создание портала самообслуживания IT на примере интеграции MS SCCM и ServiceNow. Часть 2

в 10:59, , рубрики: Help Desk Software, itsm, MS SCCM, service desk, servicenow, Блог компании ICL Services, интеграция, самооблуживание, управление проектами, управление разработкой

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

image

После положительного результата происходит проверка запрошенного приложения и компьютера на предмет возможности автоматической установки:

  • имеется ли Collection ID в CMDB?
  • является ли компьютер thin client?

Процесс автоматического развертывания программного обеспечения (Automated Software deployment workflow):

image
Разберем диаграмму по этапам, начиная от блока Start, заканчивая End.

1) Проставляем соответствующий — понятный для Service Desk агента и пользователю статус запроса. В нашем случае Work in Progress

2) Во избежание параллельного изменения записи добавлен таймер отладки, так как помимо workflow работают Business rule.

3) Происходит запуск скрипта на mid server, Service Now передает в скрипт следующие переменные:
var script = C:\Scripts\add.ps1 '+ current.variables.u_computer.name +" "+ current.variables.u_software.u_install_id;

  • Имя компьютера
  • Collection ID

Скрипт добавляет компьютер в коллекцию установки приложения и сразу же получает ответ Success (Yes) или Failed (No).

Вот живой пример

4) Дадим время SCCM для установки приложения, скажем 4 часа. Что происходит в это время:

a. SCCM клиент на компьютере периодически запрашивает с сервера политики.
b. Получает данные о назначенном для установки приложении.
c. Инициирует процесс скачивания с точки распространения.
d. Запускает установку приложения и возвращает статус установки.

image

image

image

image

5) Запускается второй скрипт, с теми же параметрами, но результатом является статус установки. Если Successfully installed, то конец workflow

6) Проверяет статус установки, если Failed, то переходит в пункт 9.

7) Проверяет статус установки, если Reboot pending, то переходит в пункт 10.

8) Глобальный таймаут процесса, во избежание цикла.

9) Создает задачу на группу поддержки Service Now для решения ошибки или задержки установки. По закрытию задачи запускается процесс с начала, с пункта 3, но вместо добавления в коллекцию, проверяет наличие компьютера в коллекции.

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

Этап 3. Постимплементация

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

image

Были найдены несколько ошибок и пробелов, которые устранены;

  • неверные Collection ID: закрались пробелы и неправильные символы во время импорта, исправили.
  • неверное имя компьютера: Аккуратность CMDB — компы были созданы вручную с неверным именем. Исправлены по мере появления ошибок.

После исправления, картина получилась такая

image

В итоге, основной массой не установленного приложения являлось банальное отсутствие компьютера в сети по разным причинам или просто компьютер был выключен. Так же многие пользователи работают через vpn и имеют ограничения на скачивание и установку пакетов, в целях сохранения пропускной способности канала.

Этап 4. Тюнинг

После успешной имплементации идет тюнинг процесса, добавляется функционал по:

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

Сама концепция точно такая же, как и установка приложения.

Ну и в качестве заключения несколько слов о встреченных проблемах и необходимых зависимостях.

Проблемы:

  1. Так как ServiceNow облачная система, а инфраструктура заказчика обычно закрыта от внешних подключений, необходимо установить MID-server ServiceNow (или его аналог для других ITSM-систем)
  2. Способ проверки результата: не все системы автоматизации позволяют получать результат установки приложения через API. В самых нетривиальных случаях потребуется доступ к базе данных.
  3. Не все приложения устанавливаются одним инструментом.
  4. Компьютеры могут быть подключены через VPN/Home Office, при этом SCCM не всегда имеет доступ к агенту, установленному на компьютере. Но это чисто сетевая проблема и должна решаться другими инструментами.

Зависимости:
Для точного определения конечной машины, CMDB должен быть в актуальном состоянии. Но автоматическое наполнение CMDB – это уже совсем другая задача…

Авторы: vkuptsov, siaint, shamseg

Автор: ICLServices

Источник

Поделиться

* - обязательные к заполнению поля