Грант Yandex Cloud и миграция: как потушить счёт, который вырос внезапно

Бывает история, после которой собственник начинает дёргаться от одного слова «облако». У нас был проект: интернет-магазин, стандартный стек, всё вроде бы работало. Команда разворачивала сервисы в зарубежном облаке, тесты и прод жили вперемешку. Счёт при этом держался на уровне 40–45 тысяч рублей в месяц. Всё изменилось за две недели: пришёл инвойс на 280 тысяч. Не из-за роста трафика — просто кто-то поднял лишние машины, не выключил тестовые базы и оставил крутиться несколько дорогих дисков. Разбираем этот провал и показываем, почему миграция в Yandex Cloud с грамотной настройкой стала не просто «переездом», а способом вернуть контроль над деньгами.

Как счёт за облако неожиданно вырос почти в семь раз

Сначала всё выглядело как рутина. Разработчик обновлял кластер, запускал нагрузочное тестирование, параллельно поднял два инстанса «на всякий случай». Через неделю девопс ушёл в отпуск, и за тестовым окружением никто не следил. Машины продолжали работать, база данных в тестовом контуре — накапливать логи, а сетевой трафик — генерироваться без какой-либо пользы для бизнеса.

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

Почему «просто переехать» недостаточно

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

В нашем сценарии после аудита выяснилось: тестовое окружение съедало 60% бюджета, прод работал нестабильно из-за неправильного размера дисков, а бэкапы лежали в том же регионе, что и основные машины. Это классика: резервные копии должны быть разнесены, иначе авария в одной зоне убивает и бэкап, и боевой сервер. Плюс никто не использовал скидки и гранты, которые Yandex Cloud даёт при правильном подходе.

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

Сценарий миграции: неделя на хаос, четыре недели на порядок

Мы зашли в проект не как «переносчики серверов», а как инженеры, которым нужно оставить после себя понятную систему. Первую неделю занял аудит. Перечислили все виртуальные машины, базы, диски, сетевые правила и внешние зависимости. Составили таблицу, в которой каждая позиция получила статус: «нужно для прода», «нужно для теста», «мусор». Мусор выключили сразу же. Уже на этом этапе счёт упал примерно на 35%.

Второй шаг — проектирование. Разделили продакшен и тестовую среду. Для тестов сделали отдельный проект с жёсткими лимитами и автоматическим выключением по расписанию. Это исключило ситуацию, когда тестовый сервер забыт включённым и съедает бюджет. Продакшен собрали с нуля в Yandex Cloud: managed Kubernetes для контейнеров, PostgreSQL в Managed Service, объектное хранилище для бэкапов и статики.

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

Как выглядит правильная схема, к которой стоит стремиться

После переезда у заказчика появилась схема, которую можно показать любому подрядчику и не краснеть. Продакшен крутится в управляемом Kubernetes, отдельно от теста. Тестовые стенды поднимаются по кнопке в CI/CD и автоматически гаснут через час после завершения работы. Бэкапы уезжают в отдельный регион. Мониторинг следит не только за доступностью, но и за расходами: при достижении порога приходит уведомление.

Пример таблицы, которую мы используем при аудите облака, может выглядеть так:

Заметьте: мы не выдумываем суммы. Реальные цифры зависят от конфигурации, но порядок экономии именно такой — от выключения забытых ресурсов можно срезать десятки процентов бюджета ещё до оптимизации архитектуры.

Типичные ошибки при переезде в Yandex Cloud

За время работы с такими проектами мы собрали список граблей, на которые наступают почти все. Перечислю те, что всплывали и в этой истории.

• Перенос «как есть». Если в старом облаке бардак, в новом он просто поменяет прописку.
• Игнорирование грантов и программ. Грант Yandex Cloud позволяет покрыть часть расходов, но его нужно активировать до того, как всё развернули на боевых мощностях.
• Старые снапшоты и диски. Их забывают, а они копят деньги годами.
• Единый проект для прода и теста. Без разделения лимитов тестовые среды легко раздувают счёт.
• Бэкапы в том же регионе. При региональной аварии теряем и данные, и копии.
• Отсутствие мониторинга затрат. Сначала счёт удивляет, потом пугает, потом становится поздно.

Отдельно скажу про партнёрский статус. Мы являемся официальным партнёром Yandex Cloud и можем предложить поддержку вендора, актуальные условия по грантам и быстрый доступ к консультациям. Когда на этапе миграции возникает вопрос по лимитам или работе сервиса, ответ приходит быстрее, чем через обычную поддержку.

Почему после миграции счёт перестал быть сюрпризом

После переезда в Yandex Cloud счёт вернулся к планке 40–45 тысяч, но теперь за эти деньги работает только то, что нужно. Тестовые стенды включаются по расписанию, бэкапы лежат в другом регионе, мониторинг пишет в Telegram при приближении к лимиту. Руководитель больше не гадает, «сколько сейчас стоит облако».

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

Если у вас похожая ситуация — облако работает, но счёт давно перестал быть предсказуемым, — начните с аудита. Или посмотрите, как устроена наша услуга по миграции в Yandex Cloud: переносим инфраструктуру с учётом гранта и наводим порядок в облаке. Не обязательно сразу менять провайдера, но разобраться, куда уходят деньги, стоит как можно раньше.

Вывод: миграция — это не переезд серверов, а ревизия

Провал из этой истории случился не потому, что кто-то был глуп. Просто облако требует дисциплины: если среда бесконтрольна, счёт растёт быстрее, чем бизнес успевает среагировать. При миграции в Yandex Cloud важно активировать грант, разделить тестовую и производственную среды, настроить мониторинг расходов и избавиться от ненужных ресурсов. Это поможет сделать облако предсказуемым и перестать беспокоиться о счетах — как о рабочей инфраструктуре. Такой, о которой не думаешь постоянно.