Комментарии 9
Может быть, нужно провести полноценное обучение? Научить всех быть супер-спецами. Они будут делать красное нагрузочное тестирование, и все запоет-засияет. Обучили какой-то состав, ребята стали супер-спецами… и ушли в другую компанию, потому что там больше платят, например.
Вот тут я напрягся
Сейчас мы находимся на этапе планового внедрения его в каждую команду Самоката и проводим микрообучения.
Вот тут отпустило
То есть обучение нужно, но пререквизитом идет стандартизация, шаблонизация, некая база?
Скорее тут вопрос кого учить, если мы учим нагрузочных инженеров быть крутыми - это дорого, долго и сложно, а выхлоп может быть никакой. А если мы предоставляем инструмент продуктовым командам (не важна роль), даём простые гайды, и максимальное обучение это небольшой воркшоп то знания не несут такой ценности и не такие хрупкие.
И вопрос чему учить : просто знания в голове или прикладной инструмент. Другими словами не надо знать всех премудростей моделей нагрузки, детектинга перф проблем, мониторинга и тд, надо просто уметь кинуть несколько запросов в систему и для этого есть гайд, шаблон и команда помощи - все остальное сделается само :)
Очень интересно было почитать про такой подход, спасибо.
Еще важный момент — определить какой профиль нагрузки сейчас актуален, если хочется повторить ситуацию продакшена. Поэтому у нас есть автосборщик, интегрированный с нашей библиотекой, который внутрь теста подкидывает актуальные данные. Так можно с определенной точностью оценить, как текущий релиз жил бы на продакшене, если бы зарелизился прямо сейчас.
Вы собираете профиль нагрузки с продуктива.
Что используется в качестве основы? Как идет работа с параметрами запросов? Есть ли что-то аналогичные property based testing, но для нагрузки в вашем подходе?
Например, (GET) /{categoryID}/positions — есть такой метод для меню доставки товаров, и вы решили его нагрузить
Если его передать в запрос вот прямо вот так:
(GET) /30/positions, то это будет запрос без фильтров и с параметрами по умолчанию
(GET) /30/positions?type=ALL&limit=100
Возвращает сначала 10 000 элементов и оставляет из них 100, у такого запроса пусть узкое место в том, что там фильтрация Limit 100 внутри сделана не средствами SQL-запроса, а средствами фильтрации коллекции ответов в памяти бекенда на Java/Kotlin
(GET) /30/positions?type=ALL&limit=100&search=Pizza
Возвращает сначала 5 элементов пиццы и оставляет из них 5 — этот запрос пусть работает всегда быстрее, чем предыдущие два варианта, потому что тут результатов мало из-за более строгой фильтрации
В тесте будут использоваться полные URL или может только первый вариант без параметров? Деперсонализация базы данных позволит использовать оригинальные ID-шки в тестовых запросах
Отличный вопрос и очень дорогостоящий :)
В рамках того подхода, что я описываю в статье есть на самом деле очень понятный конвеншн - мы хотим быть ближе к пользовательскому трафику настолько, чтобы нагрузка приносила пользу, но сами тесты не требовали космических затрат по времени. И тут мы делим подход к таким запросам на три этапа, каждый из которых повышает трудозатраты. На каждом из этапов мы можем принять решение исключить запрос из QG и делать на него отдельные тесты, которые нам будут понижать риски (вне QG у нас есть много практик):
Мы просто ориентируемся на то что считает правильным разработчик, плюс можем помочь принять ему решение проведя маленькое ревью логов и их времени выполнение запроса относительно набора параметров. Результатом будет грязная и быстрая параметризация, которая в целом нас устраивает какое-то время.
Далее мы с помощью любых наших практик, например QG скажет что расхождение с продом очень высокое или мы увидим на алертах что этот запрос стреляет в 99 персентилей по 15 сек. Мы можем сделать довольно просто - можем провести анализ на "полезные" свойства (возвращаясь к property based testing) или на "тяжелые" и тестировать только близкий к плохому сценарий. В этом случае мы точно знаем, что пользователь не будет всегда ходить по тяжелым кейсам и если наша система выдержит нагрузку ими, то любые лёгкие кейсы ей вообще не составит труда. Есть вариант, когда подмешиваем простые кейсы в нагр. Баланс тут зависит от того, что реально держит система и что должна держать. Но ключевым является парадигма, что тяжелых запросов должно быть больше чем на продуктиве.
Если все равно получаем сигналы о больших расхождениях или другими путями понимаем, что нагрузка непоказательна. Тогда мы можем сделать 2 варианта: а) собирать распределение динамически с прода в каждом тесте - это может быть анализ логов, метрик, даже распределение по времени например; б) собрать распределение разово и делать запросы на основе него. у первого варианта понятное ограничение - воспроизводимость. у второго тоже - актуальность. обычно на выбор влияет источник данных, например мы не можем сходить из теста за самым актуальным распределением в продовую базу, а например в ELK можем. Распределение можно представить в виде CSV, но тогда нужно много данных чтобы обеспечить сходимость или в виде мапы с шансом и значениями, она может быть с просто с уникальным набором ключей.
Кирилл, спасибо! Тут любой вопрос дорогой. Вот вы делали, в том числе эксперименты, командой 2-4 человека в течение 4 месяцев. Это 12 человеко-месяцев, мифических. Мне хочется сделать за спринт или за пару дней ))
И поэтому я думаю вообще не писать тесты пока, массово не писать. Вот есть статистика, пусть в Elastic, есть понятные способы ее обработки и мониторинга. И уже можно завести дефекты на ряд очевидных случаев.
Для неочевидных случаев, где нужно профилировать на тестовом стенде, в качестве исключения можно написать тесты. Сначала самые дешевые и простые. Потом посложнее, с параметрами, если простых не хватит.
Это очень хороший подход, но только это уже ближе к SRE. Мы развиваемся в похожей модели, но в ней пока главная роль у перф тестов, где не помимо QG есть ещё много всего. Наша концептуальная модель - мы овнеры проблем производительности и отказоустойчивости начиная с архитектурных комитетов, создания конвеншнов и поддержкой тестового воркэраунда, заканчивая тестами в проде, хаос инжинирингом и инцидент менеджментом. Постепенно на главную роль выходит бюджет ошибок.
И да, мы тоже чаще всего идём сейчас в максимально простые тесты лишь бы не было проблем. И вот основная комплексность появляется как раз там где что-то идёт не так: сразу задумываешься, а это тесты плохие или реально проблема есть, потом ударяешься в параметризацию, распределения, а проблема все есть и так постепенно обрастаешь толстыми сложными тестами.
Если не ударяться в разработку своего инструментария, попробовать заранее решить потенциальные проблемы с инфой, то думаю можно за месяц успеть
"Поэтому мы поставили заранее несбыточную цель — успеть сделать все от нажатия кнопки «Провести тест» до разворачивания стенда и получения результатов за 15 минут."
отлить в граните))))
PerfOps — быстрее и дешевле через сервисный подход