Как студия перенесла 4,2 млн игроков: DevOps-кейс с Yandex Cloud и Claude Code

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Кейс показывает, что AI-агент с доступом к метрикам и кластерам находит узкие места быстрее людей, но исход миграции всё равно решают запас ресурсов и отказ от CPU-лимитов в Kubernetes.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Авария за сутки до старта

Четыре с лишним миллиона аккаунтов. Средний DAU около 80 тысяч. Год подготовки к переезду на новую версию игры. И вечер, когда до переноса остаются сутки, а российская часть инфраструктуры недоступна: зона в Yandex Cloud легла после атаки.

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

Перенос всё же состоялся. Ценность этого разбора в другом: видно, где реально помогал AI-агент, где выручил запас ресурсов, а где команда просто меняла фундамент на ходу, потому что вендоры подвели.

Что переезжало

Старая версия: монолит на PHP, поверх тяжёлый мобильный фронтенд на Unity, много cron, MySQL, Redis, object storage, nginx на балансировке. Всё на bare metal в Hetzner. Дёшево, но новый сервер там ждёшь заявкой часами, а то и днями.

Новая версия: Flutter на фронте, Go на бэкенде (несколько десятков микросервисов), Postgres, Valkey, Redpanda, Cassandra, OpenSearch. Stateless-сервисы уехали в managed Kubernetes в DigitalOcean, stateful-компоненты на виртуальные машины. Отдельный кусок инфраструктуры для игроков из России жил в Yandex Cloud.

Масштаб: около 20 человек делали новую версию, шестеро вели саму миграцию. CTO, пара бэкенд-разработчиков, DevOps-инженер, тестировщик.

Продуктовых причин для переезда хватало. Unity собиралась брать деньги за каждую установку, потом передумала, но процесс уже не остановить. Архитектура и дизайн игры устарели. Плюс инфраструктурное: не хватало облака с управлением через API и нормального CI/CD вместо Jenkins.

Три подхода: тесты, фундамент, агент

Первый: нагрузочные тесты, которые ничего не доказали

Стенд из Hetzner в DigitalOcean один в один не воспроизвести: дорого, да и части конфигураций железа там просто нет. Пошли через пропускную способность. Сценарии на Grafana k6: регистрация, получение профиля, личные сообщения. При 10 rps ответы в среднем укладывались в 250 мс. При 50 rps местами доходили до 600–800 мс. Дальше выделенные ресурсы исчерпывались и начинались отказы.

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

Зато урок вышел конкретный: лимиты CPU в Kubernetes убрали.

В итоге бэкенду внезапно нужно больше CPU, свободное CPU на ноде есть, а забрать его не даёт лимит, и latency растёт на ровном месте.

Практический смысл для любого SMB с кластером: requests задают долю процессора при конкуренции, limits жёстко режут контейнер даже на простое. Проверяется за один вечер по графикам latency.

Второй: фундамент поехал за три месяца до старта

Три внешних события, ни одного в плане. ScyllaDB закрыла opensource-версию, бесплатными остались только небольшие кластеры. Ingress-nginx объявили завершённым проектом. Redis 7 исполняет команды в одном потоке, и упереться в это было легко.

Итог: Cassandra вместо ScyllaDB, Gateway API с Envoy вместо ingress-nginx, Valkey вместо Redis. Отдельной задачей подобрали requests и настройки HPA, чтобы поды эффективно утилизировали воркер-ноды.

Тогда же прошла первая боевая волна: около 10 тыс. игроков из одной страны. Гладко. Это и усыпило.

Третий: агент с доступом ко всей инфраструктуре

За месяц до переноса Claude Code подключили через MCP к репозиториям, метрикам, логам, трейсам и кластерам. Задача формулировалась так: составить план, чего не хватает и что может пойти не так. На выходе получили приоритизированный список рисков P0/P1.

Два примера стоят внимания. Первый: seq scan по таблице, которую суммарно прочитали 310 млн раз. Агент поправил и запрос, и частоту его вызова.

Сама таблица была крошечной, 599 строк, но суммарно её прочитали 310 миллионов раз. Агент сам поправил и запрос, и частоту его вызова.

Второй: кардинальность гистограмм HTTP-метрик. При росте трафика она могла утащить Prometheus, у которого лимит памяти 8 ГБ. Такое обычно ловят в ночь инцидента. Здесь поймали заранее.

Обратите внимание на порядок. Сначала год тестов и наблюдаемость, потом доступ агента к кластерам. Список P0/P1 без метрик, логов и трейсов превращается в пересказ документации.

Кому нужно и как применить

• Командам перед миграцией: агент окупается там, где уже есть метрики, логи и трейсы.
• Тем, кто держит Kubernetes: снятие CPU-лимитов даёт выигрыш по latency без нового железа.
• Проектам с десятками тысяч DAU, где простой считается не в часах, а в ушедших игроках.

Волну на 200 тыс. игроков провели за неделю до основной миграции. CCU до неё держался в диапазоне 650–830, в день волны около 1010, после 1110–1180. Вот это и есть нормальный способ проверять гипотезы: узкая волна, живые метрики, откат наготове.

Где подвох

Запас ресурсов купил спокойствие, а потом выставил счёт. Переплата за недели утилизации плюс время на ужимание обратно. Для SMB это типичная ловушка: «возьмём с запасом» превращается в счёт за облако, который никто не пересматривает.

Авария в Yandex Cloud за сутки до старта показала границу возможностей любого агента. Зона легла, и ни один план P0/P1 этого не отменяет. Устойчивость к отказу провайдера агент не создаёт.

И ещё: MCP-доступ к репозиториям, метрикам и кластерам одновременно. Это широкий радиус поражения при ошибке. Права стоит выдавать по задаче, а не «чтобы всё видел».

Итоги по аудитории и выручке автор оставил на конец разбора, так что чек-лист «когда это окупится в деньгах» по открытой части не собрать.

Брать или подождать: вердикт за 30 секунд

• Убрать CPU-лимиты в Kubernetes — брать, если latency уже мерится. Проверка дешёвая, эффект виден на графиках.
• Агент с MCP к прод-кластерам — брать, но с урезанными правами и человеком на подтверждении изменений.
• Инфраструктура «с запасом на всякий» — подождать. Считайте бюджет на запас заранее, иначе ужимать будет некому.
• Нагрузочные тесты на k6 — брать, но как поиск потолка, а не как доказательство готовности.

Ждать целиком стоит в одном случае: если у вас нет наблюдаемости. Агент без метрик бесполезен, а миграция без метрик опасна.

FAQ

Агент заменил команду миграции?

Нет. Шесть человек вели перенос, агент выдал список рисков и дважды поправил код. Решения по Cassandra, Envoy и Valkey принимали люди под давлением новостей от вендоров.

Почему отказались от лимитов CPU?

Лимит режет контейнер, даже когда процессор на ноде свободен. Бэкенду нужно больше, взять неоткуда, latency растёт без причины.

Что дала волна на 200 тыс. игроков?

Показала поведение системы на живой нагрузке до основной миграции. CCU вырос с 650–830 до примерно 1010 в день волны и до 1110–1180 после.

Миграция в итоге прошла?

Перенос состоялся, несмотря на отказ зоны в Yandex Cloud за сутки до старта. Финансовые итоги в открытой части разбора не приведены.

Что сделать на этой неделе

Проверьте две вещи: стоят ли у вас лимиты CPU на бэкендах и есть ли метрики, по которым видно деградацию. Это дешевле любого консалтинга и делается силами одного инженера.

Дальше решайте, нужен ли агент. Если да, начинайте не с кластеров, а с репозитория и логов. Права расширите, когда появится первый список P0/P1, который вы сможете проверить руками.