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

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

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

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

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

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

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

Что же в итоге? Пришлось поднимать Windows Server 2022 прямо в облаке, с нуля. Затем — проводить in-place upgrade на специальной промежуточной среде, и только после этого переносить данные. Из изначальных двенадцати виртуальных машин в облако переехали лишь девять — мы решили выкинуть три устаревшие или, по крайней мере, объединить их. В общем, наш самый первый план работ мы переписали уже через неделю после того, как стартовали.

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

Я уже рассказывал про эту «граблю» в одном из своих кейсов, связанном с zVirt — она, поверьте, универсальна. У нашего торгового клиента, например, в обработках 1С IP-адрес сервера CRM был жёстко прописан. Знаете почему? «По причинам исторической традиции», — так мне объяснили. И это не всё! Точно такие же IP-адреса мы отыскали в скрипте бэкапа, в групповой политике маппинга диска, и даже, представьте, в файле hosts на всех тридцати рабочих станциях! Понимаете, да? При смене адресной схемы (а в облаке 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С буквально «захлёбывался», пытаясь найти ключ там, где его просто не могло быть. Ведь в облаке физического USB, понятное дело, не существует! Перед нами встало три варианта:

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

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

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

Заглянем в прайс Yandex Cloud, да? Цена за исходящий трафик в интернет там стоит всего 1.20 ₽ за гигабайт. Ну, сущие копейки, казалось бы! Однако давайте представим: у вас 42 пользователя, и они ежедневно трудятся через RDP на терминальном сервере, расположенном в облаке. Каждое нажатие кнопки в 1С? Это передача обновлённого изображения экрана. Теперь прикиньте: на один рабочий день средний исходящий трафик на пользователя составляет от 1.5 до 2.5 гигабайт. А если это весь офис, все 42 рабочих места? В месяц это выливается примерно в 2200 гигабайт чистого исходящего трафика.

Итак, только за RDP-трафик ежемесячно набегает 2200 умножить на 1.20 — и это 2640 ₽. Вроде бы, ну, не такая уж и критичная сумма, правда? Но ведь она лишь прибавляется ко всем остальным платежам! А что насчёт исходящего трафика от резервных копий? Если мы, например, захотим сделать копию баз 1С, объём которых составляет 580 гигабайт, на офисный NAS в качестве третьей копии (по известному правилу 3-2-1), то это будет стоить ещё 580 умножить на 1.20 — то есть 696 ₽ в день! В день! А за месяц? Это уже 21 000 ₽! Только на один лишь бэкап.

Но мы нашли решение! Сейчас наш бэкап надёжно хранится в Yandex Object Storage, прямо там же, в облаке, что, кстати, обеспечивает абсолютно нулевой исходящий трафик. А чтобы было ещё надёжнее, мы дублируем его в наш собственный ITfresh-FTP, расположенный в дата-центре МТС в Москве. Для этого используем специальный канал, его оплачивает провайдер по очень выгодному льготному тарифу межоблачного транзита. Продумано, не правда ли?

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

Есть такая интересная «штука» в Yandex Cloud у дисков — автоматические снэпшоты. Их можно включить хоть скриптом, хоть через консоль. Но тут есть один, скажем так, неприятный нюанс: по умолчанию политика хранения там установлена как «бессрочно». Признаюсь честно, в первый же месяц мы просто забыли настроить retention. И к своему ужасу обнаружили, что ежедневно копится по одной полной копии каждого диска! А у клиента, на минуточку, было целых двенадцать дисков, каждый в среднем по 200 гигабайт. Представляете? За 30 дней набралось астрономические 12 × 30 × 200, то есть 72 терабайта одних только снэпшотов! Цена хранения снэпшота в Yandex Cloud, напомню, составляет 1.85 ₽ за гигабайт-месяц. В итоге мы получили счёт на 133 200 ₽ в месяц — и это лишь за те самые, не удалённые вовремя снэпшоты! Сумма, к слову, оказалась даже больше, чем вся основная платёжка!

Нас буквально спас Cloud Logging! Я оперативно настроил алерт: «суточные расходы > 7000 ₽». А ещё подключил Yandex Cloud Functions, которая теперь, как часы, раз в неделю сама чистит все снэпшоты, что старше четырнадцати дней. И что вы думаете? После всех этих нехитрых настроек наши расходы на снэпшоты резко рухнули: со 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% наценки на шесть виртуальных машин с персональными данными обернулись всего лишь в 22 000 ₽ в месяц. Согласитесь, это гораздо приятнее, чем пришлось бы, если бы мы переезжали в другой дата-центр.

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

Внутренний домен клиента назывался sales.local. Когда мы уже вовсю разворачивали Active Directory в облаке, вдруг выяснилось, что в офисе, оказывается, всё ещё пашут старые локальные DNS-серверы с доисторическими записями. И, что совсем удивительно, роутер MikroTik тоже продолжал раздавать «sales.local» через свой DHCP! В итоге пользователи разделились на два лагеря: одни резолвили имена через офисный DNS, получая старые офисные IP-адреса. Другие, наоборот, обращались к облачному DNS и видели уже правильные, облачные адреса. Представляете, какая это была неразбериха!

Лечение: на этапе перехода построили один уровень 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

После того, как все настройки были применены, задержка наконец-то стабилизировалась, держась на уровне 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, безусловно, отвечает за свою инфраструктуру: хост работает, сеть в дата-центре как часы. Но что, если вдруг «отвалится» ваше приложение? Это, извините, уже не их забота. Бэкап не стартовал? Тоже не их головная боль. Расходы неконтролируемо растут? И это, увы, не к ним. Когда мы, ITFresh, заходим в проект как интегратор, мы берём на себя все эти вопросы, предлагая надёжный аутсорс. Но если клиент через год решает «порулить сам», то проблемы обычно не заставляют себя ждать. Ведь штатный админ, к сожалению, порой просто не в состоянии охватить все нюансы работы с облаком.

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

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

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

На наш взгляд, облако имеет смысл использовать лишь в трёх ключевых сценариях. Первый: ваша компания раскидана по разным городам, и центральный серверный шкаф давно превратился в настоящий «бутылочное горлышко». Второй: если нагрузки постоянно скачут, например, из-за сезонности продаж или масштабных акций. И третий вариант: когда у вас попросту нет своей ИТ-команды, и платить интегратору каждый месяц выходит объективно дешевле, чем содержать штатных админов. А вот для стандартного, небольшого офиса на 25-40 рабочих мест, где крутится 1С и есть файловый ресурс, облако, по нашим расчётам (мы провели их на множестве наших клиентов), обычно оказывается дороже, чем классическое on-premise решение, особенно если смотреть на горизонт в пять лет.

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

В нашем конкретном случае с той самой торговой компанией, где было 42 рабочих места, весь проект занял 6 недель. Наши работы от ITfresh обошлись в 480 000 ₽, плюс около 210 000 ₽ — это ежемесячные платежи в Yandex Cloud, но уже после всех наших оптимизаций. А знаете, что самое интересное? Без этих оптимизаций первые пару месяцев клиент платил по 350 000 ₽! Представляете? Переплата составила колоссальные 280 000 ₽ лишь потому, что мы не успели всё настроить и «подкрутить» с самого начала.

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

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

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

После того, как мы успешно переносим инфраструктуру в облако, мы всегда держим старую on-premise среду в режиме hot standby ещё минимум 30 дней. Что это значит? Серверы хоть и выключены, но при любом ЧП их можно поднять всего за 15 минут, а бэкапы с облака синхронизируются ежечасно. Если за эти 30 дней никаких инцидентов не возникает, мы уже смело отключаем питание. А через 90 дней — утилизируем диски. По сути, такая страховка стоит сущие копейки: это лишь расходы на электричество и крошечное место в серверной стойке. Но, поверьте, однажды она по-настоящему спасла нас, когда у одного из наших клиентов внезапно всплыла критичная зависимость всего через 12 дней после миграции. Рисковать не стоит!

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

Так кто же в итоге отвечает за всё это у клиента? По правде говоря, никто, если вы не подпишете аутсорс-контракт. Да, Yandex Cloud, конечно, несёт ответственность за инфраструктуру: хост работает, сеть в дата-центре жива-здорова. Но ваша архитектура, актуальные бэкапы, постоянный мониторинг, своевременные обновления гостевых операционных систем, да и та же оптимизация расходов — за всё это должен отвечать именно интегратор. В ITfresh, например, аутсорс облачной инфраструктуры для офиса на 30-50 рабочих мест стартует от 45 000 ₽ в месяц. И, что немаловажно, мы всегда на связи 24/7, чтобы оперативно решать любые критичные инциденты.

Итог

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