Тестовый сервер для сайта стоит копейки по сравнению с тем, что теряет бизнес в день неудачного обновления. Staging - отдельная площадка, где движок, база данных и код совпадают с боевым сайтом, но правки на ней не видит ни один посетитель. Разбираем, как его завести и как не наделать бед самой копией.
Вопрос всплывает не в первый месяц работы сайта, а через полгода-год, когда на нём уже держится трафик и приходят заявки каждый день. Пока сайт свежий, правки вносят прямо в боевую копию: клиентов мало, ставки низкие, ошибку заметит разве что сам владелец. Когда на кону дневная выручка, "правка на пять минут" превращается в риск, на который никто не готов идти вслепую.
Чем staging отличается от локальной копии и боевого сайта
Сайт существует в трёх версиях, и путают обычно первые две.
Локальная копия. Живёт на компьютере разработчика. Годится, чтобы быстро проверить свою правку, но недоступна заказчику по ссылке, а версии PHP, базы данных и настройки сервера на ноутбуке почти никогда не совпадают с боевыми один в один. Ошибка, которая на локальной машине не проявляется, вылезает уже на хостинге.
Тестовый сервер (staging). Отдельный адрес на реальном хостинге с той же версией движка, той же СУБД и тем же набором модулей, что и на боевом сайте. Заказчик и разработчик открывают его по ссылке, но обычная публика на него не попадает: доступ закрыт паролем.
Боевой сайт. То, что видят клиенты и что индексирует поиск. Любая правка должна приходить сюда уже проверенной.
| Локальная копия | Staging | Боевой сайт | |
|---|---|---|---|
| Кто видит | только разработчик | разработчик и заказчик | все посетители |
| Окружение | своё, часто иное | как на бою | боевое |
| Подходит для | быстрой правки кода | генеральной репетиции | финального результата |
Когда без копии страшно
Есть ситуации, где выкладка без репетиции - почти всегда лотерея.
Обновление движка и плагинов. Новая версия CMS может поменять поведение старого шаблона или конфликтовать с установленным модулем. Разбирали это подробно в статье про обновление CMS без падения сайта: там же порядок действий на случай, если обновление всё-таки пошло не так.
Переезд на другой хостинг. Смена сервера меняет версию PHP, настройки веб-сервера и иногда даже часовой пояс - мелочи, которые на глаз не проверишь. Порядок безопасного переноса описан в статье про перенос сайта на другой хостинг без даунтайма.
Редизайн и правка вёрстки по всему сайту. Изменения затрагивают десятки шаблонов разом, и проверить каждый на боевом сайте руками нереально.
Миграция базы данных. Перенос структуры или объёма данных - операция, которую нельзя откатить одной кнопкой, если что-то пошло не так.
Интеграция с оплатой. Ошибка в обработчике платежей означает либо потерянные деньги клиента, либо повторное списание. Тестировать такие сценарии можно только там, где реальные деньги не участвуют.
Если обновление всё же прошло мимо репетиции и сайт лёг, порядок действий описан в статье сайт не работает: 9 причин и пошаговая диагностика.
Как поднять тестовый сервер и сколько это стоит
Три рабочих варианта, от простого к капитальному.
Поддомен на том же хостинге. Например test.сайт.ru. Занимает одну папку, использует тот же тарифный план. Самый быстрый способ и обычно бесплатный, если хостинг позволяет заводить неограниченное число поддоменов.
Отдельная папка вне корня сайта. Подходит, когда поддомены на тарифе ограничены. Придётся вручную настроить права доступа, чтобы папку нельзя было открыть по прямой ссылке.
Отдельный хостинг-аккаунт или VPS. Полная изоляция от боевого сайта: ошибка на staging физически не может задеть боевой сервер. Стоит как дополнительный небольшой тариф хостинга, обычно 150-400 рублей в месяц, для проектов с базой данных побольше - от 500 рублей.
Дальше в любом варианте: скопировать файлы, снять дамп боевой базы и залить на копию, поправить в конфигурации адрес сайта и пути к загрузкам, проверить, что сайт открывается на новом адресе.
Закрыть паролем, а не спрятать в robots
Запрет в robots.txt - это просьба к поисковому роботу, а не запрет доступа. Робот в норме её слушается, но страница всё равно остаётся доступна по прямому адресу: её найдёт человек, который получил ссылку не от вас, или другой робот, который правило игнорирует. Тестовая версия сайта из-за этого иногда попадает в выдачу с недоделанными текстами и старыми ценами - неловко перед клиентами, которые нашли её раньше официального запуска.
Рабочая защита - базовая авторизация на уровне сервера (файл .htpasswd) или ограничение доступа по IP-адресу офиса и разработчиков. Оба варианта настраиваются один раз: без пароля страницу не откроет ни человек, ни робот.
Обезличить базу: тестовые данные клиентов - тоже персональные данные
Самая частая ошибка - скопировать боевую базу на staging один в один, вместе с настоящими телефонами, почтами и именами клиентов. По 152-ФЗ это тоже обработка персональных данных, а не "техническая копия для своих": на тестовом сервере обычно слабее пароли, а доступ есть у большего числа людей, включая подрядчиков и фрилансеров, которых на время подключили к проекту. Утечка отсюда так же реальна, как с боевого сайта.
Практика простая: перед заливкой на staging прогнать по базе скрипт замены, который меняет реальные телефоны и почты на сгенерированные, оставляя структуру и объём данных нетронутыми. Для интернет-магазина то же касается адресов доставки и комментариев к заказам - там тоже встречаются личные данные.
Отключить письма и перевести оплату в тестовый режим
Ещё одна классика: на тестовом сервере нажали "оформить заказ", чтобы проверить форму, и реальному клиенту ушло письмо "ваш заказ подтверждён" с прошлой недели. Бывает и хуже: через тестовую копию проходит настоящая оплата.
Перед тем как отдавать staging кому-то на проверку, стоит отключить исходящую почту совсем или переключить её на почтовый перехватчик, который складывает письма в отдельный ящик, а не отправляет их получателям. Платёжный шлюз перевести в тестовый (sandbox) режим - у большинства эквайрингов и СБП он есть штатно, деньги в нём не списываются по-настоящему. Отдельно проверить интеграции с CRM и мессенджерами, чтобы тестовая заявка не улетела реальному менеджеру как боевая.
Когда копия сайта не нужна
Полноценный staging - не универсальное правило для любого сайта. Для простой страницы-визитки на пять экранов без форм, каталога и оплаты, где правки сводятся к замене текста или фото, отдельная копия - лишние расходы и время на поддержку. Здесь достаточно посмотреть правку в режиме предпросмотра CMS перед публикацией.
Граница простая: если ошибка в правке максимум испортит абзац текста, копия не нужна. Если ошибка может остановить приём заказов, унести деньги клиента или уронить сайт целиком, она нужна почти наверняка.
Чек-лист выкладки: как переносить изменения обратно
Переносится не всё симметрично: файлы и код едут туда и обратно, а база данных, как правило, только с боевого сайта на staging.
- Разработку и правки кода ведём на staging или в отдельной ветке, боевой сайт напрямую не трогаем.
- Перед выкладкой снимаем свежий бэкап боевого сайта на случай отката. Как это настроить, разбирали в статье про бэкап сайта.
- Файлы и код переносим на бой через систему контроля версий, деплой-скрипт или вручную по частям, но не архивом поверх всего.
- Изменения структуры базы, новые таблицы и поля переносим отдельным скриптом миграции, а не копированием всей базы: иначе сотрутся заказы, которые пришли на боевой сайт, пока правка готовилась.
- После выкладки проверяем на бою те же самые сценарии, что проверяли на staging: главные страницы, форму заявки, оплату.
- Условия работы с подрядчиком по срокам тестирования и по ответственности за сбой стоит закрепить заранее. Какие пункты для этого нужны в договоре, перечислили в статье договор на разработку сайта: 12 пунктов, которые защищают заказчика.
Сколько стоит спокойствие в день обновления
Тестовый сервер - это лишний поддомен и десять-двадцать минут на его настройку. Отдельным проектом это не назовёшь. Отбивается он один раз, в тот день, когда обновление плагина или смена хостинга проходит спокойно, потому что весь риск уже закрыли на копии. Вопрос не "нужен ли staging", а "что случится, если правка окажется неудачной прямо на боевом сайте" - и от ответа на него зависит, стоит ли откладывать эту настройку на потом.
Если планируете разработку или доработку сайта и хотите заранее прописать staging и тестовый режим как часть процесса, удобно сразу отразить это в брифе на разработку: подрядчик будет знать формат работы с самого начала.
