Кровавая миграция клиента в Yandex Cloud: что не пишут в гайдах

К нам в ITfresh весной 2026-го пришла торговая оптовая компания 42 рабочих места из Подольска: офис, склад, выездные менеджеры. У них был один маленький серверный шкаф в подсобке, два HPE DL360 Gen10 на VMware и отчётливое желание «уйти в облако, чтобы не возиться с железом». Мы ушли. Шесть недель работы, 11 узких мест, перерасход бюджета на 38% в первые два месяца, два эпизода с потерей сетевой связности. В этой статье — честный разбор того, что в официальных гайдах Yandex Cloud, AWS и Azure обычно благоразумно не упоминают.

Контекст: зачем клиент пошёл в облако

У клиента было три рабочих причины. Первая: серверы стояли в подсобке без нормального охлаждения, летом 2025-го было два эпизода с перегревом, отказала одна планка памяти в один из дней. Вторая: в офис хотели подключить VPN-клиентов с трёх удалённых складов в Туле, Калуге и Рязани, но MTS-канал в Подольске часто моросил и удалёнщики жаловались на отвалы 1С. Третья: владельцу казалось, что облако — это «дешевле и проще». Третья оказалась наполовину правдой.

Я честно сказал владельцу на первой встрече: переход в облако сэкономит ему деньги на железе, но не на работе. Облако требует правильной архитектуры, мониторинга, регулярной оптимизации затрат — иначе оно превращается в дойную корову Yandex. Он поверил мне и подписался на аутсорс-контракт после миграции на 75 000 ₽ в месяц. Через два месяца он сказал: «Сёма, спасибо, что не дал мне сделать это самому».

Грабля №1: lift-and-shift не работает на свободной форме

Первая ошибка, которую я чуть не совершил под напором клиента — переехать «как есть». Lift-and-shift в чистом виде означает: те же 12 виртуалок с теми же ОС едут в облако без изменений, IP-адреса и архитектура не меняются. Звучит просто. На практике, если у вас есть Windows Server 2012 R2 (а у клиента было два таких сервера) — Yandex Cloud его официально не поддерживает в Compute Cloud, и SLA не действует.

Пришлось поднимать Windows Server 2022 в облаке заново, проводить in-place upgrade на промежуточной среде, переносить данные. Из 12 ВМ в облако улетели 9 — три устаревшие выкинули или объединили. План работ мы переписали через неделю после старта.

Грабля №2: жёсткие IP-адреса в коде интеграций

Я говорил об этой грабле в кейсе с zVirt — она универсальна. У торгового клиента в обработках 1С был жёстко прописан IP-адрес сервера CRM «по причинам исторической традиции». Точно так же IP были в скрипте бэкапа, в групповой политике маппинга диска, в файле hosts на 30 рабочих станциях. При смене адресной схемы (а в облаке IP-адреса другие) всё это ломается одновременно.

Решение — две недели на инвентаризацию интеграций до миграции. Я вручную проверил каждый сервер, каждый скрипт, каждый файл конфигурации. Нашёл 27 мест с жёстко прописанными IP, заменил их на FQDN, проверил, что DNS работает корректно из всех клиентских сегментов. В облаке мы развернули собственный DNS (два сервера в разных availability zones), реплицированный с локальным AD.

# Скрипт поиска жёстко прописанных IP в 1С (запуск на конфигурации)
# 1С → Конфигуратор → Глобальный поиск → регулярка
# Pattern: [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
# Лучше всего ищется в обработках, общих модулях и WS-сервисах

# Поиск в группе Windows-серверов
$Servers = @("SRV-1C","SRV-CRM","SRV-FS","SRV-AD01","SRV-AD02")
foreach ($srv in $Servers) {
    Get-ChildItem -Path "\\$srv\c$\inetpub","\\$srv\c$\Scripts" -Recurse -Include "*.ps1","*.bat","*.cmd","*.config","*.xml","web.config" |
      Select-String -Pattern '\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b' |
      Select Path,LineNumber,Line |
      Export-Csv -Path "C:\audit\hardcoded-ips-$srv.csv" -Append -NoTypeInformation
}

Грабля №3: лицензия 1С на USB-ключе HASP

Классика жанра. У клиента были две версии 1С: бухгалтерия 8.3 на программном ключе (всё ОК) и УТ 11 на аппаратном HASP USB. Сервер 1С crawled от того, что пытался найти ключ, а в облаке физического USB не существует. Варианта три:

1. Купить USB-over-IP-сервер AnywhereUSB или DistKontrolUSB и оставить ключ в офисе клиента, прокинуть по сети в облако через VPN. Плюс — лицензия не меняется. Минус — точка отказа в офисе клиента превращается в риск для облачного 1С.
2. Конвертировать в программный ключ через личный кабинет фирмы 1С. Стоит 7 000 ₽, занимает 3-5 рабочих дней, требует подачи заявления.
3. Перейти на 1С:Fresh — официальное облачное 1С от фирмы. Но это перестройка процессов, не для всех подходит.

Мы выбрали вариант 2. Подали заявку, через 4 дня получили программный pin-код, активировали в облаке. С тех пор у клиента ни разу не было проблем с лицензией — это действительно более надёжный вариант, чем пробрасывать USB по VPN.

Грабля №4: исходящий (egress) трафик стоит дороже, чем кажется

В прайсе Yandex Cloud цена за исходящий трафик в интернет — 1.20 ₽ за гигабайт. Кажется копейки. Но когда у вас 42 пользователя ежедневно работают через RDP на терминальном сервере в облаке — каждое нажатие кнопки в 1С это передача обновлённого экрана. На один рабочий день средний egress на пользователя — 1.5-2.5 GB, в месяц на офис 42 РМ — около 2200 GB исходящего трафика.

2200 × 1.20 = 2640 ₽ в месяц только за RDP-трафик. Не критично, но это добавляется к остальным платежам. Плюс egress от резервных копий: если делать копию баз 1С (объём 580 GB) на офисный NAS как третью копию по правилу 3-2-1, выходит ещё 580 × 1.20 = 696 ₽ в день, 21 000 ₽ в месяц только на бэкап.

Решение: бэкап мы держим в Yandex Object Storage в том же облаке (egress нулевой) и дублируем его в наш ITfresh-FTP в дата-центре МТС в Москве через специальный канал, который оплачивается провайдером по льготному тарифу межоблачного транзита.

Грабля №5: snapshot retention включён по умолчанию навсегда

В Yandex Cloud у дисков есть автоматические снэпшоты, которые включаются скриптом или через консоль. По умолчанию политика хранения — «бессрочно». В первый месяц мы не настроили retention и обнаружили, что копится одна полная копия каждого диска ежедневно. У клиента было 12 дисков, средний объём 200 GB. За 30 дней набралось 12 × 30 × 200 = 72 TB снэпшотов. Цена хранения снэпшота в Yandex Cloud — 1.85 ₽ за гигабайт-месяц. Получается 133 200 ₽ в месяц только за неотдоброшенные снэпшоты — больше, чем основная платежка.

Спас Cloud Logging: я настроил алерт «суточные расходы > 7000 ₽» и Yandex Cloud Functions, которая раз в неделю чистит снэпшоты старше 14 дней. После настройки расходы на снэпшоты упали с 133 000 ₽ до 12 000 ₽ в месяц.

# Yandex Cloud Function (Python) — автоочистка снэпшотов старше 14 дней
import os, datetime, json
from yandexcloud import SDK
from yandex.cloud.compute.v1.snapshot_service_pb2 import (
    ListSnapshotsRequest, DeleteSnapshotRequest
)
from yandex.cloud.compute.v1.snapshot_service_pb2_grpc import SnapshotServiceStub

def handler(event, context):
    sdk = SDK(token=os.environ['YC_TOKEN'])
    folder_id = os.environ['FOLDER_ID']
    svc = sdk.client(SnapshotServiceStub)

    cutoff = datetime.datetime.utcnow() - datetime.timedelta(days=14)
    deleted = 0

    snapshots = svc.List(ListSnapshotsRequest(folder_id=folder_id, page_size=1000))
    for snap in snapshots.snapshots:
        created = snap.created_at.ToDatetime()
        if created < cutoff and 'auto-' in snap.name:
            svc.Delete(DeleteSnapshotRequest(snapshot_id=snap.id))
            deleted += 1

    return {"deleted": deleted, "cutoff": cutoff.isoformat()}

Грабля №6: latency RDP до Подольска

Дата-центр Yandex Cloud, в котором мы развернули клиента, находится в зоне ru-central1-a (Сасово, Рязанская область). Из Подольска до Сасово — около 150 км по физическим оптическим линиям через ММТС-9. Round-trip latency у пользователя — 11-14 мс, что для RDP заметно: курсор «плавает», 1С реагирует с задержкой 200-400 мс на действие.

Решение: переход с обычного RDP на RemoteApp с RemoteFX vGPU. RemoteApp передаёт только окна приложений, а не весь рабочий стол — экономит трафик, снижает заметность задержек. Плюс настроили GPO с включением RDP Shortpath для UDP-транспорта. После этих доработок ощущение работы у пользователей стало неотличимым от локального — они даже не поверили, что серверы не в офисе.

Грабля №7: 152-ФЗ и аттестованный контур

В торговой компании были персональные данные клиентов (B2B-контрагентов): ФИО, должность, телефон, email — это категория «иные ПДн» класса УЗ-3. Yandex Cloud имеет аттестат соответствия требованиям ФСТЭК для класса УЗ-3, но не во всех конфигурациях — нужно явно подключать «Защищённый контур» как платную услугу.

Защищённый контур включает: изолированную сеть на отдельных гипервизорах, шифрование дисков AES-256, журнал аудита, сертифицированную услугу резервного копирования. Доплата — 28% к стоимости обычных ВМ. Мы это узнали в середине проекта и пересмотрели бюджет с клиентом. К счастью, 28% наценки на 6 ВМ с ПДн оказались всего 22 000 ₽ в месяц — менее болезненно, чем переезд в другой ЦОД.

Грабля №8: split-brain DNS

Внутренний домен клиента — sales.local. Когда мы развернули AD в облаке, оказалось, что в офисе есть локальные DNS-серверы со старыми записями, плюс роутер MikroTik раздаёт «sales.local» через свой DHCP. Часть пользователей резолвила имена через офисный DNS (получая старые IP в офисе), часть — через облачный DNS (получая правильные IP в облаке).

Лечение: на этапе перехода построили один уровень DNS-форвардинга. Облачные DNS направляли все запросы для sales.local на офисный DNS на момент переходного периода (две недели), потом наоборот — офисный DNS форварден на облачный. Обновили все DHCP-области и проверили ipconfig /all на каждом из 42 рабочих мест.

Грабля №9: VPN MTU и фрагментация пакетов

Между офисом клиента и Yandex Cloud мы построили IPsec-туннель через MikroTik CCR2004 на стороне офиса и Yandex Cloud Interconnect на стороне облака. Стандартный MTU 1500 не подходит, потому что IPsec добавляет ~73 байта оверхеда. На канале с MSS clamping всё ок, но без него идёт фрагментация и латенси скачет от 14 до 80 мс.

# Настройка MikroTik CCR2004 — обрезка MSS до 1380, MTU IPsec-интерфейса до 1420
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
  src-address=192.168.30.0/24 action=change-mss new-mss=1380 \
  passthrough=yes comment="MSS clamp for IPsec to YC"

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
  dst-address=192.168.30.0/24 action=change-mss new-mss=1380 \
  passthrough=yes comment="MSS clamp for IPsec from YC"

/interface ipsec policy set [find dst-address=10.130.0.0/24] mtu=1420

После настройки latency стабилизировался на 13-16 мс, фрагментация исчезла. Это деталь, которая в официальных гайдах не упоминается, потому что Yandex предполагает, что вы используете их стандартный VPN-Gateway, а не свой MikroTik.

Грабля №10: бюджет улетает за неделю до конца месяца

В первый полный месяц после переноса (март 2026) счёт от Yandex Cloud составил 348 000 ₽ — против запланированных 220 000. На 58% больше плана. Что съело бюджет: те самые снэпшоты (133 000 ₽), Object Storage без правильной политики жизненного цикла (38 000 ₽ за хранение бэкапов в стандартном классе вместо холодного), исходящий трафик от тестовых выгрузок при настройке (24 000 ₽).

Я выставил для клиента жёсткие бюджетные алерты в Yandex Cloud Billing: 50% месячного бюджета — уведомление в Telegram, 80% — звонок мне на мобильный, 95% — автоматическая остановка наименее критичных ВМ. После настройки и оптимизации ежемесячный счёт стабилизировался на 210 000 ₽ — это та цифра, которая у клиента в годовом плане.

Грабля №11: вакуум ответственности после миграции

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

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

FAQ: что чаще всего спрашивают клиенты

Когда миграция в облако реально оправдана для МСБ?

Облако оправдано в трёх сценариях: компания распределена по городам и центральная серверная превратилась в боттлнек, нагрузки сильно колеблются (сезонность, акции), либо ИТ-команды нет и платить интегратору ежемесячно дешевле, чем держать своих админов. Для статичного офиса 25-40 РМ с 1С и файловой шарой облако обычно дороже on-premise при пятилетнем горизонте — мы считали по нашим клиентам.

Сколько стоит миграция 30 РМ в Yandex Cloud под ключ?

В нашем кейсе торговой компании 42 РМ работа заняла 6 недель и обошлась в 480 000 ₽ за работы ITfresh плюс ~210 000 ₽ ежемесячных платежей в Yandex Cloud (после оптимизации). Без оптимизации первые два месяца клиент платил по 350 000 ₽ — переплата 280 000 ₽ за то, что мы не успели подкрутить с самого начала.

Что вы будете делать с лицензиями 1С и аппаратными ключами?

1С на USB-ключе HASP в облаке не работает напрямую — нужно либо мигрировать на программный ключ, либо использовать USB-over-IP с аппаратным сервером в офисе клиента. Мы предпочитаем программный ключ: подаём заявку в фирму 1С на конвертацию (3 рабочих дня, 7000 ₽), получаем pin-код, активируем в облаке. Это надёжнее, чем сетевой проброс USB.

Какой план отката должен быть у миграции?

Минимум на 30 дней после перехода в облако оставляем on-premise среду в режиме hot standby: серверы выключены, но включаются за 15 минут, бэкапы синхронизируются ежечасно. Через 30 дней без инцидентов отключаем питание, через 90 дней утилизируем диски. Это страховка стоит копейки (электричество и место в стойке), но один раз спасала нас в полной мере, когда у клиента всплыла критичная зависимость через 12 дней.

Кто отвечает за работающее облако после миграции?

У клиента — никто, если не подписать аутсорс-контракт. Yandex Cloud отвечает за инфраструктуру (хост работает, сеть в дата-центре жива), но за вашу архитектуру, бэкапы, мониторинг, обновления гостевых ОС, оптимизацию расходов отвечать должен интегратор. У нас в ITfresh аутсорс облачной инфраструктуры стоит от 45 000 ₽ в месяц для офиса 30-50 РМ, плюс мы доступны 24/7 на критичные инциденты.

Итог

Облако — это инструмент, а не магия. Yandex Cloud, AWS или любой другой провайдер дадут вам инфраструктуру, но не работающую архитектуру. Между моментом «оплатили подписку» и моментом «всё стабильно работает за разумные деньги» лежит 4-8 недель проектирования, миграции и оптимизации. Без правильно проложенного маршрута эти 4-8 недель превратятся в боль с переплатами 30-50% от плана. Если вы планируете миграцию — зовите нас на этап аудита, мы покажем подводные камни до того, как они порвут дно.