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

Привет, на связи Дмитрий Бессольцев, руководитель ALP ITSM. Ранее в статье на «Клерк» мы уже разбирали «идеальный» сценарий облачного переезда без простоев и авралов. В этом материале — обратная сторона: реальный «пожарный» проект со сжатыми сроками, конфликтом ожиданий и скрытыми проблемами инфраструктуры, и выводы, которые помогут пережить свой переезд без штрафов и остановки бизнеса.

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

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

• клиент, которому нужно сохранить работу бизнес‑процессов;

• текущий хостер (старая площадка), откуда нужно было уйти;

• новый облачный провайдер, предложивший мощности и базовый план переезда;

• наша команда как сервисный партнер, отвечающий за поддержку.

Дальше все осложнилось ожиданиями и управлением. Клиент рассчитывал, что миграция пройдет «под ключ» силами провайдера, но тот отвечал только за инфраструктуру — перенос данных и запуск виртуальных машин. Работоспособность бизнес‑приложений вроде 1С, почты и CRM фактически оказалась в «серой зоне»: формально за них никто до конца не отвечал.​

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

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

Исследования показывают, что компании регулярно недооценивают последствия таких решений. По данным отчета VMware Private Cloud Outlook 2025, почти половина организаций считают, что более 25% их расходов на публичные облака фактически уходят впустую — в том числе из‑за неудачных миграций и неоптимальной архитектуры. Аналитики Bloor Group отмечают, что свыше 80% проектов переноса данных выходят за рамки бюджета и сроков, причем средний перерасход по времени достигает 41%.​

Главные зоны риска хорошо видны и в нашем проекте.

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

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

• Разрыв между планом и стратегией. Многие компании стартуют с красивым календарным графиком, но без продуманного сценария действий в случае ЧП. Эксперты Monte Carlo Data подчеркивают, что частая ошибка — отсутствие понятных критериев, когда нужно остановить миграцию и откатиться. В нашем проекте формальный план был, но ни четкой стратегии отката, ни критериев качества данных не прописали — это и превратило техническую задачу в затяжной стрессовый проект.​

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

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

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

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

Смена провайдера означала и смену IP‑адресов — формально штатную операцию. На практике выяснилось, что в старых скриптах, интеграциях и на внешних порталах адреса были прописаны жестко. Актуальной карты зависимостей не существовало, поэтому переключение сети «обрубало» связи между системами в самых неожиданных местах. Восстановление заняло часы ручной работы: поиск, где именно «зашит» старый адрес, и корректировка конфигураций на ходу.​

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

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

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

Предпроектное обследование инфраструктуры и сервисов — обязательный шаг. Мы больше не полагаемся на устные описания и презентации: команда должна своими глазами видеть карту зависимостей, жестко прописанные IP‑адреса, привязки лицензий и интеграции. Для аудита фиксируем отдельный объем работ и ожидаемый результат, чтобы всем участникам было ясно, какие вопросы будут закрыты до старта переезда. Принцип простой: сначала диагностика, потом «лечение» и только после этого — переезд.​

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

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

Чтобы избежать «пинг‑понга» с задачами, заранее формируем матрицу RACI: напротив каждой операции — конкретный исполнитель, а не просто название компании. Отдельный обязательный шаг — до старта собрать всех участников проекта, познакомить команды, договориться о каналах связи и регламенте. В нашем кейсе отсутствие нормального контакта между тех. специалистами разных сторон заметно замедляло работу, поэтому сейчас этот шаг фиксируем как обязательный.​

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

Миграция в облако по уровню риска ближе к сложной операции, чем к переезду в новый офис. В медицине никто не согласится на вмешательство без анализов и обследования — в ИТ принцип тот же: без аудита и плана восстановление превращается в лотерею.​

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

Перед тем как утверждать план миграции, полезно честно ответить на несколько вопросов. Если хотя бы по одному из них нет уверенности — проект в зоне повышенного риска.​

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

2. Проведен ли аудит лицензий и есть ли список ПО, привязанного к «железу» (USB‑ключи, ID процессора), с пониманием, можно ли при необходимости докупить лицензии или потребуется переход на аналоги, доступные в РФ.

3. Существует ли рабочий план отката: что вы будете делать, если новая площадка не поднимется к условным 4 утра понедельника.

4. Был ли пилот: тестировали ли вы критичные сервисы в отдельном контуре, или сразу планируете работать «по живому».

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

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

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

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

Если тема откликается и хочется больше практики, можно продолжить знакомство с нашими историями и инструментами:

• на «Клерк» уже выходили материалы о том, как планировать облачный переезд и выстраивать отказоустойчивую инфраструктуру без простоев для бизнеса — они помогут посмотреть на свой проект глазами ИТ и финансов одновременно.​

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