План отката миграции: что подготовить заранее

MAATRIX

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

Почему план отката обычно не пишут

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

Проблема в том, что вероятность неудачи никак не связана с тем, насколько тщательно вы готовились к успеху. Миграция может провалиться по причине, которую вы не могли предусмотреть в принципе: провайдер режет трафик по новому IP, в проде всплывает race condition, которого не было на тесте, у клиента браузер кэширует старый DNS ещё сутки. План отката нужен не потому, что вы плохо подготовились, а потому, что любая система, которую вы не контролируете полностью (сеть, DNS-резолверы клиентов, сторонние API), может преподнести сюрприз.

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

Точка невозврата: где проходит граница

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

Точка невозврата разная для разных видов миграции, но у неё всегда есть чёткие технические маркеры:

Общий принцип: точка невозврата — это момент, когда старая система перестаёт быть источником истины (для данных) или перестаёт получать трафик (для сети). Всё, что происходит до неё, обратимо почти бесплатно. Всё, что после — требует явных шагов и может стоить данных за период между точкой невозврата и обнаружением проблемы.

Практический приём: если это DNS-переключение, снизьте TTL записи до 300 секунд за 24–48 часов до миграции. Это не отменяет точку невозврата, но резко сокращает её «стоимость» — откат DNS-записи разлетится по резолверам за 5 минут, а не за 24–72 часа, как бывает при TTL по умолчанию (3600 и больше). Про похожую грабли — статья о проблемах с DNS после переезда: часть пользователей продолжает видеть старый сервер ещё долго после смены записи именно из-за кэширования, и это работает в обе стороны — и на переезд, и на откат.

Критерии решения об откате: определите их до, а не во время паники

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

Решение — сформулировать критерии отката числами, заранее, в спокойном состоянии. Например:

• Доля ответов 5xx превышает 5% в течение более 10 минут подряд.
• Время ответа критичных эндпоинтов (логин, оплата, поиск) выросло более чем в 3 раза от базового уровня и не падает 15 минут.
• Три подряд тестовые транзакции оплаты завершились ошибкой.
• Обнаружена потеря или рассинхронизация данных (например, лаг репликации новой БД растёт, а не падает).
• Прошло больше X минут сверх запланированного окна даунтайма без признаков решения проблемы.
• Критичный сторонний интеграционный сервис (платёжный шлюз, CDN, почтовый релей) не проходит проверку на новой инфраструктуре.

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

Пошаговые технические шаги отката — прописанные заранее

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

Хороший план отката — это пронумерованный список конкретных команд, а не абзац текста. Обычно порядок ровно обратный порядку миграции, но не всегда: некоторые шаги миграции необратимы напрямую и требуют отдельного шага компенсации (например, если новая БД уже приняла часть новых записей — их надо не отбросить, а перенести обратно).

Пример шаблона отката для миграции сайта на новый VPS:

ОТКАТ МИГРАЦИИ СИТА example.com — версия от 2026-08-20

1. Убедиться, что старый сервер 203.0.113.10 жив и отвечает:
   curl -I http://203.0.113.10 --resolve example.com:80:203.0.113.10

2. Вернуть A-запись на старый IP через API регистратора:
   curl -X PATCH "https://api.registrar.example/domains/example.com/records/A" \
     -H "Authorization: Bearer $REG_TOKEN" \
     -d '{"value": "203.0.113.10", "ttl": 300}'

3. Проверить, что запись обновилась у самого регистратора и на публичном резолвере:
   dig +short example.com @8.8.8.8

4. Если использовался CDN/прокси (Cloudflare и т.п.) — сбросить кэш и
   переключить origin обратно на старый IP в панели CDN.

5. На старом сервере убедиться, что данные не устарели: сверить время
   последнего бэкапа/синхронизации с моментом начала миграции.
   Если разница есть — восстановить дельту (см. шаг 6).

6. Перенести обратно записи, созданные пользователями УЖЕ на новом
   сервере после переключения (заказы, комментарии, загруженные файлы):
   rsync -avz --dry-run root@NEW_IP:/var/www/uploads/ /var/www/uploads/
   (сначала --dry-run, проверить список, потом без флага)

7. Уведомить команду и пользователей о завершении отката.

8. Оставить новый сервер включённым для разбора причины сбоя —
   не трогать до отдельного пост-мортема.

Обратите внимание на пункт 6 — это как раз то самое «необратимое» действие: если пользователи успели что-то создать на новой системе после переключения, простой откат DNS отбросит эти данные, если не перенести их вручную. Хороший план отката всегда учитывает такие «хвосты» отдельно, а не делает вид, что их не будет.

Для отката базы данных шаблон похожий, но критичнее по времени:

1. Остановить запись приложения в новую БД (maintenance mode / feature flag).
2. Зафиксировать точку расхождения: последний общий бинлог/WAL LSN.
3. Экспортировать записи, созданные ТОЛЬКО в новой БД после cutover:
   pg_dump --data-only --table=orders --table=users \
     -h new-db-host -U app_user appdb > delta.sql
4. Переключить конфиг приложения обратно на старую БД (DATABASE_URL).
5. Применить delta.sql к старой БД, проверив конфликты по первичным ключам.
6. Снять maintenance mode.
7. Запустить скрипт сверки количества записей и контрольных сумм
   между старой БД и последним снапшотом новой.

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

Не отключайте старую инфраструктуру сразу после переключения

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

Практика, которая себя оправдывает:

• Держите старый сервер запущенным минимум 3–7 дней после переключения (для несложных проектов) или дольше для критичных систем — стоимость лишней недели аренды VPS почти всегда меньше стоимости часа простоя при экстренном откате без рабочего запасного варианта.
• Не удаляйте данные со старого сервера — переведите его в режим "только для чтения" или просто отключите от записи трафика, но оставьте диски и БД нетронутыми.
• Если возможно, оставьте одностороннюю синхронизацию с нового сервера на старый на переходный период (например, cron-задача, копирующая новые файлы), чтобы в случае отката не пришлось долго искать различия. Делайте это аккуратно — синхронизация должна быть строго в одну сторону, чтобы не создать конфликт записи в обе БД одновременно.
• Зафиксируйте снапшот/бэкап старого сервера прямо перед его окончательным выводом из эксплуатации — это отдельная точка отхода даже после того, как активный план отката уже не нужен.

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

Кто принимает решение об откате и кто его выполняет

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

Минимальное разделение ролей, которое работает даже для команды из двух человек:

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

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

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