Как организован процесс уточнения ресурсов для новых микросервисов и баз данных с эксплуатацией
Что проверяют
Видите ли вы себя частью процесса, в котором требования к нагрузке превращаются в конкретные ресурсы, или считаете это чисто задачей эксплуатации. От QA ждут понимания нефункциональных требований и того, как тестирование подтверждает, что запрошенного хватит. Следом спрашивают, как вы проверяли это на практике.
Как отвечать
Отвечайте на своём опыте: кто в команде заводил запрос на ресурсы, через какой канал (тикет по шаблону, архитектурное ревью, чек-лист готовности к запуску) и какую часть делали вы. Каркас процесса:
- исходные цифры: ожидаемый RPS в среднем и в пике, допустимое время ответа по p95 и p99, объём данных на старте и прирост за год. Без них разговор с эксплуатацией сводится к «дайте побольше»;
- ресурсы сервиса:
requestsиlimitsпо CPU и памяти в Kubernetes, число реплик, правила автомасштабирования HPA; - база: объём диска с запасом на рост и индексы, лимит соединений (
max_connectionsв PostgreSQL, пул вроде PgBouncer), реплики, бэкапы и время восстановления; - тестовые стенды: отдельный запрос ресурсов на стенд для нагрузочного тестирования и данные объёмом, близким к проду.
Роль QA здесь конкретная: нагрузочный тест в k6, JMeter или Gatling по согласованному профилю, отчёт с метриками (при каком RPS выросли задержки, во что упёрлись, были ли OOMKilled и троттлинг CPU) и вывод, достаточно ли запрошенных ресурсов. Этот отчёт и становится аргументом в разговоре с эксплуатацией.
Если в выделении ресурсов вы не участвовали, так и скажите и опишите ту часть, что делали сами: стенды, тестовые данные, нагрузка. Если и нагрузку не вели, честно покажите, как подошли бы к ней по шагам выше.
Где спотыкаются
Отвечают «это не наша зона». Для QA на микросервисах это минус: сбои из-за нехватки памяти и лимитов соединений как раз и должны ловиться на тестировании.
Гоняют нагрузку на стенде в разы слабее прода и линейно пересчитывают результат. Узким местом часто оказывается база или сеть, и линейной зависимости там нет.
Забывают про базу: сервис держит нагрузку, но после масштабирования до десяти реплик пулы соединений упираются в max_connections, и новые подключения база отклоняет.