Production (продакшен, прод) — рабочее окружение, в котором приложение работает для реальных пользователей. Противопоставляется staging (тестирование) и development (разработка). Изменения в production требуют особой осторожности: ошибка затрагивает всех пользователей.
Как работает
Production-окружение отличается от остальных по нескольким критериям: реальные пользователи и данные, максимальная стабильность и производительность, ограниченный доступ для изменений, мониторинг и алертинг в реальном времени. Код попадает в production через pipeline: development → CI-тесты → staging → ручное тестирование → production.
Конфигурация production отличается от staging: production-секреты (пароли БД, API-ключи) хранятся отдельно, Nginx настроен на максимальную производительность, кеширование включено, подробное логирование отключено (чтобы не замедлять).
История
Термин «production environment» появился в корпоративной IT-культуре 1980-90-х годов. В ранних системах всё делалось в одном окружении — разработка прямо на продакшен-сервере. Катастрофические последствия таких практик привели к разделению на dev/test/prod. В 2000-х зафиксировалось правило: разработчик не должен иметь прямой доступ к production без процедуры одобрения (change management). DevOps-движение 2010-х снова ускорило деплои через CI/CD, не снижая контроля.
Production vs Staging
| Критерий | Production | Staging |
|---|---|---|
| Пользователи | Реальные | Команда разработки |
| Данные | Реальные (GDPR!) | Анонимизированные копии |
| Деплой | Через CI/CD с approve | Автоматически при merge |
| Масштаб | Production-ready | Уменьшенный |
| Доступ | Ограниченный | Для всей команды |
Стратегии деплоя в production
Blue-Green Deployment: две идентичные production-среды (blue и green). В данный момент пользователи на blue. Новая версия деплоится на green и тестируется. Переключение — мгновенное изменение балансировщика нагрузки с blue на green. Откат — обратное переключение за секунды.
Canary Release: новая версия деплоится на 5% серверов. 5% трафика идёт на новую версию. Если метрики нормальные — постепенное увеличение до 100%. Kubernetes Ingress или Nginx поддерживает weight-based routing.
Rolling Update: контейнеры заменяются по одному без простоя. Docker Swarm и Kubernetes реализуют из коробки.
На что обращать внимание
«Работает на моей машине» — не значит «работает в production». Различия в версиях ОС, библиотек, конфигурации Nginx между dev и production порождают «works on staging, breaks in prod». Решение — Infrastructure as Code (Terraform, Ansible) и Docker: одинаковая среда везде. Никогда не отлаживайте проблемы напрямую в production — клонируйте конфигурацию на staging и воспроизводите там.
Feature Flags
Feature flags (флаги функций) позволяют деплоить код в production без включения функциональности. Новая фича деплоится, но включается только для определённых пользователей (AB-тест) или процента трафика. LaunchDarkly, Unleash, Flipt — специализированные инструменты. В простейшем случае — конфиг в Redis или ConfigMap Kubernetes с флагами on/off.
Преимущество: rollback при проблемах занимает секунды (отключить флаг) против минут (откат деплоя). Новые функции можно показывать только внутренним пользователям для финального тестирования в production-окружении с реальными данными — без риска для всех клиентов.