Когда работа QA ограничивается только написанием тест-кейсов и автоматизацией, легко упустить из виду более широкую цель — реальное влияние на качество продукта. Настоящий QA — это про участие на всех этапах, включая прод, про понимание, как работает система на бою, и про осознанный подход к обеспечению стабильности и надёжности.

Я расскажу, как у нас в команде QA-инженеры участвуют в дежурствах на боевом контуре наравне с разработчиками: разбирают инциденты, анализируют причины сбоев и вносят улучшения в продукт и процессы. Поделюсь, какие компетенции для этого нужны, и как такой подход помогает QA не просто проверять, а действительно влиять на качество — не только после релиза, но и задолго до него.

Статья будет полезна и тимлидам с менеджерами, которые выстраивают процессы качества в команде. Она поможет по-новому взглянуть на роль QA, понять, как вовлечение инженеров в прод повышает зрелость команды и осознанность в подходе к качеству.

QA — это не только про баги

Когда я провожу собеседования, часто слышу: «QA проверяет соответствие требованиям и ищет баги». Иногда добавляют про нефункциональные требования, UX или отказоустойчивость. Всё это правда, но это только часть картины.

На деле, зелёный пайплайн и прошедшие автотесты — ещё не гарантия качества. На проде всё может пойти совсем не так. Например, сервис отвечает медленно, потому что зависимый сервис тормозит. Или в систему поступает слишком много данных, очередь растёт, воркеры не справляются — и пользователи получают ошибки.

И вот тут возникает вопрос: а должны ли QA подключаться к таким ситуациям? Я уверена — да. Потому что качество — это не только «у нас всё по плану», а «у пользователя всё хорошо». И это тоже зона ответственности хорошего QA.

Shift-left и shift-right: QA на проде

Сейчас много говорят про shift-left тестирование — когда QA подключаются на самых ранних этапах разработки. Но есть и другая сторона — shift-right. Это про участие в поддержке, в инцидентах, в анализе поведения системы в реальной жизни.

Именно об этом я хочу рассказать подробнее — как у нас устроены дежурства, как мы реагируем на инциденты и почему QA в этом процессе — не сторонний наблюдатель, а полноценный участник.

Немного контекста: как устроена наша команда

Я из команда UGC. Мы работаем над бэкендами, которые позволяют пользователям авторизовываться в приложении 2ГИС, загружать фотографии, оставлять отзывы, генерировать и получать пользовательский контент. За активность пользователи получают ачивки — и это тоже часть нашей системы.

В тестировании я уже 10 лет, последние 5 лет — в роли QA-лида. Сейчас у нас 15 инженеров, и мы вместе развиваем и поддерживаем более 30 сервисов на микросервисной архитектуре.

Наш стек: Go, Kafka, RabbitMQ, Postgres, Scylla, Cassandra, Ceph, GitLab CI, Kubernetes, Prometheus, Grafana, Jaeger, ELK. У нас полный CI/CD, и мы дежурим всей командой — и 9 разработчиков, и 6 QA. Каждую неделю кто-то один отвечает за инциденты, реагирует на алерты, делает хотфиксы и помогает эскалировать проблемы.

Зачем это нужно?

Потому что у нас серьёзная нагрузка. Например, сервис авторизации в пике обрабатывает до 35 тысяч RPS. Всего у нас 36 бизнес-сервисов, которые превращаются в 400 деплойментов в 4ДЦ, и соотвественно более 1500 подов в Kubernetes.

При такой архитектуре и нагрузке даже мелкие сбои могут вызывать серьёзные проблемы для пользователей. Поэтому нам важно быстро понимать, где началась деградация, и реагировать на неё.

QA у нас не в стороне. Мы имеем доступ ко всем тем же инструментам, что и разработка, и умеем анализировать проблемы под нагрузкой. Это позволяет нам принимать более осознанные решения. Мы начали не просто лучше тестировать — мы начали лучше проектировать.

Как выглядит наш типичный сервис

Вот базовая схема самого простого сервиса:

• Какой-то API-инстанс, который пишет в хранилище и скорее всего иногда ходит в соседние API (например за информацией об авторизации) 

• Несколько воркеров, которые читают из этого хранилища и делают что-то с данными (например, отправляют в Kafka).

• Соседние сервисы, которые читают данные из Kafka и продолжают обработку.

И в каждом месте, где есть стрелочка, может что-то пойти не так: ошибки 500 из-за соседних сервисов, забитые очереди, OOM-падения, throttling, пиковые нагрузки.

Рассмотрим на конкретном примере, как всё работает.

Что происходит на дежурстве

Понедельник, утро. QA выходит на дежурство, открывает дашборд с алертами — и видит, что в одной из очередей Kafka начало резко расти количество сообщений. Очередь не вычитывается.

Первое, что нужно сделать — построить гипотезу: почему так происходит? Возможны два варианта:

• В очередь начали писать больше данных.

• Из очереди перестали читать.

Чтобы это проверить, открываем Grafana и смотрим графики. 

Видим, что количество сообщений в очереди растёт, а потребление — на нуле. Значит, воркеры не читают.

Дальше идём смотреть, что с воркерами. Используем Lens или kubectl — неважно, какой инструмент, главное, чтобы было удобно. В логах видим, что процесс убит по OOM — воркеру не хватает памяти.

Проверяем графики потребления памяти:

Действительно, usage уходит в полку. Решение: накидываем лимиты памяти, перезапускаем деплой. После этого очередь начинает вычитываться — проблема устранена.

Можно выдохнуть, налить кофе… Но не всё так просто.

Иногда картина выглядит совсем иначе: десятки алертов, ошибки 500, 400, кастомные, всё вперемешку. 

Сервисов много, и никто не знает их все досконально (это невозможно, их более 30!) . Компоненты связаны через очереди, брокеры, вызовы — и всё это может ломаться. И вот здесь особенно важно, какими навыками обладает QA и как он понимает систему в целом.

Компетенции QA в боевом контуре

С одной стороны — это инженерная работа:

• Умение читать алерты (Karma / Alertmanager / Grafana);

• Анализ метрик и графиков (Prometheus, Grafana);

• Работа в K8s: Lens / kubectl / перезапуск подов / изменения ресурсов;

• Знание очередей: Kafka, RabbitMQ, как читать сообщения, диагностировать лаг;

• Работа с логами в Kibana / ELK;

• Понимание поведения распределенных высоконагруженных систем: ретраи, timeouts, связи между сервисами и датацентрами;

• Навигация по Jaeger: distributed tracing.

С другой стороны — это стрессоустойчивость и аналитика:

• Умение коммуницировать с Dev/SRE: быстро, по делу.

• Стрессоустойчивость: реагировать спокойно, когда всё красное.

• Навык формулировать гипотезы: быстро предполагать потенциальную причину.

• Системное мышление: видеть картину целиком, связи между компонентами.

• Инициативность: искать корень проблемы, а не просто передавать.

Именно в таких условиях прокачивается архитектурное мышление и уверенность в себе как в инженере, который влияет на стабильность продакшена.

Как дежурства меняют подход к качеству

Опыт дежурств начинает влиять на нашу повседневную работу. Мы иначе смотрим на тесты, проектирование и даже на то, какие метрики действительно важны.

Мы начинаем заранее учитывать:

• поведение при медленном ответе от внешних сервисов;

• отказ зависимостей и симуляцию сбоев в инфраструктурных тестах;

• реакцию приложения на изменение нагрузки и работу авто-масштабирования;

• наличие и адекватность таймаутов и ретраев;

• поведение фронта и клиентов при задержках (прелоадеры, заглушки, сообщения);

• восстановление после сбоев (recovery after fail);

• бизнес-мониторинг, а не только технические метрики (например, успешные заказы).

Такой подход позволяет проектировать и тестировать систему с учётом будущих инцидентов — ещё до того, как они произойдут.

А если у вас нет дежурств?

Ничего страшного. Дело не в формальном процессе, а в подходе.

Даже без дежурств можно:

• Изучать поведение системы на проде.

• Сравнивать метрики с тестовой средой.

• Анализировать алерты, даже если ты не дежурный.

• Просить доступ к дашбордам и логам.

• Задавать вопросы: «А что будет, если БД начнёт тормозить?»

Это и есть инженерия качества — не просто проверка по чек-листу, а осознанное участие в жизни системы.

Как мы прокачиваемся

Мы не стали так работать за один день. Это результат обучения, общения, наблюдений и практики. Вот что нам помогает:

• Чтение и обсуждение книг: «Высоконагруженные приложения. Программирование, масштабирование, поддержка» (Мартин Клеппман), Site Reliability Engineering (Google SRE Book), Release It! (Майкл Нигард), The Art of Monitoring (Гленн Тьюир). Кстати, «Кабанчик» — наш фаворит, обсуждаем его каждый год с ребятами, которые только пришли в команду. 

• Внутренние инструкции от команды SRE.

• Записи технических лекций внутри компании / внешние DevOps-митапы.

• Обсуждения прод-инцидентов на ретроспективах и постмортемах.

• Чтение pull-реквестов, где добавляют наблюдаемые метрики.

• Просмотр архитектурных диаграмм / воркшопы по деплою.

• Shadow-дежурства.

• Расследовать инциденты из истории логов.

• Создавать тесты, эмулирующие отказ внешнего API или сверхдолгий ответ.

• Включаться в обсуждение, где раньше «QA не принимает участие».

И, конечно, учиться замечать то, что другие упускают. Продакшн не обманет — он показывает слабые места лучше любых тестов.

Настоящее качество проверяется на проде

QA — не тестировщик, а инженер системного доверия. Можно не быть on-call, но мыслить как инженер продакшн-качества. Реальное влияние рождается в понимании слабых мест. И дежурства как раз чтобы быть ближе к реальности. Они помогают QA выйти за рамки формальных проверок и начать по-настоящему влиять на стабильность, надёжность и доверие пользователей к продукту.

А как ваша команда реагирует на инциденты на бою? Подключаются ли QA к поддержке продакшена? Делитесь опытом в комментариях — будет интересно сравнить подходы.

Хотите развивать сервисы вместе с 2ГИС — у нас открыта вакансия. А ещё мы делимся опытом в QA в телеграм-канале, заглядывайте ?