План миграции серверов: как переехать с контролируемым простоем

Определите результат миграции и условия успеха

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

Для каждого сервиса назначьте владельца и согласуйте измеримые критерии: какие функции должны работать, какие данные сверяются, сколько простоя допустимо, с какой точки допустимо восстановление и кто принимает результат. RTO и RPO здесь цели планирования, а не юридическая гарантия. Их достижимость доказывает репетиция на сопоставимом объёме данных.

Постройте карту зависимостей, а не список серверов

Инвентаризация по именам хостов недостаточна. Приложение зависит от DNS, каталога пользователей, сертификатов, базы данных, файловых ресурсов, очередей, почты, планировщика, лицензирования, API партнёров, мониторинга и резервного копирования. Часть связей проявляется только в конце месяца или во время фонового задания.

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

• ОС, версия приложения, СУБД, агенты защиты и совместимость целевой платформы.
• IP-адреса, DNS-имена, NAT, правила межсетевого экрана и балансировщики.
• Сервисные учётные записи, gMSA или аналоги, секреты и сертификаты.
• Входящие и исходящие интеграции, расписание и механизм повторной доставки.
• Объём данных, скорость изменения, окно копирования и фактическое время восстановления.
• Ответственные, контакты в окно миграции и порядок эскалации.

Предупреждение: обнаруженная после переключения зависимость от старого IP часто превращает запланированный простой в расследование. Не выключайте исходную среду до завершения периода стабилизации.

Разбейте перенос на волны по риску

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

Оцените риск по влиянию простоя, сложности зависимостей, изменчивости данных, обратимости и уровню знания системы. Высокорисковые системы получают отдельную репетицию, больше времени на сверку и формальный go/no-go. Не совмещайте миграцию с обновлением приложения, ОС и схемы базы без необходимости: несколько изменений затрудняют диагностику и откат.

1. Выделите связанные компоненты и определите обязательный порядок запуска.
2. Расположите волны от низкого риска к высокому, учитывая календарь бизнеса.
3. Назначьте технического руководителя окна и единственный канал координации.
4. Для каждой волны подготовьте runbook, тесты, критерии остановки и откат.
5. Оставьте резерв времени до начала следующей волны.

Спроектируйте перенос данных и период заморозки

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

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

Проведите репетицию с измерением времени

Репетиция должна пройти по тому же runbook, теми же инструментами и на сопоставимом объёме. Записывайте начало и конец каждого шага, ошибки, ручные решения и фактическую пропускную способность. Иначе окно останется оценкой, а не прогнозом.

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

• Запуск служб после перезагрузки и корректность зависимостей.
• DNS-разрешение, сертификат и аутентификация пользователей.
• Чтение, запись и фоновая обработка.
• Интеграция в обе стороны и обработка накопленной очереди.
• Резервное копирование и мониторинг уже целевой среды.
• Нагрузочный сценарий и запас ресурсов в пиковом режиме.

Если репетиция не уложилась в окно, нельзя просто надеяться на более быстрый production. Уменьшите объём финальной дельты, ускорьте канал или хранилище, разбейте перенос либо согласуйте другое окно.

Подготовьте cutover и откат как две полноценные процедуры

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

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

1. Объявить начало окна и остановить изменения по утверждённому сценарию.
2. Зафиксировать точку данных и выполнить финальную синхронизацию.
3. Переключить DNS, маршрутизацию или публикацию сервиса.
4. Выполнить технические проверки до допуска пользователей.
5. Провести бизнес-приёмку и принять решение go/no-go.
6. При нарушении критерия остановиться и запустить заранее проверенный rollback.

Проверяйте данные на нескольких уровнях

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

Автоматизируйте повторяемые проверки, но не подменяйте ими смысловую сверку. Совпавшее число строк не доказывает корректность расчётов, а ручной просмотр пары карточек не выявляет пропущенную таблицу. Результаты сохраняйте вместе с временем, версией и исполнителем.

Стабилизируйте сервис и закройте старый контур

После переключения установите период усиленного наблюдения. Сравнивайте ошибки, задержки, загрузку, очереди и успешность заданий с базовой линией. Все инциденты привязывайте к одной временной шкале миграции; это помогает отличить новую проблему от существовавшей ранее.

Старую среду выводите из эксплуатации только после бизнес-приёмки, прохождения согласованного периода и подтверждения резервного копирования цели. Затем отзовите правила доступа и секреты, обновите CMDB, схемы, инструкции восстановления и лицензирование. Данные удаляйте по принятой политике; сам факт миграции не определяет юридический срок хранения.

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

• Передайте первой линии известные изменения и признаки эскалации.
• Сохраните итоговый runbook и фактический тайминг.
• Разберите отклонения и назначьте корректирующие действия.
• Закройте временные сетевые правила и административные доступы.
• Проверьте первую плановую копию и очередной цикл фоновых заданий.