За последнее время наш сервис вырос как по количеству пользователей, так и в технологическом плане и вместе с ними выросли и требования к производительности наших систем.
Почему это точно интересно:
— У вас будет возможность работать над большим количеством проектов в команде профессионалов в сфере нагрузки, что позволит быстро развиваться в рамках performance тестирования.
— Как уже было сказано выше мы динамично растем и для нас актуальность производительности предоставляемого сервиса становится все выше, поэтому задач в рамках нагрузочного тестирования очень много и они довольно разнообразны по своей сути.
— Мы внедряем сервисный подход, поэтому активно автоматизируем — снижаем рутину, начиная от сбора профиля, заканчивая генерацией отчета.
— У нас есть ресурсы — мы используем очень близкие нагрузочные стенды к продуктовой среде, а если нужна идеальная точность и покрытие рисков, тогда используем продакшн.
Чем конкретно предстоит заниматься:
— Мы не занимаемся нагрузкой продуктов, вместо этого мы разрабатываем, развиваем и внедряем наш инструментарий нагрузочного тестирования в команды и инфру.
— Мы не пишем методики и не проводим долгий анализ результатов, вместо этого мы автоматизируем root cause detection, развиваем quality gate и делаем автоотчеты.
— Наши инженеры — это часть команды SRE, поэтому мы являемся владельцами сущности проблемы от архитектурного комитета до проблем менеджмента после инцидента
Требования:
— Уверенные знания подходов и методологий тестирования производительности; обязательно уметь отличать один тип тестов от другого и уметь создавать профили нагрузки.
— Опыт создания сценариев для проведения НТ и их реализации.
— Опыт работы с любым средством тестирования производительности (HP LoadRunner, JMeter, Yandex. Tank, Gatling).
— Обязателен опыт разработки заглушек/эмуляторов на любом языке программирования.
— Опыт тестирования клиент-серверных приложений (желательно с микросервисной архитектурой под капотом) и понимание принципов их работы и построения.
— Умение и желание анализировать результаты нагрузочного тестирования, локализовать проблему.
— Понимание какие нужно собирать метрики при проведении тестирования производительности и для чего они нужны.
Наш стек:
— Back: Kotlin (Spring) Ruby, Elixir, Redis, KeyDB, PGP, Golang, Hazelcast, microservices, Kafka.
— Database: PostgreSQL, MSSQL, Elasticsearch, ScyllaDB
— CI/ CD: GitLab, Kubernetes (Openshift), Argo CD, Docker Compose
Инструменты для тестирования:
— Логи/ Мониторинг: Kibana (EFK + APM), Sentry, Grafana, VictoriaMetrics, Zabbix
— НТ: Автоматизируем JMeter с помощью gitlab-ci/argocd + собственная библиотека на основе jmeter-java-dsl, ansible, bash + профильные утилиты (напр. iperf). Генерация отчетов в gitlab-pages. Заглушки на mock-server + самописные extensions.
