Распечатать

Не экономьте на нагрузочном тестировании. Опыт построения банковской IT-инфраструктуры

В технической статье Александр Горшков, консультант департамента консалтинга «Энвижн Груп», обосновывает необходимость организовать процесс тестирования внедряемых решений под нагрузкой, особенно, когда речь идет о бизнес-критичных приложениях в финансовых организациях.

2 сентября 2010

Александр Горшков, консультант, департамент консалтинга «Энвижн Груп»

Анализируя тенденции развития IT в крупных компаниях, можно заметить, что уже на протяжении нескольких лет основные работы направлены на централизацию IT-ресурсов. Такая тенденция определяется не данью моде, а стремлением повысить эффективность бизнеса и качество предоставляемых услуг. Однако для достижения этих целей можно использовать лишь проверенные решения, поэтому необходимо организовать процесс тестирования внедряемых изменений. В основном процесс тестирования хорошо отработан, но один важный момент не всегда принимается во внимание при планировании и проведении на грузочного тестирования — это дальнейшее развитие системы. Для подтверждения серьезности этой проблемы рассмотрим пример из реальной практики.

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

Казалось, что все условия эксплуатации воспроизведены адекватно, но именно на этом этапе и была допущена основная ошибка. Забегая вперед, скажу, что во время тестирования не воспроизводилась работа программы по балансировке нагрузки при работе с несколькими серверами приложений. Это обстоятельство в дальнейшем и сыграло роковую роль уже при эксплуатации системы.

Результаты нагрузочного тестирования показали, что решение работоспособно, а дополнительные сервера могут потребоваться лишь через полгода-год. Было принято решение начать внедрение.

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

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

Предложение аналитиков «нарастить» аппаратные ресурсы не могло радикально исправить ситуацию. Для этого требовались значительные финансовые и временные затраты, и даже после этого оставалась вероятность массового повторения сбоя. Впрочем, без этого обойтись не удалось. Но кардинально исправить ситуацию могла только переработка программного кода сервера приложения или замена программы балансировки нагрузки. Оценить, сколько потребуется времени для реализации этих изменений, разработчики были не в состоянии, ведь предстояло выполнить чрезвычайно большой объем работ. А времени на исправление положения при условии остановки промышленной эксплуатации у банка не было — бизнес не допускал снижения темпов развития. Возникла, мягко говоря, очень напряженная ситуация.

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

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

К каким убыткам привел данный сбой? Их трудно оценить в численном выражении, но сумма была значительной. К тому же все время, пока велись работы по модернизации программной части сервера приложения, развитие новых бизнес-проектов было приостановлено. Позволило бы проведение дополнительного нагрузочного тестирования с учетом масштабирования системы избежать этих потерь? Думаю, что да, или как минимум — значительно их сократить. Можно было избежать возникновения нервозной обстановки, скорректировать планы по развитию бизнеса и намного раньше приступить к устранению дефекта.

В заключение хочется обратить внимание IT-специалистов, что балансировка нагрузки многими предлагаемыми на рынке программами (в том числе и для Microsoft Terminal Server) выполняется так, как это описано выше. Для предотвращения возникновения подобных сбоев надо обязательно организовать нагрузочное тестирование наиболее ответственных систем, находящихся в эксплуатации, с учетом их масштабирования. Особое внимание следует уделить тщательной проработке проводимых тестов и не стоит пытаться уменьшить расходы за счет сокращения сроков проведения тестирования и числа проверок тестируемого функционала. Иначе может возникнуть ситуация, подобная рассмотренной выше, а мифическая экономия выйдет боком. Тестировать надо все.

Оригинал статьи в формате PDF (200 Кбайт)