Компьютерные клубы — это не только про игры, но и про сложную IT-инфраструктуру. Когда к нам обратился клиент с 50 сервисами на Go, которые «падали» каждую неделю из-за проблем с облаком, мы поняли: пора переходить от слов к действию.

Меня зовут Радмир, я руковожу AvantIT — компанией, которая берет на себя IT-хаос, чтобы бизнес мог сосредоточиться на своих клиентах. В этом кейсе я расскажу, как мы перенесли высоконагруженную систему в Yandex Cloud, внедрили IaC и научили её работать в двух облаках одновременно.

Когда облако стало проблемой, а не решением

Когда мы начали разбираться в проблемах клиента, стало ясно: его текущая облачная платформа не просто «тормозила» — она угрожала бизнесу. Из-за долгих ответов техподдержки, отсутствия метрик и непредсказуемых даунтаймов сервисы простаивали, а клиенты уходили к конкурентам.

Компания оказалась в ловушке: инфраструктура не справлялась с нагрузкой, а инструментов для диагностики и быстрого восстановления просто не было. Владелец продукта сформулировал четкие цели: найти платформу, которая гарантирует стабильность, ускорит разработку и позволит масштабироваться без боли.

3 шага к стабильности: Yandex Cloud, Terraform и CI/CD для 50 приложений

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

Мы разбили работу на четыре этапа:

перенос БД;
перенос сервисов в Yandex Cloud;
рефакторинг через Terraform и Ansible;
настройка CI/CD для 50 приложений.

Ключевым стало правило: никаких ручных правок — только код, только хардкор =).

Миграция в Yandex Cloud

Переносили данные постепенно: сначала тестовые окружения, затем — продакшен с blue-green deployment. Полностью избежать downtime было не возможно — мы запланировали остановку сервисов на время переноса данных.

Рефакторинг через Infrastructure as Code

Ручные настройки остались в прошлом. Вся инфраструктура — от виртуальных машин до балансировщиков — описана в коде. Вот пример кода Terraform для создания виртуальной машины в Yandex Cloud:

module "prometheus" {
  source = "git::ssh://git@gitlab.avant-it.ru/main/common/terraformmodules/yandexcloud/common.instance.git?ref=5.2.4"

  app_name                  = "prometheus"
  description               = "Contains prometheus and grafana"
  folder_id                 = local.folder_id
  environment               = local.environment
  image_id                  = "fd8lturnkbl6sc1o6dtk"
  allow_stopping_for_update = true
  
  resources = {
    cores         = 6
    memory        = 10
    core_fraction = 100
  }
  
  root_ssd_volume = {
    size = 500
  }

  vpc                       = data.yandex_vpc_network.main
  alb                       = module.networking.alb
  subnet                    = module.networking.private_subnets[1]
  hosted_zone               = module.networking.hosted_zone
  autocreated_domains_zone  = "domain.example"
  autocreate_public_domains = true

  # User (HTTPS) -> Cloudflare (HTTPS)-> TLS termination L7 ALB (HTTP)-> Prometheus
  external_ingress = [
    {
      port        = 3000,
      description = "Grafana UI",
      record      = "grafana",
      zone        = "domain.example"
    },
    {
      port        = 9090,
      description = "Prometheus UI",
      record      = "prometheus",
      zone        = "domain.example"
    }
  ]

  additional_labels = {
    generate-hourly-snapshots = "false"
    generate-daily-snapshots  = "true"
    generate-weekly-snapshots = "false"
  }

  providers = {
    cloudflare = cloudflare.domain.example
    yandex     = yandex
    yandex.dns = yandex.yandexdns
  }

  ingresses = [
    {
      id          = "from_private_networks",
      description = "Allow all inbound traffic from internal network",
      from_port   = -1,
      to_port     = -1,
      protocol    = "ANY",
      cidr_blocks = [
        "10.0.0.0/8",
        "172.16.0.0/12",
        "192.168.0.0/16"
      ]
    }
  ]

  egresses = [
    {
      id          = "unrestricted_traffic",
      description = "Allow all outbound traffic",
      from_port   = -1,
      to_port     = -1,
      protocol    = "ANY",
      cidr_blocks = ["0.0.0.0/0"]
    }
  ]
}

Это дало: 50 конфигов Terraform для сервисов и Ansible для деплоя приложений на «чистые» ВМ.

Автоматизация CI/CD

Фронтенд (React):

динамические окружения для каждой feature-ветки;
автоматический прогон e2e-тестов на Storybook.

GitLab CI-пайплайна с этапами тестирования и деплоя для фронтенд приложения.

Как AWS стал не страховкой, а трамплином для зарубежных клиентов

После проблем с VK Cloud мы предложили клиенту стратегию, где AWS — не просто резерв, а платформа для экспансии. Теперь:

иностранные клиенты подключаются к AWS (Европа/США) без задержек;
новые функции сначала тестируются в AWS, затем попадают в российское облако;
инфраструктура остается устойчивой даже при региональных сбоях.

Архитектура: две независимые среды — единый контроль:

Упрощенная схема архитектуры мультиоблака

Yandex Cloud (основная зона): 50 рабочих сервисов + общие ресурсы (GitLab, Nexus);
AWS (европейский регион): полная копия сервисов для зарубежного трафика;
Связь: IPSec-туннель для синхронизации и доступа разработчиков».

В результате клиент получил глобальное покрытие без усложнения процессов.

Проблемы, с которыми столкнулись

Несмотря на все подготовительные работы, после переноса БД мы столкнулись с 4 днями нестабильности. Вот что произошло:

Первые 2 часа — плановый простой для переноса данных (без этого никак).
Дни 1-4 — сервисы работали «на честном слове»:
- VK Cloud не справлялся с трафиком, приходящим со стороны Yandex Cloud; взаимодействие с БД было столь интенсивным, что NAT инстансы не могли обрабатывать этот входящий трафик;
- БД в Yandex тормозила из-за включенного TLS-пуллера, что дополнительно увеличивало нагрузку;
- Сервера падали по 3-4 раза в день.

Почему не откатились?

Решение было осознанным: старый облачный провайдер уже не подходил по SLA. Разработчики оперативно добавили кэширование, которое было изначально, так как мы мигрировали кэши. Однако, именно отключение TLS соединения, позволяющее принудительный переход на plaintext, стало ключевым моментом, помогающим справиться с нагрузкой только после переноса сервисов в Yandex Cloud.

Вывод: даже с идеальным планом миграции внешние факторы могут внести коррективы. Важно не паниковать, а адаптироваться.

Как переезд в Yandex Cloud изменил работу клубов

Главный результат — не просто миграция облака, а качественный скачок в управлении IT-инфраструктурой. Вот что изменилось.

Стабильность. Раньше инциденты случались 4 раза в неделю — теперь раз в 3 месяца.

Контроль над разработкой. Да, деплой стал немного медленнее (из-за дополнительных проверок), но: появилось dev-окружение, feature-стенды для фронтенда, откаты стали редкими.

Заключение

Этот проект научил главному: идеальных миграций не бывает. Даже с продуманным планом вы столкнетесь с неожиданностями — от проблем с TLS до «узких» мест в облачных API. Но именно такие вызовы закаляют инфраструктуру и команду.

Клиент не просто пережил переход — он получил:

контроль над инфраструктурой через IaC и CI/CD;
прозрачность благодаря Grafana и Kibana;
свободу маневра с мультиоблаком.

И главное — он больше не зависит от капризов одного облака.

Как мы спасли 50 сервисов для работы софта управляющего компьютерными клубами: миграция в Yandex Cloud и IaC