ЦИСУСС «NB XT EM»
Интеллектуальный мониторинг
и управление сетевым оборудованием промышленного класса
НЕБО XT
Контроль оборудования и сети связи на российском ядре ЦИСУСС, базовая лицензия — бесплатно
Элемент
Платформа для управления оборудованием экосистемы
одного производителя
Ресурс
Интеллектуальная система учета
и управления ресурсами ИТ
и телеком инфраструктуры
Горизонт
Система корреляции аварий для выявления взаимосвязи
и причин сбоя ИТ-сервисов
и причин сбоя ИТ-сервисов
Автоматизированный ОТК для Медиа
Мониторинг и управление
QoE в банковских digital-каналах и введение УПК
С 1 сентября 2026 года для банков действует требование использовать универсальный платежный код (УПК) при считывании платежной информации в предусмотренных законом сценариях. Для клиента это еще один шаг к упрощению цифровых платежей. Для банковской ИТ-инфраструктуры — дополнительный повод посмотреть на платежный сервис как на единую технологическую цепочку, где сбой одного компонента может повлиять на результат всей операции.
Актуальность такого подхода растет вместе с долей цифровых платежей. По данным Банка России, во II квартале 2026 года альтернативные картам способы уже составляли 15,1% общего объема безналичных платежей. С использованием QR-кодов и биометрии за квартал было совершено 1,1 млрд покупок на сумму 1,7 трлн рублей. По сравнению с предыдущим кварталом их количество выросло на 18%, а объем — на 13%.
По мере развития digital-каналов банкам становится недостаточно понимать, доступен ли сервер, работает ли сетевой интерфейс и отвечает ли отдельное приложение. Важен конечный результат: смог ли клиент воспользоваться банковским сервисом и с каким качеством прошел его путь. Именно на этом уровне возникает задача QoE — Quality of Experience.
Актуальность такого подхода растет вместе с долей цифровых платежей. По данным Банка России, во II квартале 2026 года альтернативные картам способы уже составляли 15,1% общего объема безналичных платежей. С использованием QR-кодов и биометрии за квартал было совершено 1,1 млрд покупок на сумму 1,7 трлн рублей. По сравнению с предыдущим кварталом их количество выросло на 18%, а объем — на 13%.
По мере развития digital-каналов банкам становится недостаточно понимать, доступен ли сервер, работает ли сетевой интерфейс и отвечает ли отдельное приложение. Важен конечный результат: смог ли клиент воспользоваться банковским сервисом и с каким качеством прошел его путь. Именно на этом уровне возникает задача QoE — Quality of Experience.
Клиентский опыт как объект мониторинга
Для клиента банковский сервис работает не тогда, когда все его технические компоненты имеют статус «доступен», а когда можно войти в приложение, получить нужные данные, выполнить перевод или платеж и получить подтверждение операции без ошибок и неприемлемых задержек.
При этом инфраструктура может оставаться формально работоспособной. Сервер отвечает на запросы, но авторизация занимает больше времени. Сетевые соединения активны, но один из прикладных сервисов начинает замедлять проведение операций. База данных доступна, однако растущая нагрузка приводит к увеличению времени выполнения отдельных запросов. Внешняя интеграция не отключилась полностью, но отвечает нестабильно.
С точки зрения отдельных объектов критической аварии может еще не быть. С точки зрения клиента качество услуги уже снизилось. Поэтому QoE меняет сам объект контроля: вместо состояния отдельного оборудования или приложения в центре оказывается клиентский сценарий и его результат.
При этом инфраструктура может оставаться формально работоспособной. Сервер отвечает на запросы, но авторизация занимает больше времени. Сетевые соединения активны, но один из прикладных сервисов начинает замедлять проведение операций. База данных доступна, однако растущая нагрузка приводит к увеличению времени выполнения отдельных запросов. Внешняя интеграция не отключилась полностью, но отвечает нестабильно.
С точки зрения отдельных объектов критической аварии может еще не быть. С точки зрения клиента качество услуги уже снизилось. Поэтому QoE меняет сам объект контроля: вместо состояния отдельного оборудования или приложения в центре оказывается клиентский сценарий и его результат.
УПК делает вопрос клиентского опыта еще актуальнее
После считывания универсального платежного кода пользователь должен получить необходимые данные для проведения платежа и продолжить операцию в цифровом канале. При этом за одним внешне простым действием может находиться целая последовательность внутренних и внешних взаимодействий. Сам УПК по определению предоставляет после считывания реквизиты перевода или ссылку на них для формирования платежного распоряжения.
Для пользователя это единый платежный сценарий. Для ИТ-службы банка — взаимодействие нескольких уровней инфраструктуры и приложений. Если проблема появляется на любом из этапов, клиент вряд ли разделит ее на сетевой сбой, ошибку API или деградацию базы данных. Он увидит один результат: платеж выполняется медленно или не выполнен вообще.
Поэтому введение УПК становится дополнительным триггером общего тренда банковских digital-каналов: чем проще выглядит услуга для пользователя, тем большее значение приобретает способность технической команды видеть всю цепочку, которая обеспечивает ее работу.
Для пользователя это единый платежный сценарий. Для ИТ-службы банка — взаимодействие нескольких уровней инфраструктуры и приложений. Если проблема появляется на любом из этапов, клиент вряд ли разделит ее на сетевой сбой, ошибку API или деградацию базы данных. Он увидит один результат: платеж выполняется медленно или не выполнен вообще.
Поэтому введение УПК становится дополнительным триггером общего тренда банковских digital-каналов: чем проще выглядит услуга для пользователя, тем большее значение приобретает способность технической команды видеть всю цепочку, которая обеспечивает ее работу.
“
... чем проще выглядит услуга для пользователя, тем большее значение приобретает способность технической команды видеть всю цепочку, которая обеспечивает ее работу
Состояние инфраструктуры и качество сервиса
Классический мониторинг строится вокруг объектов: сетевых устройств, серверов, виртуальных машин, систем хранения, процессов и приложений. Такой уровень необходим — без него невозможно определить состояние технологического фундамента. Но для сложного банковского сервиса его недостаточно.
Одна операция может зависеть сразу от нескольких приложений, баз данных, очередей, API, сетевых соединений и внешних систем. Каждый элемент при этом может оставаться доступным, хотя качество взаимодействия между ними уже ухудшается.
Здесь возникает разрыв между двумя картинами:
технической — оборудование и системы доступны;
сервисной — клиентская операция выполняется медленно, нестабильно или завершается ошибкой.
Закрыть этот разрыв позволяет сквозной подход к мониторингу, когда технические события рассматриваются не изолированно, а в контексте сервисов, которые зависят от конкретных ресурсов.
Одна операция может зависеть сразу от нескольких приложений, баз данных, очередей, API, сетевых соединений и внешних систем. Каждый элемент при этом может оставаться доступным, хотя качество взаимодействия между ними уже ухудшается.
Здесь возникает разрыв между двумя картинами:
технической — оборудование и системы доступны;
сервисной — клиентская операция выполняется медленно, нестабильно или завершается ошибкой.
Закрыть этот разрыв позволяет сквозной подход к мониторингу, когда технические события рассматриваются не изолированно, а в контексте сервисов, которые зависят от конкретных ресурсов.
Что нужно контролировать для оценки QoE
QoE невозможно описать одной метрикой. Набор показателей зависит от конкретного сценария: авторизации, перевода, платежа, получения данных или другой цифровой услуги.
На инфраструктурном уровне важны доступность оборудования и каналов, состояние сетевых интерфейсов, нагрузка на вычислительные ресурсы, задержки и технические ошибки.
На уровне приложений — состояние сервисов, баз данных, API и интеграций, показатели производительности и возникающие ошибки.
Следующий уровень — непосредственно банковский сервис. Здесь значимы доступность услуги, продолжительность выполнения операций, доля успешных и неуспешных сценариев и другие показатели, которые банк может получать из прикладных систем.
На верхнем уровне находится сам клиентский опыт: удалось ли выполнить необходимое действие и насколько полученный результат соответствует ожидаемому качеству.
Таким образом, логика сквозного контроля выглядит как последовательная цепочка:
оборудование и сеть → инфраструктурные сервисы → приложения и интеграции → банковский сервис → клиентская операция → QoE.
При таком подходе техническая метрика получает контекст. Рост задержки отдельного сервиса становится действительно значимым, когда понятно, какие операции от него зависят и как изменение отражается на работе digital-канала.
На инфраструктурном уровне важны доступность оборудования и каналов, состояние сетевых интерфейсов, нагрузка на вычислительные ресурсы, задержки и технические ошибки.
На уровне приложений — состояние сервисов, баз данных, API и интеграций, показатели производительности и возникающие ошибки.
Следующий уровень — непосредственно банковский сервис. Здесь значимы доступность услуги, продолжительность выполнения операций, доля успешных и неуспешных сценариев и другие показатели, которые банк может получать из прикладных систем.
На верхнем уровне находится сам клиентский опыт: удалось ли выполнить необходимое действие и насколько полученный результат соответствует ожидаемому качеству.
Таким образом, логика сквозного контроля выглядит как последовательная цепочка:
оборудование и сеть → инфраструктурные сервисы → приложения и интеграции → банковский сервис → клиентская операция → QoE.
При таком подходе техническая метрика получает контекст. Рост задержки отдельного сервиса становится действительно значимым, когда понятно, какие операции от него зависят и как изменение отражается на работе digital-канала.
Сервисный взгляд на ИТ-инфраструктуру банка
Еще одна проблема возникает из-за количества источников мониторинга. Сетевая система фиксирует собственные события, серверный мониторинг — свои, приложение формирует логи и метрики, внешние системы предоставляют отдельные данные. В результате информации много, но она не всегда складывается в единую картину.
Для контроля клиентского сервиса важно понимать взаимосвязи. Какое оборудование обеспечивает работу приложения? Какие приложения входят в конкретный сервис? От какой базы данных или интеграции зависит операция? Какие цифровые услуги могут быть затронуты текущим инцидентом?
Ответить на эти вопросы позволяет ресурсно-сервисная модель, в которой технические компоненты связываются с приложениями и бизнес-сервисами. Тогда задача мониторинга меняется. Вместо десятков независимых сообщений оператор получает возможность оценивать не только место возникновения события, но и его потенциальное влияние на сервис.
Для контроля клиентского сервиса важно понимать взаимосвязи. Какое оборудование обеспечивает работу приложения? Какие приложения входят в конкретный сервис? От какой базы данных или интеграции зависит операция? Какие цифровые услуги могут быть затронуты текущим инцидентом?
Ответить на эти вопросы позволяет ресурсно-сервисная модель, в которой технические компоненты связываются с приложениями и бизнес-сервисами. Тогда задача мониторинга меняется. Вместо десятков независимых сообщений оператор получает возможность оценивать не только место возникновения события, но и его потенциальное влияние на сервис.
Решения Теком для финсектора
В экосистеме «Теком» задачи мониторинга банковской ИТ-инфраструктуры и сервисов могут решаться на разных уровнях.
ЦИСУСС «NB XT EM» — платформа, предназначенная для централизованного контроля оборудования, сервисов и инфраструктуры разных производителей и формирования базового уровня наблюдаемости технологического контура.
Далее для контроля цифрового сервиса необходимо подняться выше объектов инфраструктуры. И именно этот слой задач решает система Горизонт. Она агрегирует данные из различных систем мониторинга, выявляет взаимосвязи между элементами ИТ-ландшафта и строит ресурсно-сервисную модель. Среди ее возможностей: контроль состояния сервисов в реальном времени, отображение влияния инфраструктуры на сервис, корреляция событий, поиск первопричин инцидентов и анализ доступности.
Совместное использование ЦИСУСС «NB XT EM» и Горизонт позволяет выстроить сквозную модель: от оборудования и сетевой инфраструктуры до приложений, бизнес-сервисов и пользовательских услуг. Именно такой переход необходим, когда задача эксплуатации заключается уже не только в поиске неисправного узла, но и в оценке того, какой цифровой сервис оказался затронут.
ЦИСУСС «NB XT EM» — платформа, предназначенная для централизованного контроля оборудования, сервисов и инфраструктуры разных производителей и формирования базового уровня наблюдаемости технологического контура.
Далее для контроля цифрового сервиса необходимо подняться выше объектов инфраструктуры. И именно этот слой задач решает система Горизонт. Она агрегирует данные из различных систем мониторинга, выявляет взаимосвязи между элементами ИТ-ландшафта и строит ресурсно-сервисную модель. Среди ее возможностей: контроль состояния сервисов в реальном времени, отображение влияния инфраструктуры на сервис, корреляция событий, поиск первопричин инцидентов и анализ доступности.
Совместное использование ЦИСУСС «NB XT EM» и Горизонт позволяет выстроить сквозную модель: от оборудования и сетевой инфраструктуры до приложений, бизнес-сервисов и пользовательских услуг. Именно такой переход необходим, когда задача эксплуатации заключается уже не только в поиске неисправного узла, но и в оценке того, какой цифровой сервис оказался затронут.
От контроля сервисов к качеству клиентского опыта
При этом сервисный мониторинг и QoE не стоит полностью отождествлять. Система Горизонт позволяет связать инфраструктуру, приложения и цифровые сервисы, оценивать их состояние и влияние инцидентов. Но для полноценного анализа пользовательского опыта необходимы также данные непосредственно о прохождении клиентских сценариев: результате операции, времени ее выполнения, ошибках отдельных этапов и других показателях прикладного уровня. Такая информация должна поступать из соответствующих банковских систем и источников телеметрии.
Поэтому архитектуру контроля QoE правильнее строить как несколько связанных уровней: инфраструктурный мониторинг дает техническую картину, ресурсно-сервисная модель показывает влияние событий на услугу, а прикладные данные позволяют сопоставить состояние сервиса с реальным результатом клиентской операции.
Поэтому архитектуру контроля QoE правильнее строить как несколько связанных уровней: инфраструктурный мониторинг дает техническую картину, ресурсно-сервисная модель показывает влияние событий на услугу, а прикладные данные позволяют сопоставить состояние сервиса с реальным результатом клиентской операции.
Подробнее о том, как сквозной мониторинг связывает состояние инфраструктуры с банковскими сервисами и клиентскими процессами, мы рассказывали в статье Комплексный мониторинг в банках: почему инфраструктурного контроля уже недостаточно
QoE становится частью эксплуатации digital-банка
Значение клиентского опыта постепенно становится измеримой частью платежного рынка. По результатам первой оценки Банка России общий уровень удовлетворенности граждан платежными услугами составил 71%. Для QR-кода как платежного инструмента показатель составил 72%.
Развитие УПК, мобильного банкинга и других цифровых платежных сценариев увеличивает количество взаимосвязей внутри сервисной цепочки. При этом для клиента вся сложность инфраструктуры должна оставаться незаметной: ему необходимо просто выполнение банковской операции. Поэтому следующий этап развития мониторинга — не увеличение количества собираемых метрик само по себе, а их объединение вокруг конкретных цифровых услуг.
ЦИСУСС «NB XT EM» позволяет контролировать инфраструктурный фундамент, Горизонт — связать технические ресурсы с приложениями и бизнес-сервисами, а данные прикладного уровня — дополнить эту модель фактическими результатами клиентских операций.
Так мониторинг постепенно переходит от контроля оборудования к контролю цифрового сервиса, а QoE становится естественным продолжением сквозной наблюдаемости банковской ИТ-инфраструктуры.
Развитие УПК, мобильного банкинга и других цифровых платежных сценариев увеличивает количество взаимосвязей внутри сервисной цепочки. При этом для клиента вся сложность инфраструктуры должна оставаться незаметной: ему необходимо просто выполнение банковской операции. Поэтому следующий этап развития мониторинга — не увеличение количества собираемых метрик само по себе, а их объединение вокруг конкретных цифровых услуг.
ЦИСУСС «NB XT EM» позволяет контролировать инфраструктурный фундамент, Горизонт — связать технические ресурсы с приложениями и бизнес-сервисами, а данные прикладного уровня — дополнить эту модель фактическими результатами клиентских операций.
Так мониторинг постепенно переходит от контроля оборудования к контролю цифрового сервиса, а QoE становится естественным продолжением сквозной наблюдаемости банковской ИТ-инфраструктуры.
Эльнара
Контент-маркетолог
Хотите получать интересный контент
на почту?
Заполните форму и будьте в курсе всех новостей