Цель проекта:
Предпосылки
Заказчик использует ЦФТ-Банк с расширениями собственной разработки, который обслуживает все банковские процессы (счета, кредиты, вклады, РКО, регуляторные требования) — и поэтому относится к разряду бизнес-критичных и важных систем. Простой или замедление приводит в потере сотен тысяч, а то и больше рублей.
У заказчика были сомнения в качестве текущих работ по нагрузочному тестированию, поэтому он обратился к нам для проведения аудита, а также для улучшения автоматизации при подготовке и процессе тестирования.
Это было необходимо, чтобы уйти от лишних перезапусков тестов и ускорить нагрузочные испытания. Функционал системы реализован на базе данных Oracle, включая очереди JMS и AQ и планировщик заданий. Обработка сообщений от других систем может быть осуществлена в рамках одной транзакции либо разбита на несколько этапов, связь между ними реализована через внутренние очереди.
Задачи тестирования
Решение
В начале проекта главная сложность заключалась в следующем: из-за недостатков автоматизации и неправильной подготовки тестового контура после копирования баз данных с промышленного стенда очень часто не получалось провести нагрузочное тестирование или получить валидные результаты.
Код для автоматизации нагрузочного тестирования и сбора его результатов уже был написан — но работал некорректно. В базе знаний отсутствовали важные данные, в том числе описания сути скриптов. Статистика оказалась неполной и частично ошибочной, качество пулов данных — низким.
Для того чтобы настроить прозрачный и четкий процесс работы, команда
«Перфоманс Лаб»:
Остановимся подробнее на некоторых особенностях проекта.
Одна из них — длительная подготовка к нагрузочному тестированию после копирования базы данных. Специалист «Перфоманс Лаб» получал базу данных прямо с боевой среды и подготавливал к проведению нагрузочного тестирования по длинному списку действий, накопленному коллегами.
Настройку базы данных наши инженеры автоматизировали, но лишь частично — из-за высокой сложности множества операций, в которых слишком высока вероятность ошибки, способной привести к большой потери времени на исправление. Поэтому этот риск не был принят, часть действий осталась за инженерами.
Пулы данных скриптов нагрузочного тестирования собирались некорректно. Мы исключили повторения данных, где это недопустимо, и наоборот реализовали возможность повторения, где этого требовала логика бизнес-процесса, исправили важные ошибки в критериях выборки, улучшили надежность и скорость их сбора.
Мы также обнаружили невалидную работу джобов. Дело в том, что сессии прерывались после отката баз данных. В таком случае был необходим рестарт системы — но у команды заказчика не получалось сделать это быстро и корректно.
Правильным решением оказалось создавать точку восстановления после того, как все джобы выключены.
Основные метрики производительности ЦФТ собирались в целом неправильно, поскольку не учитывали технические особенности системы (использование очередей для взаимодействия компонентов)
Агрегировались разные по сути сущности без учета внутренних взаимодействий системы. Например, платежные документы проходили через несколько этапов обработки, через несколько очередей, и для получения объективных измерений эту архитектуру необходимо учитывать.Цепочки этапов обработки различных запросов и документов (операций) различаются. Для того чтобы правильно оценивать времена обработки различных документов, мы подключили отдел сопровождения заказчика, который помог разработать два инструмента.
Один — для оценки разных этапов обработки документов (операций) расчетного центра, другой — для оценки только полезного времени обработки платежных документов (платежных операций).
Стенд был эквивалентным промышленному. Всё управление тестами производилось из Jenkins, который, в свою очередь, запускал инструменты Loadrunner и JMeter, подающие нагрузку на базу данных.
Благодаря команде «Перфоманс Лаб» пайплайн запуска теста в Jenkins стал надежным: время запуска стало соблюдаться точнее, число параметров для заполнения уменьшилось, порядок полей стал логичнее — всё это уменьшило
вероятность ошибки при запуске и ускорило процесс подготовки.
Удалось исправить крайне несовершенную работу с ДРП (функционалом для миграции клиентов в другой банк): неоптимальные запросы, избыточную длительность работы плановых заданий (джобов), создание и обработку огромных объемов данных в одной транзакции.
Мы также обнаружили неверную агрегацию данных на графиках Grafana.
Проблема заключалась в некорректных запросах, которые мы исправили.
Результаты проекта и преимущества для заказчика
Кроме того, у нашей команды есть идеи для дальнейшей автоматизации процессов в компании заказчика.
