Близится самая горячая и напряженная пора для онлайн-ритейла и банков. По данным Admitad, в 2022 году во время ноябрьской недели распродаж количество покупок в онлайн-магазинах увеличилось на 43% по сравнению с обычными периодами. А рост числа покупок в предновогодний период эксперты оценивают в 25-50%. Интернет помнит немало историй, когда из-за повышенного ажиотажа, например, в момент старта распродажи, сайт не справлялся с нагрузкой и «падал» из-за наплыва покупателей. Как подготовить к высокому сезону свой продукт, чтобы не потерять ни одного клиента, рассказывает директор отделения нагрузочного тестирования IBS Николай Марченко.
Классический подход и его недостатки
Привычной является ситуация, когда оценкой производительности ПО занимаются разработчики, нагрузочное тестирование проводится на стенде функционального тестирования, а узкие места обнаруживаются и исправляются уже на продуктивной среде.
Несмотря на распространенность такого подхода, у него есть ряд недостатков. Проблемы с производительностью ПО в этом случае зачастую проявляются в самое неподходящее время, когда в системе начинает работать наибольшее число пользователей, и стоимость ошибки очень велика. У разработчиков нет мотивации проверять досконально свой продукт, ведь найденные ошибки бросают тень на качество разработки, да и нагрузочное тестирование в среднесрочной перспективе несет только затраты. Поэтому проверки производительности предельно упрощаются, используются далекие по составу и конфигурации от продуктивного тестовые стенды. В совокупности все это приводит к невозможности аппроксимации результатов на реальную работу системы (другими словами — тестируется совершенно не то, что используется в продуктиве).
Как организовать действительно полезное нагрузочное тестирование
Чтобы повысить эффективность нагрузочного тестирования, следует, во-первых, разделить функции разработки и тестирования. Проверкой решения должна заниматься независимая служба, а еще лучше — отдельная организация. В таком случае создается правильная мотивация разработчиков для создания качественного продукта. Если нет возможности выделить отдельно команду тестирования, то как минимум следует предусмотреть выделение группы, контролирующей качество и глубину тестирования в проектных и продуктовых командах.
Во-вторых, модель нагрузки должна отражать бизнес и строиться на основе статистики из продуктивной среды. Если система еще не в продуктиве, можно использовать бизнес-прогнозы. Для достоверного тестирования необходимо выбрать 80-90% наиболее частотных и ресурсоемких операций.
В-третьих, тестовый стенд надо максимально приблизить к промышленному. В таком случае вы сможете говорить, что результаты, полученные на тесте, могут быть применены на продуктиве. Можно использовать результаты тестового стенда, но в этом случае нужно отдавать себе отчет в непредсказуемости итогового результата, который вы или нанятый вами консультант предполагаете получить. При росте нагрузки в 99% случаев работа системы пойдет не по плану.
В нашей практике был интересный случай, когда крупный онлайн-ритейлер решил провести нагрузочное тестирование перед наступлением пикового сезона, учитывая проблемы сервиса с нагрузкой в предыдущем пиковом сезоне. Одним из ключевых вопросов стал выбор стенда для проведения тестирования. В то время как вопрос «как тестировать» не вызывал затруднений, проблема возникла с определением подходящего стенда. Разработчики пробовали нагружать каждый сервис отдельно на слабом тестовом стенде, но такой подход не позволял полноценно оценить общую картину. Создание копии промышленного стенда также оказалось невозможным из-за сложной архитектуры и состава стенда. В конечном итоге проблему удалось элегантно решить путем проведения тестирования на продуктивной среде. Мы сгенерировали тестовых пользователей, создали тестовые магазины со своими товарами, чтобы не влиять на реальных покупателей, разработали скрипты нагрузки и начали проводить нагрузочное тестирование в ночное время — с 23:00 до 02:00. Таким образом, после тестирования мы получили не только результаты тестов, но и смогли сразу внедрить все изменения в продуктивной среде (тестировщики и разработчики работали бок о бок, находили проблемы и незамедлительно их устраняли). Этот случай оказался чрезвычайно успешным, поэтому мы настоятельно рекомендуем всем учесть его опыт.
Наконец, стоит помнить, что при проведении нагрузочного тестирования экспертиза важнее, чем инструменты нагрузки. Если вернуться к ранее приведенному примеру, то там это выглядело так. Сначала готовилась правильная модель нагрузки, определялось, какие операции будут эмулироваться, и дальше выбирался наиболее подходящий инструмент. При таком подходе вы будете решать в первую очередь бизнес-проблему, а не пытаться натянуть опыт команды, возможно недостаточный, на проблему. Можно рассматривать любой инструмент, поддерживающий протоколы системы, причем, что приятно, наиболее популярные и мощные сейчас это опенсорс-решения (Jmeter, Gattling, K6).
Основной совет, который я бы хотел бы донести до владельцев высоконагруженных продуктов, — не пренебрегайте тестированием. Лучше потратить относительно немного времени и денег в спокойное время, чтобы хорошо проверить свой продукт, подготовить его к пиковым нагрузкам и избежать возможных рисков, когда система окажется под нагрузкой.