Runbook миграции серверной без простоя: план и точки контроля

Что идет не так при переезде и что значит «без простоя»

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

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

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

Самые чувствительные к переезду сервисы обычно те, у которых много внешних связей и жесткие требования ко времени: AD/LDAP, DNS и DHCP, базы данных и очереди, телефония и VDI, платежные и интеграционные шлюзы, а также мониторинг и резервное копирование (особенно если они переезжают вместе со всеми).

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

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

Инвентаризация и карта зависимостей

Runbook начинается не с расписания работ, а с точного списка того, что вы переносите и что должно продолжить работать. Если инвентаризация «примерная», переезд превращается в угадайку: не тот кабель, не тот порт, не та версия прошивки, и вы теряете часы.

Соберите единый реестр оборудования по стойкам: серверы, СХД, коммутаторы, UPS, KVM, модули SFP, патчкорды и другие «мелочи», без которых стойка не поднимется. Зафиксируйте серийные номера, схемы портов, питание (сколько линий и какие разъемы), а также текущие версии прошивок и настройки, которые сложно восстановить по памяти.

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

Зависимости описывайте простыми словами: что без чего не стартует. Примеры: «портал не работает без базы», «аутентификация нужна всем», «мониторинг нужен до начала работ, иначе вы слепы». Этого уже достаточно, чтобы понять порядок переноса.

Минимум, который стоит зафиксировать в карте зависимостей:

• RTO/RPO и допустимые окна доступности для каждого сервиса
• источники данных и направления записи (репликации, бэкапы, очереди)
• сетевые зависимости: VLAN, подсети, ACL, VIP, DNS, NTP
• точки доступа пользователей: офис, филиалы, внешние клиенты, интеграции
• текущее состояние: конфиги, схемы подключений, версии, учетные записи и доступы

Если вы привлекаете системного интегратора, просите на выходе не «отчет», а рабочую карту зависимостей, по которой команда сможет действовать ночью без лишних звонков.

Окно работ и коммуникации без хаоса

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

Кто должен быть в курсе, зависит от масштаба. Бизнес подтверждает допустимые риски и влияние на клиентов. ИБ проверяет доступы, требования к журналированию и физической безопасности. Сеть и эксплуатация отвечают за маршруты, адресацию, питание и охлаждение. Подрядчики нужны не «на всякий случай», а под конкретные задачи и с понятным временем прибытия.

Коммуникации проще держать по правилу: один координатор и один основной канал. Координатор принимает решения по паузам, фиксирует время шагов и не дает «чинить на месте» без записи в runbook.

Чтобы не утонуть в сообщениях, договоритесь о коротких статусах:

• START: шаг начат, ожидаемое время завершения
• DONE: шаг завершен, что проверили
• HOLD: остановка, причина, что нужно для продолжения
• ROLLBACK: откат, какая контрольная точка и кто исполняет

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

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

Готовность новой площадки и базовая инфраструктура

Если новая площадка не готова, никакой runbook не спасет. До перевозки железа добейтесь простой вещи: вы можете включить стойку, подключить сеть и получить предсказуемый результат.

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

• Питание: две независимые линии (если требуется), расчет по мощности, тест АВР/ИБП под нагрузкой
• Охлаждение: замеры температуры в горячих точках, запас по холодопроизводительности, понятный поток воздуха
• Стойки: крепеж и направляющие, свободные юниты, ограничения по весу и глубине
• Заземление: единая схема, замеры, без «самодельных» перемычек
• Кабельные трассы: лотки, вводы, радиусы изгиба, место под маркировку

Дальше - сеть и адресация. Согласуйте VLAN, маршруты и точки подключения так, чтобы при включении сервера не пришлось «на коленке» менять IP или правила. Отдельно проверьте DNS и DHCP (или статическую адресацию), доступы админов, ACL/фаерволы и удаленный доступ, который нужен именно в окно работ.

Требования ИБ закройте заранее: контроль доступа в помещение, журналирование входов, пломбы на стойках и понятные зоны (например, отдельно для сетевого ядра). Если есть регламенты по гостевым допускам или фотофиксации, включите их в план и назначьте ответственного.

Перед днем переезда подготовьте «расходники и геометрию». Частая ситуация: стойка с критичным сервисом приехала, а нужных SFP нет - и вы теряете часы.

• Запас патчкордов нужной длины, SFP/DAC, стяжки, липучки, заглушки
• Маркировка: принтер/этикетки, схема имен портов и кабелей
• План размещения: где стоит каждая стойка и куда идут силовые и сетевые линии
• Резерв по портам: свободные порты на коммутаторах и PDU, запасные розетки
• Мини-набор на случай аварии: консольные кабели, адаптеры, запасные вентиляторы/БП (по критичности)

Если вы работаете с интегратором или производителем, заранее согласуйте, кто отвечает за замеры, приемку и финальное подтверждение готовности площадки. Например, у GSE.kz, помимо поставки локально произведенного оборудования, есть системная интеграция и поддержка - это удобно, когда нужно заранее распределить ответственность и не выяснять ее в ночь переезда.

Как устроен хороший runbook: структура, роли, правила

Runbook на время переезда - это один источник правды. Он должен быть доступен всем участникам, но редактироваться по правилам: один владелец документа, понятная версия и список тех, кто утверждает финальный вариант. Иначе в ночь работ окажется, что у сетевой и серверной команды разные планы.

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

Роли лучше описать не должностями, а ответственностью. Минимальный набор:

• Руководитель работ: ведет тайминг, принимает решения на контрольных точках
• Сеть: каналы, маршрутизация, DNS, балансировщики
• Серверы и виртуализация: хосты, СХД, кластеры, резервное копирование
• ИБ: доступы, сегментация, журналы, контроль изменений
• Владелец сервиса: подтверждает, что сервис «работает как надо»

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

Шаблон шага

Чтобы шаги были предсказуемыми, используйте один и тот же формат:

Цель: что именно должны получить
Действия: 2-6 коротких команд/операций
Ожидаемый результат: что изменится
Проверка: как убедиться за 1-3 минуты
Откат: как вернуть исходное состояние

Тайминг и точки решений

У каждого шага должна быть оценка длительности и крайнее время, после которого вы останавливаетесь и решаете: продолжаем или откатываемся. Например, если после переноса стойки сеть не поднялась за 15 минут, это контрольная точка. Руководитель работ принимает решение, а команды действуют по заранее описанному плану, без импровизации.

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

Пошаговый план миграции: от подготовки до запуска

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

1) Подготовка (за дни, не за часы)

Начните с того, что позволит восстановиться, если что-то пойдет не по плану: резервные копии, экспорт конфигов, снимки виртуальных машин. В runbook зафиксируйте, где лежат бэкапы, кто имеет доступ и как выглядит «успешное восстановление» (например, тестовый подъем базы на стенде и проверка ключевого запроса).

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

2) Заморозка изменений

За 24-72 часа вводят change freeze: запрещены обновления, смена сетевых правил, релизы приложений, изменения в домене/сертификатах и любые «быстрые правки». Причина простая: любая смена, не внесенная в runbook, ломает прогноз и делает откат туманным.

3) Предпереключение

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

4) Остановка и упаковка

Нужен строгий порядок выключения: от верхних сервисов к базовым (приложение -> очереди -> БД -> хранилище/виртуализация, если применимо). Обязательны маркировка кабелей и портов, фотофиксация коммутации и список того, что должно уехать в каждой коробке.

5) Транспортировка и монтаж

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

6) Запуск

Включение идет от базового к верхнему: питание/ИБП -> сеть -> гипервизоры/хосты -> хранилища -> базы -> приложения -> фоновые задачи. После каждого уровня - короткая проверка (например, «БД принимает соединения», «основной API отвечает 200», «логины проходят»), и только потом следующий шаг.

Контрольные точки и критерии отката

Контрольные точки нужны, чтобы переезд не превращался в спор «кажется, все работает». В runbook заранее фиксируют моменты, когда команда обязана остановиться, сверить факты и либо продолжать, либо откатываться.

Обычно достаточно четырех точек:

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

Критерии успеха лучше задавать в цифрах и заранее зафиксировать «норму». Например: задержки не хуже базового уровня более чем на 10-15%, доля 5xx/ошибок приложений не выше обычной, контроль целостности (хэши, сверка счетчиков, выборочные транзакции) без расхождений.

Критерии отката должны быть такими же четкими. Если после включения стойки платежный сервис отвечает, но задержка выросла вдвое и растет очередь, это повод не «подождать еще час», а действовать.

• Данные не совпали при проверке целостности.
• Ошибки выше порога и не снижаются 10-15 минут.
• Нет связи с ключевой зависимостью (БД, DNS, AD) и нет быстрого обходного пути.
• Времени до конца окна меньше согласованного лимита отката.

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

Проверки после переезда и приемка работ

После переезда и включения на новой площадке самая частая ошибка - считать, что раз «пингуется», значит все работает. В runbook заранее зафиксируйте минимальный набор проверок, кто их делает и что считается нормой.

Сначала пройдите базовую «гигиену» инфраструктуры. Эти быстрые проверки ловят большинство проблем: сеть (VLAN, маршруты, MTU), DNS (разрешение внутренних имен), домен (вход и политики), доступы (VPN, bastion, админки), мониторинг (агенты и алерты), логи (поступают ли события на сборщик). Если в компании есть 24/7 поддержка, убедитесь, что дежурная смена видит новые хосты и умеет их правильно идентифицировать.

Дальше проверьте сервисы глазами пользователя и интеграций. Работает короткий сценарий: сотрудник заходит в систему, выполняет типовую операцию (заказ, платеж, запись в БД), формирует отчет и убеждается, что данные сходятся. Отдельно пройдитесь по интеграциям: обмен с 1С/ERP, почтой, внешними API, печатью, очередями.

Чтобы запуск был предсказуемым, выделите «пост-старт наблюдение» на 2-24 часа. Назначьте ответственного от инфраструктуры и от приложения и заранее согласуйте, какие метрики смотрите.

Приемка должна быть формальной:

• все критичные сервисы проходят согласованные тесты
• нет аварийных алертов, и мониторинг собирает метрики
• резервное копирование выполняется, тест восстановления пройден
• доступы и роли подтверждены, временные учетные записи закрыты
• изменения зафиксированы (схемы, IP, кабельные карты) и переданы в поддержку

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

Частые ошибки и ловушки

Даже хороший runbook может провалиться из-за мелочей, которые никто не считает критичными.

Что ломает план чаще всего

Проблемы обычно начинаются не с тяжелого железа, а с организации и зависимостей:

• Учитывают только «главные» системы и забывают про базовые вещи: DNS, NTP, лицензирование, агенты бэкапа, мониторинг, печать, интеграции с 1С или медсистемами.
• Не фиксируют критерии отката заранее. При сбое спорят, «ждем еще 10 минут» или «возвращаемся», и теряют время.
• Плохая маркировка. На месте выясняется, что патчкорды одинаковые, порты перепутаны, а схема не совпадает с реальностью.
• Окно работ без буфера. Не остается времени на проверку, прогрев, синхронизацию и стабилизацию.
• Нет единого координатора. Команды действуют параллельно, меняют настройки «по пути», и контрольные точки перестают быть точками контроля.

Маленький пример из практики

Переносят стойку с виртуализацией: хосты поднялись, ВМ стартуют, но пользователи не могут войти. Причина банальна: на старой площадке остался сервис времени, и Kerberos начал выдавать ошибки из-за дрейфа часов. Если бы в runbook был пункт «NTP доступен с новой сети, расхождение не больше X секунд», проблему нашли бы за минуты, а не после валящихся заявок.

Если вы работаете с интегратором, заранее назначьте одного ответственного за изменения и фиксацию решений. Это дешевле, чем разбирать последствия хаотичных правок ночью.

Короткий чеклист: до переезда и после включения

Этот чеклист помогает не забыть мелочи, которые чаще всего дают сбой при переезде. Держите его рядом с runbook и отмечайте выполненное по факту, а не «вроде сделали».

До выезда и перед выключением

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

• Проверьте бэкапы на восстановление: хотя бы один тестовый restore, зафиксируйте результат и время.
• Соберите контакты и дежурства: владелец сервиса, сеть, питание, безопасность, перевозчик, ответственный за площадку.
• Подтвердите доступы: VPN, учетные записи, права в гипервизоре/кластере, пароли от iLO/iDRAC/консоли.
• Перед выключением снимите «последний снимок состояния»: статус репликации, очередь задач, место на дисках, время последней синхронизации.
• Введите заморозку изменений: остановите деплой, запретите ручные правки, зафиксируйте окно изменений в журнале.

После этого спокойно готовьте оборудование к транспортировке. Маркировка должна совпадать с планом портов и схемой стойки.

Перед включением и сразу после запуска

На новой площадке сначала проверьте базу: питание, сеть и доступ к железу, а уже потом прикладные сервисы.

• До подачи нагрузки проверьте питание и сеть: фазы/UPS, VLAN, скорости портов, uplink, DNS/NTP.
• Убедитесь в доступе к консоли и удаленному управлению, чтобы не бегать к стойке из-за одной настройки.
• После запуска подтвердите ключевые сервисы по критичным сценариям (логин, запись в БД, очередь сообщений), а не только «пингуется».
• Проверьте мониторинг: метрики, алерты, логирование, резервное копирование, место на дисках.
• Ведите единый журнал работ: что сделали, когда, кто подтвердил, что пошло не так и что решили.

Пример: переезд стойки с критичным сервисом

Ситуация: у вас одна стойка с двумя хостами виртуализации, общим хранилищем (или vSAN), файловым сервисом и 1С. Бизнес дает ночное окно 4 часа, но просит, чтобы утром все работало как обычно. Главная цель runbook здесь не «успеть», а заранее договориться, что именно делаем, в каком порядке и когда принимаем решение об откате.

Карту зависимостей лучше написать простыми фразами, без схем на 20 блоков. Например: 1С зависит от домена (AD), DNS, времени (NTP), маршрутов, доступа к файловым шарам, лицензирования и печати. Файловый сервис зависит от AD и сети. Виртуализация зависит от питания, охлаждения, uplink в сеть и доступа к management-сети.

Порядок запуска можно зафиксировать так:

• Поднять базовую сеть и проверить маршрутизацию до ключевых подсетей.
• Поднять AD/DNS/NTP (или убедиться, что они доступны на новой площадке).
• Запустить хранилище и проверить целостность/репликацию.
• Запустить хосты виртуализации и затем ВМ: файловый сервис, потом 1С.
• Проверить доступ пользователей и фоновые задачи (обмены, регламенты).

Чтобы не спорить в процессе, заранее поставьте контрольные точки с понятными критериями. Например: «после включения сети есть ping и DNS-resolve для 10 тестовых узлов», «после запуска файлового сервиса открываются 3 контрольные папки с правами», «после запуска 1С за 5 минут проходит вход и открывается тестовая база».

Откат опишите как конкретное действие: возвращаем стойку на старую площадку или переключаем сервисы обратно на старые IP/маршруты, плюс кто дает команду. Полезно указать тайм-лимит: например, если к T+120 минут 1С не проходит тесты, откатываемся, а на физический возврат закладываем 60-90 минут с учетом перемещения по площадке.

Для бизнес-приемки оставьте короткие проверки: вход в 1С под тестовым пользователем, проведение одного документа, печать на контрольный принтер, открытие трех типовых файлов с сетевого диска, скорость доступа «не хуже, чем вчера» по субъективной оценке 2-3 ключевых пользователей.

Следующие шаги: как организовать переезд и кому поручить

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

Соберите основу и зафиксируйте ее в одном документе (хотя бы в таблице), затем превратите это в runbook:

• Инвентаризация: стойки, серверы, сетевое оборудование, линии питания, порты, серийные номера, контакты вендоров.
• Карта зависимостей: какие сервисы завязаны на базы, DNS, AD, сети, хранилища, лицензии.
• Критерии успеха: что должно работать в конце (метрики, доступы, RTO/RPO, список проверок).
• Критерии отката: когда откатываемся и как именно возвращаемся на старую площадку.
• Черновик runbook и короткая репетиция: один тестовый шаг (например, второстепенный сервис) с фиксацией времени и проблем.

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

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

Если нужен максимально предсказуемый результат или есть критичные сервисы, имеет смысл подключать интегратора: он поможет с планированием, репетицией и выполнением работ. В Казахстане GSE.kz может быть уместным партнером, когда требуется совместить поставку инфраструктуры, системную интеграцию и последующую поддержку, чтобы переезд не держался на «героизме» одной ночи.