Автоматизация создания тестовых сред для банков – новая тенденция времени

Как технический директор департамента по работе с финансовыми организациями «Техносерва» в последнее время я все чаще сталкиваюсь с намерениями ряда крупных банков оптимизировать процесс подготовки и создания тестовых сред.

Информационные технологии за последние несколько лет претерпели значительные изменения. Этот факт не мог не отразиться на процессе тестирования. Логично, что руководители ИТ-департаментов таких крупных банков, как Промсвязьбанк, ВТБ 24, Россельхозбанк, УРАЛСИБ или «Хоум Кредит», задумываются о реорганизации этого процесса. CIO банков говорят совершенно логичные вещи: «Прежде чем внедрять систему, мы обязаны ее качественно протестировать на работоспособность. Мы не хотим, чтобы через полгода у нас был глобальный сбой. Сервис для клиентов не должен быть остановлен ни при каких условиях! Это главное требование нашего бизнеса».

Понимая эту потребность, «Техносерв» подготовил специальное предложение по созданию и управлению тестовыми средами. Под этой услугой мы понимаем организацию тестового стенда высокой степени готовности, на котором можно качественно и оперативно «прогнать» практически любое решение, используемое в банке. Почему проработка технического решения создания тестовых сред должна быть поручена внешней организации, а не выполняться силами собственных сотрудников? Ответ не очевидный, но вполне понятный. Накопленный опыт реализации в предыдущих проектах тестирования и создания тестовых сред позволяет избежать многих ошибок. Приведу пример одной такой ошибки из практики, когда я работал в ИТ-департаменте одного крупного банка.

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

Результаты нагрузочного тестирования показали, что решение работоспособно, а дополнительные сервера потребуются только через полгода-год. На основании этого заключения было принято решение о начале внедрения. До определённого момента система функционировала достаточно стабильно. Периодически в эксплуатации наблюдались сбои, но никто не мог дать конкретного объяснения причины их возникновения. Так как эти сбои были очень редки и устранялись оперативно, то до детального анализа причин их возникновения дело не дошло. Ситуация кардинально изменилась после того, как сбои неожиданно стали повторяться ежедневно. Для анализа проблемы и поиска обходного решения были привлечены все ресурсы банка - аналитики, программисты и сотрудники подразделения поддержки.

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

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