При переезде офиса отключение и подключение ИТ-оборудования необходимо выполнять в заранее согласованной последовательности. Серверы, системы хранения данных, сетевое оборудование и корпоративные приложения связаны между собой, поэтому нарушение порядка остановки может привести к повреждению данных, сбоям сервисов и увеличению времени простоя.
План ИТ-переезда должен описывать не только физический демонтаж техники, но и безопасное завершение работы систем, восстановление инфраструктуры на новой площадке, действия при неудачном запуске и итоговую проверку доступности сервисов.
1. Инвентаризация, резервное копирование и фиксация схемы
Подготовка начинается с инвентаризации оборудования и сервисов. Необходимо составить перечень серверов, систем хранения данных (СХД), коммутаторов, маршрутизаторов, межсетевых экранов, источников бесперебойного питания (ИБП) и рабочих станций.
Для каждого критичного компонента фиксируют его назначение, место установки, зависимости от других систем, ответственного специалиста и планируемое время отключения.
Резервные копии по правилу 3-2-1
Перед остановкой критичных систем необходимо убедиться в наличии актуальных резервных копий данных и возможности их восстановления. Для организации резервного копирования применяют правило 3-2-1:
3 копии данных — рабочая версия и две резервные; 2 разных типа носителей или независимых сред хранения; 1 копия за пределами основной площадки.
Для ИТ-переезда особенно важно, чтобы резервная копия не перевозилась вместе с единственным рабочим экземпляром данных. Перед началом работ проверяют успешность последних заданий резервного копирования и, для критичных систем, возможность восстановления из резервной копии.
Экспорт конфигураций сетевого оборудования
До отключения необходимо сохранить конфигурации маршрутизаторов, коммутаторов и межсетевых экранов. Для устройств, использующих Cisco-подобный синтаксис, это может быть экспорт текущей конфигурации running-config, а также сохранённой конфигурации запуска.
В зависимости от производителя аналогичные настройки выгружают штатными средствами управления. В резервных копиях конфигураций важно сохранить сведения о VLAN, маршрутизации, интерфейсах, правилах фильтрации и других параметрах, необходимых для восстановления сети.
Файлы конфигураций следует хранить в защищённом месте с ограниченным доступом, поскольку они могут содержать чувствительную техническую информацию.
Фиксация соединений и коммутации
Перед демонтажем необходимо задокументировать подключения оборудования. Для кабелей используют бирки, на которых указывают оба конца соединения по принципу:
До отключения кабелей выполняют фотофиксацию патч-панелей, портов коммутаторов и задних панелей серверов. Фотографии должны позволять различить номера портов и фактическое расположение соединений.
Отдельно сохраняют актуальную схему сети и размещения оборудования в стойках. Такая документация помогает восстановить коммутацию без попыток определить назначения кабелей уже после переезда.
2. Последовательность выключения — Down-последовательность
При отключении инфраструктуры сначала завершают работу пользовательских и прикладных систем, затем останавливают обеспечивающие их платформы. Это позволяет снизить риск незавершённых транзакций, повреждения данных и некорректного выключения виртуальных машин.
Для типовой корпоративной инфраструктуры последовательность может выглядеть следующим образом:
- Пользовательские сессии. Предупредить сотрудников о времени остановки, завершить активные подключения и запретить новые операции в критичных приложениях.
- Бизнес-приложения: CRM, ERP, 1С. Корректно остановить прикладные службы, фоновые задания и интеграции, чтобы исключить новые обращения к базам данных.
- Базы данных (СУБД). Убедиться в завершении транзакций, выполнить предусмотренные процедуры остановки и штатно завершить работу серверов баз данных.
- Виртуальные машины и гипервизоры. Завершить работу оставшихся виртуальных машин, проверить их состояние, затем штатно остановить хосты виртуализации, например VMware ESXi или Proxmox VE.
- Системы хранения данных (СХД). После прекращения обращений со стороны серверов корректно остановить системы хранения в соответствии с документацией производителя.
- Ядро сети. После остановки зависимых систем отключить коммутаторы, маршрутизаторы и другое сетевое оборудование, которое больше не требуется для управления инфраструктурой.
- Источники бесперебойного питания. После штатного отключения подключённого оборудования вывести ИБП из работы по предусмотренной производителем процедуре.
Это базовая логика остановки, а не универсальная команда для любой инфраструктуры. Например, службы управления виртуализацией, доменные контроллеры, DNS или отдельные сетевые устройства могут потребоваться до завершения остальных операций.
Поэтому перед переездом необходимо построить фактическую карту зависимостей и определить, какие инфраструктурные сервисы должны оставаться доступными до последнего этапа.
3. Последовательность запуска — Up-последовательность
После перевозки оборудование устанавливают на подготовленной площадке и проверяют физические подключения. Запуск выполняют в обратном направлении: сначала восстанавливают питание, сеть и базовые инфраструктурные компоненты, затем серверные платформы и прикладные сервисы.
Для типовой инфраструктуры порядок включения следующий:
- Вводное электропитание и ИБП. Проверить питание, состояние электрических линий, готовность ИБП и возможность безопасного включения оборудования.
- Каналы связи. Проверить готовность операторских подключений, провайдерского оборудования, внешних шлюзов и необходимых физических линий.
- Сетевое ядро. Запустить маршрутизаторы, L2/L3-коммутаторы и необходимые сетевые сервисы. Проверить VLAN, маршрутизацию, а также доступность DNS и DHCP по мере запуска соответствующих серверов или сетевых устройств.
- Системы хранения данных. Запустить СХД, проверить состояние контроллеров, дисковых групп, томов и готовность ресурсов хранения для серверов.
- Серверы виртуализации. Запустить гипервизоры ESXi, Proxmox VE или другие используемые платформы, проверить доступность хранилищ и состояние виртуальной инфраструктуры.
- Доменные контроллеры и инфраструктурные службы. Запустить Active Directory, проверить DNS, DHCP и другие необходимые службы, если они размещены на виртуальных или физических серверах.
- Серверы баз данных. Запустить СУБД, проверить доступность баз, состояние служб и корректность подключения приложений.
- Прикладные сервисы и почта. Восстановить CRM, ERP, 1С, почтовые системы и интеграции, проверить выполнение основных бизнес-операций.
- Рабочие места сотрудников. Подключить пользовательские устройства, проверить доменную авторизацию, сетевые ресурсы, периферию и доступ к корпоративным приложениям.
На практике порядок может корректироваться с учётом архитектуры. Например, если DNS или DHCP работают на виртуальных серверах, они становятся доступны после запуска соответствующей виртуальной инфраструктуры. При этом физические сетевые подключения и маршрутизация должны быть подготовлены заранее.
После каждого критичного уровня необходимо подтвердить его работоспособность. Переходить к запуску зависимых компонентов следует только после проверки систем, от которых они зависят.
4. План отката и приёмочное тестирование
Даже при подробной подготовке запуск на новой площадке может пойти не по плану. Причиной могут стать ошибки коммутации, несовместимость настроек, неисправность оборудования или недоступность внешних каналов связи.
Поэтому до переезда необходимо определить план отката — Rollback Plan. Он описывает действия, которые выполняются, если восстановить критичные сервисы в установленное время не удаётся.
Что предусмотреть в плане отката
Для каждого критичного сервиса фиксируют допустимое время простоя, условия принятия решения об откате, ответственного специалиста и доступный способ восстановления.
Возможные варианты включают возврат к сохранённой конфигурации оборудования, восстановление данных из резервной копии, переключение на резервную площадку или использование временной инфраструктуры.
При этом физический возврат всего оборудования в старый офис не всегда возможен. Если прежняя площадка уже отключена или освобождена, план должен предусматривать реалистичный альтернативный сценарий.
Решение об откате необходимо принимать до того, как будет исчерпано согласованное окно простоя. Для этого заранее устанавливают контрольное время и критерии, при которых продолжение запуска становится нецелесообразным.
Приёмочное тестирование после запуска
После восстановления инфраструктуры необходимо проверить не только включение оборудования, но и доступность сервисов с точки зрения пользователей.
Для этого выполняют контрольные операции: проверяют сетевые соединения, авторизацию, доступ к файловым ресурсам, работу баз данных, корпоративных приложений, почты и телефонии.
Результаты фиксируют в протоколе приёмки. Если выявлены неисправности, указывают их влияние на работу компании, ответственного за устранение и результат повторной проверки.
- Инвентаризация завершена, схема подключений и фотографии коммутации сохранены.
- Резервные копии проверены, правило 3-2-1 учтено, экспорт конфигураций оборудования выполнен.
- Down-последовательность согласована, ответственные назначены, критичные зависимости учтены.
- Электропитание, ИБП, каналы связи и сетевая инфраструктура новой площадки проверены.
- СХД, виртуализация, доменные службы, СУБД и приложения запущены в согласованном порядке.
- Сетевые соединения, VLAN, маршрутизация, DNS и DHCP работают корректно.
- CRM, ERP, 1С, почта и другие критичные сервисы прошли функциональную проверку.
- План отката доступен, результаты приёмочного тестирования зафиксированы.
Чёткая последовательность отключения и запуска помогает снизить риск повреждения данных, избежать ошибок при восстановлении связей между системами и сократить простой компании во время переезда офиса.
ИТ-переезд офиса
X-Com помогает спланировать перенос ИТ-инфраструктуры, организовать отключение и демонтаж оборудования, выполнить перевозку, подключение и проверку систем на новой площадке.
Подробнее об услуге →
