Предупреждение: миграция — не место для экспериментов в продакшне. Ты думаешь: «перенесу за час, всё простое». Но чаще всего миграция тормозит из-за банальных ошибок, которые можно было избежать заранее. Я опишу реальные ловушки и покажу, как их обходить.
Первое, что рвёт нервы — DNS и TTL
Ты выкатываешь новый сервер, меняешь записи, и ждёшь минуту. На практике DNS может кэшироваться часами или сутками, и пользователи будут прыгать между старым и новым сервером. Совет: заранее уменьшай TTL и держи оба сервера синхронизированными на время переключения.
База данных и код — ещё одна классика ошибок
Часто забывают про кодировку, разные версии MySQL/MariaDB или отсутствующие расширения PHP. Помни: дамп базы из-old.sql может некорректно восстановиться на новом сервере. Проверь версию СУБД, кодировку и сравни структуру таблиц до переключения.
Файловые права и владельцы — источник 90% «не работает»
Ты скопировал файлы rsync-ом, но сделал всё под root, а веб-сервер работает от www-data. Результат — 500 ошибки при попытке записать в директорию uploads. Установи правильного владельца и права, и не делай chmod 777 по привычке.
Неправильные конфигурации виртуальных хостов и SSL
Часто забывают про server_name, www vs non-www и редиректы с HTTP на HTTPS. Когда сертификат не привязан к правильному домену — браузеры ругаются и трафик падает. Проверь конфигурацию nginx/apache и тестируй HTTPS заранее.
Зависимости и окружение — рано или поздно подведут
На новом сервере может не быть нужной версии PHP, модулей, Composer-пакетов или Node. Поставишь проект — и он просто упадёт с ошибкой import/require. Пропиши версию в composer.json, проверь php -v и установи все модули.
Скрытые конфиги и .env файлы:
забытые или неверные переменные убьют приложение. Частая ситуация: на локале .env.local работает, а на сервере переменные не настроены и приложение пытается подключиться к несуществующему сервису. Не копируй .env в открытый доступ и заранее сверяй ключи и адреса сервисов.
Сессии, кэш и очереди — именно они создают «интермиттентные» баги
Представь: пользователи сессируются на старом сервере, а на новом нет общей сессии — все разлогинены. Если используешь Redis, Memcached или shared storage — проверь доступ и настройки. Запланируй синхронизацию кэша или используйте общую инфраструктуру.
Cron и фоновые задачи часто забывают
Ты перенёс сайт, но забываешь зарегистрировать кронтаб и воркеры. Результат — не приходят письма, не обновляются отчёты, задачи висят в очереди. Перед переключением проверь все cron-описи и systemd-timers, запусти тестовые задания.
Email-рассылка — тихая катастрофа
Почтовая система может начать попадать в спам, если IP сервера не прописан в SPF/DKIM/DMARC. Многие сталкивались: письма с форм регистрации не доходят. Настрой почтовые записи и тестируй отправку заранее.
Отсутствие бэкапа и плана отката — смертельная ошибка
Всегда держи свежий бэкап базы и файлов, и репетицию отката в тестовом окружении. Помни историю: знакомый фрилансер потерял три дня работы из-за повреждённого дампа mysqldump без --single-transaction. Делай проверяемые бэкапы.
Логи и мониторинг — твои лучшие друзья
При переносе без логов ты будешь гадать, почему падает сайт. Настрой логирование, временные алерты и проверь диск на логах — иногда лог-файлы обходятся дороже простоя. Даже простая отправка ошибок в файл с понятным названием помогает в диагностике.
Скрипты деплоя и права доступа Git: люди руками копируют файлы и ломают симлинки
Лучше автоматизировать деплой, чтобы не забыть убрать .git или установить правильные симлинки на storage. Если приложение использует симлинки (например, storage -> shared), удостоверься, что путь совпадает.
Сетевые настройки и брандмауэры
Частая ошибка: блокируются исходящие соединения к API, к Redis или к обновлениям. Ты думаешь, сервис бедствует, а на деле iptables/ufw не пропускает порт. Проверь правила и убедись, что необходимые порты открыты.
SEO и индексация: не выключай сайт от всех поисков случайно
Бывает, что после миграции оставляют robots.txt закрытым или включают noindex. Через пару дней клиенты в панике: «трафик упал». Проверь robots.txt, метатеги и sitemap после переключения.
Проверки перед переключением — твоя страховка
Минимальный чеклист, который реально помогает: резервная копия, синхронизированные базы, проверенные права, рабочие cron/фоновые процессы, корректные DNS/TTL, тестовый прогон на staging и мониторинг. Сделай эти шаги и снизишь шанс факапа почти до нуля.
И последний совет от практики: не делай всё в одиночку в ночи. Планируй окно миграции, оповещай клиента или коллег и имей под рукой список отката. Миграции — это не гонка, а контроль качества. Немного подготовки сэкономит гору времени и нервов.
Эти ошибки я видел много раз, и почти всегда они были предсказуемы. Ты можешь избежать их простыми проверками и процедурой. Сделай паузу, пройдись по списку и не торопись — результат того стоит.