Детали
проекта
- Настроили РСМ, которая визуально показывала текущее состояние здоровья всех ИТ систем на одном экране и позволяла видеть, падение каких сервисов может критично повлиять на доступность цифровых услуг, и правильно расставлять приоритеты в решении инцидентов.
- Клиент получил инструменты продвинутой визуализации. По графу зависимостей можно было настроить триггеры и объединять события.
Клиент исходил из необходимости проверки сверху ресурсно-сервисной модели от начала оказания услуг до работы самого сервиса, а не от слоя какой-то инфраструктуры. Связано это было с рядом технических причин, где часть сервисов находится на межфункциональном взаимодействии. Подключить новую систему оперативно там может не получиться, а проверка с помощью сценариев позволяла оперативно проверить работоспособность сервисов.
Там, где клиент мог подключить дополнительную инфраструктурную проверку с помощью мониторинга, он это делал, обогащал собственную РСМ и получал таким образом, помимо событий и оповещений, достаточно четкий результат в виде информации о месте сбоя, который можно было сразу на месте починить.
"
шаг 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 минут – инцидент официально регистрируется.
"
