Привет, Хабр! Продолжаем рассказывать о собственных кейсах, задачах, проблемах и способах их решения. Сегодня поговорим о платформе ServiceNow и о том, как мы с ее помощью управляем инцидентами.
ServiceNow — это практически универсальный комбайн, который может пригодиться многим компаниям любого масштаба. Наверное, проще перечислить, что платформа не умеет, чем то, что она способна делать, поскольку возможности ServiceNow очень обширные. ServiceNow — это PaaS, который позволяет автоматизировать большинство ITSM-процессов, включая Help Desk, мониторинг сервисов, управление их доступностью, управление поставщиками, изменениями, конфигурациями, инфраструктурой и, конечно, инцидентами и событиями. Это первая статья из цикла материалов о ServiceNow, надеемся, наш опыт пригодится читателям Хабра. Приступим.
Немного о платформе
Servicenow предоставляет большое количество возможностей, которые можно кастомизировать под свои требования. В первую очередь это:
CMDB.
Управление инцидентами.
Управление событиями.
Управление проблемами.
Мониторинг сервисов и управление запросами.
Управление изменениями и мониторинг изменений.
Почему мы ее выбрали? Причин несколько:
Управление не только ITSM-процессами, но и бизнес-процессами.
PaaS, т. е. нам не нужно поддерживать само решение.
Возможность кастомизации интерфейса и логики под наши требования,
Ориентирование на высокие нагрузки.
Надежность (uptime около 99,95%).
Наличие веб-интерфейса и мобильного приложения.
Интеграцию с большим количеством других платформ и сервисов.
Есть большой маркетплейс приложений.
Есть возможность использовать решения со встроенными нейронными сетями и AI (правда, до этого мы пока так и не дошли).
Зачем нам эта платформа
На момент выбора ServiceNow у нас уже было несколько подходов к реализации собственных продуктов, с помощью которых мы пытались решить вопросы CMDB, автоматизации управления инцидентами и других ITSM-процессов. Но все они требовали ресурсов на разработку и поддержку и все равно не успевали за нашими растущими потребностями. Также мы рассматривали другие решения, но все они не удовлетворяли нашим требованиям по:
функциональности,
возможности кастомизации,
стоимости,
поддержке,
минимуму собственных ресурсов на обслуживание инфраструктуры решения.
На одной из конференций мы заметили стенд ServiceNow. Пообщались, познакомились, попробовали, нам понравилось. ServiceNow позволял нам решать широкий спектр задач, привлекая минимум собственных ресурсов. Мы решили использовать его.
Что и как мы делали
Когда мы окончательно решились на внедрение ServiceNow, стало ясно, что интегрировать с платформой придется всю инфраструктуру Quadcode. Ну а чтобы не распылять усилия, действовали пошагово.
В первой итерации решили внедрять:
Процесс управления инцидентами (Incident Management).
Процесс управления событиями (Event Management).
Звучит просто, но «под капотом» было очень много работы.
Сперва нужно было организовать доступ к платформе для всех сотрудников (у нас в группе компаний больше 700 человек). Для удобства мы интегрировали ServiceNow с Google SSO и Active Directory, что упростило задачу идентификации пользователей.
Далее мы взялись за CMDB, чтобы выстроить связи между элементами нашей инфраструктуры. Для этого мы интегрировали ServiceNow с внутренними системами инвентаризации, наполнили ее данными, выстроили связи, настроили регулярную синхронизацию. Да, в ServiceNow есть модуль Discovery, который самостоятельно находит новые элементы (железо, хосты и т. д.), определяет связи между ними, но мы пока его не используем из-за ограничений наших внутренних процессов по вводу в эксплуатацию нового оборудования.
Когда фундамент был готов, мы приступили к "реальной работе".
Начали с управления событиями. В этот модуль мы отправили практически все алерты, включая алерты от серверов, контейнеров и приложений. Почему алерты? Модуль управления событиями отлично с ними работает: группирует, схлопывает, привязывает к конкретным элементам CMDB для дальнейшей обработки в других процессах.
Затем мы добавили автоматизации, связав управление событиями с управлением инцидентами. Так нам удалось добиться того, что при поступлении критического алерта по нему автоматически заводится инцидент. Если приходит «нормальный» алерт, свидетельствующий о восстановлении, инцидент автоматически резолвится — участие человека не требуется. Хотя нет: человек может понадобиться для того, чтобы очистить место на сервере.
Хочу отметить важный нюанс. Мы брали функционал «из коробки» и адаптировали к собственным требованиям и текущим реалиям. В частности, поправили назначение приоритетов, добавили дополнительные интеграции с внешними системами, ввели новые сущности и т. д.
Немного про интеграции
В качестве первого примера можно взять Slack, где мы захотели получать уведомления об инцидентах. Но это не всё.
Мы все не любим, когда нас отвлекают от работы, не любим сложные интерфейсы и особенно не любим бюрократию. А ITSM — это все-таки про нее. Учитывая это, мы задумались, как нам сделать так, чтобы взаимодействие сотрудников с процессом не вызвало боль и отторжение и проходило в наиболее дружелюбной манере.
Проблема в том, что при получении уведомления, человеку нужно было переходить в интерфейс ServiceNow для изучения деталей или добавления комментариев. Что само по себе вызывало боль и было неудобно.
Мы решили сделать Slack интерфейсом к ServiceNow. К сожалению, существующие плагины из маркетплейса ServiceNow не позволяли нам решить эту задачу. Поэтому мы сделали свой.
Что мы там сделали:
Отправку уведомлений о новых инцидентах в канал Slack.
Отправку обновлений по инциденту в тред основного уведомления.
Подписку на обновления по инциденту.
Уведомления в каналы ответственных команд о назначении на инцидент.
Регистрацию нового инцидента из любого сообщения в Slack.
Добавление комментариев к инциденту через Slack.
Автоматические эскалации.
Так мы связали мессенджер с ServiceNow.
Теперь работать с инцидентами можно как через веб-интерфейс (он, кстати, в ServiceNow называется ServicePortal), так и через Slack. После регистрации нового инцидента в канал в Slack приходит нотификация с кнопкой подписки на обновление инцидента.
После подписки, в случае если статус инцидента будет меняться или инцидент будет наполняться информацией, в личку в Slack будут приходить соответствующие уведомления от бота, которого мы написали сами. У каждого подобного сообщения есть кнопка для отписки от уведомлений. Для облегчения работы с инцидентами владельцу инцидента приходят специальные нотификации (например, уведомления о назначении владельцем инцидента). В таких сообщениях есть кнопки, например: «Подтверждение начала работы над инцидентом», «Разрешение (resolve) инцидента».
Для облегчения регистрации инцидента мы добавили возможность его заведения через Slack простым кликом по любому сообщению в любом канале. После заведения можно выставить приоритет, статус и добавить другие детали.
Дальше нам нужно было научиться трекать задачи, привязанные к инцидентам.
Бывают ситуации, когда для решения инцидента необходимо выполнить какую-либо большую задачу, а не просто передеплоить сервис. Чтобы меньше отвлекаться на оформление инцидента, мы интегрировались с нашим таск-трекером TargetProcess.
В итоге мы сделали следующее:
В ServiceNow появилась возможность привязать к инциденту задачу из таск-трекера.
ServiceNow сам регулярно проверяет, изменился ли статус у привязанной задачи, и когда задача переходит в статус Done — инцидент резолвится автоматически, без участия человека, с отправкой всех необходимых уведомлений.
Естественно, в ServiceNow существует возможность просмотреть список всех инцидентов, их статус, привязку к пользователям и другие отчеты в различных разрезах. Всё это доступно через ServicePortal.
В целом управление инцидентами и событиями у нас автоматизировано, что, по нашему мнению, оказалось очень удобно для всех — и сотрудников, и компании.
Что дальше
Мы продолжаем автоматизировать наши IT-процессы. В следующих статьях расскажем, как мы автоматизировали в ServiceNow такой процесс, как контроль за изменениями в инфраструктуре (Change management).
Процесс контроля за изменениями — неотъемлемая часть ITSM, ведь подавляющему большинству компаний необходимо знать обо всех проводимых работах. Важно это и для нас, потому что у нас большая распределенная инфраструктура, много команд разработки и микросервисов. И каждый день в прод выкатывается большое количество фич. Поэтому, чтобы добавить прозрачности в этот процесс, мы интегрировали ServiceNow со всеми деплоями и пайплайнами команд, которые есть в нашей компании.
А еще мы собираемся прокачивать мониторинг, изучаем возможность отправки в ServiceNow не только алертов, но и «голых» метрик. Это поможет обнаруживать аномалии и паттерны, которые иначе обнаружить никак нельзя.
Вывод
Всё, что указано выше, — знакомство с платформой ServiceNow. В будущем мы хотим показать ее изнутри, рассказав о том, что она может и какую пользу от этого можно получить. Если у вас есть вопросы по теме первой статьи — задавайте, с удовольствием на них ответим. Ну а мы пока готовим вторую часть — более подробный рассказ о том, как мы делали интеграцию с Slack. Не переключайтесь.
