Задача стояла предельно жестко: перевезти всю ИТ-инфраструктуру к новому провайдеру в сжатые сроки, не остановив при этом работу компании. Чтобы бизнес не пострадал, миграцию разбили на этапы и проводили строго в нерабочее время — по ночам и в выходные. Но то, что должно было стать серией штатных технических работ, превратилось в месяц изматывающих ночных смен. Каждый сервис при переезде «спотыкался» о непредвиденные проблемы новой площадки, заставляя команду инженеров буквально сражаться за доступность систем к утру. Рассказываем честную историю этого проекта, чтобы вы не повторяли чужих ошибок.
«Мы переедем по плану»: когда карта не совпадает с местностью
Ситуация на старте выглядела критической. Крупная производственная компания была вынуждена экстренно сменить провайдера: контракт со старой площадкой заканчивался, продлить его было невозможно. Переезд был не плановым улучшением, а вынужденной эвакуацией с жестким дедлайном.
В проекте участвовали четыре стороны:
Клиент, которому нужно сохранить бизнес-процессы любой ценой.
Текущий хостер («старая площадка»), с которого нужно съехать.
Новый облачный провайдер, предложивший мощности и базовый план переезда.
Мы (ALP ITSM) — сервисный партнер, отвечающий за поддержку.
Ситуация осложнялась завышенными ожиданиями и вакуумом управления. Клиент рассчитывал, что миграция пройдет «под ключ» силами провайдера. Но выяснилось, что провайдер отвечает только за уровень «железа» (перенос данных и старт ВМ), оставляя работоспособность бизнес-приложений (1С, почты, CRM) в «серой зоне».
При этом на проекте отсутствовал детальный план миграции и единый центр управления.
Документ, который называли «планом», был скорее верхнеуровневой дорожной картой, не учитывающей технические зависимости сервисов.
Менеджера проекта (PM), который бы координировал действия всех сторон, просто не было. От нашего предложения выделить выделенного PM-а со стороны ALP зак��зчик отказался в целях экономии, решив управлять процессом самостоятельно.
Главная проблема заключалась в том, что проект стартовал без реального предпроектного обследования.
У клиента не было четкого понимания итогового бюджета.
Новая площадка предоставила план, который не учитывал особенностей их собственной сети.
Мы на этапе пресейла тоже недооценили масштаб проблем, доверившись вводным данным.
Когда мы предложили провести аудит (проверить зависимости сервисов, лицензии), предложение отклонили из-за нехватки времени и денег.
Сложилась парадоксальная ситуация: все технические специалисты понимали, что без детального плана и аудита схема не сработает. Но остановить процесс было нельзя — сроки горели. Мы оказались перед выбором: отказаться и бросить клиента или войти в проект «как есть», приняв риски.
Мы остались. Но, понимая, что идем по минному полю без карты, настояли на одном условии: провести тестовое переключение (пилот) перед основной миграцией. Это единственное решение, которое спасло компанию от полного коллапса.
Для руководителя главный вывод простой: если в проекте нет выделенного PM и плана миграции с «картой зависимостей» и сценарием восстановления, это не проект, а надежда на чудо.
Что говорит рынок: миграция — это всегда риск
Наш случай — не уникальная аномалия, а типичная иллюстрация того, о чем предупреждают аналитики. Миграция в облако остается одним из самых рискованных ИТ-проектов, особенно если подготовка ограничивается только желанием «быстро переехать».
Вот ключевые зоны риска по данным свежих отчетов.
Бюджет всегда под угрозой
Проблема с деньгами не заканчивается в день переключения. По данным опроса VMware, почти половина компаний (49%) считают, что более 25% их облачного бюджета тратится впустую. Причина проста: при миграции «как есть» (Lift & Shift) в облако переезжают не только данные, но и все старые «болячки» архитектуры.
В нашем кейсе финансовые сюрпризы начались мгновенно: из-за привязки лицензий к старому «железу» и остановок процессов бюджет проекта вырос прямо на старте.
Время: сроки часто съезжают
Самый непредсказуемый фактор — данные. По оценке Bloor Group, более 80% проектов миграции выбиваются из графиков и бюджетов. В среднем перерасход по времени составляет 41%.
Причина — недооценка «исторического наследия». В процессе переноса всегда всплывают забытые интеграции, битые форматы и архивы, о которых не было ни слова в документации. Именно это случилось и у нас: «типовой» переезд споткнулся о реальную сложность данных.
Разрыв между планом и стратегией
Многие проекты стартуют с красивым календарным графиком, но без стратегии действий в случае ЧП. Эксперты Monte Carlo Data отмечают главную ошибку: отсутствие четких критериев «стоп-крана». Команды бегут по плану, не понимая, в какой момент нужно остановиться и откатиться назад.
В нашей истории формальный план был, но стратегии отката и критериев качества данных не было. Это и превратило техническую задачу в «месяц ада».
Анатомия катастрофы: почему месяц оказался «кровавым»
Когда мы проанализировали проект задним числом, стало очевидно: корень проблем лежал в «идеальном» плане миграции, который никак не был связан с реальной инфраструктурой. Ниже — пять точек, где он сломался.
1. Не перенос, а пересборка
На бумаге всё выглядело просто: «мигрируем виртуальные машины».
В реальности на старой площадке был зоопарк: часть серверов — виртуальные, часть — физические. Старый хостер «железо» не отдавал, и вместо «переноса ВМ» нам фактически пришлось пересобирать инфраструктуру: поднимать новые виртуалки в облаке и настраивать их с нуля под текущие сервисы.
Именно в этот момент сроки начали «плыть» с первого дня: план провайдера не учитывал фактическую архитектуру, а время на пересборку нигде не было заложено.
2. Лицензии и человеческий фактор
Отдельная проблема — лицензии 1С и спецсофта, жестко привязанные к аппаратным ключам (USB) старого оборудования. При переезде в облако они ожидаемо «превратились в тыкву».
Почему об этом не узнали заранее? Здесь сыграл роль человеческий фактор. Отношения заказчика со старой площадкой были, мягко говоря, натянутыми. Старый хостер занял жесткую позицию и не предоставил административных доступов к физическому уровню серверов. Увидеть аппаратные ключи удаленно было невозможно. Эта «мина» взорвалась при переезде, и пока производство ждало старта, подрядчики клиента экстренно искали поставщиков, чтобы купить и активировать новые программные лицензии.
3. Адресация и отсутствие карты зависимостей
Смена провайдера = полная смена IP‑адресации. На уровне презентации это выглядело штатно. На практике оказалось, что десятки старых скриптов, интеграций и внутренних сервисов жили на жёстко прописанных адресах.
Актуальной карты зависимостей не было.
Каждое переключение сети рвало очередную невидимую связку между приложениями, и её приходилось искать руками: вылавливать «упавшие» интеграции, править конфиги, перезапускать сервисы.
Без предварительного аудита адресации и зависимостей это превращается не в миграцию, а в квест «найди, что ещё сломалось после переключения».
4. Вакуум поддержки: когда вы никому не нужны
Психологически самый тяжёлый фактор — отсутствие союзников.
Старый провайдер понимал, что клиент уходит, и не видел смысла тратить ресурсы на «идеальное расставание». Поддержка оказывалась формально и по минимуму.
Новый провайдер честно держался позиции IaaS: «Мы даём инфраструктуру и гарантируем доступность виртуальных машин. Всё, что внутри гостевых ОС и приложений, — не наша зона ответственности».
Когда что‑то ломалось «на стыке», мы и заказчик оказывались крайними. Старый хостер говорил: «мы уже ни при чём», новый — «это не к нам». Созвоны превращались в поиск виноватых, а не решений, и каждая правка занимала в разы больше времени, чем могла бы при нормальном взаимодействии сторон.
5. Финал: битва за Exchange
Пик напряжения пришёлся на перенос корпоративной почты на Exchange — ключевого сервиса для продаж и взаимодействия с клиентами. Большие базы, тесная связка с AD и остальным ландшафтом Microsoft, плюс жёсткий дедлайн «к понедельнику утром всё должно работать».
Формальный план отводил на миграцию почты выходные. Реальность оказалась жестче: объём данных и накопленные по пути проблемы привели к тому, что процесс пошёл не по сценарию. Чтобы к началу рабочего дня страна смогла отправлять заказы, команда провела трое суток без сна — дебажила, перенастраивала и «оживляла» почтовый сервер в режиме нон‑стоп.
Бизнес так и не увидел катастрофы: утром понедельника почта работала. Но для команды это был тот самый финальный «кровавый босс‑файт», после которого мы пересобрали подход к миграциям — и никогда больше не соглашаемся идти в такой проект без аудита, плана и понятного управления рисками.
Работа над ошибками: как избежать повторения сценария
Несмотря на месяц авралов, проект мы вытащили. Данные не потерялись, отгрузки не остановились. Но этот успех был достигнут за счет героизма инженеров, а не правильного процесса. В ретроспективе мы сформулировали правила, которые теперь используем как жесткий стандарт для любых миграций.
1. Аудит — это не опция, а фундамент
Теперь мы категорически настаиваем на предпроектном обследовании (инструментальном аудите). Мы больше не верим «на слово» ни клиенту, ни планам сторонних провайдеров. Мы должны сами увидеть карту зависимостей, жестко прописанные IP-адреса и привязки лицензий. На аудит обязательно формируется отдельное коммерческое предложение с четким результатом.
Правило: Сначала диагностика, потом «лечение».
2. Планирование и тестовая миграция
Нельзя полагаться на план, написанный теоретиками. Перед переносом всей инфраструктуры мы всегда требуем проведения тестовой миграции (пилота) в изолированной среде. Это позволяет выявить 80% проблем до того, как они затронут бизнес.
Также необходим единый план для всех участников (клиент, мы, провайдер) и единая база знаний проекта. Коммуникация не должна быть разорвана по разным чатам.
3. Управление ожиданиями и рисками
Одна из главных ошибок этого кейса — завышенные ожидания. Теперь мы уделяем огромное внимание менеджменту ожиданий: объясняем клиенту на берегу, что может пойти не так, и составляем детальную Матрицу рисков.
Мы не боимся подсвечивать риски команде партнера (новой площадки) и предлагать помощь, если видим, что их план нерабочий. Это не критика, а страховка общего результата.
4. Матрица ответственности (RACI) и знакомство
Чтобы исключить «пинг-понг» проблемами, в список обязательных документов включена матрица RACI. Напротив каждой задачи — от настройки сети до бэкапа — должна стоять конкретная фамилия, а не название компании.
Также критически важно провести встречу с партнером (провайдером) до старта: познакомиться, обсудить подходы, «синхронизировать часы». В нашем кейсе отсутствие контакта между технарями разных команд сильно тормозило процесс.
5. Проектный менеджмент (PM) — обязательно
Хаос возникает там, где нет «головы». Даже если проектом формально управляет другая сторона (например, сам клиент или провайдер), с нашей стороны всегда должен быть выделенный Project Manager.
ИТ-директор заказчика не может координировать три команды 24/7. Нужен человек, который сводит статусы, контролирует дедлайны и, главное, держит связь между техническим подпольем и бизнесом. Экономия на PM-е обходится дороже всего.
Всё, что ниже, — не теоретическая «методичка», а набор принципов, которые мы много лет используем в проектах миграции. Этот кейс лишь подтвердил их критичность, и теперь мы жёстко придерживаемся этих правил в любых переездах — без исключений.
Скупой платит дважды: почему аудит дешевле простоя
Миграция в облако по сложности ближе к нейрохирургии, чем к переезду на дачу. Вы вряд ли согласитесь на операцию у хирурга, который скажет: «Анализы сдавать не будем, по ходу разберёмся». В ИТ этот принцип работает так же жёстко.
Цена простоя крупной компании даже за одни сутки кратно превышает стоимость самого детального аудита и пилотной миграции. Экономия на планировании — это кредит с грабительскими процентами, который придётся отдавать нервами команды, репутацией перед клиентами и ночными авралами.
Лучшая миграция — та, которую бизнес не заметил. Но чтобы эта «магия» случилась, под капотом должна быть проделана большая и довольно скучная черновая работа: инвентаризация, аудит, тестовые запуски, матрица рисков и ответственности.
В нашем «кровавом переезде» потенциальный простой завода за сутки стоил в разы дороже полного аудита. Формально на обследовании сэкономили — по факту заплатили ночными сменами и постоянным риском остановки производства.
Чек‑лист: 6 во��росов, которые спасут ваш проект
Этот список можно принести на встречу с ИТ‑директором или интегратором. Если хотя бы на один пункт ответ «нет» или «не знаем» — миграцию запускать опасно.
Понимание зависимостей
Вы точно знаете, какие 10 сервисов упадут, если отключить вот этот «неважный» сервер? Это знание проверено тестовым отключением, или это только чьё‑то предположение?Аудит лицензий
Проведён ли аудит лицензий? Есть ли список софта, который привязан к «железу» (USB‑ключи, ID процессора), и можно ли вообще сейчас купить новые лицензии? Или уже на берегу нужно закладывать переход на аналогичное ПО из того, что доступно в РФ?План отката
Есть ли рабочий план отката? Прописано ли пошагово, как вы будете возвращаться на старую площадку, если новая не запустится к 4 утра понедельника, и сколько времени это займёт?Тестовая миграция (пилот)
Был ли пилот? Проверяли ли вы критичные сервисы в изолированной среде, или сразу идёте в бой на живых данных и боевых объёмах?Матрица ответственности (RACI)
Есть ли матрица RACI? Чётко ли разделено, кто отвечает за сеть, кто за бэкапы, а кто за приложения — старый провайдер, новый провайдер, интегратор, внутренняя команда? Напротив каждой задачи должна стоять фамилия, а не название компании.Управление проектом
Кто управляет проектом? Есть ли выделенный Project Manager, который координирует все стороны и держит картину целиком, или функции управления «размазаны» по технарям между созвонами и ночными сменами?
Итого: цена урока
Эта история — не о том, как «всё сломалось». Это пример того, что бывает, когда бизнес‑риски заставляют игнорировать инженерный здравый смысл. Мы вошли в этот проект, понимая, что впереди минное поле. Мы прошли его, приняв удар на себя, и сохранили бизнес заказчика — но ценой героизма людей, а не благодаря правильному процессу.
Главный вывод ретроспективы: героизм — почти всегда следствие ошибок в планировании. Мы больше не хотим совершать подвиги там, где должна быть просто качественно сделанная работа. Миграция — это не кнопка «Перенести», а сложный инженерный проект, где 80% успеха закладывается на этапе аудита, инвентаризации и тестов, а не во время ночных штурмов.
Если вы планируете переезд в облако или смену ЦОДа, не надейтесь на «типовые сценарии» и красивые дорожные карты. Начните с честного аудита, карты рисков и ответственных.
С уважением,
Авдей Мартынович,
Руководитель подразделения по работе с средним и малым бизнесом ALP ITSM
PS. Если у вас появились вопросы — задавайте в комментариях.
