Опубликовано: 4 сентября 2026 · Источник: TAdviser
ИльяКакие задачи сегодня выходят на первый план при развитии ИТ-инфраструктуры? Что сильнее всего влияет на требования к ней?
Илья Виссарионов: Я бы разделил эти требования на две группы. Первая связана с естественным развитием бизнеса. Растет интенсивность работы информационных систем, увеличивается нагрузка, и компаниям необходимо обеспечивать высокую доступность и достаточную производительность прикладных решений.
Вторая группа требований связана с регулированием и импортозамещением. В ряде отраслей необходимо переходить на российское программное обеспечение и серверное оборудование — как из-за требований регуляторов, так и для снижения рисков, связанных с использованием зарубежных технологий. В результате требования распространяются на весь технологический стек, который находится под прикладным решением: системы хранения и обработки данных, средства интеграции, системное ПО, инфраструктурные компоненты. Они должны обеспечивать необходимую производительность и отказоустойчивость, а там, где это требуется, соответствовать требованиям к использованию российского ПО и оборудования.
Лет 20 назад корпоративные системы чаще всего представляли собой монолитные решения, а сегодня это сложные распределенные архитектуры с большим количеством взаимосвязанных компонентов и горизонтальным масштабированием. В монолите круг возможных причин сбоя был относительно невелик. Сейчас источник деградации может находиться на разных уровнях системы, поэтому сопровождать такую инфраструктуру стало значительно сложнее.
Как «Диасофт» решает задачу мониторинга такой инфраструктуры?
Илья Виссарионов: Для наших инфраструктурных платформ мы развиваем собственные средства мониторинга. В частности, такие возможности реализованы в Digital Q.MessageBroker — нашей платформе для организации обмена информацией между приложениями.
Для нас важно не только зафиксировать уже произошедший инцидент, но и увидеть признаки проблемы заранее. Самые простые примеры — постепенное заполнение дискового пространства или рост утилизации процессорных ресурсов. Если система показывает такой тренд, можно принять меры до того, как ресурс будет исчерпан и возникнет сбой.
Мы стараемся переходить от реактивной модели, когда служба эксплуатации уже разбирается с аварией, к проактивной, когда потенциальную проблему можно увидеть и устранить заранее.
При этом вы выполняете мониторинг не только инфраструктуры, но и прикладных решений. Зачем связывать эти два уровня?
Илья Виссарионов: Потому что сама по себе доступность сервера еще не означает, что пользователь может нормально работать с приложением. Мы исходим из прикладной задачи. Пользователю важно, чтобы условная кнопка работала быстро и была доступна тогда, когда она ему нужна. Все, что находится ниже, его не волнует.
В микросервисной архитектуре за одну бизнес-функцию могут отвечать сразу несколько сервисов. Поэтому мы мониторим не только отдельные инфраструктурные элементы и микросервисы, но и группы микросервисов, реализующие определенную функциональность. Это позволяет связать проблему, которую видит пользователь, с ее возможной причиной на более низком уровне, вплоть до инфраструктурного.
Такой подход важен и для сопровождения. Если отслеживать только деградацию прикладной операции, придется выяснять, что ее вызвало. Если смотреть исключительно на инфраструктуру, можно увидеть перегруженный или недоступный компонент, но не сразу выявить, на какие бизнес-функции это повлияло. Наша задача — связать эти уровни и тем самым сократить время локализации проблемы.
Как эта логика реализована в Digital Q.MessageBroker? Что именно можно контролировать?
Илья Виссарионов: Digital Q.MessageBroker — инфраструктурная платформа для организации обмена информацией между приложениями. В ней используются два основных компонента — Kafka и Artemis. Kafka подходит для интенсивного обмена сообщениями между микросервисами, когда особенно важны производительность, масштабируемость и отказоустойчивость. Artemis мы используем прежде всего в интеграционных сценариях, когда требуется связать системы с разной архитектурой.
Но если говорить о мониторинге, мы смотрим значительно шире самого брокера сообщений. Контролируются инфраструктура, Kubernetes, базы данных, микросервисы, интеграционные компоненты и состояние прикладных решений. Для микросервисов, например, мы отслеживаем утилизацию выделенных ресурсов, доступность и количество запущенных реплик. Для высоконагруженного сервиса важно, чтобы требуемое число экземпляров действительно работало: это влияет и на производительность, и на отказоустойчивость.
Учитывается и кластерная конфигурация инфраструктурных компонентов. Для баз данных или Kafka можно видеть, какие серверы или виртуальные машины являются активными участниками кластера, какие выполняют роль лидеров или резервных узлов, доступны ли сами компоненты, с которых собираются метрики.
Когда компонентов много, мониторинг сам рискует превратиться в огромное количество метрик и экранов. Как из этой информации понять, где действительно возникла проблема?
Илья Виссарионов: Мы сделали несколько уровней детализации. На верхнем уровне пользователь видит общее состояние стенда. Условно, это движение от зеленого состояния через промежуточные градации к красному. На цвет состояния влияют утилизация ресурсов, доступность компонентов, количество работающих сервисов и другие параметры.
Если появляется проблема, можно последовательно провалиться на следующие уровни и посмотреть, с чем она связана. При этом мы сохраняем историю там, где это возможно, и показываем тренды изменения показателей. Это важно именно для проактивного мониторинга: оператор видит не только текущее значение, но и то, что параметр постепенно ухудшается.
Можно настраивать и оповещения. Один уровень сигнализирует о том, что показатель выходит из нормальной зоны и на него уже стоит обратить внимание. Следующий означает критическое состояние, когда необходимо подключать соответствующего администратора и локализовывать причину.
На рынке уже доступно достаточно большое количество инструментов мониторинга. В чем ваше конкурентное преимущество?
Источник: TAdviser · Оригинал статьи: Илья Виссарионов, «Диасофт» — От прикладных решений до инфраструктуры: как мониторинг помогает локализовать источник проблемы
