Если вы уже выкатываете релизы автоматически и в процессе выкатки есть стадия нагрузочного тестирования, то этот рецепт – для вас.
В нашем релизном процессе был шаг выкатки на тестовый стенд, на который выкатывается сборка и нагружается трафиком. Чтобы сильно не задерживать релизный процесс, мы выставили довольно высокое стартовое значение нагрузки по принципу «ну, столько наш бэкенд точно выдержит всегда». Затем система плавно увеличивала трафик. По мере его повышения стенд переставал отвечать на запросы, тестирование завершалось, а последнее успешное значение трафика принималось за результат нагрузочного тестирования. Если результат был допустим, то релиз выкатывался дальше в продакшн.
Долгое время наш результат тестирования был более-менее стабильным. Потом добавили немного логики, потом еще немного, потом еще… А он продолжал оставаться таким же, и релизы выкатывались в продакшн. Пока кто-то не пошел зачем-то посмотреть результаты тестирования своими глазами…
Что произошло на самом деле: по мере добавления новой функциональности и деградации производительности уровень допустимого трафика на стенд постепенно падал и упал ниже заданного стартового значения. В итоге тестирование заканчивалось сразу же, как только начиналось, потому что стенд обслуживал несколько запросов и сразу же отваливался, а в результаты просто записывалось то самое стартовое значение. За это время производительность бэкенда снизилась на 50%, но об этом никто не знал.
Как стоило бы поступить:
– начинать нагрузку трафиком с нулевого значения, но это сильно замедляет процесс релиза, и для кого-то это может быть принципиально
– создать параллельный процесс полного нагрузочного тестирования, чтобы не задерживать релизы
– считать тестирование успешным в случае, если финальное значение трафика отличается от стартового
– вычислять долю успешных и неуспешных ответов от стенда