5 ошибок миграции в облако: разбор провального переезда клиента
Представьте картину: на третьей неделе миграции меня буквально бросили в самый эпицентр провала — как скорую помощь на поле боя. В офисе царил хаос: бухгалтерия не могла выписать ни единого счёта, учёт смен на производстве встал колом, а директор, видя это, уже нанял адвоката для суда со старым подрядчиком. Знаете, мне пришлось всё это расхлёбывать. Сегодня хочу поделиться с вами историей: расскажу о пяти критических ошибках, которые превратили, казалось бы, обычный переезд IT-инфраструктуры в настоящий полуторамесячный ад.
Кто я? Меня зовут Семёнов Евгений Сергеевич. Я в IT-инфраструктуре малого бизнеса уже 15 лет. За это время я лично провёл и, что важнее, восстановил больше двадцати различных миграций. Этот конкретный кейс — наглядный учебник, пособие «как не надо делать». Понятно, имена мы скрыли, но цифры здесь абсолютно реальны.
Контекст: что и куда переезжало
Наш клиент — это крупное производство металлоконструкций, их штат — 47 рабочих мест. Офис у них в Москве, прямо на Дубровке, а цех расположен в Балашихе. Вся их IT-инфраструктура до недавнего времени держалась на старой площадке: два физических сервера HP DL380 G8, стоящие в стойке у местного провайдера. Всё на них и 'крутилось'.
Что было:
- Типичная картина: Windows Server 2016 с Hyper-V, а на нём — целых 9 виртуалок. Это и AD, и файловый сервер, и 1С УПП с MSSQL, и Exchange 2016, плюс RDP-ферма. Ещё сервер для CAD-чертежей с лицензиями Autodesk, биллинг для отгрузок, веб-сервер intranet. И, конечно, Ardour, который всё это мониторит. Представляете, какая это связка?
- Знаете, один физический сервер мы так и не перенесли. Почему? Он управлял станками, а HASP-ключ был буквально воткнут в материнскую плату. Перенести такое оказалось просто невозможно. Так что этот остался на земле.
- Бэкап на Synology в офисе по VPN-каналу.
- Внешний IP, на нём — Exchange, RDP, веб.
Какая была цель? Переехать в Yandex Cloud, используя формат IaaS. Это позволило бы разом избавиться от ежемесячных платежей в 280 тысяч рублей за хостинг и колокацию. А что дальше? Новый бюджет в облаке оценили всего в 95 тысяч рублей. Посчитали? Выходит, экономия — целый миллион двести тысяч в год! Идея-то, согласитесь, совершенно здоровая. А вот её реализация... увы, нет.
Хронология провала
И вот тут началась первая проблема: заказ ушёл интегратору. Выяснилось, что они никогда прежде не делали миграции с физических серверов. Тем не менее, продали услугу «под ключ» за 380 тысяч рублей. Обещали? Всего две недели работы и нулевой простой! Их план? Это было нечто: пять шагов, уместившиеся на одной странице. Дальше события развивались...
- Неделя 1. Интегратор поднял в облаке базовую инфраструктуру: VPC, два DC, шаблоны виртуалок. Пока всё хорошо.
- Неделя 2. Начали мигрировать AD. Поднялся новый домен с новым именем, потому что старое имя уже было где-то занято в самом облаке (так интегратор сказал, я потом проверил — было неправдой). Потащили часть пользователей, потеряли группы и GPO.
- Неделя 3. Перенос файлового сервера через robocopy без сохранения NTFS-прав. Пользователи начали жаловаться на доступ к чужим папкам и невозможность открыть свои. Дали всем full access на корень "временно" — это потом аукнулось.
- Неделя 4. Попытка перенести 1С УПП. БД 280 ГБ, переносили через дамп. На новом сервере не запустилась — лицензии HASP остались привязаны к старой материнке. Дополнительно — конфигурация работала через сетевой принтер по жёсткому IP, который, конечно, в облаке поменялся.
- Неделя 5. Меня позвали через знакомого на пожар. Бухгалтерия не работает 6 рабочих дней, склад ведёт учёт в Excel-файле на флешке.
Ошибка №1: отсутствие предпроектного аудита
Симптом
Приехали эти интеграторы, посмотрели дашборд Hyper-V. Знаете, что спросили? Всего два вопроса: «Сколько у вас места и памяти?» На основе этого... они составили смету. Какая глубокая аналитика, правда?
Что не учли
- Беда с 1С: в её конфигурации были пять регламентных задач, намертво привязанных к UNC-путям старого файлового сервера. Что произойдёт в облаке? Правильно, эти пути просто исчезнут, и задачи встанут.
- А как вам такое: в групповых политиках обнаружилось перенаправление папок на UNC-путь. Стоило бы изменить имя сервера — и что? Вся компания моментально осталась бы без доступа. Это бы просто сломало всех пользователей одновременно! Представляете?
- С Exchange тоже ждал сюрприз. У него был внешний IP, который засветился и в SPF-записи провайдера, и в SSL-сертификате, привязанном к конкретному FQDN. А теперь представьте: меняем IP, но забываем согласовать с регистратором домена. Итог? Все наши письма улетают в спам к клиентам на целых 7-14 дней. Приятного мало, согласитесь?
- А лицензии Autodesk? Они, оказывается, были привязаны к MAC-адресу через сетевой менеджер. Помните, что у каждого нового виртуального адаптера свой MAC? Вот и мы помнили. А это значит, что при переезде все лицензии слетели бы.
- У нас были принтеры прямо в цеху, которые намертво привязали к жёстко прописанным IP-адресам контроллера. Они ведь печатали важные наклейки на отгрузки! Что будет без правильного маппинга? Просто тишина — лента молчит, отгрузок нет. Представьте себе такой коллапс.
Как должно было быть
Минимум 5 рабочих дней на аудит до подписания договора. Инвентаризация всех сервисов, зависимостей, лицензий, интеграций. Карта в формате Service → Depends_on → IP/FQDN/License минимум на одной странице. У нас есть шаблон такого аудита — он занимает около 80 пунктов для типового офиса 30 человек.
Ошибка №2: переименование домена и потеря AD-объектов
Симптом
В облаке подняли свежий домен company.local вместо старого klient.lan. Пользователей переносили скриптом без групп, без атрибутов, без SID-history.
Последствия
- А что с LDAPS-сертификатами? Их CN был привязан к старому домену. Переехали — и всё, приложения просто перестали их валидировать. Ничего не работает.
- Это классика жанра: на старом файловом сервере в правах NTFS остались SID-ы старого домена. Что случилось после переноса? Они мгновенно превратились в 'неизвестные SID', и доступ к куче важных файлов просто слетел.
- А теперь представьте катастрофу: у бухгалтера, который годами шифровал важные файлы EFS-сертификатами, эти сертификаты остались в старой системе. Что это значит? Документы за целых два года стали нечитаемыми! Просто кошмар. Так что, планируя миграцию, помните о таких мелочах.
- Представьте, утро понедельника. И тут — бац! — Outlook отказывается работать у всех сотрудников. Что случилось? Причина всегда одна: профиль пользователя остался привязан к серверу старого домена. Мы это проходили.
Как надо было
Всегда, если есть хоть малейшая возможность, постарайтесь сохранить имя домена. Если же это невозможно, тогда уж используйте ADMT — Active Directory Migration Tool, обязательно с миграцией SID-history. Почему это так важно? Потому что тогда пользователи сохранят доступ ко всем ресурсам, будто домен и не менялся вовсе. На нашей практике это значит 2-3 дня работы вместо двух недель мучительного восстановления!
# Пример миграции пользователей через ADMT с SID-history:
Set-Location 'C:\Program Files\Active Directory Migration Tool'
.\admt user /N "u_buh1" /SD:"klient.lan" /SDC:"OLD-DC01.klient.lan" `
/TD:"company.local" /TDC:"NEW-DC01.company.local" /TO:"Users" `
/MSS:Yes /UUR:CopyUserRights /PS:"new_account_pwd_csv.txt"Ошибка №3: миграция файлов через robocopy без NTFS-прав
Симптом
Команда интегратора запустила robocopy /MIR без флагов сохранения прав, владельцев и атрибутов. На новом сервере пришлось руками назначать всё.
Правильная команда выглядит так
robocopy \\OLD-FILES\Share \\NEW-FILES\Share /MIR /COPYALL /B /R:3 /W:5 \
/MT:16 /XJ /LOG+:robocopy.log /TEE
# /COPYALL = data + attributes + timestamps + NTFS ACL + owner + auditing
# /B = backup mode (читать игнорируя ACL)
# /MIR = mirror (с удалением)
# /MT:16 = 16 потоковЧто ещё? Перед любым массовым копированием мы всегда советуем сделать простейший тест на тестовой папке. Обязательно проверьте, что команда Get-Acl на новом сервере показывает корректные SID. Если вдруг вы видите SID старого домена — это сразу сигнал: либо нужна миграция с использованием SIDHistory, либо придётся повторно назначать права через скрипт. Иначе будут проблемы.
Что мы сделали для исправления
Пришлось мне, как вы понимаете, засесть и написать специальный PowerShell-скрипт. Что он делал? Сначала считывал отчёт прав доступа со старого сервера через icacls. Затем, используя нашу заранее подготовленную таблицу соответствия, маппил группы старого домена на новый. И только после этого применял все эти права заново. Работа, признаюсь, была очень объёмной: только на обработку 4.7 ТБ файлов и 1240 папок машина потратила 14 часов. Плюс ещё 6 часов мне понадобилось на тщательнейшую проверку. Чувствуете масштаб?
Ошибка №4: лицензии не учли в смете
Симптом
Ну и, конечно же, что произошло? 1С просто не запускалась! Оказалось, HASP-ключ всё это время так и оставался воткнутым в старую материнскую плату. Затем Autodesk, как по расписанию, потребовал немедленной переактивации, ссылаясь на новый MAC-адрес. А Microsoft Office? Он хоть и работал благодаря GVLK, но KMS-сервер-то остался на старом контроллере. В итоге новый Volume License так и не был активирован. Вот такой вот «чудесный» букет проблем нам достался.
Что нужно было сделать заранее
- Мы всегда начинаем с детального реестра всех лицензий. Это не просто список названий, а целая таблица с указанием типа активации: у вас USB-ключ, программная, KMS, MAC или OEM?
- Избавиться от старых HASP-ключей? Мы знаем, как! Достаточно оформить запрос в 1С на электронную поставку новых лицензий. И что самое приятное: это абсолютно бесплатно. Только учтите, процесс обычно занимает около пяти рабочих дней.
- А что делать, если старый добрый USB-ключ просто невозможно заменить на что-то более современное? Мы не сдаёмся. В таких случаях спасает проброс USB-ключа. Обычно для этого используем проверенные решения типа AnywhereUSB или Eltima USB Network Gate.
- При переезде на новую инфраструктуру у вас есть два пути: либо аккуратно перенести KMS-сервер, либо, если это слишком сложно, перейти на MAK-активацию. Мы поможем выбрать оптимальный вариант.
- Если речь идёт о новых сетевых лицензиях Autodesk, приготовьтесь к запросу через FlexNet. И учтите важную деталь: их нужно будет привязать к новому MAC-адресу, иначе не заработают.
В нашем случае, только из-за этих ключей, 1С простояла ещё целых 4 дня — ждали электронные пинкоды от разработчика. Представляете? Все эти четыре дня бухгалтерия выписывала счета вручную, прямо в Word! Какая эффективность, да?
Ошибка №5: миграция продакшена без пилота и плана отката
Симптом
В субботу утром старый сервер остановили. И тут же — сразу начали переносить виртуалки в облако. Но вот к вечеру воскресенья стало абсолютно ясно: ничего не запустилось. Ни 1С, ни Exchange. Представьте панику! И вот тут началось самое страшное: откатываться назад было просто некуда! К этому моменту старый Hyper-V уже частично разобрали, диски сняли. А провайдер, ко всему прочему, объявил, что с понедельника услуга будет окончательно отключена. Мы оказались в настоящем тупике, и это мягко сказано.
Что должен был включать план
- Пилотный сервис. Переносим один некритичный сервис (например, intranet) и держим его в облаке две недели. Учимся на нём.
- Параллельная работа. Старые серверы не выключаются до полного перекрёстного теста новой среды. Оплата провайдеру за лишний месяц — копейки относительно простоя.
- План отката. Документ из 5-7 пунктов, что делаем, если в момент X не работает Y. Например: "Если Exchange в облаке не принимает почту в течение 2 часов — переключаем MX обратно на старый сервер, откатываем DNS, поднимаем старый сервер, запускаем postpending-очередь".
- Снапшоты на старте. Перед миграцией — снапшот всех виртуалок на старом гипервизоре. Возврат — в 5 минут.
- Стоп-кран. Чёткие критерии отказа от миграции на любом этапе. Например: "если время простоя превышает 4 часа — откат, разбор, новая попытка через неделю".
Как мы спасли проект
Что ж, на пятой неделе этого безумия я лично приехал в офис клиента, прихватив с собой ещё двух наших инженеров. Перед нами стоял чёткий план восстановления:
- День 1-2. Полный аудит того, что сделано. Составление карты "что работает / что не работает / что сломано необратимо". Получилось 87 пунктов проблем.
- День 3. Разговор с заказчиком. Объяснил, что старый интегратор не справится, нужно переделать AD и файловый сервер. Получил подтверждение и временный бюджет на параллельные мощности.
- День 4-5. Поднял дополнительный сервер у Selectel (не Yandex — для распределения рисков), на нём — временный AD с правильным именем домена и SID-history, временный файловый сервер с правами в полном объёме, восстановленный из вчерашнего бэкапа Synology.
- День 6-9. Переключение пользователей на временный AD через trust-отношения, постепенное восстановление прав, заведение новых GPO, установка KMS, активация всех лицензий через корпоративные кабинеты.
- День 10-14. Восстановление 1С: получили электронные пинкоды, развернули MSSQL 2019 с restore из недельного бэкапа + догон через transaction logs, запустили регламентные задачи под правильными UNC-путями.
- День 15-19. Exchange: подняли заново на отдельной виртуалке, перенесли почту через Public Folder Migration и New-MoveRequest, согласовали MX-записи с новым IP, выправили SPF/DKIM/DMARC.
- День 20-25. Финальная консолидация: перенос мощностей с временного сервера обратно в Yandex Cloud по плану с пилотом и откатом, на этот раз с правильной картой зависимостей.
Что же мы получили в итоге? Миграция, которую первоначально обещали завершить за 2 недели и всего за 380 тысяч рублей, в реальности растянулась на целых 9 недель! А обошлась клиенту, вы только вдумайтесь, уже в 1.7 миллиона рублей. Но и это ещё не всё: к этой астрономической сумме добавились примерно 4 миллиона рублей упущенной выручки из-за всех этих дней простоя. Самое обидное? Старого интегратора клиент так и не смог привлечь к ответственности через суд. И почему, спросите вы? А потому что в их договоре было невероятно хитро прописано: «результат работ — поднятая виртуальная инфраструктура». Формально-то она действительно была поднята. Вот такая вот юридическая казуистика!
Чек-лист правильной миграции в облако
| Этап | Длительность | Что делаем |
|---|---|---|
| 1. Аудит | 5-10 раб. дней | Инвентаризация серверов, сервисов, зависимостей, лицензий, интеграций. Карта зависимостей. |
| 2. Дизайн | 3-5 раб. дней | Архитектура целевой инфраструктуры, схема сети, расчёт ресурсов, бюджет, SLA. |
| 3. Подготовка | 5-7 раб. дней | Поднятие инфраструктуры в облаке, VPN-канал к офису, базовые шаблоны, мониторинг. |
| 4. Пилот | 3-5 раб. дней | Перенос одного некритичного сервиса, тестовая эксплуатация, корректировка планов. |
| 5. Основная миграция | 5-15 раб. дней | Перенос сервисов в правильном порядке, параллельная работа со старой средой. |
| 6. Перекрёстное тестирование | 3-5 раб. дней | Прогон бизнес-процессов, проверка интеграций, нагрузочное тестирование. |
| 7. Cutover | 1-2 ночи | Финальный синк данных, переключение DNS/MX, отключение старой среды. |
| 8. Поддержка | 2-4 недели | Дежурство, оперативное реагирование на хвосты, оптимизация затрат в облаке. |
Главные мысли
- Знаете, «облако» – это совсем не магия. Мы знаем, о чём говорим. Это просто другая инфраструктура, со своими, между прочим, «граблями». Если вы переезжаете туда без подготовки, будьте готовы к проблемам. Это как переселиться в новый офис, совершенно не спланировав расстановку мебели: всё сломается, всё пойдёт не так.
- Вот вам наш главный совет: никогда, слышите, НИКОГДА не подписывайте договор без полноценного аудита. А если какой-то интегратор готов оценить всю миграцию просто по списку виртуалок — это очень, ОЧЕНЬ плохой знак. Так не бывает. Это верный путь к проблемам и переплатам.
- Лицензии – это, как правило, вообще отдельная песня, и она требует времени. Имейте в виду: полноценная работа с вендорами может занять от двух до трёх недель. Так что, когда планируете проект, обязательно заложите этот период. Иначе потом будут авралы.
- Поверьте нам на слово: пилотный проект – это НЕ этап, который можно пропустить. Он экономит десятки, если не сотни часов авралов и головной боли в будущем. Сделайте пилот – спите спокойно.
- И запомните: старая инфраструктура обязательно должна прожить параллельно с новой минимум две недели, а лучше — месяц. Да, это будут лишние деньги провайдеру. Но, поверьте нашему опыту, это самая лучшая страховка от любых внезапных проблем. Спокойствие дороже.
Бесплатный аудит инфраструктуры от ITfresh
Если вы сейчас планируете миграцию в облако или, что ещё хуже, подозреваете, что ваш текущий проект уже катится под откос — не медлите, позвоните мне. Я готов приехать к вам на 2 часа, чтобы оценить все риски. Вместе мы составим карту зависимостей, разработаем реалистичный план и получим ориентир по бюджету. И это совершенно бесплатно для компаний с 10-50 рабочими местами в Москве.
Telegram: @ITfresh_Boss
Телефон: +7 903 729-62-41
Часто задаваемые вопросы
Сколько времени занимает миграция офиса 30 рабочих мест в облако?
Помните: при действительно нормальной подготовке миграция занимает 4-8 календарных недель. А вот если работать без полноценного аудита? Тогда проект рискует растянуться до 4-6 месяцев, почти полгода! И будьте уверены, закончится это всё не иначе как постоянными ночными авралами.
Что дешевле: своё железо или облако?
Как узнать, выгодно ли облако? Всё упирается в трёхлетний горизонт и ваш темп роста. На малых масштабах облако, как правило, выходит на 30-60% дороже классических решений. Зато взамен вы получаете невероятную гибкость! Ответ, конечно, всегда кроется в точном TCO-расчёте.
Что брать: IaaS, PaaS или приватное облако?
Что касается России и перспектив на 2026 год, то IaaS от Yandex Cloud, Selectel и VK Cloud очень популярен. Нужен приватный VDC, особенно для 1С? Тогда Servermall или 1cloud — ваш выбор. А если хотите совместить их плюсы, всегда есть гибрид.
Что делать с лицензиями 1С при переезде в облако?
У вас есть USB-ключ? Можно либо пробросить его через UsbHasp или AnywhereUSB, либо полностью перейти на программные лицензии с активацией прямо через 1С. Но имейте в виду: этот процесс занимает 3-7 рабочих дней. Поэтому планируйте всё заранее, чтобы потом не кусать локти!
Можно ли обойтись без тестовой миграции?
Нет, и ещё раз нет. Как можно начинать без пилота? Вы ведь не узнаете реальных таймингов, не выявите всех скрытых зависимостей. На нашей практике это самый-самый недооценённый этап, особенно для малого бизнеса. А потом удивляются, почему всё пошло не так.