Переезжает не папка с сайтом, а рабочая система
Самый обманчивый момент наступает, когда главная страница уже открылась на новом сервере. Кажется, что перенос закончен. Но форма может отправлять письма через старый адрес, фотографии — загружаться из отдельного хранилища, а остатки товаров — обновляться заданием, которое забыли перенести.
До работы полезно нарисовать простую схему без архитектурных терминов: откуда приходит посетитель, где открывается сайт, куда записывается заказ, кто получает уведомление и какие внешние сервисы участвуют. Такая схема быстрее обнаруживает забытые зависимости, чем перечень папок на сервере.
- Код сайта и его точная рабочая версия.
- База данных, пользовательские загрузки и служебные файлы.
- Переменные окружения, ключи и настройки подключения к внешним сервисам.
- Домен, DNS-зона и SSL-сертификат.
- Почтовые ящики, отправка писем с сайта и DNS-записи почты.
- Задания по расписанию, очереди, обработчики платежей и обмен с CRM или 1С.
- Резервное копирование, журналы ошибок и уведомления о сбоях.
Что зафиксировать до первого изменения
Переезд часто начинают из-за проблем со старым хостингом, поэтому хочется действовать сразу. Но несколько часов инвентаризации обычно полезнее повторного переноса. Нужно знать не только параметры нового сервера, но и текущее состояние: версии программ, объём данных, способы запуска и владельцев аккаунтов.
| Объект | Что зафиксировать | Как проверить |
|---|---|---|
| Домен | Регистратор, владелец, DNS-серверы и текущие записи | Есть административный доступ и можно изменить запись |
| Приложение | Репозиторий, ветка, команда сборки и версия среды | Проект собирается вне старого сервера |
| Данные | База, файлы, объём и время последнего изменения | Копия восстанавливается отдельно |
| Интеграции | Адреса, ключи, разрешённые IP и обратные вызовы | Есть тестовый сценарий для каждого критичного обмена |
| Фоновые задачи | Расписание, команда запуска и ожидаемый результат | Задача выполняется вручную на тестовом окружении |
| Наблюдение | Логи, проверки доступности и получатели уведомлений | Тестовое предупреждение доходит ответственному |
Сначала запустите копию, потом переключайте домен
Новый сервер можно проверить до того, как его увидят посетители. Для этого сайт открывают по временному техническому адресу или подменяют адрес только на компьютере проверяющего. Домен продолжает вести на старую версию, а команда спокойно исправляет различия окружений.
Подготовить сервер и ограничить административный доступ.
Развернуть нужные версии среды, веб-сервера и системных библиотек.
Перенести код, восстановить копию базы и пользовательские файлы.
Добавить конфигурацию и секреты через защищённое хранилище, а не внутри репозитория.
Запустить фоновые процессы и настроить их автоматический перезапуск.
Подключить журналы, резервное копирование и уведомления до публичного запуска.
Пройти основные сценарии по временному адресу.
Почему DNS и почту проверяют отдельно
После изменения DNS разные провайдеры обновляют информацию не одновременно. Некоторое время один посетитель может попасть на новый сервер, а другой — на старый. Поэтому на старой версии нельзя сразу выключать базу и удалять файлы. Иначе часть заказов окажется в месте, которое уже никто не проверяет.
Отдельная ловушка — корпоративная почта. При переносе DNS-зоны легко скопировать запись сайта и забыть MX, SPF, DKIM или служебные записи подтверждения. Сам сайт откроется, но письма перестанут приходить или начнут попадать в спам.
- Заранее сохранить полную DNS-зону, а не только запись сайта.
- Проверить срок действия домена и доступ к кабинету регистратора.
- Выпустить и проверить сертификат на новом сервере.
- Согласовать способ синхронизации заказов и файлов, появившихся во время переключения.
- Отправить тестовые письма наружу и на корпоративный адрес, затем ответить на них.
- Оставить старый сервер доступным для контроля до завершения переходного периода.
Переключение должно иметь обратный путь
План отката пишут до переключения, пока всё спокойно. В нём должно быть указано, кто принимает решение, какие признаки считаются критичными и как вернуть трафик на старую систему, не потеряв новые данные. Фраза «если что, вернём как было» не отвечает ни на один из этих вопросов.
| Сценарий | Проверка результата | Сигнал для остановки |
|---|---|---|
| Открытие сайта | Главные страницы доступны по HTTPS | Ошибки соединения или сертификата |
| Заявка | Данные появились у ответственного сотрудника | Форма успешна только со стороны посетителя |
| Заказ и оплата | Статусы и уведомления прошли весь маршрут | Деньги и статус заказа расходятся |
| Вход в кабинет | Существующий пользователь входит и видит свои данные | Сессии или данные пользователей потеряны |
| Интеграции | CRM, 1С и другие системы получают новые события | Очередь растёт или обмен остановился |
Зафиксировать момент финальной синхронизации данных.
Переключить DNS по заранее подготовленному набору записей.
Пройти критичные сценарии с внешнего устройства, не из сети разработчика.
Сравнить новые заказы и события на старом и новом сервере.
Проверить журналы ошибок, нагрузку и доставку уведомлений.
Принять решение о продолжении или откате по заранее согласованным признакам.
Что принять после переезда
После успешного переключения часто остаются временные доступы, старые ключи и сервер, который «пока пусть работает». Это нормально на время наблюдения, но у каждого временного решения должна быть дата пересмотра и ответственный.
- У компании есть административный доступ к новому серверу и биллингу.
- Описание запуска и развёртывания соответствует новой инфраструктуре.
- Резервные копии создаются на новом месте и успешно восстанавливаются.
- Мониторинг проверяет не только сервер, но и важные действия на сайте.
- Внешние сервисы и списки разрешённых адресов обновлены.
- Старые доступы отозваны, а временные ключи заменены.
- Понятно, когда и после какой проверки можно выключить старый сервер.