Привет, Хабр! Меня зовут Игорь Шестаков. Я занимаюсь тестированием ЕСПП (единая система приема платежей) в Блоке обеспечения и контроля качества выпуска изменения ПО в РСХБ‑Интех. Сегодня обсудим тему выживания в контейнере и ветвистых путей импортозамещения, его плюсы, минусы и возможности.
ЕСПП — мидл‑решение, расположенное в центре хитросплетений систем РСХБ. Система представляет собой масштабный платежный хаб, нацеленный на обработку запросов от фронтальных систем банка: терминалы, банкоматы, мобильные приложения, интернет‑банк и в целом любые доступные пользователю каналы. На основании успешной операции ЕСПП формирует набор бухгалтерских проводок в АБС (автоматизированную банковскую систему) с целью списания средств в пользу поставщика, расчета комиссии и всех остальных сопутствующих расчетов.
ЕСПП — связующее звено между клиентом и поставщиком. Она содержит в себе динамическую базу данных (БД) услуг, которые распределяются по точкам обслуживания, предоставляя клиентам возможность оплачивать мобильную связь, ЖКХ, налоги, производить переводы по реквизитам и, что самое важное, переводы по номеру телефона, на которых и хотелось бы заострить внимание.
В РСХБ именно на базе ЕСПП реализована СБП — система быстрых платежей, оператором которой выступает НСПК (Национальная система платежных карт). Без прикрас скажу, что СБП уже практически стала родной системой и неотъемлемой частью современных переводов со счета на счет.
СБП является высококритичной системой. Её участникам выставляются строгие требования соответствия в части доступности сервиса, скорости обработки и сроков выпуска функционала. У нас в банке уже реализованы:
C2C — customer‑to‑customer, вышеупомянутые переводы от одного физического лица другому, самый популярный вид переводов не требующий заполнения массы реквизитов, достаточно номера телефона получателя;
C2B — customer‑to‑business, от физического лица юридическому, то есть оплата покупок через СБП, активно внедряется в виде QR‑кодов и уже присутствует в большинстве магазинов;
B2C — business‑to‑customer, обратный вариант C2B позволяющий переводить средства от юридического лица физическому.
В обозримом будущем ожидаются новые типы платежей:
C2G — customer‑to‑government, переводы в бюджет, позволяют оплачивать по номеру телефона, ЖКХ, налоги, таможенные платежи и любые бюджетные платежи;
C2INT — customer‑to‑customer‑international, переводы физическим лицам в другие страны;
B2B — business‑to‑business, переводы между юридическими лицами.
Мы уже активно трудимся над новыми видами переводов, расширяя возможности наших клиентов. Но до появления СБП мы были относительно небольшой системой, с тестированием которой вполне справлялся один тестировщик. Зачастую было достаточно даже мануального UI‑тестирования с просмотром логов. СБП стала для нас драйвером роста. Когда появились С2С у нас начал расти штат, поскольку сильно выросли объемы тестирования. Появление С2В принесло нам полноценное api‑тестирование, и с ним же начала зарождаться автоматизация. Сейчас в команде уже семь человек.
Однако за комфортом пользователя, доступностью сервиса 365/24/7 и скоростью всегда кроется тяжелая работа всей команды, разработчиков, аналитиков, сопровождения и, конечно же, тестирования. И пока мы старательно стояли на стражи качества, наступил день Х, произошло импортозамещение
Импортозамещение
Основная цель импортозамещения — полностью уйти от внешних поставщиков, обеспечив цифровую независимость. Способ достижения — глобальная миграция всей программной части на отечественные и open‑source решения, что включает в себя абсолютно все: операционные системы, базы данных, толстые клиенты (в случае если в их реализации задействованы компоненты, не соответствующие новым требованиям).
Разумеется, столь масштабные изменения просто не могут пройти безболезненно, даже при беглом анализе вырисовываются существенные трудности. Давайте рассмотрим их детальнее.
Большинство систем не могут похвастаться гибкостью и потребуют серьезных доработок, порой на архитектурном уровне.
Переход с привычных платформ негативно скажется на работе, так как не все сотрудники знакомы и работали с целевыми решениями. Самый простой пример — операционная система, большинство нашего функционала работает на базе Windows. Конечно же, многие сотрудники знакомы с различными дистрибутивами Linux, но ознакомиться и работать на постоянной основе не одно и тоже. Кроме того, изменениям будет подвержено все: от текстового редактора до систем мониторинга. Придется привыкать к новым инструментам.
Для реализации плана потребуется параллельная разработка и тестирование. То есть одновременно с развитием и поддержкой текущего функционала будут существовать специализированные контура, содержащие версию системы в целевой реализации, на которых потребуется вести параллельную работу в части разработки, тестирования и стабилизации вплоть до выпуска в промышленную эксплуатацию. В зависимости от количества изменений в системе это может потребовать даже больше ресурсов чем текущая деятельность.
Интеграция, ситуация осложняется тем, что смежные системы будут делать тоже самое и нужно учитывать все нюансы внутреннего взаимодействия.
Требуется практически перестроить систему заново и учитывая вышесказанное, задача с трудом кажется выполнимой и уж точно не кажется полезной для системы. Тем не менее, в этот момент у нас было недостаточно информации, а трудностям, как известно, свойственно бросаться в глаза. Вопрос требовал более детальной оценки и чем больше углублялся анализ, тем становилось очевиднее, что перед нами открылась уникальная возможность перестроить систему, адаптировать ее, оптимизировать, сделать лучше и учесть все то, что было упущено.
Для дальнейшей работы были определены следующие пункты.
Костыли, неоптимальные решения — избавиться от всех или хотя бы большинства
Тут мы иллюзий не питаем. Ото всех, разумеется, не избавишься. Костыли — неизбежность в жизни ПО, а неоптимальные решения будут преследовать нас пока люди не научатся заглядывать в будущее, обеспечивать идеальное планирование, писать совершенный код и лишать тестировщиков работы. Однако, перестраивая систему, мы все же можем оптимизировать большую часть.
Упрощение автоматизации — избавиться от толстых клиентов
UI нашей системы реализован на толстом клиенте. В самом начале с этим не было трудностей, потому что, когда система только начинала тестироваться, у нас еще не было автоматизации. Но с развитием системы и внедрением автоматизации стало невозможно отрицать, насколько неудобна и трудоемка реализация UI тестирования на толстом клиенте, во многих аспектах требуются излишние трудозатраты.
Покрытие тестовой модели в этой части продвигается намного медленнее остального функционала. В рамках миграции планируется перенести функционал UI в Web, что открывает океан возможностей и уже готовых решений автоматизации на все случаи жизни.
Развитие — глобальный процесс
Подобная перестройка системы подразумевает полномасштабное, доскональное регрессионное тестирование с массой исследовательской работы для последующего документирования. В эту активность, несомненно, будут вовлечены все сотрудники без исключения и с уверенностью можно сказать, что это положительно повлияет на их экспертизу и знание системы.
Переход на передовые технологии
Данный пункт настолько обширен, что влияет на все вышеописанное и даже порождает собственные пункты. Поэтому рассмотрим его отдельно. Для понимания полной картины потребуется небольшое отступление.
В нашем банке разработана и внедрена уникальная платформа App.Farm на технологической основе Kubernetes. Она представлена в виде PaaS (Platform as a Service), то есть на платформе осуществляется поддержка полного жизненного цикла web‑приложения: разработки, тестирования, развертывания, управления и обновления. Фактически App.Farm является гибридной интеграционной платформой.
В чем отличия?
Enterprise Service Bus (ESB) ‑ или корпоративная служебная шина, в классическом понимании это централизованная архитектура промежуточного ПО, позволяющая различным приложениям обмениваться данными. Действует как центр маршрутизации сообщений, преобразования форматов данных и управления интеграцией. ESB обеспечивают более масштабируемый и гибкий подход к интеграции, позволяющий улучшить контроль и мониторинг.
App.Farm сочетает в себе все вышеупомянутые возможности, но также позволяет размещать системы, соответствующие требованиям внутри собственной инфраструктуры, обеспечивая их сопровождение в процессе всего жизненного цикла.
Основные сущности App.Farm
Внутренняя информационная система — определенный бизнес‑продукт, имеющий собственную рабочую область в App.Farm с выделенными ресурсами.
Внутренний сервис (psvc — platform service) — компонент информационной системы. Сервис приводит к действию внутри платформы. Каждый сервис выполняет только одну функцию.
Внешняя информационная система — внешний бизнес‑продукт, развернутый вне App.Farm.
Внешний сервис (exsvc — external service) — компонент внешней информационной системы; описание с параметрами.
Интеграционная связь (link) — обеспечивает связь между внутренними сервисами, внешним и внутренним сервисами, внешними сервисами.
В данный момент ЕСПП является для App.Farm внешней системой и существует в собственной рабочей области. В такой позиции система не получает всех преимуществ, предоставляемых платформой, поскольку они распространяются только на внутренние системы. Вернемся к этому моменту чуть позже, сперва завершим знакомство с App.Farm.
Если смотреть на платформу глобально, то становится очевидно, что в работе задействованы сотни сервисов. Учитывая каскадную коммуникацию между ними, процессу категорически необходимо управление, эту задачу на себя берет Service Mesh — абстрактный слой инфраструктуры, определяющий взаимодействие между микросервисами приложения.
Service Mesh управляет трафиком между сервисами, диагностирует ошибки. Он предназначен для решения задач через контроль над взаимодействием сервисов друг с другом. В частности:
динамическое обнаружение сервисов;
маршрутизация и управление трафиком;
шифрование, аутентификация и авторизация;
сбор метрик и мониторинг;
трейсинг http;
управление исходящим трафиком (istio‑egressgateway).
Service Mesh очень полезен при большом количестве сервисов и наличии каскадных коммуникаций между ними. Также за счет istio‑egressgateway‑контроллеров упрощается управление исходящим трафиком за счет применения политик сетевого доступа к внешним ресурсам.
Нужно назвать еще несколько ключевых функций Service Mesh.
Единообразным для всего стека. Функции, предоставляемые service mesh, применяются ко всем сервисам платформы независимо от того, на каком языке те написаны, какой фреймворк используют, как они были развернуты и от всех остальных тонкостей их разработки и применения.
Независимым от кода приложения. Фундаментальная основа функциональности service mesh — обеспечение независимости. Сервисы могут меняться, не затрагивая service mesh. В свою очередь, service mesh может меняться без какого‑либо участия сервисов и наоборот. Тут стоит уточнить, что это зависит от реализации и не всегда справедливо, но это предмет отдельного обсуждения.
В настоящее время на платформе осуществляется поддержка следующих технологий: Java, Kotlin, Python, Python‑проекты с использованием исполняемых модулей от вендора, C# /.NET,.NET‑проекты с использованием исполняемых модулей от вендора, Angular, React, NodeJS, Frontend‑приложение, собранное вне App.Farm. Список может расширяться в зависимости от пожеланий систем‑участников, в данный момент он такой.
За этим наше краткое знакомство с платформой заканчивается.
К сожалению, ЕСПП «сегодня» не подходит для полноценного переезда на платформу, поскольку, не смотря на микросервисную архитектуру, строится на базе ОС Windows, а App.Farm подразумевает контейнеризацию сервисов. Тем не менее, благодаря импортозамещению ситуация круто меняется. План еще полностью не утвержден, но рассматривается полная или частичная контейнеризация системы с последующим размещением в App.Farm. К счастью, платформа очень гибкая и позволяет различные подходы.
Закончим небольшое отступление и вернемся к пункту перехода на передовые технологии, порождающему собственные подпункты.
«Исторически сложилось» — Думаю, многие слышали подобный ответ не вопрос о неочевидном поведении системы — хватит это терпеть! Оглядываясь на пункт про костыли, перестройка системы под контейнеризацию действительно позволит учесть все исторически сложившееся нюансы, корректировку неоптимальных решений. Конечно же это не является страховкой от подобных ситуаций в будущем. Поэтому потребуется проводить регулярное ревью для поддержания состояния системы.
Автоматизация автоматизации. Да, именно так! Благодаря AppFarm мы сможем подключить автотесты прямо к необходимым сервисам, и они будут запускаться автоматически сразу же после успешной пересборки. Кроме того, имеется возможность подключить специальные библиотеки, возвращающие человекочитаемый формат ошибок по заранее заданным условиям, что существенно ускоряет анализ причин падения автотеста.
Давайте посмотрим на примере, задана проверка строки на содержание xyz.
Проверка:
gomega.Expect(actualStr).To(gomega.ContainSubstring("xyz"), "checking log output")
Проверка завершается неудачей. Но самое главное, вместо всеми любимого «Error», без каких‑либо пояснений, мы сразу понимаем, в чем дело. Ожидалось что строка будет содержать xyz. Не содержит. Можно передавать на анализ.
Вывод ошибки:
[FAILED] checking log output
Expected <string>: hello world
to contain
substring <string>: xyz
Вся эта схема позволит практически полностью автоматизировать smoke тестирование, что освободит огромное количество времени тестировщиков, которое можно смело направить на требующий человеческого внимания функционал, дополнительный анализ, исследовательскую работу, и как итог еще выше поднять планку качества выпускаемого продукта, что и является основной целью.
И вновь, развитие (еще раз)
Работа с новым стеком технологий позволит вызвать стремительный рост компетенций команды, а наша, вероятно, самая динамически развивающаяся сфера IT не позволяет стоять на месте.
Полноценный CI/CD
Сейчас мы разворачиваем функционал «по старинке». После передачи поставки аналитики готовят инструкции, которые вместе с поставкой передаются администраторам для установки на контур на функционального тестирования. Затем, по успешному завершению, вносятся корректировки. Цикл повторяется для регрессионного тестирования и промышленной эксплуатации. Это очень ресурсоемкий процесс, особенно если в релизе несколько десятков модулей.
Думаю, многим знакома ситуация, когда в процессе тестирования модуль неоднократно дорабатывается, поднимается его версия, подключается расширенное логирование для локализации дефекта и каждая итерация осуществляется вышеописанным циклом. И это абсолютно правильный процесс, обеспечивающий надлежащее качество тестовых стендов и промышленной среды. Однако переход на конвейер позволит просто собирать и разворачивать поставки в целевом окружении с необходимой конфигурацией практически одной кнопкой. В итоге процесс не изменяется, но изменяется инструментарий, существенно снижая затраты времени и повышая комфорт работы, что тяжелее измеримо, но отнюдь не менее важно. И это взгляд только с позиции тестирования, думаю глобальные плюсы CI/CD мы в очередной раз обсуждать не будем.
Пункты завершились, и уже давно зреет закономерный вопрос — какие же минусы?
Разумеется, минусы есть. Теперь… все это нужно сделать. Да, масштаб работы впереди гигантский, но открывающиеся возможности создают нерушимую мотивацию, а это уже половина успеха.
И в завершение, думаю, следует подвести небольшой итог, к чему мы пришли.
Сейчас перед многими системами стоит задача по импортозамещению. Правильный подход к реализации позволит не только достигнуть цели, но и осуществить скачок в развитии системы или как минимум оптимизировать ее работу. И эту возможность нужно использовать по максимуму.
Чем раньше начнется анализ, тем больше идей будет сгенерировано, больше корректировок будет внесено, тем лучшего состояния системы можно достигнуть, дабы обеспечить наилучшее качество, к чему мы все и стремимся.
Импортозамещайтесь и совершенствуйтесь.