«Кровавый переезд»: как миграция в облако превратилась в месяц ада

Автор: Наталья Волчкова, Руководитель отдела системного администрирования ALP ITSM.

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

«Мы переедем по плану»: когда карта не совпадает с местностью

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

В проекте участвовали четыре стороны:

• Клиент, которому нужно сохранить бизнес-процессы любой ценой.
• Текущий хостер («старая площадка»), с которого нужно съехать.
• Новый облачный провайдер, предложивший мощности и базовый план переезда.
• Мы (ALP ITSM) — сервисный партнер, отвечающий за поддержку.

Ситуация осложнялась завышенными ожиданиями и вакуумом управления. Клиент рассчитывал, что миграция пройдет «под ключ» силами провайдера. Но выяснилось, что провайдер отвечает только за уровень «железа» (перенос данных и старт ВМ), оставляя работоспособность бизнес-приложений (1С, почты, CRM) в «серой зоне».

При этом на проекте отсутствовал детальный план миграции и единый центр управления.

• Документ, который называли «планом», был скорее верхнеуровневой дорожной картой, не учитывающей технические зависимости сервисов.
• Менеджера проекта (PM), который бы координировал действия всех сторон, просто не было. От нашего предложения выделить выделенного PM-а со стороны ALP заказчик отказался в целях экономии, решив управлять процессом самостоятельно.

Главная проблема заключалась в том, что проект стартовал без реального предпроектного обследования.

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

Когда мы предложили провести аудит (проверить зависимости сервисов, лицензии), предложение отклонили из-за нехватки времени и денег.

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

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

Что говорит рынок: миграция — это всегда риск

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

Вот ключевые зоны риска по данным свежих отчетов.

Бюджет всегда под угрозой

Проблема с деньгами не заканчивается в день переключения. По данным опроса VMware, почти половина компаний (49%) считают, что более 25% их облачного бюджета тратится впустую. Причина проста: при миграции «как есть» (Lift & Shift) в облако переезжают не только данные, но и все старые «болячки» архитектуры.

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

Время: сроки часто съезжают

Самый непредсказуемый фактор — данные. По оценке Bloor Group, более 80% проектов миграции выбиваются из графиков и бюджетов. В среднем перерасход по времени составляет 41%.

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

Разрыв между планом и стратегией

Многие проекты стартуют с красивым календарным графиком, но без стратегии действий в случае ЧП. Эксперты Monte Carlo Data отмечают главную ошибку: отсутствие четких критериев «стоп-крана». Команды бегут по плану, не понимая, в какой момент нужно остановиться и откатиться назад.

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

Анатомия катастрофы: почему месяц оказался «кровавым»

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

Нулевой километр: как мы избежали полной остановки

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

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

1. Не перенос, а пересборка

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

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

2. Лицензии и «человеческий фактор»

Отдельная проблема — лицензии 1С и спецсофта, жестко привязанные к аппаратным ключам (USB) старого оборудования. При переезде в облако они ожидаемо «превратились в тыкву».

Почему об этом не узнали заранее? Здесь сыграл роль человеческий фактор. Отношения заказчика со старой площадкой были, мягко говоря, натянутыми. Старый хостер занял жесткую позицию и не предоставил административных доступов к физическому уровню серверов. Увидеть аппаратные ключи удаленно было невозможно. Эта «мина» взорвалась при переезде, и пока производство ждало старта, подрядчики клиента экстренно искали поставщиков, чтобы купить и активировать новые программные лицензии.

3. Адресация и отсутствие карты зависимостей

Смена провайдера означала полную смену IP-адресации. В теории — штатно. На практике — в десятках старых скриптов и на порталах дистрибьюторов адреса были прописаны жестко (hardcoded).

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

4. Фактор равнодушия: когда вы никому не нужны

Самый психологически тяжелый момент — вакуум поддержки.

• Старый провайдер уже понимал, что клиент уходит. У него не было никакой мотивации помогать, предоставлять глубокие доступы или тратить ресурсы своих инженеров на «красивое прощание». Поддержка оказывалась формально, по минимуму.​
• Новый провайдер занял принципиальную позицию «мы даем инфраструктуру (IaaS), а не сервис». Их инженеры отвечали за доступность виртуальных машин, но не готовы были погружаться в проблемы приложений, баз данных или настройки сети внутри ОС.​

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

5. Финал: битва за Exchange

Апогеем стал перенос почтового сервера Exchange — сердца продаж. Сервис сложный, капризный к архитектуре и тесно связанный с остальным ландшафтом Microsoft. К тому же — огромный объем баз данных.

План отводил на это выходные. Из-за накопленных ошибок и объема данных процесс пошел не по сценарию. Чтобы в понедельник утром страна смогла отправить заказы, наша команда провела трое суток без сна. Мы дебажили, перенастраивали и оживляли сервер в режиме нон-стоп.

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

Работа над ошибками: как избежать повторения сценария

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

1. Аудит — это не опция, а фундамент

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

Правило: Сначала диагностика, потом «лечение».

2. Планирование и тестовая миграция

Нельзя полагаться на план, написанный теоретиками. Перед переносом всей инфраструктуры мы всегда требуем проведения тестовой миграции (пилота) в изолированной среде. Это позволяет выявить 80% проблем до того, как они затронут бизнес.

Также необходим единый план для всех участников (клиент, мы, провайдер) и единая база знаний проекта. Коммуникация не должна быть разорвана по разным чатам.

3. Управление ожиданиями и рисками

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

Мы не боимся подсвечивать риски команде партнера (новой площадки) и предлагать помощь, если видим, что их план нерабочий. Это не критика, а страховка общего результата.

4. Матрица ответственности (RACI) и знакомство

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

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

5. Проектный менеджмент (PM) — обязательно

Хаос возникает там, где нет «головы». Даже если проектом формально управляет другая сторона (например, сам клиент или провайдер), с нашей стороны всегда должен быть выделенный Project Manager.

ИТ-директор заказчика не может координировать три команды 24/7. Нужен человек, который сводит статусы, контролирует дедлайны и, главное, держит связь между техническим подпольем и бизнесом. Экономия на PM-е обходится дороже всего.

Скупой платит дважды: почему аудит дешевле простоя

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

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

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

Чек-лист: 6 вопросов, которые спасут ваш проект

Проверьте свой план миграции. Если хотя бы на один пункт вы ответите «нет» или «не знаю» — вы в зоне риска.

1. Вы точно знаете, какие 10 сервисов упадут, если отключить вот этот «неважный» сервер? Знание проверено тестовым отключением или это только чье-то предположение?
2. Проведен ли аудит лицензий? Есть ли список софта, который привязан к «железу» (USB-ключи, ID процессора) и можно ли вообще сейчас купить новые лицензии? Или в силу объективных обстоятельств (санкции, уход вендоров) необходимо заложить переход на аналогичное ПО из списка доступных в РФ ?
3. Есть ли план отката (Rollback)? Прописано ли пошагово, как вы будете возвращаться на старую площадку, если новая не запустится к 4 утра понедельника?
4. Был ли «пилот»? Проверяли ли вы критичные сервисы в изолированной среде, или сразу идете в бой на живых данных?
5. Есть ли матрица ответственности (RACI)? Четко ли разделено, кто отвечает за сеть, кто за бэкапы, а кто за приложения — старый провайдер, новый или интегратор?
6. Кто управляет проектом? Есть ли выделенный Project Manager, который координирует все три стороны, или эти функции «размазаны» по технарям?

Итого: цена урока

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

Но вывод, который мы сделали на ретроспективе: героизм — это следствие ошибок в планировании.

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

Если вы планируете переезд в облако или смену ЦОДа — не надейтесь на «типовые сценарии». Приходите к нам до того, как таймер начнет отсчитывать часы до отключения серверов. Мы проведем аудит, найдем все «скелеты» и сделаем так, чтобы ваш переезд прошел скучно. Без драм, без валидола и без героев.

Обсудите безопасную миграцию с экспертами ALP ITSM.