Оставьте данные или свяжитесь с нами
Как обеспечить непрерывность работы цифровых сервисов и снизить затраты на управление ИТ?
Кейс внедрения ИТ-мониторинга Monq в ДИТ Москвы
клиент
mos.ru
масштаб
1+ млн
количество уникальных пользователей цифровых сервисов в сутки
О клиенте
150 000
среднее количество запросов на услуги в день
нагрузка
сложность
35
количество независимых бизнес-юнитов
объем
до 30 000
объем ежедневно обрабатываемых событий и триггеров в ИТ
Цели внедрения зонтичного мониторинга
Сократить время решения инцидентов
Обнаруживать сбои до того, как их заметят пользователи
Решить проблему разрозненности в командах поддержки и эксплуатации
Снизить «шум» от систем мониторинга и повысить эффективность
Получить инструмент real-time визуализации состояния ИТ-ландшафта
Контролировать выполнение SLA подрядчиками
Сократить затраты на ИТ-мониторинг
Создать автоматическую систему оповещения о внештатных ситуациях
Проблемы
эксплуатации
эксплуатации
Портал госуслуг, цифровые сервисы и ПО для сотрудников работали нестабильно
Внешние и внутренние пользователи жаловались на недоступность сервисов
ИТ-подразделение узнавало о проблемах от пользователей
Критические инциденты обрабатывались более 30 минут, иногда – до 1 часа
Большое число
жалоб о неработоспособности продуктов приходили в централизованный контакт-центр от жителей
жалоб о неработоспособности продуктов приходили в централизованный контакт-центр от жителей
Клиент эксплуатировал 100+ ИС, работал с 22 подрядчиками, а системы вручную мониторили 50 инженеров
Высокие затраты на мониторинг: у клиента был дорогостоящий контракт на малоэффективные ручные проверки
В случае обнаружения сбоя работа с инцидентом происходила вручную и занимала много времени
Много шума от систем мониторинга: только по одной ИС в день могли приходить несколько сотен оповещений
Было непонятно, какие алерты особенно важные и на какие нужно реагировать быстрее, а какими можно заняться позже
В каждом юните за состоянием систем следили инженеры, которые вручную сортировали события и принимали решения об их критичности
Подрядчик, обслуживающий ряд ИС, завышал SLA и не регистрировал инциденты
Результаты
внедрения Monq
Затраты снизились на 30% за счет автоматизации и снижения числа инженеров, занятых на обработке инцидентов.
Доступность сервисов выросла до 98.5% (на 1.2% с 97.3%).
на 30% меньше затрат на ИТ-поддержку
98.5% доступность
Маршрутизация инцидентов ускорена в 10 раз – с 25 минут до нескольких минут.
х10 выше скорость маршрутизации
Число сотрудников, занятых в процессах мониторинга, сократилось в два раза.
Вышли на новый уровень визуализации состояния ИТ – на РСМ отражаются и проблемы, и степень их влияния на сервисы.
всё состояние ИТ-окружения – на одной РСМ
х2 меньше сотрудников
Средняя скорость решения сбоя выросла с 30-60 минут до 15 минут.
Два из трех ситуационных центра реорганизовали из диспетчерских в рабочие группы продуктов.
реорганизация
2 из 3 ситуационных центров
2 из 3 ситуационных центров
х2 выше скорость работы над сбоями
Инциденты регистрируются и назначаются ответственным автоматически, рутинные операции автоматизированы.
автоматизация рутинных действий
Затраты на ИТ-мониторинг снижены в 20 раз за счет сокращения расходов на мониторинг пользовательских интерфейсов
На 64% снизили количество ложных срабатываний за счет умной логики обработки алертов.
в 20 раз меньше затрат на мониторинг
на 64% меньше ложных срабатываний
Клиент получил объективный инструмент контроля подрядчиков и перестал платить за невыполненные SLA.
Объем жалоб на недоступность снизился в 8 раз. ИТ начало реагировать на сбои до того, как их заметят пользователи.
контроль SLA и подрядчиков
в 8 раз меньше жалоб
Детали
проекта
проекта
- Настроили РСМ, которая визуально показывала текущее состояние здоровья всех ИТ систем на одном экране и позволяла видеть, падение каких сервисов может критично повлиять на доступность цифровых услуг, и правильно расставлять приоритеты в решении инцидентов.
- Клиент получил инструменты продвинутой визуализации. По графу зависимостей можно было настроить триггеры и объединять события.
Клиент исходил из необходимости проверки сверху ресурсно-сервисной модели от начала оказания услуг до работы самого сервиса, а не от слоя какой-то инфраструктуры. Связано это было с рядом технических причин, где часть сервисов находится на межфункциональном взаимодействии. Подключить новую систему оперативно там может не получиться, а проверка с помощью сценариев позволяла оперативно проверить работоспособность сервисов.
Там, где клиент мог подключить дополнительную инфраструктурную проверку с помощью мониторинга, он это делал, обогащал собственную РСМ и получал таким образом, помимо событий и оповещений, достаточно четкий результат в виде информации о месте сбоя, который можно было сразу на месте починить.
Там, где клиент мог подключить дополнительную инфраструктурную проверку с помощью мониторинга, он это делал, обогащал собственную РСМ и получал таким образом, помимо событий и оповещений, достаточно четкий результат в виде информации о месте сбоя, который можно было сразу на месте починить.
"
шаг 3
построили ресурсно-сервисную модель ИТ-окружения
Ресурно-сервисная модель (РСМ) – логическая модель сервиса, описывающая состав и взаимосвязи набора конфигурационных единиц. Предназначается для хранения и визуализации информации об объектах и сущностях, включая взаимосвязи ИТ-окружения.
Масштаб и зрелость продуктов клиента разная, процессы поддержки системы мониторинга сложные, на некоторых продуктах уже стояли подключенные системы. Ко всему этому еще прибавлялось сопротивление системных администраторов, которые хотели использовать только свои закрытые контуры. Клиент провел стандартизацию процессов мониторинга, однако саму эксплуатацию полностью передали в локальные команды. Между смежными командами, наконец, появилась эффективная коллаборация. Это был очень важный шаг.
"
шаг 2
подключили к Monq необходимые источники данных и автоматизировали их обработку
Зонтичный мониторинг – это подход, при котором весь комплекс приложений и инфраструктуры охватывается одним централизованным инструментом для получения комплексного представления об ИТ в связке с бизнес-сервисами и ИТ-услугами. Централизация позволяет эффективно отслеживать и устранять проблемы в приложениях, инфраструктуре и сервисах.
- Подключили к зонтику Monq все системы мониторинга клиента.
- Создали единый экран контроля состояния всех систем: к Monq подключили практически все крупные городские сервисы.
- Система начала обрабатывать в сутки до 30 000 событий и триггеров.
- Создали единый экран работы с инцидентами.
- Настроили автокластеризацию и дедупликацию событий: Monq автоматически начал группировку событий, назначение важности в зависимости от потенциального уровня угрозы от сбоя.
- Настроили автоэскалацию событий, их автоматическую регистрацию в ITSM, оповещение ответственных команд, подсказки для инженеров по разрешению проблем.
- Интеграция с ITSM позволила многократно увеличить количество создаваемых инцидентов. Раньше на создание одного инцидента уходило примерно 20 минут времени одного сотрудника ситуационного центра. Чтобы отрабатывать такие же объемы, как это делает Monq, клиенту понадобилось бы одновременно работающих 10 сотрудников в день.
До внедрения Monq затраты на мониторинг были высокими, а эффективность – низкая из-за сложностей в координации всех разрозненных процессов и человеческого фактора. Один из подрядчиков клиента вручную проверял большое число интерфейсов и сервисов. Речь шла о 80 информационных системах, которые нужно было проверять по пяти сценариями. Это давало в общей сложности 400 сценариев для обработки, которые проверяли в день минимум 10 раз. В сумме ежедневно проводилось 4 000 ручных проверок. На каждую проверку уходило минимум 20 минут, и при обнаружении проблемы регистрация инцидента и работы с ним тоже происходила вручную. Время инженеров использовалось неэффективно.
"
шаг 1
настроили синтетический мониторинг
Синтетический мониторинг позволяет создавать и автоматизированно выполнять сценарии и тесты, имитирующие действия реальных пользователей. Результаты тестов анализируются, выявляя возможные проблемы и узкие места в инфраструктуре и приложениях до того, как они начнут массово влиять на конечных пользователей.
Клиент перестал зависеть от воли подрядчика и его нежелания регистрировать часть инцидентов ночью.
"
- Подключили к Monq cвязку Zabbix+Jenkins+Selenium+Allure.
- Подключили к Monq 87 информационных систем клиента.
- Заменили ручные проверки автоматическим синтетическим тестированием: в среднем 3-7 тестов по 10 шагов на каждую систему.
- Настроили более 7 000 метрик и более 2600 триггеров.
- Cначала клиент поставил на мониторинг функционирования простые системы, внешние порталы, простые внутренние системы, например, «Инвестпортал города Москвы» или сервис «Узнай Москву», где в сценарии были простые авторизации, проверка доступности контента, поиск кнопок, проверка сервисов подписок и т.д.
- Потом – системы с более сложной логикой. Например, в государственных услугах для ЮЛ нужна ЭЦП, а для проверки корректности отработки функции генерации отчета надо было посмотреть на состав документа Word.
шаг 5
настроили автопостроение отчетов SLA
Отчеты о доступности строятся в платформе автоматически, при этом позволяют учитывать, например, сервисные режимы. Объективная картина состояния ИТ окружения позволяет эффективнее управлять внутренними и внешними исполнителями.
- Monq позволил прописать в условиях обслуживания систем время реагирования на сбои, а также автоматически считать недоступность и другие показатели.
- Все инциденты сразу начали регистрироваться на нужного подрядчика или субподрядчика (над некоторыми проектами работают до 10 команд). Уведомления начали приходить именно нужным исполнителям.
- Система начала строить отчеты SLA по доступности каждой из услуг. Проставление со стороны ситуационного центра тегов к событиям и возможность не учитывать периоды сервисного обслуживания систем позволила получать объективную картину расчетов и проводить анализ.
- Monq начала обнаруживать и фиксировать проблемы и запускать скрипты автохилинга и моментально оповещать ответственные команды об инцидентах.
- Все инциденты начали регистрироваться в ITSM, все данные о них – обновляться автоматически.
- Клиент как оператор системы сам определил список ответственных лиц, кому должны были оповещения — подрядчикам, непосредственно отвечающим за систему, ответственным со стороны ДИТа, и всем тем, кому нужно быть в курсе, что что-то не так. Использовали различные виды оповещений — на электронную почту и в мессенджеры.
- Настроили критичность оповещений: ввели четыре вида оповещений, от высокого до низкого приоритета и с разным уровнем ответственности. В самом оповещении есть информация о приоритете.
- Запустили автоматизацию Monq на уровне автоисполнения скриптов с поддержкой bash и rest внутри, которые снижают рутину в работе системных администраторов.
- Ввели отраслевой стандарт: подключили 26 Zabbix-серверов.
шаг 4
Скрипты автохилинга в Monq повышают эффективность работы системных администраторов и позволяют автоматически решать некоторые типовые проблемы эксплуатации. Эскалация событий в платформе – максимально гибкая и настраивается любым образом, удобным заказчику.
настроили автохилиг и автоэскалацию событий
Настройка оповещений в платформе гибкая: если, например, сбой длится 5 минут – оповещение по почте, если больше 5 минут – отправляем сообщение, если больше 10 минут – инцидент официально регистрируется.
"