Testing in Production: когда staging недостаточно

В главе «Как проверить надёжность до продакшена?» мы разбирали нагрузочное тестирование, а в «Chaos Engineering» — управляемые сбои. Но между staging и chaos engineering есть зона, которая долгое время считалась табу: тестирование на реальном проде.

Testing in Production (TiP) — это не про «забить на staging и фигачить в проде». Это набор техник, которые дополняют pre-production тесты и ловят то, что в staging в принципе невозможно воспроизвести: реальный трафик, реальные данные, реальное железо, реальные баги в зависимостях.

Почему staging недостаточно

Казалось бы, в staging — копия прода, можно всё проверить. На практике:

1. Тестовые данные не похожи на реальные. В staging у вас 1000 записей, в проде — 100 миллионов. Сложные edge cases, невалидные кодировки, огромные вложения, странные регулярные выражения — всё это проявляется только на реальных данных.

2. Тестовый трафик не похож на прод. В staging вы делаете 100 запросов через JMeter. В проде пользователи делают 10000 RPS с паттернами, которые нельзя воспроизвести: волны, спайки, зависимость от времени суток.

3. Реальное железо и сеть. В staging у вас условный EC2, в проде — конкретная железка в конкретном регионе с конкретной сетевой топологией.

4. Реальные зависимости. В staging у вас mock-сервисы. В проде — реальные API третьих сторон, реальные баги их поведения.

5. Реальное время. Состояние системы накапливается за месяцы: индексы в БД разрослись, логи забили диск, метрики показывают дрейф. В staging, который разворачивается из образа каждый день, этого нет.

Вывод: тесты в staging обязательны, но недостаточны. Нужны практики, которые работают с реальной системой.

Техники Testing in Production

1. Canary deployment

Уже разбирали в «Canary и Progressive Delivery»: раскатка новой версии на 1-5% трафика, проверка метрик, расширение или откат.

Это базовая форма TiP: новая версия живёт в проде, но получает только часть реального трафика.

Метрики для решения: - Error rate новой версии vs старой - Latency p95/p99 - Бизнес-метрики (конверсия, время на странице)

Длительность: от часа до нескольких дней, зависит от цикла бизнеса.

2. Feature Flags

Тоже разбирали в «Feature Flags». Новый код деплоится в прод, но включается через флаг для подмножества пользователей.

Ключевое отличие от canary: feature flag позволяет выключить фичу мгновенно без деплоя. И тестировать не только новую версию, но и новую логику на старой версии.

3. Shadow traffic (теневой трафик)

Новая версия получает копию продового трафика, но ответы пользователю отдаёт старая версия. Это позволяет нагрузить новую версию реальными данными без риска для пользователей.

Реализация: - TCP-level дублирование (NGINX mirror, Envoy shadowing) - Application-level копирование (отдельная очередь в Kafka)

# Envoy route с shadow policy
routes:
  - match:
      prefix: "/api"
    route:
      cluster: payment_v2
      request_mirror_policy:
        cluster: payment_v3_shadow
        runtime_fraction:
          default_value:
            numerator: 100
            denominator: HUNDRED

Плюсы: реальные данные, реальная нагрузка, ноль риска для пользователей. Минусы: не тестирует правильность ответа (пользователь видит ответ от старой версии). Нужно сравнивать метрики между двумя версиями вручную.

4. Synthetic monitoring (синтетические проверки)

Регулярные запросы к проду от внешних регионов, имитирующие действия пользователя. Ловят проблемы до того, как о них сообщат клиенты.

Примеры: - Каждые 30 секунд: открыть главную, проверить цены, положить в корзину, оплатить - Каждые 5 минут: авторизоваться под тестовым пользователем, проверить баланс - Каждый час: запустить поиск, проверить выдачу

Инструменты: Blackbox exporter для Prometheus, Datadog Synthetics, Pingdom, Checkly.

Что ловит: - DNS резолвится - TLS-сертификат валиден - Login работает - Главная отвечает за < 3 секунды - Корзина не падает с 500

Что НЕ ловит: - Реальные ошибки пользователей (только синтетические сценарии) - Долгосрочные проблемы (drift модели, накопление данных)

5. A/B testing для надёжности

Разделение трафика на группы с разной логикой, сравнение не только конверсии, но и метрик надёжности.

Пример: старая логика vs новая логика обработки платежа. Сравниваем: - Error rate - Latency - Retry rate - Конверсия

Это классический A/B-тест, но с метриками надёжности как критериями успеха.

6. Real User Monitoring (RUM)

Сбор реальных метрик от пользователей в браузере или мобильном приложении.

Что ловит: - Время загрузки страницы у реальных пользователей - Core Web Vitals (LCP, FID, CLS) - JavaScript errors - API latency с точки зрения пользователя

Инструменты: Sentry, Datadog RUM, New Relic Browser, Google Analytics.

Плюсы: видите реальный пользовательский опыт, а не синтетику. Минусы: требует инструментации на клиенте, privacy-вопросы.

7. Error tracking в проде (Sentry-style)

Автоматический сбор ошибок с контекстом: stack trace, переменные окружения, действия пользователя до ошибки, окружение (браузер, ОС, регион).

Инструменты: Sentry, Rollbar, Bugsnag, GlitchTip.

Что даёт: - Раньше узнаёте о проблемах - Видите, как воспроизвести - Приоритизация по частоте и severity - Группировка связанных ошибок

8. Load testing в проде (load shedding, spike testing)

Специально запускают нагрузку выше нормальной в продакшен-окружении, но в контролируемых условиях: - Spike test: кратковременный пик в 10x, проверка что автоскейлинг срабатывает - Soak test: длительная нагрузка в нормальном режиме, поиск утечек памяти - Capacity test: постепенное увеличение нагрузки до отказа

Когда это уместно: если у вас есть standby-регион или shadow environment с продовым трафиком. На основном проде без контроля — опасно.

9. GameDay

Запланированный день, когда команда намеренно ломает систему и тренируется её чинить. Chaos engineering в продакшене, но с предупреждением и наблюдателями.

Что даёт: - Проверка runbook-ов на реальной системе - Обучение команды - Выявление скрытых зависимостей

Когда делать: раз в квартал для критичных систем.

Что должно остаться в staging

Не нужно бросаться всё тестировать в проде. Staging остаётся для:

  • Smoke tests — базовая проверка, что деплой не сломал очевидное
  • Integration tests — критичные пользовательские сценарии
  • Pre-merge проверки — тесты перед принятием PR
  • Performance regression — проверка, что код не стал медленнее
  • Security scanning — статический анализ, dependency check

Staging — это первый барьер. Testing in Production — второй, который ловит то, что первый пропустил.

Риски TiP и как с ними жить

Риск 1: Повреждение продовых данных. Решение: фикстуры, откаты транзакций, dry-run режим.

Риск 2: Ухудшение UX реальных пользователей. Решение: canary на 1-5%, feature flags, kill switch.

Риск 3: Сложность анализа. Решение: Wide Events (см. главу «Wide Events и Observability 2.0»), хороший трейсинг.

Риск 4: Privacy и compliance. Решение: анонимизация данных, разделение трафика по регионам, opt-in для новых пользователей.

Риск 5: Ложное чувство безопасности. Решение: TiP дополняет, а не заменяет staging-тесты. Не выбрасывайте unit-тесты ради TiP.

Как начать

Не пытайтесь внедрить всё сразу. Начните с того, что даёт быструю отдачу:

  1. Canary deployment — на следующий релиз, через ваш CI/CD
  2. Synthetic monitoring — 5 ключевых сценариев на главной
  3. Error tracking (Sentry) — если ещё нет
  4. Feature flags — для фич, которые трудно откатить

Дальше по мере зрелости: 5. Shadow traffic — для критичных компонентов 6. A/B тесты для надёжности — для крупных изменений 7. GameDay — раз в квартал

Когда НЕ нужен TiP

  • Если у вас нет real-time мониторинга. Без observability вы не увидите, что тест в проде что-то сломал.
  • Если вы не умеете откатывать релизы. TiP требует способности быстро откатиться.
  • Если данные в проде настолько чувствительные, что нельзя даже читать. Тогда shadow traffic не сработает.
  • Если у вас один клиент и одна фича. Staging достаточно.

Резюме

Testing in Production — это не «тестируем в проде, потому что лень делать staging». Это набор техник, которые дополняют pre-production тесты:

  • Canary deployment — раскатка на 1-5% трафика
  • Feature flags — включение нового кода для подмножества
  • Shadow traffic — копия трафика без риска для пользователей
  • Synthetic monitoring — регулярные проверки снаружи
  • A/B testing — сравнение вариантов по метрикам надёжности
  • RUM и error tracking — реальный пользовательский опыт
  • GameDay — управляемые сбои для тренировки

Главное правило: staging обязателен, но недостаточен. Только комбинация pre-production и in-production практик даёт уверенность, что система надёжна в реальных условиях.

См. также: «Нагрузочное тестирование», «Chaos Engineering», «Feature Flags», «Canary и Progressive Delivery», «Wide Events и Observability 2.0», «OpenTelemetry».