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