Реальная стоимость «переезда за один вечер»

MAATRIX

«Перенесём вечером за пару часов, чего там готовиться» — фраза, после которой обычно начинается ночь с чашками кофе и открытым логом ошибок. Идея сэкономить время на планировании миграции выглядит разумно только до момента, когда в проде всплывает забытый cron или DNS-запись, о которой никто не вспомнил. Дальше вечер превращается в утро, а «пару часов простоя» — в half a day с недовольными пользователями. Разберём, сколько на самом деле стоит такая экономия и как её посчитать заранее, а не постфактум.

Откуда берётся соблазн переехать без подготовки

Планирование миграции воспринимается как накладные расходы: нужно составить инвентарь сервисов, продумать порядок действий, протестировать новую площадку, написать план отката — и всё это до того, как перенесён хоть один файл. Когда дедлайн горит или переезд кажется «просто копированием», соблазн пропустить эту фазу велик: код и так есть, бэкап есть, DNS переключить — пять минут в панели регистратора.

Проблема в том, что этот расчёт учитывает только видимую часть работы — перенос файлов и базы. Он не учитывает скрытую часть: связи между сервисами, которые никто не документировал, потому что они «и так работают». Именно эта скрытая часть почти всегда всплывает не на этапе подготовки (там её просто не искали), а через 3-4 часа после переключения трафика, когда обнаруживается, что письма не уходят, платежи не проводятся или отчёт не сформировался.

Экономия на подготовке — это не отсутствие риска, а перенос риска с этапа планирования (когда он контролируем и стоит дёшево) на этап эксплуатации (когда он неконтролируем и стоит дорого). Дальше — почему это плохой обмен почти всегда.

Что обычно остаётся незамеченным без чеклиста

Если переезд планируется «на глазок», из поля зрения обычно выпадают не файлы сайта — их видно сразу, — а фоновые механизмы, которые не проявляют себя в момент копирования:

• Cron и systemd timers. crontab -l для каждого пользователя, systemctl list-timers --all — задачи ротации логов, очистки временных файлов, ночных бэкапов, отправки отложенных писем. Если их не перенести и не проверить на новом сервере, ошибка обнаружится не сразу, а через день-два, когда накопится место или сломается очередная зависимая задача — разбор именно такого сценария есть в статье про тихий сбой cron.
• Внешние интеграции. Вебхуки платёжных систем, callback-адреса от почтовых сервисов, IP в белых списках у партнёров — всё это привязано к старому адресу и не меняется само.
• DNS-записи не для сайта. Основную A-запись домена меняют почти всегда, а MX, SPF/DKIM, TXT-записи для верификации сторонних сервисов — забывают. Итог — письма, которые перестают доходить не сразу, а через сутки, когда истечёт TTL старой записи; это отдельный частый сценарий, разобранный в статье «письма перестали доходить после переезда».
• Сертификаты и порты. Если TLS-сертификат выпускался под старый IP или через файловую валидацию, привязанную к путям, которых на новом сервере ещё нет, HTTPS может не подняться сразу после переключения.
• Права доступа и переменные окружения. Скрипты деплоя, которые ссылаются на локальные пути, session-хранилища, специфичные версии рантайма — всё, что не входит в «просто скопировать папку с проектом».

Каждый из этих пунктов сам по себе решается за 10-20 минут, если знать, что искать. Без чеклиста их не решают заранее — их обнаруживают в проде, один за другим, в течение ночи.

Экономика спешки: почему час подготовки и час аварии — это не одно и то же

Ключевая ошибка в расчёте «переезда за вечер» — сравнение по номинальному времени, а не по цене часа. Час, потраченный на подготовку днём, и час, потраченный на устранение аварии ночью, стоят принципиально по-разному:

Это не абстракция — это то, почему один и тот же по длительности простой воспринимается совершенно по-разному в зависимости от того, был он запланирован или нет. Час заранее объявленного окна обслуживания в 2 часа ночи в воскресенье — это одно. Три часа незапланированного простоя в рабочий вторник, растянувшиеся из-за поиска причины методом «а что если», — совсем другое, даже если суммарное время меньше.

Отдельно стоит учитывать не только прямые часы, но и «хвост» — на следующий день после ночной аварии продуктивность обычно ниже: разбор постфактум, объяснения клиентам, донастройка того, что чинили на скорую руку. Этот хвост в расчёт «сэкономленного вечера» никто заранее не закладывает.

Методика: сравниваем подготовку и риск

Прежде чем решать, готовиться к переезду по чеклисту или переносить «на глазок», стоит явно сопоставить две вещи — не на глаз, а по пунктам:

1. Оцените стоимость подготовки. Это конечное и предсказуемое число:

• инвентаризация зависимостей (cron, интеграции, DNS-записи, сертификаты) — обычно 1-2 часа для типового проекта, больше для сервера с историей в несколько лет;
• тестовый прогон на новой площадке до переключения трафика — от получаса до нескольких часов в зависимости от сложности стека;
• написание плана отката — 20-30 минут, если структура миграции уже продумана.

Итого подготовка — это часы, потраченные заранее, в рабочее время, без давления.

2. Оцените ожидаемую стоимость риска без подготовки. Здесь нет точного числа — это вероятностная оценка, но её можно сделать осмысленно:

• сколько скрытых зависимостей вероятно есть в системе такого возраста и сложности (чем старше и «живее» проект, тем больше — это не подлежит точному расчёту, но интуиция инженера, работавшего с системой, обычно верна);
• какой ущерб несёт час простоя именно для этого проекта — для внутреннего инструмента компании это одно, для интернет-магазина в разгар продаж — совсем другое;
• насколько дорого исправление именно в проде: если откат занимает 5 минут (снапшот старого сервера ещё жив), риск ниже; если старый сервер уже выключен и пути назад нет — риск существенно выше.

3. Сравните не абсолютные числа, а асимметрию. Подготовка стоит фиксированные и небольшие часы. Риск без подготовки — это произведение вероятности проблемы на её цену, а цена включает не только время исправления, но и репутационные издержки, потерянные заказы, письма от клиентов «у вас всё сломалось». Даже при скромной оценке вероятности эта асимметрия почти всегда играет в пользу подготовки.

Тестовый прогон и план отката как страховка, а не бюрократия

Тестовый прогон — это не «ещё раз всё проверить для галочки», а конкретное действие: поднять сервисы на новом сервере до переключения продакшен-трафика и убедиться, что они действительно работают — не просто запустились, а обрабатывают реальные сценарии.

Практически это выглядит так:

1. Разворачиваете стек на новом сервере, база данных синхронизирована (актуальный дамп или репликация).
2. Меняете hosts на локальной машине или тестовом окружении, чтобы обратиться к новому серверу по продакшен-домену, не трогая боевой DNS.
3. Проходите ключевые сценарии руками: логин, оформление заказа, отправка письма, работающие вебхуки, cron-задачи (можно запустить вручную флагом --run-once или аналогом, если фреймворк поддерживает).
4. Проверяете логи на ошибки, которые не видны в интерфейсе — обращения к несуществующим путям, таймауты подключения к внешним API.

Отдельно — про перенос сайта без остановки старого сервера: подробный разбор такого сценария есть в статье «перенос сайта на новый VPS без простоя», а общий подход к минимизации окна недоступности при переезде между локациями — в статье «простой при переезде между локациями: как минимизировать».

План отката — это не абстрактная строчка «если что, откатимся», а конкретный, заранее написанный набор шагов:

• что именно возвращает старую конфигурацию (обычно — откат DNS-записи и/или возврат трафика на старый IP, если сервер ещё не выключен);
• сколько времени занимает откат и кто его выполняет;
• условие, при котором откат запускается: например, «если через 30 минут после переключения в логах больше N ошибок 5xx» — а не «если станет совсем плохо», потому что в 3 часа ночи «совсем плохо» определяется субъективно и поздно.

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

Когда «переезд за вечер» действительно оправдан

Справедливости ради: не каждая миграция требует многочасовой подготовки. Экономика меняется в зависимости от контекста:

• Маленький статический проект, малое количество внешних интеграций — риск объективно ниже, инвентаризация занимает 15 минут, а не полдня. Здесь «вечер» — реалистичная оценка, если вечер включает хотя бы беглую проверку cron и DNS-записей.
• Тестовый или staging-сервер без реальных пользователей — цена простоя условно нулевая, подготовка может быть минимальной.
• Есть недавний успешный опыт точно такой же миграции — если тот же стек уже переносили месяц назад по такому же процессу и всё прошло гладко, риск неожиданностей ниже, чем при миграции «в первый раз».

Но даже в этих случаях экономия не в том, чтобы не готовиться вообще, а в том, чтобы сократить подготовку до размера реального риска — например, пропустить полноценный тестовый прогон, но не пропускать инвентаризацию cron и DNS. Разница между «сократить подготовку осознанно» и «не готовиться вообще, потому что лень» — именно она и определяет, будет ли вечер вечером или растянется до утра.

Частые вопросы