Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

Linux / DevOps

Организация сред Dev, Stage и Prod: как перестать тестировать код на боевом сервере

Обновлено: 27.08.2026 · Официальная документация ↗

Главная ошибка начинающих разработчиков

Редактирование файлов сайта напрямую на боевом сервере через FTP или SSH («правки на проде») рано или поздно приводит к фатальным последствиям: случайная синтаксическая ошибка в PHP ломает оформление заказов, а непроверенная миграция базы данных безвозвратно затирает клиентские данные.

  • Клиенты видят белый экран или фатальные ошибки прямо в процессе оформления покупок.
  • Невозможно протестировать новый функционал без риска для стабильности бизнеса.
  • Отсутствует возможность быстрого отката на предыдущую стабильную версию.

Стандарт трех контуров (Dev -> Stage -> Production)

Для надежной и предсказуемой разработки используется разделение на три изолированные среды:

  1. 1. Development (Dev-контур / Локальный ПК):

    Каждый разработчик пишет код на своем компьютере (например, в среде Docker Desktop или WSL2). Любые поломки видны только самому программисту.

  2. 2. Staging (Тестовый сервер):

    Точная копия боевого сервера (та же версия ОС, СУБД, веб-сервера и PHP/Node.js). Сюда выкатывается готовый функционал для проверки тестировщиками или заказчиком.

    # Пример изолированного контейнера Staging:
    docker run -d --name site-stage -p 8080:80 my-site:v1.2
  3. 3. Production (Боевой сервер):

    Сервер, на котором работают реальные клиенты. Код попадает сюда только после успешного тестирования на Stage через системы контроля версий (Git) и автоматического деплоя (CI/CD).

Золотое правило безопасности: У разработчиков не должно быть прямого доступа с правами root к базе данных боевого сервера. Дампы для разработки должны быть предварительно обезличены (удалены пароли, телефоны и email реальных клиентов).

💡 Практика специалистов: Мы внедрили жесткое правило: ни строчки кода не попадает на Production без прохождения автотестов и ручной проверки на Staging-контуре. Это снизило количество аварийных инцидентов у наших клиентов на 98%.

Частые вопросы (FAQ)

Можно ли разместить Stage и Prod на одном сервере?

Для экономии бюджета на начальном этапе — да, с помощью изолированных Docker-контейнеров. Однако на высоконагруженных проектах Stage выносят на отдельную виртуальную машину, чтобы тесты не создавали нагрузку на боевую базу данных.

Как изолировать доступ к Staging от посторонних глаз и поисковых ботов?

Закройте тестовый домен базовой HTTP-авторизацией через auth_basic в Nginx и добавьте директиву Disallow: / в файле robots.txt.

Что такое Blue-Green деплой?

Это метод развертывания, при котором рядом запускается новая версия проекта (Green), проверяется ее работоспособность, после чего балансировщик Nginx мгновенно переключает весь трафик со старой версии (Blue) на новую без простоя.

Какая утилита помогает синхронизировать переменные сред?

Используются файлы конфигурации .env, которые не добавляются в репозиторий Git (.gitignore). Для каждого контура (.env.dev, .env.stage, .env.prod) задаются свои пароли и домены.

Полезные материалы
Рекомендуем