СПО для СДО: как free soft помогает администрировать критичные бизнес-системы в ВТБ

Система документационного обеспечения в нашем банке постоянно развивается и масштабируется, а требования к скорости и отказоустойчивости при этом только возрастают. В какой-то момент обслуживать СДО без эффективного централизованного мониторинга стало слишком рискованно. Чтобы обезопасить бизнес-процессы в ВТБ и упростить работу администраторов, мы внедрили решение на основе стека открытых технологий. С его помощью мы можем проактивно реагировать на инциденты, предотвращая потенциальные проблемы. Под катом — история о нашем опыте использования свободного ПО для мониторинга масштабных бизнес-систем.

Зачем мониторить систему документооборота

Документационным обеспечением в банке ВТБ с 2005 года «заведует» система CompanyMedia. В СДО работает свыше 60 тысяч пользователей, ежемесячно создающих более миллиона новых документов. Наши серверы должны функционировать 24 часа в сутки: практически в любой момент в системе находится по 2500–3000 человек, которые подключаются по всей стране, от Петропавловска-Камчатского до Калининграда. Каждая секунда работы СДО — это 10–15 изменений.

Чтобы система четко выполняла возложенные на нее задачи, мы развернули отказоустойчивую инфраструктуру с применением серверов проксирования, балансировки запросов, защиты информации, полнотекстового поиска, интеграционных маршрутов и резервного копирования. Чтобы поддерживать и администрировать проект такого масштаба, требуются колоссальные ресурсы. Администраторы круглосуточно отслеживают базовую информацию о работе серверов, загрузке оперативной памяти, процессорного времени, подсистемы ввода-вывода и так далее. Но, кроме этого, нужна более тонкая аналитика:

• расчет времени, которое тратится на выполнение бизнес-сценариев;
• отслеживание динамики производительности системы и нагрузки на нее;
• поиск отклонений в компонентах системы от утвержденных нефункциональных требований.

Спустя 11 лет после внедрения СДО вопрос проактивного реагирования на различного рода ошибки встал особенно остро. Руководство банка осознало, что работать без мониторов и консоли жизнедеятельности системы — это играть с огнем: малейший сбой в бизнес-системе подобного уровня чреват миллионными убытками.

В 2016 году мы начали внедрение инструментов для оперативного выявления проблем в функционировании СДО, в том числе для наблюдения за интересующими нас параметрами в режиме реального времени. Предварительно систему прикладного мониторинга разворачивали и тестировали в рамках инфраструктуры компании «ИнтерТраст».

С чего все начиналось

Сегодня централизованная система прикладного мониторинга СДО ВТБ, основанная на СПО-продуктах, помогает предотвращать большую часть ошибок, связанных с документооборотом, быстро и точно классифицировать проблемы, оперативно реагировать на любые инциденты. Она включает в себя две подсистемы:

• для мониторинга IT-инфраструктуры сервисов системы;
• для мониторинга возникновения ошибок в работе СДО.

Все началось с единственного бесплатного приложения для мониторинга. Перебрав несколько вариантов, мы остановились на Zabbix — свободном ПО, которое изначально писалось под банковские сервисы и оборудование. Эта система с веб-интерфейсом на PHP, которая может хранить данные в MySQL, PostgreSQL, SQLite или Oracle Database, идеально соответствовала нашим запросам.

Zabbix запускает своих агентов на каждом сервере и собирает информацию по интересующим метрикам в режиме реального времени в единую базу данных. При помощи приложения удобно собирать данные о нагрузке на процессоры и оперативную память, об использовании сети и прочих компонентов, проверять доступность и реакцию стандартных сервисов (SMTP или HTTP), выполнять внешние программы, поддерживать мониторинг через SNMP.

Развернув Zabbix, мы настроили стандартные аппаратные метрики, и поначалу этого было достаточно. Но СДО ВТБ постоянно развивается и растет: в 2016 году количество серверов заметно увеличилось, появились миграционные процессы, к системе подключились Банк Москвы, ВТБ Капитал, ВТБ24. Стандартных метрик стало мало, и мы научили Zabbix отслеживать информацию о наличии очередей на каждом из томов, подключенных к серверу (из коробки Zabbix отражает только общую дисковую очередь), а также о времени, которое занимает отработка той или иной процедуры.

Кроме того, мы оснастили систему множественными триггерами — условиями, при которых администратору отправляется уведомление (сообщение в «Телеграм», СМС на номер телефона или письмо на электронную почту). Триггеры настраиваются для любого набора параметров. Например, можно указать определенный процент свободного места на диске, и система будет оповещать администратора, когда заданный порог будет достигнут, или информировать, если какая-либо фоновая процедура выполняется дольше обычного.

Подключение к Java и визуализация данных

Мы значительно расширили спектр анализируемых данных, но вскоре и этого стало недостаточно для эффективного мониторинга. Воспользовавшись тем, что СДО от CompanyMedia является Java-приложением, мы подключились к Java Virtual Machine через интерфейс JMX и смогли снимать метрики Java напрямую. Причем не только стандартные параметры жизнедеятельности Java, такие как интенсивность работы GC или расход Heap, но и специфичные пробы, относящиеся непосредственно к исполняемому коду приложения.

В 2017 году, примерно год спустя после внедрения системы мониторинга, стало понятно, что для нормальной работы с колоссальным массивом данных, который собирается в Zabbix, не хватает визуализации — комплексных экранов. Оптимальным вариантом решения этой проблемы снова стало свободное ПО — Grafana, удобный дашборд для метрик, позволяющий агрегировать все данные на одном экране.

Интерфейс Grafana интерактивный, напоминает OLAP-систему. Подсистема выводит данные, которые получает Zabbix, на единый экран, представляя информацию в виде удобных для анализа графиков и схем. Администратор легко настраивает под себя срезы, которые ему нужны.

Мониторинг и превентивное устранение ошибок в системе СДО

Фильтровать и анализировать получаемую в ходе мониторинга информацию помогает СПО-платформа ELK. Этот opensource-продукт состоит из трех мощных инструментов для сбора, хранения и анализа данных: Elasticsearch, Logstash и Kibana. Внедрение этой подсистемы позволяет, в частности, видеть в режиме реального времени, сколько ошибок произошло в системе, на каких серверах и повторяемые ли это ошибки.

Теперь администратор может засечь проблему на ранней стадии, еще до того, как с ней сталкивается пользователь. Такой проактивный мониторинг позволяет предотвращать нарушения работоспособности системы, своевременно устраняя ошибки. Кроме того, мы можем понять, как изменилось поведение системы после обновления, а также обнаружить новые проблемы в случае их появления.

Мониторинг бизнес-операций

Помимо базовых функций мониторинга потребления ресурсов, система обладает возможностью анализа и контроля бизнес-операций.

Контроль общего времени выполнения бизнес-операций позволяет выявлять новые факторы и понимать, какое влияние они оказывают на работу системы.

Контроль времени исполнения запросов в разрезе каждого бизнес-сервиса дает возможность засечь операции, имеющие отклонение от нормы.

На скриншоте выше — пример мониторинга фоновой задачи с точки зрения ее отклонения от нормы.

Перечень контролируемых задач с точки зрения их активности на определенном сервере позволяет выявлять ошибки — в том числе дублирования исполнения задач — по всем серверам.

Также проводится мониторинг трендов времени исполнения фоновых процедур.

Система растет, развивается и помогает справляться с проблемами

С внедрением описанной системы мониторинг работы серверов СДО существенно упростился. Тем не менее периодически возникают разного рода конфликты, влияющие на скорость документооборота и вызывающие жалобы пользователей. Так мы поняли, что необходимо контролировать и поведение самого приложения, а не только серверы.

Для решения этой задачи к системе мониторинга подключили по API балансировщик, который работает с кластером серверов приложений. Благодаря этому администратор может видеть, за какое время отвечает сервер по каждому запросу пользователя.

Данные о времени ответов серверов стали доступны для анализа, что дало возможность связать замедление СДО с процессами, происходящими на сервере. Выявилась, в частности, интересная ситуация: сервер работает медленно, хотя в этот момент он не загружен. Анализируя аномалию, мы обнаружили отклонения в работе Garbage Collector Java. В конце концов выяснилось, что именно некорректная работа этого сервиса и приводила к данной ситуации. Взяв под контроль Garbage Collector Java, мы полностью устранили проблему.

Вот так свободное ПО помогает развиваться и расти системе документооборота в банковской сфере. Мы затронули только основные вопросы, касающиеся системы мониторинга СДО ВТБ. Если вам интересны подробности — спрашивайте в комментариях, мы с радостью поделимся с вами своим опытом.

Источник: habr.com