Почему дефицит стоек в ЦОДах заставляет бизнес переходить на геораспределенные архитектуры
По данным Strategy Partners, объём российского рынка ЦОДов и облачных сервисов в 2025 году — 225 млрд рублей, плюс 23% год к году. К 2030-му аналитики обещают 737 млрд при среднегодовых ~27%. Звучит мощно.

Рынок ЦОДов растёт, а стойко-мест — нет. Пора учить GSLB
Но есть нюанс: физических мощностей вводят всё меньше. В 2025-м — около 4,6 тыс. новых стойко-мест против 10,8 тыс. годом ранее. Деньги растут быстрее бетона. И это прямой сигнал бэкендерам: не надейся на бесконечный масштаб горизонтально — учи геораспределённую архитектуру на том, что уже есть.
Деньги есть, электричество — не факт
Ограничения рынка — классический коктейль: дефицит электроэнергии, стоимость финансирования, импорт оборудования и софта под санкциями. Параллельно Аналитический центр при Правительстве РФ межведомственно согласовывает дорожную карту по развитию ЦОДов: больше 20 инициатив — от профильных кодов ОКВЭД до упрощения строительства и энергетических ограничений. Звучит как движение в правильном направлении, но до реальных мегаватт на площадке — дистанция огромного размера.
На практике это значит: компании будут держать собственную площадку + мощности провайдера + резервный ЦОД +, возможно, несколько облаков. Классическая гибридная мешанина. И тут начинается боль.
Несколько ЦОДов ≠ отказоустойчивость
Михаил Соболев, директор по продукту Termidesk Connect (входит в «Группу Астра»), прямо говорит: наличие нескольких площадок ещё не значит, что приложение стало отказоустойчивым. Нужно определить логику распределения трафика между ними, контролировать доступность сервисов и иметь механизм переключения, если одна площадка упала.
Типичная ситуация: у тебя ADC на уровне одного ЦОДа раскидывает запросы между экземплярами приложения. Респект. Но как только инфраструктура выходит за пределы одного дата-центра, нужен другой слой — GSLB, глобальная балансировка. Она выбирает уже не между серверами, а между площадками: с учётом их доступности, задержек и заданных политик. Один ЦОД перестал отвечать на healthcheck конкретного сервиса — трафик пошёл на соседнюю площадку. Сервис на площадке жив, но приложение на нём криво отвечает — GSLB должен это отловить и не слать туда пользователей.
Разница между «сервер пингуется» и «приложение работает» — это то, что большинство игнорирует, пока не случится incident на проде в 3 часа ночи.
Edge добавляет точек отказа
Компьютерра отмечает, что 2026-й может стать переломным для российского edge-сегмента — переход от экспериментов к реальному использованию. Драйверы: дефицит мощностей ЦОДов, требования к минимальной задержке (промышленность, IoT), необходимость обрабатывать данные там, где они возникают. По данным Onside, рынок IoT к 2028-му может вырасти в 2–3 раза относительно 2024-го.
Что это значит для архитектуры: вместо одного-двух централизованных ЦОДов появляются региональные и локальные узлы, облака, центральные площадки — всё это нужно связать в единую доставку приложения. Каждый новый узел — потенциальная точка отказа. Каждый новый edge-регион — ещё один healthcheck, ещё одна политика маршрутизации, ещё один костыль в конфиге, который кто-то забыл задокументировать.
При этом, как подчёркивают в Termidesk, GSLB не является обязательным компонентом любого edge-проекта. Но чем больше площадок — тем неизбежнее вопрос: а кто раскидывает трафик между ними и что происходит, когда одна из них отваливается?
Что делать прямо сейчас
Краткий чеклист для тех, у кого уже больше одного ЦОДа или планируется edge:
- Инвентаризация точек отказа. Понять, где у тебя балансировка заканчивается на уровне одного дата-центра и начинается ручное переключение DNS или, того хуже, тикет в саппорт провайдера.
- Healthcheck на уровне сервиса, не хоста. Пингуется!= работает. Проверяй, что приложение отвечает на конкретный endpoint, а не просто ICMP проходит.
- Политики распределения трафика. Latency-based, failover, weighted — выбери и настрой заранее. GSLB настраивается не за пять минут, когда прод горит.
- Единый лог и мониторинг. Если у тебя три площадки и три разных стека логирования — добро пожаловать в ад при инциденте.
- Документация. Если никто в команде не может нарисовать схему, как трафик идёт от пользователя до приложения, — она не существует.
Рынок ЦОДов растёт, денег на него выделяют больше. Но железо — это только фундамент. Распределённая архитектура доставки приложений — это про логику, мониторинг и готовность к тому, что одна из площадок рано или поздно отвалится. Не будете проектировать это заранее — будете дебажить на проде. Выбор за вами.