План миграции ЦОДа выглядел безупречно: графики, окна простоя, чек-листы, ответственные, запас по времени. На

План миграции ЦОДа выглядел безупречно: графики, окна простоя, чек-листы, ответственные, запас по времени. На бумаге — классический проект без сюрпризов. В реальности всё ломается там, где обычно «ну это же мелочь».

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

Главный вывод неприятный, но полезный: миграция ЦОДа — это не перенос железа, а управление зависимостями. DNS, SSL, почта, маршрутизация, бэкапы, ACL, внешние интеграции — всё должно быть проверено как единая цепочка. Один недооценённый TTL или забытый IP в allowlist способен устроить простой там, где его «не было в плане». ⚠️

Хороший проект миграции — это не отсутствие проблем. Это когда у проблем уже есть сценарий, ответственный и план отката.