Shift-left в performance-тестировании: нагрузочные тесты в CI/CD

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

Shift-left переносит нагрузочные тесты на более ранние этапы цикла разработки: регрессия становится видна в том же PR, который её внёс.

Мышление shift-left

Традиционное performance-тестирование происходит поздно: после feature freeze, на staging-окружении, силами выделенной QA-команды. Shift-left переносит его в:

1. Smoke-тесты на каждый PR — 30-секундные тесты с малым числом VU, ловят очевидные регрессии
2. Ночные soak-тесты — длинные прогоны на ветке main
3. Pre-deploy gate — средний нагрузочный тест как условие мержа в production

Настройка GitHub Actions

name: Load test (smoke)
on:
  pull_request:
    paths:
      - 'src/**'
      - 'tests/load/**'

jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: grafana/setup-k6-action@v1
      - name: Run smoke test
        run: |
          k6 run \
            --vus 5 \
            --duration 30s \
            --out json=results.json \
            tests/load/smoke.js
      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: k6-smoke-results
          path: results.json

Правильный тест для каждого этапа

Этап	Длительность	VUs	Порог
PR smoke	30s	5	p95 < 1000ms
Ночной load	10m	50	p95 < 500ms, err < 1%
Pre-deploy stress	5m	200	p99 < 2000ms

Что измерять

Не ограничивайтесь кодами ответов. Отслеживайте:

• Долю ошибок — http_req_failed должен оставаться ниже вашего SLO
• Пропускную способность — RPS не должен падать относительно прошлого прогона
• Латентность p95/p99 — сравнивайте с baseline, а не только с абсолютными значениями
• Память/CPU — если инфраструктура отдаёт метрики, коррелируйте их

Цель — не зелёный бейдж, а данные, говорящие: «этот PR не сделал хуже».