Пилотный проект с Тинькофф: как мы настраивали зонтичный мониторинг для одного из крупнейших банков России
Весной этого года команда MONQ Digital Lab реализовала пилотный проект для банка Тинькофф.
Мы внедряли систему зонтичного мониторинга, который нужен для сложных для сложных IT-инфраструктур.
Кейс Тинькофф показывает, зачем «зонтик» нужен банкам, какие «боли» позволит решить и как его настроить «под себя». И как запросы клиента позволяют нам доработать продукт.
Мы внедряем MONQ (в том числе в качестве пилотов) в разных отраслях — в госсекторе, в авиации, в банках, в телеком-компаниях и т. д.
Конечные цели мониторинга могут быть разные. У банков, например, это:
Кейс Тинькофф показывает, зачем «зонтик» нужен банкам, какие «боли» позволит решить и как его настроить «под себя». И как запросы клиента позволяют нам доработать продукт.
Мы внедряем MONQ (в том числе в качестве пилотов) в разных отраслях — в госсекторе, в авиации, в банках, в телеком-компаниях и т. д.
Конечные цели мониторинга могут быть разные. У банков, например, это:
бесперебойная работа мобильных приложений
бесперебойная работа сайтов
бесперебойная работа внутренних систем и ПО, которые обрабатывают финансовые операции.
Цена ошибки и простоя тут внушительная
У банков общие со всеми крупными IT-инфраструктурами «боли» с мониторингом:
«кто во что горазд»: техотделов много, практически у каждого как минимум одна своя система мониторинга, а у большинства — больше
«комариный рой» алертов: каждая система генерирует сотни и бомбит ими всех ответственных. Постоянно держать фокус контроля на каждом уведомлении сложно, их срочность и важность нивелируется из-за большого количества
крупные банки — лидеры сектора хотят не просто непрерывно мониторить свои системы, знать, где есть сбои, но и настоящей магии AI — сделать так, чтобы системы самомониторились, самопрогнозировали и самоисправлялись.
В идеале банки, как и другие компании со сложными IT-системами, хотят централизации и свести все данные из разных систем на «один экран», чтобы понимать общую картину происходящего. Для этой задачи подходят «зонтики» — MONQ как раз такой.
Когда мы делали пилот для банка Тинькофф, коллеги поставили перед нами ряд задач:
Когда мы делали пилот для банка Тинькофф, коллеги поставили перед нами ряд задач:
подключить систем мониторинга (в том числе Prometheus) к зонтику
отправлять оповещения ответственным в Slack и по СМС
запускать скрипты автохилинга
Тут проблема: на первом этапе MONQ не имел интеграции с Prometheus и не знал, что такое скрипты автохилинга. Реализация новой интеграции и функционала по запуску скриптов заняла у нас месяц-полтора.
Пока настраивали пилот (делали на контуре клиента, хотя мы предоставляем свое облако) столкнулись с проблемой, которая могла закрыть проект досрочно: для отправки оповещений в мессенджеры и по СМС нам нужны входящие и исходящие соединения с серверами Microsoft Azure и внешним сервисом отправки СМС, но клиент их предоставить не мог из-за политики безопасности. Нам предложили использовать API собственных сервисов, которые отправляют оповещения в Slack и по СМС — мы поразмышляли и согласились, решив сделать плагинную систему оповещений. Такое решение вопроса всех устраивало.
В результате пилота получили несколько важных результатов и выводов:
В результате пилота получили несколько важных результатов и выводов:
1.
MONQ начал правильно принимать алерты из Prometheus и производить их группировку. Алерты по проблеме из Prometheus клиента летели каждые 30 секунд (не включена группировка по времени), и нам было интересно, можно ли их будет группировать в самом "зонтике". Оказалось, что можно — настройка обработки алертов в платформе реализована скриптом. Это дает возможность реализации практически любой логики их обработки. Стандартную логика мы уже реализовали в платформе в виде шаблонов — если нет желания придумывать что-то свое, можно воспользоваться готовым.
Интерфейс «синтетического триггера». Настройка обработки алертов из подключенных систем мониторинга
2.
По алертам создавались события мониторинга, влияющие на здоровье конфигурационных единиц (КЕ). Мы реализуем ресурсно-сервисную модель (РСМ), которая может использовать либо внутреннюю CMDB, либо подключить внешнюю — на пилотном проекте клиент свою CMDB не подключал
Интерфейс работы с ресурсно-сервисной моделью. Пилотная РСМ
3.
События мониторинга инициировали запуск преднастроенных действий — отправку оповещений, запуск скриптов, регистрацию/обогащение инцидентов — последнее не попробовали именно с этим клиентом, т.к. в пилотном проекте не было интеграции с их сервисдеском.
Интерфейс настройки действий. Отправка оповещений в Slack и перезагрузка сервера
4
При обсуждении скриптов Autoheal клиент просил поддержку bаsh и интерфейс, в котором эти скрипты можно было бы удобно настраивать. Мы сделали чуть больше и реализовали функционал, позволяющий управлять жизненным циклом скрипта (создавать, редактировать, версионировать, удалять — архивировать), но и возможность написания полноценных логических конструкций на Lua с поддержкой cURL, SSH и SNMP.
Интерфейс работы со скриптами автохилинга. Скрипт перезагрузки сервера по SSH
5
Ну и, собственно, у клиента появился, наконец, единый экран мониторинга, где видно события из разных систем. На текущий момент к «зонтику» подключено две системы — Zabbix и Prometheus, и внутренняя система мониторинга самой платформы, тоже Zabbix.
Единый экран мониторинга
6.
В «коробке» платформы, кроме популярных Zabbix и Prometheus, есть также интеграции с SCOM и Ntop.
Интерфейс подключения новой системы мониторинга
Если интеграции с какой-либо системой пока нет, мы предлагаем два пути:
1.
сделаем сами за две недели
2.
сделать это это сделать самостоятельно — через открытое и опубликованное API с помощью MONQ EasyBus Technology.
Во время пилота нашли нашли функционал, который требует улучшений и модификаций:
реализовать возможность проброса переменных непосредственно из аллерта в скрипт автохилинга
добавить на платформе авторизацию через Active Directory
Реализуем это в последующих версиях продукта
Более глобальные вызовы для нас — «нарастить» MONQ другими возможностями:
автопостроением ресурсно-сервисной модели на основе ML, а не правил (наверное, главный вызов сейчас)
поддержкой дополнительных языков скриптования (пока только Lua)
На мой взгляд, это история не только для клиентов, которые хотят настроить мониторинг, но и для разработчиков — по сути, это кейс о том, как применять продуктовый подход и вместе с клиентом улучшать свой продукт.
