Как «Инфосистемы Джет» совместно с заказчиком улучшила управление инцидентами
В начале 2024 года наша компания «Инфосистемы Джет» стала сервисным партнером крупного автомобильного дилера. На этапе transition-периода заказчиком была поставлена задача по трансформации некоторых процессов, в частности реорганизации процесса обработки ИТ-инцидентов системы мониторинга. Дежурные инженеры периодически сами отслеживали события в системе мониторинга и вручную заводили заявки в сервис-деске. При этом в сервис-деске отсутствовали инструменты отчетности и автоматической приоритизации заявок. Такие ограничения системы не позволяли своевременно и независимо от человека реагировать на инциденты, получать аналитику и улучшать качество сервиса. Проанализировав все технические вводные и требования, мы совместно с заказчиком проработали и реализовали несколько решений. Как результат — нагрузка на систему сократилась на 50%, а время реакции — с 20 минут до 5. Рассказываем, как мы этого добились.
Содержание |
 | Михаил Волотов, Директор центра компетенций мониторинга «Инфосистемы Джет». |
Комплексное решение
В разработке решения наша команда опиралась на требование клиента — он хотел работать в своей системе сервис-деска. Мы же, как крупная ИТ-компания с большим количеством заказчиков, используем свой сервис-деск, где есть много полезных функций. Это позволяет строить отчетность, проводить аналитику, задействовать систему машинного обучения в маршрутизации заявок, помогать заказчику в решении инцидентов, а также быстро выделять профильного специалиста при возникновении проблем. Поэтому совместно было принято решение интегрировать два сервис-деска с соблюдением ряда условий:
- интеграция не должна привести к снижению качества оказываемых услуг;
- решение должно быть зарезервировано;
- расхождение между данными двух систем не должно превышать более 10 с;
- сопровождение интеграции полностью осуществлялось нами.
В случае нарушения любого из условий внедрение и дальнейшее использование решения прекращалось.
Реализация такой интеграции была выгодна обеим сторонам. Заказчик получал возможность более детальной аналитики, а также снижение времени реакции на обращения. А мы могли больше не тратить время на обучение своих специалистов системе клиента.
Однако этого оказалось недостаточно — мы увидели несколько причин, почему нам стоит оптимизировать еще и мониторинг. Во-первых, мониторинговая система заказчика не покрывала всей инфраструктуры. Во-вторых, выстроенная модель здоровья генерировала слишком большое количество событий, включая дублирующие. Наконец, в качестве системы оповещения использовался платный SMS-шлюз, что увеличивало затраты клиента из-за событий-дублей.
Такая ситуация требовала дополнительного решения. В итоге мы продумали и реализовали полную автоматизацию процесса создания и управления заявками системы мониторинга, а также интегрировали ее с сервис-деском.
Интеграция сервис-десков
Для начала мы проанализировали сервис-деск клиента, который работал на базе Open source-платформы OTRS. Наша команда работала с ней в рамках другого проекта, поэтому знали, что функционал системы можно расширить с помощью собственных плагинов (далее мы будем их называть «сервисы», как это принято в терминологии продукта). Изучив конфигурацию и используемый заказчиком функционал, мы создали веб-сервис для OTRS.
| Веб-сервис по сути представляет собой набор скриптов для управления состоянием компонентов OTRS (заявки, отчеты, очереди). Его можно настраивать либо в веб-интерфейсе самой OTRS, либо импортировать готовый YAML-файл с конфигурацией. Это самый простой случай, когда сервис будет использовать функционал, уже реализованный разработчиками сервис-деска. Если нужно реализовать более сложную логику, то тут одним YAML-файлом уже не обойтись. | ||
Первым шагом мы разработали словарь, который сопоставлял направления в обеих системах, что было необходимо для правильной маршрутизации тикетов. Затем создали словарь с другими параметрами заявок: критичность, системы, классификация события (авария, инцидент, запрос на обслуживание).
После словарей мы продумали и реализовали автоматическую маршрутизацию заявок. Теперь при создании тикета в системе заказчика у нас также создавался связанный тикет со всей информацией о событии. Помимо этого, в тикет поступали данные о его состоянии, он перемещался между направлениями внутри нашего сервис-деска вместе с тикетом в системе клиента.
Однако без обратной интеграции нашего сервис-деска с системой заказчика мы все еще использовали OTRS для закрытия заявок, изменения их статуса и общения с заказчиком. Поэтому следующим шагом стала двусторонняя интеграция. Опираясь на свою экспертизу в OTRS, мы разработали внешний модуль уже для нашего сервис-деска, который управлял нашими тикетами в сервис-деске заказчика.
Такая двухсторонняя интеграция позволила нашим инженерам работать в привычной системе и пользоваться всеми ее преимуществами, а клиенту — работать в своем сервис-деске. Это решение помогло автоматизировать передачу данных о заявках, упросить работу первой и второй линий поддержки, причем с помощью привычных инструментов для заказчика и нас.
Автоматизация управления инцидентами
Синхронизировав заявки, мы переключились на мониторинг заказчика, реализованный на базе Zabbix. Последующими шагами наша команда оптимизировала нагрузку на дежурную смену и избавилась от некорректно или не вовремя заведенных тикетов, так как это делалось полностью вручную. Проанализировав технические данные, мы реализовали сервис интеграции между сервис-деском и системой мониторинга. В качестве языка программирования выбрали Go для упрощения дальнейшей поддержки on-site у заказчика на случай, если у клиента будут отсутствовать доступы к репозиториям. Сервис стал посредником между системой мониторинга и сервис-деском заказчика. В сервисе мы предусмотрели следующий функционал:
- Прием и обработка алертов. Сервис получал уведомления от Zabbix, обогащал их необходимой информацией и создавал тикеты в сервис-деске заказчика;
- Очередь сообщений. Поскольку мониторинг при массовой аварии генерирует сотни или даже тысячи алертов, такой поток данных может запросто вывести из строя сервис-деск. Поэтому в нашей реализации мы предусмотрели эту вероятность и установили лимит на количество создаваемых тикетов в минуту. Помимо описанного, в дальнейшем очередь сообщений может быть использована для корреляции событий на основе тегов системы мониторинга;
- Self-мониторинг системы. Нам необходимо знать, что наш модуль работает и мы не пропустим оповещения;
- Отслеживание спамеров. Некорректно настроенный триггер порождает огромное количество уведомлений/тикетов. В итоге инженеры тонут в однотипных обращениях, бизнес платит за услуги СМС-провайдера, руководители переживают за состояния сервисов. При этом резко падает один из самых важных показателей работы: доверие к мониторингу. Поэтому в интеграции мы заложили механизм, который отслеживает такие события, автоматически выключает оповещения для виновника и заводит тикет для диагностики случившегося.
Настройка Zabbix
Заключительным этапом стала работа с самим мониторингом. Мы провели аудит всей системы заказчика, моделей здоровья, правил оповещения, эскалации задач и скорректировали некоторые настройки. Помимо этого, использовали функционал по автоматическому назначению ряда событий сразу на корректные группы второй линии поддержки. Таким образом наша команда снизила количество генерируемых инцидентов, избавилась от спама и некорректно работающих/неработающих метрик.
Чего мы достигли?
Нам удалось соблюсти требование заказчика. При этом в результате разработки и внедрения комплекса решений мы увеличили прозрачность предоставления услуг. Наш клиент в любой момент видит статус по инциденту и что происходит.
Благодаря автоматизации процесса создания тикетов снизились трудозатраты наших инженеров и дежурной службы, а также сократилось время реакции с 15–20 до 5 минут. Сократилось время на маршрутизацию тикетов — она стала происходить в автоматическом режиме. Аудит системы мониторинга увеличил качество самой услуги и сократил количество алертов в сутки с 1000–1200 до 40–60. В итоге нагрузка на систему уменьшилась более чем на 50%.
