• Легислатура Мэна одобрила LD 307 — первый в США мораторий на выдачу разрешений для дата-центров мощнее 20 МВт. Действует до ноября 2027 года.
• Поводом стали два громких провала: проект на $5 млрд в Wiscasset (жители заблокировали из-за закрытого NDA и размещения на общественной земле) и проект на $300 млн в Lewiston (городской совет единогласно отклонил из-за нагрузки на сеть).
• По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд.
• Сейчас дата-центры потребляют около 4% электричества США; к 2030 году цифра может удвоиться — это давит на тарифы везде, где идёт ИИ-стройка.

Что именно приняли

LD 307 временно запрещает штату и муниципалитетам выдавать разрешения на дата-центры с подключённой мощностью более 20 МВт. 20 МВт — это порог, ниже которого остаются небольшие корпоративные и колокейшен-объекты, но выше него начинается всё, что строят гиперскейлеры под ИИ-нагрузки: кластеры на тысячи GPU уходят за 50–100 МВт легко.

Мораторий действует до 1 ноября 2027 года. За это время новая Data Center Coordination Council должна изучить, как такие объекты влияют на изношенную электросеть штата, и предложить постоянные правила. Губернатор Джанет Миллс (демократ) поддерживает паузу.

«Взять эту паузу сейчас — критически важно», — заявил член палаты представителей Кристофер Кесслер со ссылкой на Maine Public Radio. Застройщик Тони Макдональд назвал новые ограничения «катастрофическими» и пожаловался, что его команда «попала в эту облаву».

Почему именно Мэн

Формально инициатива на уровне штата — но раскатал её конкретный провал в Lewiston. В декабре 2025 года городской совет единогласно зарубил проект дата-центра на $300 млн внутри старого текстильного комплекса Bates Mill. Детали проекта вскрылись за шесть дней до голосования — и жители успели поднять шум вокруг расхода воды и нагрузки на сеть. Показательная деталь: раньше в том же здании сидел колл-центр TD Bank на тысячу с лишним рабочих мест, а дата-центр обещал дать всего около 30.

За месяц до этого в городе Wiscasset так же жёстко слили проект на $5 млрд. Недовольство вызвали закрытое NDA, которое город подписал с застройщиком, и размещение объекта на общественной земле. Также в подвешенном состоянии находятся площадки в Jay (на месте бывшего бумажного комбината), в Sanford и на Loring Air Force Base.

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

Не только Мэн: кто ещё тормозит

По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане. Города от Денвера до Детройта обсуждают похожие ограничения — и это ещё до того, как мэнский прецедент начнёт раскатываться дальше.

Сейчас дата-центры потребляют около 4% электричества США. Прогнозы сходятся на том, что к 2030 году цифра может удвоиться — в основном за счёт ИИ-нагрузок. Экономист Анирбан Басу назвал решение Мэна «канарейкой в шахте» для сопротивления штатов энергоаппетитам бигтеха.

Что это значит для разработчиков

Прямого эффекта «AWS завтра подорожает» ждать не стоит: Мэн — не главный ИИ-хаб США. Но если прецедент подхватят более жирные штаты (а к этому сейчас движется дискуссия в Вирджинии и Техасе, где сконцентрирована бо́льшая часть американских ЦОДов), сроки запуска нового железа у гиперскейлеров (то есть Google, AWS, Microsoft, Meta и прочих операторов гигаваттных ЦОДов) поедут вправо. Дефицит capacity — это классический триггер для роста цен на облачные инстансы и, особенно, на GPU-мощности для обучения моделей.

Российским командам это косвенно важно по двум линиям. Первая — мировые цены на ИИ-инференс: даже если вы работаете с российскими провайдерами вроде Yandex Cloud, VK Cloud или Cloud.ru, тарифы на GPU формируются под влиянием глобального дефицита H100 и B200. Вторая — локальная повестка: в России тоже регулярно вспыхивают истории про нагрузку ЦОДов на регионы, и мэнский сценарий даёт удобную шпаргалку, чего ждать от публичной дискуссии. Что конкретно стоит начать делать уже сейчас: следить за новостями по Вирджинии и Техасу как по раннему индикатору; закладывать в годовые GPU-бюджеты диапазон неопределённости на случай роста цен; мониторить spot-рынки H100/B200 у российских провайдеров — там первый эффект виден быстрее всего.

Источники: Gadget Review, Bangor Daily News, Data Center Watch.

В ноябре 2025 года Starcloud запустила первый спутник с GPU Nvidia H100 на борту — и впервые в истории провела обучение ИИ-модели прямо на орбите.

— — $170 млн Series A, оценка $1,1 млрд (всего привлечено $200 млн)

— Инвесторы: Benchmark, EQT Ventures, Monolith Power Systems

— Первый спутник с Nvidia H100 уже на орбите (ноябрь 2025)

— Следующий запуск: Starcloud-2 с чипом Blackwell и серверным блейдом AWS

— Цель: орбитальный дата-центр мощностью 5 ГВт

Орбитальный дата-центр — вычислительный кластер на базе спутников с GPU и солнечными панелями, работающий автономно без подключения к земным электросетям. Разбираемся, зачем переносить вычисления в космос и насколько это реалистично.

Зачем дата-центры в космосе

Земные дата-центры упираются в два ресурса: электричество и охлаждение. По данным SiliconANGLE, только в США строятся дата-центры суммарной мощностью более 25 ГВт. Энергосети не справляются, а политические и экологические ограничения тормозят строительство новых.

Космос решает обе проблемы принципиально иначе:

• Энергия. Солнечные панели на орбите генерируют, по расчётам Starcloud, в 5 раз больше энергии, чем наземные — нет ночи, облаков и атмосферного поглощения
• Охлаждение. В вакууме тепло отводится через радиаторы инфракрасным излучением. Это пассивные устройства — проще конструкция, меньше энергопотребление
• Масштабирование. Не нужно согласовывать строительство, подключение к электросетям, водоснабжение. Запустил модуль — подключил к кластеру

Что уже работает: Starcloud-1

Первый спутник Starcloud-1 (NORAD 66303) вышел на орбиту в ноябре 2025 года. На борту — GPU Nvidia H100, один из самых мощных чипов для ИИ-вычислений.

Что удалось сделать на орбите:

• Обучить собственную ИИ-модель (nanoGPT) — первое в истории обучение модели в космосе
• Запустить инференс Gemma — открытой модели от Google DeepMind
• Обработать данные с радарных спутников Capella Space в реальном времени

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

Один из GPU (Nvidia A6000) вышел из строя при запуске. Полученные данные о работе чипов в космических условиях повлияют на дизайн следующих поколений.

Дорожная карта: от одного спутника до 5 ГВт

Starcloud-2 — 2026–2027

Следующий спутник получит:

• Несколько GPU, включая чип Nvidia Blackwell и серверный блейд AWS
• Крупнейший коммерческий раскладной радиатор в истории космических запусков
• Солнечную батарею, генерирующую в 100 раз больше энергии, чем Starcloud-1
• Майнер Bitcoin (да, это не шутка)

Среди первых клиентов — Crusoe, строитель ИИ-дата-центров.

Starcloud-3 — запуск со Starship

Ключевой рубеж — Starcloud-3: трёхтонный космический аппарат мощностью 200 кВт, спроектированный под систему развёртывания Starship от SpaceX. По расчётам компании, это будет первый орбитальный дата-центр, конкурентный по стоимости с наземными — около $0,05 за кВт·ч.

Условие: коммерческие запуски Starship по цене ~$500 за килограмм. CEO Starcloud ожидает, что это произойдёт в 2028–2029 годах.

Финальная цель: 88 000 спутников

Долгосрочный план — созвездие из 88 000 спутников, формирующих распределённый дата-центр мощностью 5 ГВт. Солнечная батарея площадью около 16 км² будет питать модули, соединённые лазерными каналами связи. Загрузка данных — через оптоволоконные модули, доставляемые ракетами (петабайты за рейс).

Риски и ограничения орбитальных дата-центров

Масштаб амбиций вызывает обоснованный скептицизм:

• Starship ещё не летает коммерчески. Если сроки сдвинутся, Starcloud продолжит запуски на Falcon 9 — но о конкурентной стоимости энергии придётся забыть
• Синхронизация GPU. Тренинг крупных моделей требует сотен GPU, работающих синхронно. На орбите это значит либо гигантские аппараты, либо надёжные лазерные каналы между спутниками в строю
• Масштаб пропасти. Starlink — крупнейшая спутниковая сеть (10 000 аппаратов) — генерирует, по оценкам TechCrunch, около 200 МВт. Наземные дата-центры одних только США — более 25 ГВт. Разница в 125 раз
• SpaceX как конкурент. Компания Маска запросила разрешение на запуск миллиона спутников для распределённых вычислений — под нужды Grok и Tesla

Джонстон не считает SpaceX прямым конкурентом: «Они строят под свои внутренние нужды — Grok и Tesla. Мы — энергетическая и инфраструктурная компания для сторонних клиентов».

Кто ещё строит космические дата-центры

• Aethero — бортовые ИИ-вычисления для спутников, запустила первый GPU Nvidia Jetson в космосе (2025)
• SpaceX — запросила разрешение на миллион спутников для распределённых вычислений

Отдельно Nvidia на GTC 2026 представила космические чип-модули Vera Rubin Space-1, хотя ни один ещё не произведён.

Выводы

Starcloud — первая компания, которая запустила передовой ИИ-чип на орбиту и провела на нём обучение модели. $170 млн нового раунда и статус единорога за 17 месяцев показывают, что инвесторы верят в идею.

Но между одним H100 в космосе и 5-гигаваттным созвездием — пропасть размером с целую индустрию. Ближайшие 2–3 года покажут, удастся ли Starcloud преодолеть технологический разрыв — или космические дата-центры останутся красивой, но непрактичной мечтой.

Источники: TechCrunch, SiliconANGLE, Data Center Dynamics, Nvidia Blog

Во время Супербоула компания показала 30-секундный ролик, посвященный спутниковому интернету Starlink. Ранее ни одна из компаний Илона Маска напрямую не размещала рекламу на этом событии.

Реклама без Маска, но с Артуром Кларком

Ролик построен на архивной аудиозаписи выступления писателя-фантаста Артур Кларк. На фоне его слов показывают посадки ускорителей Falcon 9 и Starship, а также работу Starlink в удаленных и труднодоступных регионах.

Основной посыл простой: «быстрый и доступный интернет — в любой точке мира».

Это заметный отход от привычной стратегии Маска, который годами продвигал свои компании без классической рекламы. Вместо этого он использовал громкие заявления, демонстративные запуски ракет и личную активность в соцсетях.

Почему это важно именно сейчас

Выход SpaceX на Супербоул выглядит не случайным. По данным западных СМИ, компания готовится к публичному размещению акций, которое может стать одним из крупнейших IPO в истории — с потенциальной оценкой до $1,5 трлн.

Контекст усиливает и недавнее заявление Маска об объединении SpaceX с его ИИ-стартапом xAI.

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

Сколько стоит такой выход

По данным телеканала NBCUniversal, 30 секунд рекламы на Супербоуле в этом году обходились брендам в $8–10 млн. Для SpaceX это первый подобный расход.

Starlink как главный двигатель роста

Выбор Starlink в качестве героя ролика тоже показателен. Именно спутниковый интернет сейчас является самым «гражданским» и массовым продуктом SpaceX.

В компании ранее сообщали, что сервисом пользуются около 9 млн клиентов в 155 странах, а на орбите уже работает более 9000 спутников.

Зачем Маску слияние

По данным Bloomberg, ключевая причина — деньги. Разработка ИИ в xAI обходится примерно в $1 млрд в месяц и эта нагрузка становится слишком тяжелой даже для компании Маска.

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

Что может получиться на выходе

В случае объединения, речь пойдет о структуре с колоссальной оценкой. По состоянию на конец 2025 года, SpaceX оценивалась примерно в $800 млрд, а xAI — в $200 млрд. В сумме это один из самых дорогих частных технологических конгломератов в мире.

Источники Bloomberg также допускают, что в руководство объединенной компании, помимо Маска, войдет Гвинн Шотвелл — президент и операционный директор SpaceX. Инвесторы традиционно считают ее ключевой фигурой в управлении бизнесом.

ИИ, космос и дата-центры на орбите

Стратегически слияние может пойти дальше простой финансовой поддержки xAI. Аналитики считают, что Маск может попытаться связать развитие ИИ напрямую с космической инфраструктурой.

В частности, SpaceX уже подала заявки на размещение до миллиона спутников. А одна из обсуждаемых идей — вынос дата-центров за пределы Земли.

Параллельно объединение ресурсов может помочь SpaceX ускорить разработку Starship и укрепить позиции в борьбе за крупные государственные контракты — от лунной программы Artemis до проектов ПРО и запусков для Космических сил США.

Экспериментальный радиотрансивер работает на частотах около 140 ГГц и рассматривается как технологическая база для будущих стандартов 6G и так называемого FutureG.

«Беспроводной патч-корд» вместо кабеля

Руководитель проекта Паям Хейдари описывает разработку просто: это «беспроводной оптоволоконный патч-корд». Смысл идеи прост — получить пропускную способность, сравнимую с волокном, но без физического кабеля. Только радиосигнал на сверхвысоких частотах.

Используемый диапазон F-band (примерно 90–140 ГГц) находится намного выше частот 5G. Именно здесь, по мнению регуляторов и разработчиков стандартов, лежит следующий технологический рубеж мобильной, машинной и промышленной связи.

Отказ от классической цифровой схемы

Главный прорыв — не только в частотах, но и в архитектуре чипа. Современные беспроводные системы упираются в цифро-аналоговые и аналого-цифровые преобразователи (DAC и ADC).

Чем выше скорость, тем больше энергии они потребляют и тем сильнее греются. В какой-то момент физика просто начинает мешать.

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

Передатчик формирует сигнал сразу в радиочастотном диапазоне, обходя DAC, а приемник разбирает сложный поток данных до оцифровки. В результате исчезает главное «узкое место» архитектуры.

Итог — 120 Гбит/сек без перегрева чипа, что раньше считалось почти недостижимым.

Почему это важно для 6G и дата-центров

Такие скорости открывают сценарии, которые сегодня либо невозможны, либо требуют километров кабелей.

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

Приемный чип, изготовленный по 22-нм технологии FD-SOI, потребляет около 230 мВт. Это уже укладывается в требования к портативным и встраиваемым устройствам.

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

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

Критерии сравнения

При выборе провайдера для размещения за рубежом нужно учитывать несколько параметров:

География присутствия

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

Процесс оплаты и виды договоров

В какой валюте принимают платежи, с каким юрлицом (российским или зарубежным) заключается договор. От этого зависят бухгалтерские процессы и налоговые нюансы.

Форматы предоставления ресурсов

Облачные серверы (shared или dedicated vCPU) или выделенные физические серверы. Виды услуг — Public Cloud, Private Cloud, инфраструктура с GPU для машинного обучения, VDI-решения, S3-хранилища, managed ITdatabases.

Чем шире набор услуг у провайдера, тем больше вероятность закрыть все потребности по инфраструктуре через одного подрядчика — это даёт единое окно управления и одного ответственного за все компоненты системы.

Техподдержка

Язык общения и время отклика. Для команд без свободного английского русскоязычная поддержка сокращает время решения инцидентов.

ITGLOBAL.COM — облачный провайдер 12 дата-центров в 10 странах

Компания развернула 12 облачных площадок в локациях от Торонто до Шэньчжэня. География присутствия включает Нидерланды (Амстердам), ОАЭ (Дубай), Бразилию (Сан-Паулу), Центральную Азию (два ЦОДа в Казахстане Алматы, и один дата-центр в Узбекистане, в Ташкенте, Китай (Шэньчжэнь), Северную Америку (Торонто и Нью-Джерси), Беларусь (Минск) и Россию (2 дата-центра в Москве). Облачные площадки размещены в проверенных сетях дата-центров Cologix, Equinix, IXcellerate и других партнёров; используемые дата-центры соответствуют стандарту Uptime Institute Tier III.

20 января 2026 года провайдер запускает новую облачную площадку в Китае на базе дата-центра SeaArea Shenzhen, расположенного в районе Лунган (Шэньчжэнь). Дата-центр входит в инфраструктуру Henggang Data в Южном Китае, соответствует уровню Tier III, устойчив к землетрясениям до 8 баллов и обеспечивает круглосуточную поддержку. Расположение в Шэньчжэне, рядом с Гонконгом, даёт удобную сетевую связность в регионе; близость к производственным кластерам и площадкам вендоров сокращает логистику и ускоряет ввод оборудования, что упрощает масштабирование инфраструктуры.

Формат работы построен под российские компании: можно заключить договор с российским или зарубежным юр.лицом ITGLOBAL.COM, оплачивать услуги в рублях, евро, долларах, юанях или криптовалюте. Русскоязычная техподдержка работает круглосуточно и входит в стоимость. Если команде нужен привычный процесс взаимодействия без языковых барьеров и разницы в понимании SLA — здесь это реализовано.

Что можно развернуть

На базе зарубежных площадок доступен полный стек облачных сервисов: публичное облако на VMware или vStack, частное облако на VMware, аренда инфраструктуры с GPU, аренда удалённых рабочих столов (VDI и 3D VDI), S3-хранилище, хостинг ERP-систем, решения для аварийного восстановления и георезервирования. Провайдер готов кастомизировать конфигурации под проект — это скорее исключение для зарубежного рынка, где обычно предлагают только пакетные решения.

Дополнительно есть услуги по администрированию инфраструктуры, а также дают набор продуктов и сервисов, чтобы усилить информационную безопасность.

Когда это работает

Типичные сценарии для развертывания облака в зарубежных ЦОДах: открытие представительства в новой юрисдикции с требованиями по локализации персональных данных, запуск дополнительной зоны присутствия для сервисов, чувствительных к задержкам (например, онлайн-сервисы или финтех-приложения для пользователей в Европе или Азии), реализация DR-планов с хранением резервных копий за пределами основной площадки.

Партнерские возможности

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

Партнёры могут выступать реселлерами и продавать услуги ITGLOBAL.COM под собственным брендом, привлекая международных клиентов, сопровождая проекты и получая партнёрские скидки от базовых цен провайдера. Такой сценарий подходит технологическим компаниям с международной клиентской базой и локальным интеграторам, выходящим на новые рынки.

Для запуска или расширения собственного облачного бизнеса на зарубежных рынках может быть реализована модель White‑Label. Сценарий подходит облачным провайдерам, телеком‑операторам и инсорсинговым компаниям, расширяющим географию присутствия.

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

2. Hostkey — хостинг-провайдер с собственным парком серверов

Hostkey работает на рынке 14 лет, управляет более чем 5000 серверами в дата-центрах России, Нидерландов и США. Формат работы ориентирован на российских клиентов: оплата в рублях картами российских банков, техподдержка на русском языке с откликом до 15 минут, возможность заключить договор с российским юр.лицом.

Что предлагает провайдер

Линейка начинается с VPS (виртуальные серверы с разделяемыми ресурсами) и VDS с выделенным vCPU — подходит для проектов, где нужна предсказуемая производительность без влияния соседей по физическому серверу. Для задач машинного обучения или рендеринга доступны VDS с GPU. Если стандартные конфигурации не подходят, можно собрать индивидуальную сборку или взять выделенный сервер.

Все виртуальные серверы управляются через API и контрольную панель — есть HTML5-консоль, управление питанием, переустановка ОС или установка системы с собственного ISO. Из коробки доступны предустановленные приложения: панели управления (ispmanager, Plesk, cPanel), система автоматизации n8n, VoIP для геймеров TeamSpeak, таск-трекер Plane, видеоконференции Jitsi.

Когда это работает

Типичные сценарии: веб-сайты и сервисы с низкой нагрузкой (блоги, CRM, CMS), VPN-серверы, репозитории кода, тестовые среды для разработки. Если проект требует высокой нагрузки — есть конфигурации до 16 виртуальных ядер, 2 TB дискового пространства на NVMe и порт 1 Гбит/с с бесплатными 3 TB трафика в месяц.

Бесплатная базовая DDoS-защита работает на серверах в России и Нидерландах. Для проектов с повышенными требованиями к безопасности доступны расширенные пакеты защиты, включая уровень приложений. Это актуально для игровых серверов, финансовых сервисов или публичных API, которые регулярно становятся мишенью для атак.

Партнёрская модель и нестандартные задачи

Hostkey предлагает White-Label решения для реселлеров и партнёров — можно использовать инфраструктуру под собственным брендом с гибкой системой вознаграждений. Компания позиционирует себя как провайдера для нестандартных задач: когда требуется адаптировать конфигурацию под специфичные требования проекта, команда готова проектировать и настраивать решения с нуля.

3. Timeweb Cloud — европейские VDS с фокусом на Германию и Нидерланды

Провайдер работает с дата-центрами уровня Tier III в двух локациях: Франкфурт (Германия) и Амстердам (Нидерланды). Обе площадки соответствуют GDPR, ISO и PCI DSS, обеспечивают SLA 99,98% и связаны с крупными интернет-магистралями Европы. Оплата принимается в рублях, что упрощает расчёты для российских команд без конвертации валюты.

Архитектура построена на тройном резервировании с региононезависимостью — если одна зона недоступна, нагрузка перераспределяется без простоя. Управление происходит через собственную панель, API, CLI или Terraform — можно автоматизировать развёртывание инфраструктуры и интегрировать серверы в существующий CI/CD pipeline.

Что предлагает провайдер

Линейка VDS и VPS начинается с минимальных конфигураций (1 vCPU, 1 GB RAM, 15 GB NVMe) и масштабируется под высоконагруженные проекты. Процессоры работают на частоте 3.3 ГГц, диски — NVMe, каналы — от 200 Мбит/с до 1 Гбит/с. Есть готовые сборки и конфигуратор для индивидуальной настройки под задачу.

Отдельная опция — Managed Kubernetes с развёртыванием кластера за 5 минут через панель, API или Terraform. Вся инфраструктура уже настроена, не нужно тратить время на конфигурирование базовых компонентов. В маркетплейсе доступны готовые пресеты для быстрого запуска типовых сервисов — это сокращает время от идеи до продакшена.

Когда это работает

Timeweb Cloud разделяет сценарии использования по локациям. Германия подходит для проектов, где важна строгая репутация и compliance: финансовые компании с высокой нагрузкой на регуляции, интернет-магазины для DACH-региона (Германия, Австрия, Швейцария), корпоративные сервисы вроде CRM или ERP, где клиенты ценят немецкие стандарты надёжности. Игровые серверы и стриминг для Центральной и Восточной Европы также получают стабильную задержку через франкфуртскую площадку.

Нидерланды ориентированы на более гибкие сценарии: финтех-стартапы с международными транзакциями, e-commerce с охватом всей Европы, игры и стриминг для Западной Европы с минимальным пингом, динамичные SaaS-проекты, где важна скорость запуска и масштабирования. Амстердам исторически выступает как хаб для глобальных магистралей, что даёт хороший отклик для пользователей за пределами ЕС.

Техподдержка и тестирование

Судя по отзывам клиентов, техподдержка отвечает в пределах 5-10 минут и решает задачи по делу — от продления SSL-сертификатов до помощи с развёртыванием. Язык поддержки — русский, что ускоряет коммуникацию для команд из России. Для новых проектов доступен грант на тест-драйв: провайдер помогает перенести существующий проект, настроить инфраструктуру и проверить стабильность работы до полного перехода.

4. FirstByte — бюджетные VDS с широкой географией

Провайдер работает с девятью локациями: Россия, Финляндия, Нидерланды, Германия, Франция, Испания, Болгария, США и Сингапур. Это даёт возможность выбрать площадку под конкретный регион присутствия — от Западной Европы до Юго-Восточной Азии. Все тарифы оплачиваются в рублях, техподдержка работает круглосуточно на русском языке через тикет-систему в личном кабинете.

Что предлагает провайдер

Линейка VPS и VDS построена на процессорах Intel Xeon E5, оперативной памяти DDR4 и SSD-накопителях. Конфигурации масштабируются от минимальных (768 MB RAM, 5 GB SSD) до серьёзных рабочих нагрузок (до 32 GB RAM, 200 GB SSD). Каналы связи — 100-200 Мбит/с, защита от DDoS варьируется в зависимости от локации: L3/L4 в России, BlackHole в Финляндии, США и Сингапуре, базовая защита в европейских дата-центрах.

Управление автоматизировано через единый интерфейс: личный кабинет с биллинговым центром, обработка услуг без участия персонала, предустановка последних версий популярных CMS. Дополнительно доступны выделенные серверы, веб-хостинг, SSL-сертификаты и бесплатный DNS-хостинг на трёх серверах (DataPro Москва, OVH Страсбург, WebDC Москва) с автоматической балансировкой нагрузки.

Когда это работает

Типичные сценарии: разработка и тестирование проектов с ограниченным бюджетом, запуск небольших веб-сервисов или блогов в нужной географии, VPN-серверы для команд (хотя провайдер уточняет, что не несёт ответственности за работу VPN-сервисов), репозитории кода. Широкая география позволяет покрыть разные рынки одним провайдером — например, сервер в Хельсинки для Скандинавии, в Мадриде для Испании и Латинской Америки, в Сингапуре для Азии.

Для проектов с высокими нагрузками доступны выделенные серверы и конфигурации до 8 vCPU. Если нужно протестировать инфраструктуру перед оплатой — провайдер предоставляет тестовый доступ на 24 часа (условия уточняются у менеджеров).

DNS-инфраструктура

Бесплатный DNS-хостинг работает на трёх серверах в разных дата-центрах с автоматической балансировкой. При недоступности одного сервера запросы перенаправляются на другие с минимальным временем отклика. Поддерживаются все популярные типы DNS-записей для доменов в зонах от .RU и .РФ до .ONLINE и .TECH.

5. 1cloud — российский провайдер с площадками в СНГ и Балтии

Компания работает с шестью локациями: Санкт-Петербург, Москва, Астана, Алма-Ата, Минск и Таллин. География сфокусирована на России, Казахстане, Беларуси и Эстонии. Все дата-центры имеют сертификацию Tier III, европейская площадка в Таллине дополнительно лицензирована по стандарту PCI DSS с резервированием N+1 и схемой питания 2N.​

Что предлагает провайдер

Линейка включает VPS/VDS на базе Windows, Linux или FreeBSD с правами администратора и любой конфигурацией. Управление происходит через панель 1cloud с API для автоматизации процессов. Доступны пулы ресурсов с оборудованием разных типов и производительности — при создании виртуальной машины можно выбрать параметры аппаратной основы под конкретную задачу.​

Дополнительные сервисы: частное облако с упрощённым управлением IT-инфраструктурой через несколько кликов, облачное объектное хранилище с S3 и SWIFT API для раздачи статического контента и хранения бэкапов, бесплатный DNS-хостинг с управлением доменными зонами через панель или API, SSL-сертификаты от Globalsign (включая EV и WildCard), CDN для быстрой доставки контента, Anti-DDoS защита с доступностью 99,9875%.​

Когда это работает

Типичные сценарии: хостинг приложений в соответствии с ФЗ-152 о персональных данных (у провайдера есть лицензии ФСБ и ФСТЭК, полное сопровождение проекта опытными менеджерами), размещение данных платёжных карт в защищённом сегменте с сертификацией PCI DSS, развёртывание корпоративных сервисов с требованиями к локализации данных в России и СНГ.​

Московский ЦОД Dataspace получил сертификат Tier III Operations Gold от Uptime Institute — каждый критический элемент инфраструктуры зарезервирован и может быть заменён в горячем режиме без влияния на оборудование клиентов. Площадка в Астане работает на Hi-End оборудовании Dell, Huawei, Cisco, что обеспечивает высокую производительность для проектов с нагрузкой на вычисления.​

Резервное копирование и архитектура

Провайдер встроил резервное копирование в базовую функциональность облака — детали о стоимости и механизме работы описаны в документации. Общая архитектура 1cloud построена на комбинации аппаратного и программного обеспечения, которое обеспечивает надёжность и скорость работы сервисов. Балансировщик нагрузки и расширенное облачное хранилище находятся в разработке.

Что выбрать

Выбор провайдера зависит от того, где именно нужно разместить инфраструктуру и какие задачи решать. Если проект требует присутствия в конкретной стране Европы — Timeweb Cloud покрывает Германию и Нидерланды с compliance по GDPR. Для бюджетных тестовых сред с широкой географией подойдёт FirstByte. Hostkey даёт GPU-инфраструктуру и собственный парк оборудования с быстрой заменой при сбоях.

Когда речь о крупных проектах с требованиями к глобальному присутствию — ITGLOBAL.COM покрывает 11 дата-центров на трёх континентах. Это единственный провайдер из подборки с площадками от Северной Америки до Ближнего Востока и Латинской Америки. Возможность оплаты в рублях, евро, долларах, юанях или криптовалюте решает вопрос с валютными операциями, а выбор между российским и зарубежным юрлицом упрощает бухгалтерию.

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

По его словам, человечество несколько столетий приучали к простой мысли: если ответ выдала машина — значит, он правильный.

Сначала механические калькуляторы, потом компьютеры, потом автоматизация всего подряд. Ошибка человека — норма, ошибка машины — исключение.

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

Они выглядят убедительно, говорят уверенно и звучат разумно. Но в то же время они не обладают тем качеством, на котором строилось доверие к машинам: надежностью результата.

Как работает классическое мошенничество

Любая афера строится по одной схеме. Сначала формируется доверие. Потом играют на эмоциях — страхе или надежде. В конце создается ощущение срочности: действуй сейчас, иначе проиграешь.

Критика LLM предлагает рассматривать нынешний ИИ-бум именно в этом ключе. Нам показывают системы, которые «почти как человек». Затем годами подогревают доверие к автоматическим решениям. И в итоге включают эмоциональное давление.

Страх как основной двигатель

Риторика вокруг ИИ с самого начала строилась на страхе. Нам рассказывали о риске вымирания человечества, потере рабочих мест и необходимости срочно адаптироваться.

То есть если не внедришь ИИ, то тебя обязательно вытеснят. Или еще пример: если не научишься пользоваться искусственным интеллектом, то останешься без работы.

При этом те же компании продолжают активно продавать доступ к своим моделям и наращивать дата-центры. Если бы угроза была реальной, логичным шагом было бы торможение, а не масштабирование.

Лесть вместо интеллекта

Вторая эмоциональная ловушка — симпатия. Современные LLM намеренно обучены быть максимально дружелюбными и поддерживающими.

Это результат RLHF — обучения с подкреплением от людей. Модели усваивают простое правило: чем больше ты хвалишь пользователя, тем выше оценка.

В итоге система одинаково восторженно поддерживает рабочую идею, ошибочный вывод или откровенно бредовую гипотезу.

Это создает иллюзию понимания и формирует псевдодоверительные отношения между человеком и машиной.

Срочность и пузырь ожиданий

По словам Реннера, нас убеждают — действовать нужно прямо сейчас. Инвестировать, перестраивать бизнес, увольнять людей, внедрять ИИ везде.

И компании охотно ведутся на манипуляцию. Хотя реальность оказывается куда прозаичнее: по данным исследований MIT, до 95% ИИ-проектов в индустрии не приносят ожидаемого ROI.

Не интеллект, а уверенная болтовня

Ключевая мысль материала проста: LLM не являются интеллектуальными системами. Они не понимают, не проверяют и не знают — они угадывают наиболее правдоподобный ответ.

Но благодаря исторически сложившемуся доверию к машинам, мы принимаем этот ответ за истину. Именно на этом и держится иллюзия.

1. H3LLO.CLOUD

H3LLO.CLOUD — молодая, но амбициозная облачная платформа гиперскейлерского уровня, построенная с нуля без легаси и на передовом железе. Облако уже находится в боевой эксплуатации, с гарантированным SLA 99.97% и возможностью масштабирования клиентских нагрузок в 10 раз и более в моменте. Команда обещает бенчмарк на уровне 1 миллиарда запросов в секунду — подобную нагрузку держит только AWS. Пока кейсы клиентов в процессе подготовки, платформа уже показывает уверенную стабильность: с момента запуска не было зафиксировано ни одного падения нагрузки в проде. Под капотом — каналы до 800 Гбит/с, внутренние сети на 400 Гбит/с, балансировщик нагрузки, автоскейлинг (в разработке), быстрый отклик техподдержки (от нескольких минут до пары часов).

H3LLO.CLOUD предлагает IaaS и PaaS: виртуальные машины, объектное хранилище (S3), DNS, балансировщики, базы данных, Kubernetes, очереди и SOC — всё на собственной платформе без OpenStack. В архитектуре предусмотрено размещение в трёх дата-центрах: два в IXCellerate (Москва) и один собственный, до конца года появятся еще пять региональных площадок. Используются серверы последнего поколения HP Proliant Gen11 на процессорах Intel Gen6 и памяти DDR5 — это дороже, но в 3 раза быстрее, обеспечивая до 40% экономии для клиента.

Условия тарификации прозрачны: базовый набор ресурсов (2 vCPU, 4 ГБ RAM, 40 ГБ диска, белый IP, база данных, 100 ГБ S3 и Load Balancer) предоставляется на год бесплатно при пополнении баланса всего на 5000₽. Управление — через собственную панель с мониторингом, поддержка API и скриптов для автоматизации.

2. L1veStack

L1veStack — бессерверная PaaS-платформа, созданная для быстрого развёртывания, управления и масштабирования приложений на базе Docker-контейнеров. Это решение фокусируется на упрощении работы DevOps-инженеров и разработчиков: запуск микросервисов происходит за секунды, а мониторинг и настройка портов — через интуитивную панель. SLA платформы составляет 99.97%, показатели отказоустойчивости и масштабируемости соответствуют продакшен-нагрузкам. Кейсы клиентов находятся в процессе, однако инфраструктура уже стабильно работает в разных сценариях: от слабонагруженных Dev-сред до боевых систем с нестабильным трафиком.

L1veStack подходит для тех, кто ищет баланс между простотой VPS и возможностями облачной архитектуры. Платформа реагирует на пиковые нагрузки, адаптируясь под разные среды: dev, stage, прод и внутренние сервисы. Средний аптайм — 99.97%, масштабирование происходит гибко и без участия пользователя.

Цены прозрачны:

• 1%vCPU (High Performance) — 0,45 ₽/час
• MB RAM (DDR5) — 0,00085 ₽/час
• GB SSD (3xReplicated) — 0,015 ₽/час
• IPv4 Public IP — 0,015 ₽/час

Сейчас проект в бете: все ресурсы предоставляются бесплатно, а ранние пользователи получат бонусы. Управление — через удобную визуальную панель со статусами контейнеров и настройкой в пару кликов.

3. Incloud

Incloud — облачная платформа для бизнеса любого масштаба, работающая на отказоустойчивом кластере VMware с использованием Enterprise-СХД NetApp и HPE 3PAR. Вся инфраструктура резервирована: дублируются сетевые устройства, питание обеспечивается двумя вводами от разных подстанций и собственными дизельными генераторами. Это гарантирует стабильность и защищённость сервисов, что подтверждается аптаймом 100% за последние 12 месяцев при SLA 99.95%.

На платформе развёрнуты десятки проектов малого и среднего бизнеса, в том числе NT-IT — IT-аутсорсер, обслуживающий клиентов с разнообразной инфраструктурой. До перехода в облако Incloud компании приходилось сталкиваться с разрозненными системами и частыми инцидентами у разных провайдеров. После миграции в Incloud удалось централизовать управление пулами ресурсов, сократить сроки запуска новых проектов с нескольких дней до часов и снизить число простоев до минимума. Инженеры NT-IT отмечают быстрый отклик поддержки и возможность гибкого масштабирования без расширения штата.

Incloud предоставляет IaaS и SaaS-решения, включая корпоративную почту Exchange, базы данных и 1С. Масштабирование происходит мгновенно за счёт резерва мощностей: в любой момент можно увеличить ресурсы под пиковую нагрузку. Среднее время реакции техподдержки на инциденты — 15 минут.

Тарифы прозрачны: базовый CPU — от 250 ₽, RAM — от 200 ₽ за 1 ГБ, диски — от 4 ₽ за 1 ГБ (SATA) до 12 ₽ (SSD/NVMe), резервные копии — 2 ₽ за 1 ГБ. Для производительных конфигураций CPU доступен от 500 ₽ за ядро и RAM — от 250 ₽. Калькулятор для расчёта доступен на сайте.

4. Cloud.ru

Cloud.ru Evolution — это масштабируемая облачная платформа, построенная на собственных технологиях и открытых компонентах. Пользователям доступны десятки IaaS- и PaaS-сервисов: от виртуальных машин и управляемых баз данных до платформы для ML-задач и AI-инструментов. Облачная инфраструктура размещена в дата-центрах Tier III на территории РФ, соответствует требованиям 152-ФЗ и аттестована по УЗ-1. SLA — 99.95%.

Платформа работает по модели «pay-as-you-go» и предлагает гибкую архитектуру: Managed Kubernetes, бессерверные контейнеры, балансировщики нагрузки, геораспределённые хранилища и поддержку Terraform. Есть и физические выделенные серверы, и мощные вычислительные ресурсы с GPU. Новые пользователи получают грант в 4000 бонусов и доступ к free tier. В числе PaaS-инструментов — Kafka, Redis, PostgreSQL, ArenadataDB, Spark, Trino и платформа AI Factory с LLM, инференсом, агентами и обучением ML-моделей в распределённой среде. Панель управления объединяет весь стек облачных сервисов и даёт полный контроль над расходами, доступами и ресурсами.

Cloud.ru подходит как для построения базовой инфраструктуры проекта, так и для сложных AI- и data-driven-сценариев. Среди преимуществ — поддержка контейнеров, работа с Terraform и CLI, встроенные инструменты безопасности и быстрое масштабирование.

Узнать цену для своего сервиса можно через калькулятор.

5. Selectel

Частное облако Selectel — решение для проектов со строгими требованиями к информационной безопасности и кастомизации. Оно может быть развернуто как на инфраструктуре Selectel, так и on-premise, с полным сопровождением инженеров 24/7, лицензированием по модели «за хост» и временем реакции на критические инциденты от 15 минут. Облако полностью совместимо с OpenStack и входит в реестр российского ПО.

Selectel проектирует архитектуру под конкретные задачи клиента: гибкая настройка железа (Intel Xeon, AMD EPYC, NVIDIA GPU), интеграция с СХД, конвергентное и гиперконвергентное хранение на базе Ceph. Возможны сценарии с геораспределённостью и гибридной инфраструктурой. Поддерживаются масштабируемые отказоустойчивые базы данных (PostgreSQL, Kafka, Redis и др.) и Managed Kubernetes до 1 500 нод с GPU-кластерами.

Компания также реализует меры защиты данных под любые регуляторные требования: 152-ФЗ, ФСТЭК №17/21, ГОСТ Р 57580, PCI DSS 4.0. Selectel помогает пройти аттестацию до К-1/УЗ-1 и развивать инфраструктуру с ежемесячными обновлениями и SLA до 99.98%. Это облако для тех, кому нужно не просто IaaS, а стабильная и безопасная цифровая среда, полностью адаптированная под бизнес.

Цены рассчитываются индивидуально.

6. VK Cloud

VK Cloud — универсальная облачная платформа, включающая широкий спектр IaaS- и PaaS-сервисов для разработки, хранения данных, масштабирования и построения отказоустойчивой cloud-native инфраструктуры. Платформа подходит как для стартапов, так и для крупных корпоративных заказчиков, предлагая гибкие условия подключения, бесплатную миграцию и сертифицированную безопасность.

VK Cloud предоставляет виртуальные серверы, сети, объектное хранилище, управляемые базы данных, Kubernetes-кластеры, а также решение VK Data Lakehouse для работы с большими данными. Вся инфраструктура размещена в дата-центрах уровня Tier III в России и соответствует требованиям 152-ФЗ, ГОСТ Р 57580, ISO, PCI DSS. Облачные серверы аттестованы по 152-ФЗ.

Платформа построена на OpenSource и российском ПО, обеспечивает единое резервируемое окружение, автоматическое масштабирование, плановые бэкапы и послеаварийное восстановление. SLA — 99,95% с финансовыми гарантиями. Поддержка 24/7 и «IT-служба одного окна» делают VK Cloud удобным выбором для любых сценариев.

Дополнительно: приветственный бонус 5000 ₽ для новых аккаунтов (до 12 000 ₽ — для юрлиц), гранты до 2 млн ₽ для стартапов и 10 000 ₽/мес. для благотворительных фондов.

7. Timeweb.Cloud

Timeweb.Cloud предлагает аренду выделенных серверов (bare metal) в дата-центрах уровня Tier III в России и Европе с гарантированным SLA до 99,98%. Это решение для тех, кто ищет высокую производительность, изолированную инфраструктуру и максимальную гибкость в управлении.

Вы получаете физический сервер полностью в своё распоряжение: root-доступ, KVM-консоль в панели управления, возможность установить любое ПО и ОС, а также подключать дополнительные процессоры, диски и шлюзы. Вся настройка доступна на уровнях сервера, железа и сети — вплоть до объединения в приватную сеть между регионами и провайдерами.

Timeweb.Cloud предоставляет мощные конфигурации на базе процессоров Intel Xeon Gold, AMD Ryzen 9 и EPYC, с NVMe-дисками и премиальными сборками от Supermicro и Gigabyte. Быстрый запуск готовых конфигураций — от 1 часа, индивидуальные — за 1 день.

Техподдержка — сильная сторона сервиса: персональный менеджер, ответы по телефону и в чате — за минуту, в тикетах — до 15 минут. Надёжность подтверждена соответствием 152-ФЗ, PCI DSS и ISO. Timeweb.Cloud — подходящее решение для разработчиков и бизнеса, которым нужно больше, чем просто «облако», и которые ценят контроль, мощность и поддержку.

На что ориентироваться при выборе облака

Универсального «идеального» облака не существует: платформа должна соответствовать именно вашим задачам. Для стартапов и быстрых MVP подойдут решения с простым управлением и гибкой тарификацией вроде L1veStack или H3LLO.CLOUD. Если ключевую роль играет отказоустойчивость и предсказуемый SLA — обратите внимание на Incloud, Cloud.ru или Selectel. Для работы с большими данными, ML и высоконагруженными сервисами удобнее использовать экосистемы уровня VK Cloud. А если требуется полный контроль над железом и гарантированная изоляция, оптимальным выбором станут выделенные серверы Timeweb.Cloud.

При выборе облака важно учитывать три фактора: технические возможности (производительность, поддержка контейнеров, интеграция с CI/CD), надёжность (аптайм, резервирование, дата-центры Tier III) и экономику (модель тарификации, стоимость ресурсов, наличие грантов и бонусов). Сравнив эти параметры в разрезе реальных сценариев, вы сможете выбрать платформу, которая не подведёт именно в вашем продакшене.

Происходящее привело к тому, что компания официально предупредила партнеров: производство, а также поставки SSD и другой продукции, завязанной на памяти, приостановлены. Причина прозаична — выпускать стало просто нечего.

Проблемы тянутся еще с октября, когда поставки NAND от ключевых производителей — Samsung и SanDisk — внезапно остановились. Цепочка разорвалась и пошли массовые перебои. Из-за этого срывались контракты, а заказы невозможно было выполнить.

В письме партнерам Transcend говорит о «небывалой скорости удорожания» и полном дефиците компонентов. Главный виновник — стремительный рост спроса со стороны ИИ-платформ и облачных дата-центров.

Amazon, Microsoft и другие крупные игроки выкупают огромные объемы NAND под собственные кластерные потребности. На традиционный рынок уходят жалкие остатки и цены там взлетают до небес.

Производители уходят с рынка один за другим

Кризис уже выбивает старых игроков. Crucial — один из самых известных брендов SSD и оперативной памяти — фактически закрывает потребительское направление.

Как пишет CNews, компания уже убрала из продажи большую часть ассортимента, а выпуск SSD прекратит до апреля 2026 года.

Micron, владелец Crucial, объясняет решение нестабильностью бизнеса. Спрос смещается в промышленный и серверный сегменты, а массовые устройства тонут в дефиците и дорожающих компонентах. По словам компании, рынок «разрывает» спрос со стороны ИИ-кластеров и ферм на базе GPU NVIDIA и AMD. Туда же утекают NAND и DRAM.

Дефицит будет только усиливаться

Transcend не считает происходящее временным. Компания ждет, что давление на цепочки поставок сохранится еще минимум от трех до пяти месяцев, а пик кризиса придется на конец 2025 — начало 2026 года.

Это подтверждают и отраслевые источники. SanDisk уже подняла контрактные цены на NAND на 50%. Innolux и Apacer предупредили партнеров о срыве поставок и невозможности выполнять обязательства.

Теперь он человек, который собрал персональный дата-центр, отказался от ChatGPT и крутит свои LLM локально. Об этом он рассказал в своем свежем видео на YouTube.

Свой «ИИ-совет» из восьми моделей

В новом видео PewDiePie показал свой «суперкомпьютер» — 10 GPU уровня RTX 4090, на которых он одновременно запускает до 64 моделей вроде Llama 405B.

Ради фана он даже сделал «ИИ-совет»: восемь нейросетей спорят между собой и голосуют за лучший ответ на его запрос.

Отмена ChatGPT и философия приватности

Феликс отписался от ChatGPT, когда понял, что удаленные чаты все равно остаются в обучающей выборке OpenAI.

«Когда Google или OpenAI знают мои личные данные — это странно. Но если мой ИИ хранит их у меня на ПК — это мои данные».

PewDiePie теперь полностью живет в духе цифрового суверенитета: он отказался от Google, перешел на Linux и GrapheneOS, самохостит облако на Raspberry Pi и даже превратил Steam Deck в сервер.

Из мемного короля в философа самоконтроля

Корни такого подхода — в 2017 году. После скандала с WSJ и разрыва контрактов с Disney и YouTube, Феликс понял, что один заголовок может стереть твою карьеру. С тех пор он выстраивает систему, где не зависит ни от одной корпорации.

Сегодня PewDiePie говорит языком open-source движения: локальные LLM, приватные данные, самохостинг, отказ от бигтеха.

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

Проблемы зафиксированы у Perplexity, Fortnite, Steam, Snapchat, Asana, Roblox, Duolingo, Coinbase, Canva, Venmo, McDonald’s, Apple TV и множества других платформ, завязанных на инфраструктуру AWS.

Согласно данным Downdetector, пик жалоб пришелся на 11:00 МСК, когда было зафиксировано более 5700 обращений, хотя реальное число пострадавших, вероятно, значительно выше.

Половина интернета — в офлайне

AWS — это не просто сервис Amazon, а фундаментальная часть интернета. Она обеспечивает работу миллионов веб-приложений, API и баз данных.

Именно поэтому даже частичный сбой в дата-центрах Amazon мгновенно отражается на десятках отраслей — от финтеха до гейминга.

Показательно, что даже панель статуса AWS Health Dashboard в момент инцидента оказалась недоступна, выдавая ошибку «This site can’t be reached».

Что известно о причинах

Официальных комментариев от Amazon на момент публикации нет, но все признаки указывают на проблемы в восточном регионе Вирджинии (us-east-1) — ключевом узле AWS, через который проходит значительная часть мирового трафика.

Компания Perplexity AI одной из первых подтвердила зависимость инцидента от инфраструктуры AWS.

Perplexity сейчас не работает. Причина — сбой на стороне AWS. Мы уже занимаемся восстановлением.

С аналогичным сообщением выступили представители Asana, которые сообщили о «полной недоступности всех сервисов» и ожидании обновления от Amazon.

Реакция пользователей

В соцсетях пользователи жалуются на невозможность войти в аккаунты, запускать игры или открывать веб-страницы.

В некоторых регионах перестали работать даже корпоративные системы и приложения, использующие облачное хранилище AWS для авторизации.

Что дальше

AWS пока не раскрывает детали, но инженеры компании, по данным внутренних каналов, уже работают над «локализацией и перезапуском кластеров в Вирджинии».

Сбои AWS происходят редко, но их эффект показывает, насколько уязвим современный интернет: когда падает Amazon — падает и все остальное.

Решение совпало с кадровыми изменениями — после ухода CEO Томаса Демке компания официально интегрируется в подразделение CoreAI корпорации Microsoft.

Причина — нехватка мощностей

По данным The Verge, внутреннее письмо CTO GitHub Владимира Федорова объясняет, что нынешние центры обработки данных достигли предела:

«Мы ограничены в серверных мощностях и не можем наращивать их в регионе Северной Вирджинии»

Федоров назвал миграцию «экзистенциальной». Мол, без перехода в Azure, GitHub не сможет масштабировать сервисы, включая Copilot и другие ИИ-инструменты. Ради этого компания даже заморозит запуск части новых функций до завершения переезда.

Что изменится

По словам COO Кайла Дайгла, переход займет около 24 месяцев. В Microsoft заявляют, что объединение GitHub с CoreAI ускорит разработку и интеграцию ИИ-продуктов, а также улучшит стабильность и производительность платформы.

Интеграция касается не только серверов: сотрудников GitHub уже переводят с Slack на Microsoft Teams для внутренних коммуникаций.

Контекст

GitHub остается крупнейшей экосистемой для разработчиков, но нагрузка растет из-за взрывного интереса к ИИ-инструментам и Copilot.

Теперь платформа окончательно становится частью инфраструктуры Microsoft — как технологически, так и организационно.

Пожар произошёл 26 сентября 2025 года и, по данным издания DCD, был вызван возгоранием аккумуляторных батарей. Инцидент парализовал работу ряда государственных ведомств, включая цифровые сервисы, кадровые системы и хранилища документов.

Уничтожен сервер G-Drive — без резервной копии

Наиболее серьёзной потерей может стать гибель правительственного G-Drive — внутреннего облачного сервиса хранения документов, который использовался всеми госслужащими.

«Система G-Drive не имела резервного копирования из-за колоссального объёма данных», — сообщил источник из правительства в интервью The Chosun.

«Остальные 95 систем имели резервные копии — онлайн или офлайн, но этот диск был уязвим».

Всего, по официальным данным, в огне были полностью уничтожены 96 систем.

Правительственные службы — фактически в стоп-режиме

По информации Министерства управления персоналом, многие отделы не могут выполнять ежедневные операции:

«Сотрудники хранили все рабочие материалы на G-Drive. Сейчас работа практически остановлена».

На момент 5 октября восстановлено 115 из 647 сетей, что составляет лишь 17,8%.

Полное восстановление инфраструктуры может занять до одного месяца.

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

Полиция Южной Кореи арестовала четырёх человек, предположительно связанных с профессиональной халатностью, которая могла привести к возгоранию.

Расследование продолжается, в том числе изучаются условия хранения аккумуляторов и системы пожаротушения.

Трагедия на фоне восстановления

Как сообщает The Dong-A Ilbo, 3 октября трагически погиб 56-летний сотрудник Министерства цифровых инноваций, курировавший восстановление сетей NIRS.

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

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

По данным The Information и независимых аналитиков, Microsoft с трудом продала Copilot всего 1,8 млн пользователей — при общем числе подписчиков Microsoft 365 в 440 млн человек. То есть платной версией пользуются менее 0,5% клиентов.

Причина? Продукт дорогой (от $30 в месяц) и пока не дает ощутимого прироста производительности.

Вдобавок, компания теряет более $20 в месяц на одного пользователя Copilot, а некоторые обходятся ей в $80 и выше.

А как дела у OpenAI?

Тоже не очень. Стартап обещает потратить $1 трлн на инфраструктуру (в том числе — дата-центры и чипы NVIDIA), но:

• Зарабатывает при этом около $13 млрд в год.
• Уже имеет контрактов на $300+ млрд, которые пока не может оплатить.
• Ищет финансирование у Oracle, Microsoft, инвестфондов и всех, кто готов поверить в «революцию ИИ».

Тем временем, Claude Code от Anthropic, один из популярных ИИ-ассистентов для программирования, приносит около $33 млн в месяц, но работает в минус — пользователи жгут токены быстрее, чем платят за подписку.

Все пропало?

Нет. Но аналитики называют происходящее «одним из самых раздутых пузырей в истории Кремниевой долины».

• Генеративный ИИ пока не заменил ни одного класса специалистов.
• Продукты вроде Copilot и ChatGPT остаются дорогими в обслуживании.
• Доходность большинства ИИ-стартапов находится на грани фола (если не за ней).

Что дальше?

Пока компании вроде OpenAI и Anthropic продолжают сжигать миллиарды, инвесторы верят в «будущее».

Но с каждым новым месяцем становится все сложнее игнорировать факты: ИИ-революция может закончиться раньше, чем NVIDIA успеет доставить новые чипы.

Утечка касается компании Geedge Networks. Она, по данным WIRED, поставляет технологии цифрового надзора и цензуры не только в Китае, но и в прочие страны.

Что входит в утечку?

Среди слитых данных:

• Исходный код платформы Tiangou Secure Gateway (TSG) — «файрвол из коробки», способный фильтровать весь интернет-трафик страны.
• Логи, Jira/Confluence-данные, рабочая переписка, внутренняя документация.
• Скрипты, позволяющие внедрять вредоносный код в HTTP-трафик.
• Материалы о разработке «репутационного рейтинга» для пользователей с привязкой к их биометрии.
• Планы по геофенсингу и построению графов связей между пользователями по данным об их активности.

Где работает эта система?

Geedge уже работает в Мьянме, Пакистане, Эфиопии, Казахстане, а также в ряде регионов самого Китая — включая Синьцзян, Фуцзянь и Цзянсу.

Оборудование развернуто в десятках дата-центров. В одной только Мьянме зафиксировано 81 млн активных TCP-соединений в реальном времени.

Что умеет система?

• Перехват нешифрованного трафика и извлечение логинов, паролей, содержимого писем.
• DPI-анализ шифрованного трафика для выявления VPN.
• Блокировка VPN, Signal, Tor и других инструментов обхода цензуры.
• Отслеживание геолокации пользователей, сбор информации о мобильных номерах, устройстве и сессиях.
• Возможность инъекции малвари в уязвимые сайты, которые пользователь посещает без HTTPS.

Кто за этим стоит?

У Geedge тесные связи с Фан Бинсином — «отцом Великого фаервола». Он лично инвестировал в компанию через специальные структуры, а также руководил проектами в Синьцзяне.

Geedge ранее использовала оборудование Dell и HP, но после санкций перешла на китайское «железо».

Почему это важно?

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

Исследователи призывают относиться к утечке с осторожностью: архив содержит модули низкоуровневой слежки, возможно, с уязвимостями, которые могут быть использованы как правозащитниками, так и злоумышленниками.

Мы разобрали семь VPS-хостингов, которые подходят для быстрого деплоя без глубоких познаний в DevOps. Изучили доступные из коробки образы операционных систем и форматы тарификации.

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

1. RUVDS: Гибкое решение для старта и развития MVP

RUVDS позиционирует себя как решение, ориентированное на потребности MVP-проектов, предлагая гибкие условия для старта и развития. Платформа позволяет развернуть прототип с минимальными затратами, быстро получить обратную связь и масштабировать ресурсы по мере роста проекта, избегая необходимости миграции.

Типовые сценарии использования (MVP):

• Небольшой интернет-магазин;
• Лендинг для проверки гипотез;
  
• Тестовый бэкенд/API;
• Чат-боты.

Ключевые преимущества RUVDS для MVP-проектов:

1. Гибкая тарификация и контроль затрат.

• Минимальный тариф: От 139 рублей в месяц за базовую конфигурацию (VPS на Linux, 1 vCPU, 512 МБ RAM, 10 ГБ диска, 1 белый IPv4).
• Оплата по фактической нагрузке: Для проектов с переменной нагрузкой предусмотрена посекундная тарификация или списание каждые 15 минут, позволяющие оплачивать только фактически потребленные ресурсы. Неиспользованный остаток средств возвращается на баланс.
• Долгосрочные скидки: При предоплате на срок от 3 до 12 месяцев предоставляются скидки до 20%.

2. Быстрый старт и удобное управление.

• Маркетплейс шаблонов: Доступны готовые шаблоны для быстрого развертывания различных решений.
• База знаний: Подробный справочник с пошаговыми инструкциями для новичков и расширенными гайдами для опытных администраторов.
• Бесплатная ISP Manager: До конца 2025 года панель управления ISP Manager предоставляется без дополнительной платы при создании любого VPS.

3. Бесшовное масштабирование.

Ресурсы сервера (CPU, RAM, диск) легко масштабируются непосредственно из личного кабинета, что исключает необходимость миграции данных при росте проекта.

• Стандартный IPv4-адрес. Каждая виртуальная машина включает в стоимость стандартный IPv4-адрес. Дополнительные IPv4-адреса доступны для аренды.
• Интеллектуальное управление через API. API, соответствующее OpenAPI 3.0.0, позволяет интегрировать ресурсы с внешними системами и автоматически масштабировать серверные мощности в зависимости от нагрузки.

4. Глобальная инфраструктура и стабильность.

• Дата-центры: Инфраструктура включает 18 дата-центров уровня Tier III, расположенных по всему миру, что является одним из крупнейших показателей среди российских провайдеров по географическому охвату.
• Оборудование: Использование корпоративного оборудования и современных накопителей (HDD, SSD, NVMe) обеспечивает высокую производительность и надежность работы размещенных проектов.

5. Круглосуточная техническая поддержка.

• Доступность: Служба поддержки доступна 24/7.
• Время ответа: Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет около 15 минут.
• Административные права: Клиенты сохраняют полные административные права на серверы и могут получать консультации по их настройке и эксплуатации.

6. Безопасность.

Платформа реализует комплекс мер для обеспечения безопасности данных и стабильности работы клиентских проектов.

• Защита от DDoS-атак. Встроенная защита от DDoS-атак работает 24/7, обеспечивая бесперебойную работу серверов даже при сильном внешнем давлении.
• Гарантия безопасности данных. Подтверждено соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных.

RUVDS предлагает комплексное решение для развертывания MVP-проектов, сочетая в себе экономичность, гибкость масштабирования и удобство управления. Это позволяет командам быстро тестировать гипотезы и развивать продукты, минимизируя первоначальные инвестиции и операционные сложности.

2. KoaraCloud: быстрый и оптимальный старт

Базовая конфигурация провайдера заточена под деплой нетребовательных сервисов. Минимальный тариф стоит 279 рублей за месяц аренды. В эту конфигурацию включен сервер с 1vCPU на базе процессора Ryzen 9 3900, 1 ГБ оперативной памяти, накопитель на 15 ГБ и пропускная способность сети 100 Мбит/с.

Под какие задачи подойдет

Стартовых мощностей достаточно для публикации лендингов, развертывания тестового бэкенда или проверки гипотез легкого SaaS-решения. Поднять интернет-магазин на минималках не выйдет — для работы тяжелых баз данных без лагов потребуются конфигурации START-2 или DE-1.

Ресурсы можно масштабировать по мере роста проекта. Апгрейд тарифа внутри одной линейки делается в два клика через панель управления. Провайдер работает по ежемесячной подписке без почасовой оплаты, но возвращает средства по запросу, если сервер не подошел под специфику сервиса.

Формат работы поддержки

Штат инженеров дежурит круглосуточно, среднее время ответа специалиста составляет 5–10 минут. Часть типичных задач берет на себя автоматический ИИ-ассистент — он же подсказывает по вопросам запуска MVP на минимальных тарифах. На старших тарифах с настройкой проекта помогает уже живой саппорт.

Задать технические вопросы можно на сайте, через Telegram-бота или в чате коммьюнити. Сбои обычно носят локальный характер и затрагивают небольшие группы серверов. Информацию об инцидентах сразу публикуют в канале, а восстановление доступа занимает от 5 до 20 минут.

Характеристики всех машин собраны на сайте KoaraCloud. С апреля ребята также развивают свой блог, где раз в одну-две недели публикуют практические мануалы по работе с VDS.

3. Timeweb: виртуальные серверы для MVP и рабочих окружений

Когда речь заходит о запуске MVP-проекта, разработчикам важен не только тариф, но и то, как быстро можно развернуть инфраструктуру, перенести код и при необходимости расширить ресурсы. Timeweb выстраивает всю экосистему вокруг этого подхода: прозрачные тарифы, гибкость в настройке и упор на поддержку, которая берёт часть задач на себя.

Тарифы для старта: от минимального к кастомному

Самый доступный вариант — Cloud MSK 15 за 270 ₽ в месяц (или 9 ₽ в день). Конфигурация выглядит так: процессор 1×3.3 ГГц, 1 ГБ RAM, 15 ГБ NVMe-диска, публичный IP и канал 1 Гбит/с без ограничений по трафику. Для MVP-лендингов, тестовых API или небольших CRM-систем этого достаточно.

Дальше тарифная линейка растёт по наращиванию RAM и диска: от Cloud MSK 30 (495 ₽/мес., 2 ГБ RAM и 30 ГБ диска) до конфигураций с двумя ядрами и расширенным хранилищем. Есть и кастомный вариант — собрать сервер под себя с минималкой от 594 ₽/мес.

Оплата возможна помесячно или по дням — удобно для тестов и экспериментов, когда сервер нужен на короткий срок.

Сценарии использования

Timeweb прямо указывает на широкий диапазон проектов: от тестовых сред разработки и блогов до онлайн-магазинов, ERP-систем и даже игровых серверов. На практике это значит, что один и тот же VPS можно легко переиспользовать: сегодня для staging-окружения, завтра — для SaaS-прототипа.

Контроль и масштабирование

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

Интерфейсы и управление

Управление организовано максимально гибко:

• собственная веб-панель с современным UI,
• мобильные версии для iOS и Android,
  
• API для автоматизации, включая поддержку Terraform и cloud-init (массовый запуск серверов),
  
• привычные панели уровня ISPmanager, Vesta, Hestia и др., которые можно подключить в один клик.

Поддержка и миграция

Поддержка у Timeweb работает в чате и мессенджерах сразу, а тикеты разбирают в течение 20 минут. Для тех, кто переносит проект с другого хостинга, действует сервис миграции без простоев: команда сама перенесёт файлы, развернёт ПО (Nginx, Apache, MySQL, PHP) и проверит работоспособность. Бесплатно можно получить и настройку сервера, и восстановление сайта из бэкапа.

Для более сложных сценариев доступно платное администрирование — если хочется снять с себя рутину управления VPS.

Инфраструктура и безопасность

Сервера развёрнуты в дата-центрах уровня TIER III в России, Казахстане и Европе. SLA заявлен на уровне 99,98 %. С точки зрения безопасности — соответствие 152-ФЗ, ISO и GDPR (актуально, если пользователи из ЕС). Встроенная защита от DDoS покрывает уровни L3–L4, а L7 можно подключить дополнительно.

Timeweb подойдет для небольших интернет-магазинов, SaaS-MVP, игровых серверов, а также для команд, которые разворачивают staging-окружение и хотят быстро переключаться между конфигурациями.

4. Cloud4box: виртуальные серверы с гибкой настройкой и строгим SLA

Cloud4box делает акцент на прозрачности: никаких oversell, только гарантированные ресурсы и чёткий SLA на уровне 99,98 %. Для команд, которым важна предсказуемость окружения и возможность быстро менять конфигураци, это может стать ключевым фактором.

Тарифы и масштабирование

У Cloud4box нет жёсткой тарифной сетки — здесь работает конфигуратор, который позволяет собрать сервер под задачу. Минимальный старт возможен с 1 ядра CPU, 1 ГБ RAM и 20 ГБ диска. Важная особенность — ресурсы можно увеличивать и уменьшать даже после оплаты, не прерывая работу сервиса. Это удобно для MVP: сегодня хватает базовой конфигурации, завтра — можно добавить ядро или пару гигабайт памяти в пару кликов.

Дополнительно доступны гибкие опции: +1 ядро за 110 ₽ в месяц, +1 ГБ RAM за 46 ₽, +1 ГБ диска всего за 4,8 ₽. Такой подход позволяет понять оптимальный баланс мощности и бюджета без переплат за неиспользуемые ресурсы.

Техническая база

Cloud4box использует современное «железо»: процессоры Intel i9-9900K и Xeon Gold 6240R, серверные SSD-диски Intel и Micron. Виртуализация — KVM без oversell, то есть клиент получает ровно те ресурсы, которые оплатил. С точки зрения стабильности задекларирован SLA в 99,98 %, а при простое по вине провайдера действует компенсация в трёхкратном размере.

Дата-центры уровня Tier-3, а сеть соединена с крупнейшими точками обмена трафиком. Для юридических лиц — полный комплект закрывающих документов через ЭДО.

Управление и дополнительные услуги

Сервера активируются в течение 5–10 минут после оплаты. На выбор доступны панели управления: Hestia, Fastpanel или Plesk. Из дополнительных опций — полные бэкапы дисков (3,3 ₽ за 1 ГБ в месяц), снапшоты, резервное копирование по расписанию.

Для ОС выбор широкий: от Ubuntu (20.04, 22.04, 24.04) и Debian (11, 12) до AlmaLinux, CentOS, FreeBSD и Windows Server (2016, 2019, 2022). При необходимости можно поставить любую другую ОС через панель.

Поддержка и администрирование

Техподдержка отвечает в среднем за 5–15 минут и работает 24/7. В базовом пакете — помощь с установкой ОС, перенос данных и базовая DDoS-защита (уровни L3–L4). Для тех, кому нужно больше, доступно платное администрирование: 625 ₽ за 15 минут.

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

Для каких проектов подойдёт

Cloud4box хорошо впишется в сценарии, где важна максимальная предсказуемость SLA и свобода настройки ресурсов. Это может быть staging-окружение для разработчиков, сервисы с непостоянной нагрузкой (например, маркетинговые кампании), корпоративные проекты с требованиями по документообороту.

5. Макхост: виртуальные серверы на KVM с простым входом и гибкой линейкой

Макхост предлагает линейку VPS/VDS на KVM-виртуализации с акцентом на баланс между минимальным входным порогом и возможностью развернуть серьёзные проекты.

Стартовые тарифы и ресурсы

Минимальный рабочий вариант — тариф KVM-1: одно ядро CPU (2.35 ГГц), 1 ГБ DDR4 RAM и 15 ГБ NVMe-диска. При оплате за год стоимость составит 396 рублей в месяц, плюс в комплекте бесплатный месяц панели ISPmanager 6. На этом уровне можно развернуть лендинг, блог, небольшую CRM или тестовый backend.

Дальше линейка масштабируется до KVM-12: 6 ядер CPU, 12 ГБ RAM и до 360 ГБ NVMe. Для интернет-магазинов, ERP-систем или SaaS-проектов средней нагрузки такие конфигурации дают запас прочности.

Отдельный вариант — короткие акции и спецтарифы с ограничениями (например, KVM-NEW с урезанной RAM), но основной акцент сделан на стабильные планы с безлимитным трафиком и выделенным IP.

Панели и управление

Для управления сервером доступны две панели: бесплатная FastPanel с упором на простоту и Ispmanager lite, который на старте даётся на месяц бесплатно. Обе решают базовые задачи: настройка сайтов, доменов, почтовых ящиков, мониторинг ресурсов.

С точки зрения администрирования пользователи получают root-доступ и полный контроль: можно ставить любой софт, управлять портами и таблицами маршрутизации. Для автоматизации процессов предусмотрена интеграция с популярными Linux-дистрибутивами — CentOS, Debian, Ubuntu, включая готовые сборки с панелями

География и дата-центры

Сервера доступны в двух точках: Россия (Москва, DataPro) и Европа (Нидерланды, Serverius). По умолчанию выбирается российский ЦОД, но переключение на европейский вариант даёт гибкость, если проект ориентирован на зарубежных пользователей.

Поддержка и миграция

Поддержка работает 24/7 через тикет-систему. Отдельный бонус для тех, кто мигрирует с другого хостинга, — бесплатный перенос сайта и месяц использования в подарок. Для сложных задач можно подключить платное администрирование (от 1500 рублей за полчаса), что закрывает сценарии вроде аварийного восстановления или оптимизации производительности.

Акции и дополнительные услуги

К тарифам можно докупить выделенные IP-адреса, SSL-сертификаты и лицензии на панели управления. Часто действуют акции: домен в .RU или .РФ при оплате VPS на год, бонусы за переезд. Эти условия помогают командам оптимизировать бюджет на старте MVP.

Для каких проектов подойдёт

Макхост ориентирован на проекты, которым важна предсказуемость ресурсов и гибкость в управлении: интернет-магазины, корпоративные порталы, проекты с высокой посещаемостью и сложной архитектурой. На младших тарифах можно запускать пилотные версии SaaS-продуктов или выделять staging-сервера под разработку.

6. Fornex: международный VPS с акцентом на географию и поддержку

Для команд, которым важно запускать проекты в разных регионах и контролировать инфраструктуру на уровне железа, Fornex предлагает VPS-сервера в пяти странах и делает ставку на стабильность работы дата-центров и скорость поддержки.

Локации и инфраструктура

Доступны пять точек размещения: Германия, Нидерланды, США, Швейцария и Испания. Все сервера работают на базе Supermicro с NVMe-дисками, объединёнными в RAID10, что даёт отказоустойчивость и предсказуемую скорость. Сетевая архитектура построена на оборудовании Juniper и Arista, а гипервизоры используют KVM-виртуализацию с полной изоляцией ресурсов.

Дата-центры сертифицированы по Tier III и обслуживаются локальными инженерами, которые следят за состоянием оборудования. SLA формализован через высокую доступность и защиту от DDoS-атак до 10 Гбит/с.

Тарифы для старта

Минимальная конфигурация — Cloud NVMe 1 за 6,5 € в месяц: 1 ядро CPU (3 ГГц), 1 ГБ RAM и 10 ГБ NVMe. Такой сервер подойдёт для MVP-лендинга или тестовой среды.

Следующий шаг — Cloud NVMe 2 (8,5 € в месяц), где уже 2 ГБ RAM и 20 ГБ диска — этого достаточно для простого SaaS-прототипа или небольшого интернет-магазина. Линейка продолжается до Cloud NVMe 8 (4 ядра, 8 ГБ RAM, 120 ГБ NVMe) — вариант для нагруженных сервисов.

Трафик во всех тарифах безлимитный, скорость подключения — 100 Мбит/с.

Панели и управление

Управление строится вокруг root-доступа по SSH и VNC, но для удобства можно бесплатно добавить панели вроде HestiaCP, CyberPanel или CloudPanel. Из коробки поддерживаются популярные ОС: Ubuntu, Debian, Fedora, AlmaLinux, RockyLinux, Arch, CentOS и даже Windows Server.

В панели заказа доступны фильтрация трафика и быстрые изменения конфигурации VPS. Это позволяет менять ресурсы «на ходу» без долгих переносов.

Поддержка и реакция

Команда техподдержки работает 24/7, помогают с переносом сайтов, настройками и решением инцидентов без доплат. Среднее время реакции на тикет — 3 минуты 45 секунд, а оценка пользователей — 4,69 из 5. Для тех, кто хочет дополнительной уверенности, действует гарантия возврата денег, если сервис не устроит.

Для каких проектов подходит

Fornex выглядит интересным решением для международных проектов: от e-commerce с трафиком из Европы до SaaS-сервисов с географически распределёнными пользователями. Благодаря гибкой конфигурации и быстрому апгрейду VPS можно начинать с тестового окружения и постепенно расширять его под боевую нагрузку.

7. THE.Hosting: масштабируемый VPS в 46 странах с акцентом на скорость и гибкость

Когда проект требует размещения в разных точках мира — будь то MVP для локального рынка или сервис с распределённой аудиторией — важно, чтобы провайдер предлагал инфраструктуру в широком географическом диапазоне. THE.Hosting работает сразу в 46 странах, а в ключевых локациях (Европа, США, Азия) предоставляет скорость соединения до 10 Gbps, что выделяет его среди решений для проектов с интенсивным трафиком.

Локации и инфраструктура

Сервера доступны в Европе, США, Азии, Латинской Америке и Океании. В крупных центрах — от Германии и Нидерландов до Японии и Австралии — заявлена скорость порта 10 Gbps, а дисковая подсистема построена на NVMe с RAID10 для отказоустойчивости. Виртуализация на базе KVM гарантирует изоляцию ресурсов и полный контроль.

Такой разброс по географии делает сервис интересным для SaaS-проектов, которые хотят приближать окружение к пользователям, снижая задержки, или для e-commerce, работающего сразу в нескольких странах.

Тарифы для старта

Минимальный тариф — Aluminium-[NL] за 5,77 € в месяц: 1 vCore, 1 ГБ ECC RAM, 25 ГБ NVMe и порт 10 Gbps. Это хорошая точка входа для прототипов и тестовых backend-окружений.

Далее линейка растёт ступенчато: Argentum-[NL] с 2 ядрами и 2 ГБ RAM за 6,77 €, Ruthenium-[NL] с 4 ГБ RAM за 9,77 €, и доходит до мощных конфигураций вроде Obsidian-[NL] (32 vCore, 64 ГБ RAM, 510 ГБ NVMe за 160 €) и Adamantium-[NL] (24 vCore, 32 ГБ RAM, 410 ГБ NVMe за 111 €). Такой диапазон позволяет плавно двигаться от MVP до полноценного продакшн-кластера.

Панели управления и ОС

Для управления можно выбрать как платные, так и бесплатные панели: ISPmanager, Plesk, cPanel, DirectAdmin, а также VestaCP, Hestia, CyberPanel и другие без дополнительной платы.

Из операционных систем доступны популярные Linux-дистрибутивы (Ubuntu, CentOS, Debian, Arch, AlmaLinux и др.) и Windows Server — что делает сервис универсальным для разных стеков разработки.

Поддержка и перенос

THE.Hosting предлагает круглосуточную поддержку администраторов, которые помогают с настройкой окружения и запуском проекта. Важный плюс — бесплатный перенос данных с другого хостинга.

Запуск автоматизирован: сервер активируется в течение 15 минут после заказа. Это удобно для команд, которым нужно быстро развернуть тестовую или боевую среду без лишних задержек.

Для кого подойдёт

THE.Hosting хорошо вписывается в сценарии, где важны скорость и распределённость: стриминговые сервисы, международные SaaS-проекты, крупные e-commerce и highload-системы. Для команд с небольшими MVP подойдёт минимальный тариф, а в будущем можно перейти на серьёзные мощности без смены провайдера.

Если нужно комплексное решение, единая платформа с привычным набором: DDoS-защита, антибот, WAF, DNS, CDN и другие необходимые для веба вещи, то есть платформа NGENIX — одна из ведущих российских альтернатив Cloudflare для проектов любого масштаба.

Что такое NGENIX и почему его выбирают?

NGENIX — российская облачная платформа, которая сочетает в себе защиту от атак, ускорение загрузки, управление DNS и SSL-сертификатами, фильтрацию вредоносного трафика. Инфраструктура развернута в России и СНГ. Переезд с Cloudflare возможен за считанные часы, без риска блокировок Роскомнадзором и с техподдержкой, которая отвечает на русском с понятным SLA.

Основные функции и возможности платформы:

• Защита от DDoS — отражение атак до 7+ Тбит/с и 5 млн RPS, включая атаки на DNS;
• Фильтрация вредоносных ботов — блокировка парсеров, скрейперов и автоматизированных атак;
• Облачный WAF — предотвращает взломы и эксплуатацию уязвимостей;
• Доставка контента (CDN) — благодаря распределённой сети из 50+ узлов в России и СНГ, запросы обслуживаются ближайшим к пользователю сервером;
• Авторитативный DNS — отказоустойчивая система с обработкой до 100+ млн запросов в секунду;
• SSL/TLS-сертификаты — поддержка стандартов шифрования RSA, ECDSA и ГОСТ 34.10, автоматический выпуск и продление SSL-сертификатов Let's Encrypt, поддержка загрузки и использования собственных сертификатов (включая самоподписанные);
• Управление доступом — организация доступа к сайту или приложению при помощи простых правил или подписанных ссылок;
• Стриминг видео — стабильная передача в высоком качестве и в различных форматах;
• Распределенный мониторинг доступности — возможность отслеживать доступность сайта 24/7, оперативно реагировать на инциденты и получать метрики доступности в формате Prometheus;
• Аналитика — 35+ готовых отчётов с задержкой всего в 1 минуту.

Всё это доступно через единый интерфейс.

Инфраструктура под задачи любого масштаба

• 50+ узлов в РФ и СНГ — максимальная близость к пользователю;
• Пропускная способность 7+ Тбит/с — запас на любые пиковые нагрузки;
• На платформе используются разные виды балансировки: Anycast BGP, DNS и HTTP;
• Единый SLA на все сервисы платформы;
• Поддержка 24/7 с быстрой реакцией.

Реальный кейс: переход с Cloudflare за несколько часов

Один из клиентов NGENIX — крупный московский девелопер — столкнулся с блокировкой Cloudflare со стороны Роскомнадзора. Благодаря оперативной техподдержке переход на NGENIX занял всего несколько часов.

В ходе миграции была подключена система защиты от DDoS и настроены индивидуальные правила доступа, что позволило не только полностью заменить функционал Cloudflare, но и сократить расходы на защиту без потери качества фильтрации и безопасности.

Тарифы — под любые масштабы

У NGENIX есть тарифы как для стартапов, так и для корпораций:

• Promo — 6 900 ₽
• Lite — 13 900 ₽
• Start — от 23 900 ₽
• Pro — от 59 900 ₽
• Ultimate — индивидуально, с кастомной настройкой, премиальным SLA и выделенным менеджером.

Кому подойдёт?

• Владельцам, администраторам и командам как небольших и средних сайтов и сервисов, так и крупных проектов в сферах: e-commerce, SaaS, OTT, а также госструктурам и финтеху.
• Компаниям, утратившим доступ к зарубежным облачным сервисам, нуждающимся в быстром и удобном переходе;
• Командам с ограниченным количеством специалистов по безопасности — платформа обеспечивает комплексный набор функций под единым интерфейсом.

Если вы использовали Cloudflare ради скорости, защиты и стабильности — NGENIX даст тот же набор инструментов, но с локальной инфраструктурой, без проблем с регуляторами и с поддержкой, которая говорит с вами на одном языке.

DDoS-Guard: кастомная защита от атак уровня L3–L7 с гибкой настройкой под ваш проект

Если вы думаете, что защита сайта от DDoS-атак — это что-то вроде базового щита на периметре, который «где-то там» на краю сети отсекает подозрительный трафик, то стоит взглянуть, как работает DDoS-Guard. Эта платформа предлагает куда более глубинный подход: защита на всех уровнях от L3 до L7, с возможностью тонкой настройки под архитектуру вашего проекта.

Не просто фильтр, а эшелонированная оборона

DDoS-Guard — это инфраструктурная экосистема, которая умеет:

• отражать любые типы DDoS-атак: как волюметрические, так и прикладного уровня;
• анализировать HTTP-трафик и блокировать вредоносные запросы в реальном времени;
• оптимизировать TTFB и ускорять загрузку контента за счёт встроенного CDN;
• маскировать реальный IP и строить эшелонированную защиту через Reverse Proxy;
• управлять правилами фильтрации на уровне каждого домена, поддомена или даже URI;
• кастомизировать защиту под конкретные угрозы: от скрейпинга до TOR-трафика.

Защита на базе собственного софта и ИИ

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

За счет использования anycast-маршрутизации и собственной сети узлов, DDoS-Guard минимизирует задержки — запросы обрабатываются на ближайшем к пользователю центре фильтрации. Это критично для e-commerce и финансов, где лишняя секунда отклика может стоить клиентской корзины.

Реальный кейс: защита одного из крупнейших онлайн-сервисов по продаже лекарств

Один из клиентов DDoS-Guard — сервис из топ-3 аптечных агрегаторов в России — обратился с проблемой: высокий TTFB, нестабильная маршрутизация после сбоев и уязвимость к ботам и парсерам.

После миграции с Cloudflare результат оказался ощутимым:

• скорость сайта выросла на 40%;
• появились гибкие правила фильтрации и кастомный каскад антискрейпинга;
• доступность под нагрузкой восстановлена полностью.

И всё это — без «боли» переезда: миграция прошла быстро, с сопровождением инженеров DDoS-Guard.

Кому подойдёт?

DDoS-Guard — это решение не только для корпораций. Сервис работает с банками, госорганами, e-commerce и телекомом, но в то же время:

• небольшим проектам подойдёт тариф Basic (визитка, лендинг, каталог);
• малому и среднему бизнесу — Normal и Medium с фильтрацией TOR, кастомными TLS-наборами;
• крупным продуктам — Premium и Enterprise, где возможны уникальные L7-модули и фильтры на уровне API.

Сегменты, где защита особенно критична: СМИ, маркетплейсы, финтех, игровые платформы, госуслуги.

Что говорят внутри

«Мы анализируем HTTP-запросы на лету, сверяясь с интернет-стандартами и нашими сигнатурами, — рассказывает Дмитрий Никонов, руководитель веб-направления DDoS-Guard. — Это позволяет блокировать атаки без ложных срабатываний и без тормозов. Наши клиенты могут гибко настраивать правила, в том числе каскадные сценарии защиты на каждый поддомен».

StormWall: когда защита сайта — дело минут, а не дней

Если ваш проект работает в интернете, то вопрос киберзащиты — это не «если», а «когда». DDoS-атаки стали буднями даже для малого бизнеса, не говоря уже о финансовых сервисах, SaaS, e-commerce или онлайн-играх. И вот тут в игру вступает StormWall — российский разработчик решений для защиты сайтов, сетей и онлайн-сервисов с опытом более 12 лет.

Быстрая и комплексная защита от DDoS — без компромиссов

StormWall — это не просто прокси с анти-DDoS, а целая облачная экосистема, заточенная под разные типы инфраструктуры. Заказчику доступны сразу три варианта защиты:

• Для сайтов и приложений — включает DDoS-защиту, антибот, WAF;
• Идеально для интернет-магазинов, медиа, финтеха и госсайтов;
• Для сетей и автономных систем — работает на уровнях L3/L4, актуально для провайдеров, дата-центров и телекомов;
• Для сервисов на базе TCP/UDP — используется в играх, VoIP, стриминге, VPN и других чувствительных к задержкам сервисах.

За счёт собственной сети фильтрации с пропускной способностью 5+ Тбит/с и 9 дата-центров по всему миру, платформа может нейтрализовать даже самые сложные мультивекторные атаки.

Антибот, WAF, CDN — всё из одного окна

StormWall — это не только анти-DDoS. В арсенале платформы есть и другие полезные инструменты:

• Web Application Firewall (WAF) — защита L7 от SQL-инъекций, XSS и других попыток взлома;
• Антибот — фильтрация трафика по сигнатурам и поведенческим признакам;
• CDN — для ускорения контента, доставки видео, апдейтов и стабильной работы под нагрузкой;
• DNS, reverse proxy, API gateway — всё интегрировано в инфраструктуру с управлением через личный кабинет.

Быстрая миграция, как это было у АТОЛ

Весной 2022 года на облачные сервисы и онлайн-кассы АТОЛ обрушились мощные DDoS-атаки. Компания была вынуждена срочно искать профессиональное решение для защиты — и выбрала StormWall. За 10 минут специалисты развернули защиту, и уже через 30 минут вредоносный трафик был отфильтрован.

Даже при ежедневных DDoS-атаках мощностью 50–100 Гбит/с сервисы разработчика продолжают работать бесперебойно — клиенты-ритейлеры уверены в стабильности и надёжности его ПО.

Кому подойдёт StormWall?

• E-commerce и ритейл — устойчивость к пикам в «чёрную пятницу»;
• Банки и финансы — SLA и отказоустойчивость на уровне инфраструктуры;
• Госуслуги — соответствие реестру российского ПО;
• Разработчики игр, стриминговые платформы, SaaS — защита TCP/UDP и CDN для скорости;
• Малый бизнес — тарифы от 7 200 ₽ в месяц и помощь при миграции.

Почему выбирают StormWall

• Поддержка 24/7, ответ до 15 минут;
• Сервис как услуга — от настройки до сопровождения;
• Собственные технологии на C с eBPF и DPDK, асинхронные микросервисы на Python и JavaScript;
• Реестр российского ПО, лицензии СЗКИ/ТЗКИ;
• Модульность и кастомизация фильтрации под каждого клиента;
• Поддержка BGP, reverse proxy, API gateway, машинное обучение внутри фильтров.

Тарифы — от малого до enterprise

• Для сайтов: от 7 200 ₽/мес;
• Для сетей и сервисов: от 18 000 ₽/мес;
• Enterprise — по запросу, под SLA, с кастомными модулями фильтрации.

Вывод: российские аналоги уже закрывают ключевые задачи Cloudflare

После ухода зарубежных провайдеров рынок не остался пустым. NGENIX, DDoS-Guard и StormWall доказали, что могут обеспечить не только базовую защиту, но и полный набор сервисов для ускорения сайтов, фильтрации трафика и борьбы с ботами.

Если нужен комплекс «всё в одном» — с CDN, WAF, DNS и отказоустойчивостью, стоит смотреть на NGENIX: инфраструктура в России, понятный SLA и миграция за часы без проблем с регуляторами. DDoS-Guard — выбор для проектов, которым нужна глубина кастомизации и защита на всех уровнях L3–L7. StormWall берут за скорость внедрения и большой спектр решений — от сайтов до сетей и игровых сервисов.

Главный вывод: закрыть задачи Cloudflare в России сегодня реально — выбор зависит от масштаба бизнеса, критичности инфраструктуры и требований к гибкости настроек.

Чтобы сэкономить вам время и нервы, мы разобрали рынок и собрали подборку облачных платформ. В ней — топовые провайдеры с примерами, ценами и плюсами. Поможет выбрать решение под вашу задачу и бюджет, без длинных ресёрчей и сомнительных форумов.

1. H3LLO.CLOUD: для быстрого старта

Если вы запускаете стартап, делаете MVP или просто не хотите платить больше за инфраструктуру — у H3LLO.CLOUD есть стартовый набор на 12 месяцев, который бесплатно выдается при создании аккаунта.

Специально собрали предложения под запросы небольших команд и стартапов: 2 базовые ВМ Capsule.S (1vCPU/2GB RAM/12,5 NVMe), 5GB Network SSD, 5GB Object Storage, 1 Basic LoadBalancer, 1 IPv4, мониторинг.

Этого набора более чем хватит, даже для довольно посещаемых проектов. А тем, кому нужно больше, в ассортименте полный набор IaaS и PaaS решений и дружелюбная команда, которая помогает с их внедрением.

Облако H3LLO CLOUD подойдет тем, кто:

• запускает MVP и хочет минимизировать издержки на старте;
• работает с Big Data и аналитикой;
• использует Kubernetes или контейнеризацию;
• разворачивает inference-серверы под ИИ-модели;
• делает бэкапы и настраивает восстановление после сбоев.

H3LLO CLOUD работает с посекундной тарификацией: платите только за то, чем действительно пользуетесь. Можно выставлять счета на юрлицо, есть постоплата. Обещают добавить Cloud API, шаблоны деплоя, маркетплейс SaaS-решений и serverless — но даже сейчас по функциональности всё покрыто: базы управляемые, биллинг гибкий, интерфейс понятный.

Техподдержка отвечает быстро — от пары минут до пары часов. Для крупных клиентов — приоритетный канал связи.

2. L1veStack: полный контроль бюджетов

Если вы только запускаете проект и хотите чётко контролировать, за что платите — L1veStack делает ставку на полную прозрачность. Никаких округлений, скрытых тарифов и загадочного биллинга. Всё просто: используете ресурсы — платите посекундно, не используете — не платите вообще.

Что вы получаете на старте:

• На этапе беты L1veStack можно запустить до 3 проектов, каждый из которых может использовать до 1 vCPU и 4 ГБ RAM.
• У них есть уникальный вариант тарификации: существует нетарифицируемый пороговый уровень для небольших проектов, и оплата начинается только при превышении этих значений. Идеально для пет-проектов и стартапов, когда вы еще не знаете точных потребностей в мощности.

L1veStack построен как платформа, которая растёт вместе с вами:

• Этап 1: Пет-проекты и небольшие стартапы. Здесь вы используете нетарифицируемый порог.
• Этап 2: Команды и фрилансеры. Сервис выгодно использовать для управления Dev и Stage окружениями.
• Этап 3: Инструмент разработки для команд внутри enterprise. Предлагаются выгодные тарифы для dev/stage окружений и возможность переводить продакшен на собственные сервера под контроль ваших DevOps специалистов.

Из дополнительного и про биллинг:

В целом, всё удобно, гибко, прозрачно — есть все необходимые функции: GitHub wizard, автоматический SSL-сертификат (авто-SSL) и понятные объяснения для переменных.

Плата только за фактические минуты использования CPU и RAM. Есть поминутный счетчик и предиктивная симуляция затрат, чтобы прогнозировать расходы до того, как они возникнут.

Сервис предоставляет Live-индикаторы, который отслеживает нагрузку в реальном времени, human-friendly ошибки и мгновенный preview изменений.

3. Облачная платформа Selectel: Масштаб, безопасность и опытная поддержка

Selectel предлагает более 50 продуктов — от виртуальных и выделенных серверов до готовых к работе баз данных, кластеров Kubernetes, объектного хранилища, CDN и решений для безопасности. Всё запускается за пару кликов через удобную панель управления, API или Terraform.

Для стартапов действует акция: Кешбэк до 1 000 000 бонусов. Каждый месяц Selectel возвращает 30% бонусами от расходов на инфраструктуру. Кешбэк начисляется в течение 12 месяцев.

Selectel подходит под задачи любой сложности:

1. Разворачивать MVP и первые версии приложений — настраивать среды разработки и тестирования.
2. Запускать приложение в продакшен и масштабироваться под нагрузкой.
3. Хранить и обрабатывать данные — платформа позволяет хранить большие объемы данных на дисках объемом до 10 ТБ и более.
4. Защитить данные от сетевых атак — есть готовые инструменты защиты от DDoS-атак и инструменты резервного копирования ,
5. Соответствовать требованиям безопасности — платформа хранит персональные данные до 1 уровня защищенности и следует требованиям 152-ФЗ, 21 приказа ФСТЭК, PCI DSS, ISO 27001, ГОСТ Р 57580.

Насколько удобно работать

Инфраструктура строится как конструктор: 50+ продуктов и сервисов можно объединить через глобальный роутер, связать с собственной инфраструктурой (настраивать гибридные решения), масштабироваться в несколько кликов. Не нужно разбираться со сложными настройками — запустить сервис можно в несколько кликов из панели управления или с помощью Terraform. Есть IAM-система для разграничения доступов и определения ролей пользователей, чтобы настроить федерации удостоверений через SSO и соответствовать требованиям корпоративной безопасности.

Биллинг и поддержка

Биллинг облачной платформы работает по модели pay-as-you-go: платите только за то, что реально используется. При этом можно сэкономить до 75%, с прерываемыми ВМ и функцией заморозки — удобно, если нужно приостановить проект или снизить расходы ночью.

Техподдержка работает 24/7, специалисты помогают с подбором необходимой инфраструктуры и решений, настройками и функциональностью. Берут полную ответственность за работу инфраструктуры и быстро решают любые возникающие вопросы. Для сложных задач, например, миграции на инфраструктуру Selectel можно подключить услугу Администрирования.

4. RTCLOUD: Гибридное облако для стартапов с масштабом и безопасностью

RTCLOUD — это гибридное облако, объединяющее локальные ресурсы с публичным облаком провайдера для создания гибкой, масштабируемой и безопасной ИТ-инфраструктуры. Подходит стартапам, которым нужно быстро адаптироваться к нагрузкам без крупных затрат.

RTCLOUD предлагает гибридное облако, объединяющее частное и публичное облако:

• Единый каталог приложений: Доступ к приложениям в обоих облаках без разделения.
• Единое адресное пространство: Перемещение виртуальных машин и приложений без изменения сетевых настроек.
• Унифицированное управление: Просмотр, копирование и перемещение нагрузок (виртуальные машины, vApp, шаблоны) между облаками.
• Инструменты мировых лидеров: Veeam Backup & Replication для репликации и управления восстановлением, vCloud Availability для миграции и Disaster Recovery (DR).

Поддерживаются сценарии:

• Уменьшение нагрузки на локальные ресурсы.
• Запуск сервисов с непроверенной нагрузкой.
• Организация тестовой площадки.
• Резервирование инфраструктуры.

Дополнительные возможности

• Облачный ЦОД: Инфраструктура без капитальных затрат, высокая надёжность, масштабирование.
• Резервный ЦОД: Быстрое восстановление с минимальным RTO.
• Объектное хранилище S3: Хранение архивов, резервных копий и медиа-контента.
• Kubernetes-as-a-Service: Готовая контейнерная инфраструктура с контролируемым периметром безопасности.
• Облачный десктоп (VDI и VDI GPU): Доступ к рабочим местам, включая производительные для конструкторов.
• Backup as a Service (BaaS): Управление копиями и расписанием для надёжного хранения.
• Размещение оборудования: Дата-центры TIER III с интеграцией облачных сервисов.

Биллинг и поддержка

• Гибкая оплата: Pay-as-you-go, без инсталляционных платежей, платите только за потреблённые ресурсы.
• Экономия: Нет затрат на покупку или модернизацию оборудования, масштабирование по потребностям.
• Техподдержка: 24/7, помощь с настройкой инфраструктуры, миграцией и решением задач.

На что ориентироваться при выборе облака

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

H3LLO.CLOUD делает ставку на доступность, предлагая стартовый набор за 5 000 рублей с виртуальными машинами, базами данных и объектным хранилищем, что идеально для небольших команд, работающих с Big Data или ИИ.

L1veStack выделяется прозрачным биллингом и нетарифицируемым порогом, помогая стартапам с ограниченным бюджетом точно прогнозировать расходы.

Selectel обеспечивает масштабируемость и безопасность, с инструментами для защиты данных, что важно для проектов с высокими требованиями к соответствию 152-ФЗ.

RTCLOUD предлагает гибридное облако, которое объединяет локальные и публичные ресурсы, позволяя масштабироваться под пиковые нагрузки и минимизировать расходы благодаря модели pay-as-you-go без инсталляционных платежей.

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

В этой подборке мы собрали сервисы для облачной аренды — то есть платформы, которые позволяют:

1. запускать модели прямо в облаке, без локальной инфраструктуры;
2. платить исключительно за те вычислительные ресурсы, которые реально используете;
3. легко наращивать мощности по мере роста нагрузки.

1. Hostkey — сервера с GPU на все случаи жизни

Hostkey — один из проверенных хостинг-провайдеров на российском рынке, который сдаёт в аренду виртуальные и физические серверы с новыми видеокартами. У Hostkey гибкая почасовая оплата — значит, что вы используете мощность ровно столько, сколько нужно, без лишних трат.

Задачи, для которых GPU-решения от Hostkey подойдут

Современные GPU дают скорость для обучения нейросетей. Для изображений — сверточные сети (CNN). Для последовательностей — рекуррентные, как RNN, LSTM или GRU. Для больших моделей вроде GPT или BERT — архитектуры Transformer. Параллельная обработка позволяет запускать несколько моделей сразу, чтобы подбирать гиперпараметры. Интеграция с фреймворками TensorFlow, PyTorch, JAX и HuggingFace Transformers работает без проблем.

Генеративные модели для текстов — GPT, LLaMA или Falcon, чтобы генерировать контент, чат-боты, копирайтинг или переводы. Для изображений — Stable Diffusion, DALL·E или Midjourney, включая стилизацию. Аудио: TTS вроде Tacotron или VITS, плюс клонирование голоса. Видео: генерация анимации или upscaling с Topaz. Код: автогенерация через Codex, Code LLaMA или StarCoder.

Инференс: онлайн для быстрых ответов в чат-ботах, поиске или персонализации; батч для больших объёмов, как генерация изображений по текстам. Библиотеки ONNX, TensorRT и DeepSpeed оптимизируют скорость.

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

Параметры аренды: модели, цены и варианты

HOSTKEY предлагает выбор GPU-решений — от выделенных серверов с индивидуальными конфигурациями до виртуальных машин с гарантированным доступом к выделенной видеокарте, ресурсы которой не разделяются с другими пользователями. По задачам и бюджету: игровые модели вроде NVIDIA RTX 4090 или 5090; профессиональные вроде Tesla A100 и H100 — для крупных ИИ-проектов и расчётов.

Аренда помесячная с большой скидкой или почасовая. Серверы в России, Исландии, Франции, Нидерландах, Германии, Финляндии или США.

Цены от 7000 рублей в месяц или от 10 рублей в час — это базовые тарифы. Аренда оборудования оформляется через российскую компанию, даже для зарубежных дата-центров: оплата простая, без международных переводов.

Примеры использования GPU-серверов клиентами HOSTKEY

Один из примеров применения — наложение рекламных объектов на элементы видеопотока во время прямых трансляций спортивных событий. Благодаря мощности GPU, обработка происходит в реальном времени, без задержек и с высоким качеством. Этот кейс описан в блоге на сайте компании.

Другой кейс — виртуальная примерка в интернет-магазине: достаточно навести камеру на стопу, и система в реальном времени покажет, как будут выглядеть кроссовки. Здесь задействуются генеративные модели, способные мгновенно адаптировать изображение под конкретного пользователя.

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

Как быстро арендовать вычислительные ресурсы

Заказать сервер можно на сайте или в личном кабинете, предварительно зарегистрировавшись. С момента заказа до предоставления доступов к серверу проходит от 5 до 60 минут, в зависимости от выбранного ПО. Если нужна индивидуальная конфигурация с ручной сборкой, то 1–3 рабочих дня. Доступ через веб-панель управления, API для автоматического заказа, управления и расформирования сервера, или консоль.

Также HOSTKEY предлагает предустановленное программное обеспечение из Маркетплейса. Подборка приложений для GPU серверов находится в разделе AI-платформа.

Лимиты на данные и тесты

Исходящий трафик 50 Тб в месяц бесплатно на скорости 1 или 10 Гбит/с.

Для крупных корпоративных клиентов — тестовый период по запросу. Бесплатного пробного баланса нет, но короткая аренда заменяет тест.

HOSTKEY предлагает серверы с картами последнего поколения Nvidia RTX PRO 6000 Blackwell с объемом видеопамяти 96 ГБ. RTX PRO 6000 предоставляет в 3 раза больше памяти, чем RTX 5090, и в 4 раза больше, чем RTX 4090, что делает ее уникальным решением, способным работать с моделями ИИ и наборами данных корпоративного уровня.

Поддержка

Поддержка круглосуточная, ответ на обращение — не дольше 15 минут. Связаться можно через онлайн-чат на сайте, мессенджеры WhatsApp или Telegram, по e-mail.

Сейчас у HOSTKEY действуют дополнительные скидки до 25% на долгосрочную аренду серверов.

2. ITGLOBAL.COM GPU Cloud — облачные ускорители для AI, ML, HPC и сложной графики

ITGLOBAL.COM предлагает сервис GPU Cloud, который позволяет арендовать виртуальные серверы с графическими ускорителями. Услуга актуальна для тех компаний, которым требуется быстрый доступ к мощным GPU без необходимости инвестировать в покупку собственного дорогостоящего оборудования. Сервис построен на базе платформы виртуализации VMware, виртуальные машины оснащены графическими ускорителями NVIDIA.

Сценарии применения: где работают облачные ускорители

ITGLOBAL.COM перечисляет четыре ключевых сценария, где облачные GPU приносят максимальный эффект:

1. Машинное обучение и ИИ. Модели обучаются быстрее благодаря параллельным вычислениям.
2. Высокопроизводительные вычисления. Ускорители позволяют специалистам быстрее решать математические задачи и проводить научные расчёты.
3. Научное моделирование и CUDA‑вычисления. Графические процессоры ускоряют выполнение сложных вычислений и симуляций.
4. Дизайн и графика. Дизайнеры используют облако для визуализации, анимации и рендеринга больших объёмов данных.

Аппаратные возможности и базовые тарифы

Клиентам предлагают несколько поколений профессиональных видеокарт NVIDIA: A16, A800, A100, H100 и H200. Минимальная конфигурация виртуальной машины включает 1 vCPU, 1 ГБ RAM, 30 ГБ SSD и 4 ГБ памяти GPU на базе A16. Стоимость такой конфигурации начинается от 5 000 рублей с НДС, при этом минимальный срок аренды — один месяц.

Типичные кейсы: обучение моделей и создание контента

Мы нашли два наглядных примера, как используют сервис ITGLOBAL.COM:

1. Тренировка и запуск моделей. Data Scientist или ML‑инженер развёртывает в облаке GPU‑сервер для обучения нейросетей (к примеру, для распознавания изображений или обработки текста). Преимущество в том, что не нужно покупать дорогое оборудование; ресурсы удобно масштабировать под задачу и менять тип видеокарты.
2. Видеорендеринг и 3D‑графика. Видеостудия или дизайнер отправляет сложные сцены на рендер в облако. Это избавляет от необходимости содержать мощные рабочие станции и даёт доступ к современному железу с высокой производительностью, позволяя легко обновлять конфигурацию по мере роста проектов.

Быстрый старт и тестовый период

Сервис ориентирован на длительную аренду, но при этом позволяет быстро приступить к работе: стандартные конфигурации выдаются в течение одного дня. Для оценки возможностей предлагается бесплатный тестовый период на 30 дней, который заменяет собой традиционный «пробный баланс» и даёт время проверить, подходит ли производительность GPU‑клауда под ваши задачи.

Как получить поддержку и консультацию

Тем, кто ещё не является клиентом, ITGLOBAL.COM предлагает оставить заявку на сайте, написать на почту sales@itglobal.com или позвонить по указанному на сайте номеру. Действующие клиенты получают доступ к личному кабинету с системой тикетов, могут обращаться по e‑mail, телефону, в онлайн‑чат и даже через каналы экстренной поддержки 24/7 для решения срочных вопросов.

3. immers.cloud — виртуальные и выделенные GPU с посекундной тарификацией

immers.cloud — облачный провайдер, который сдаёт в аренду виртуальные и выделенные серверы с GPU на базе OpenStack. Главное отличие от других провайдеров — каждая виртуальная машина получает GPU целиком, без разделения ресурсов с другими пользователями и без оверселлинга.

Задачи, для которых подойдут GPU-решения immers.cloud

Ресурсы платформы используются для инференса и обучения нейросетей, файнтюнинга LLM, 3D-рендеринга, научного моделирования и обработки видео. Помимо самих серверов, доступны частные инстансы с Immers Foundation Models, программно-определяемое S3-хранилище и маркетплейс образов с популярным ПО — Windows, Ubuntu, Debian и другими дистрибутивами Linux.

Параметры аренды: модели, цены и варианты

Immers.cloud предлагает 13 моделей GPU — от дата-центровых H200, H100 NVL, H100 и A100 до игровых RTX 5090, RTX 4090, RTX 3090 и RTX 3080, а также промежуточные варианты RTX A5000, A10, RTX 2080 Ti, A2, T4 и V100.

Тарификация посекундная — платите ровно за то время, что сервер реально работал. Цены стартуют от 20 рублей в час, минимальная конфигурация — teslat4-1.4.8.60.

На платформе можно арендовать виртуальные серверы с GPU и CPU (NVMe/SSD/HDD), выделенные серверы с GPU и CPU, а также подключать несколько видеокарт сразу: до 8 GPU на один виртуальный сервер и до 10 — на выделенный.

Примеры использования GPU-серверов клиентами immers.cloud

Команда «КС Авто» развернула автономную AI-систему для круглосуточной модерации контента — спама, фото и текстов. Мультимодальные модели работают через Ollama на трёх облачных RTX 4090 с NVMe, потоки изолированы по видеокартам, без Kubernetes. Система фильтрует сотни спам-атак ежедневно и полностью заменяет штат из 15 модераторов.

Команда IBS построила на платформе единую R&D-песочницу для быстрых AI-экспериментов. Смешанная нагрузка — LLM, NLP, VLM — управляется через GPUStack и vLLM на пуле облачных видеокарт (A100, RTX 3090, RTX 4090) с гибридным сетевым доступом через VPN и прокси. Сейчас в работе 11 активных инстансов для 14 моделей, что позволяет тестировать новые гипотезы за часы, не разворачивая новые серверы.

Как быстро арендовать вычислительные ресурсы

Одно из главных преимуществ immers.cloud — быстрый онбординг: чтобы начать работу, достаточно зарегистрироваться и пополнить баланс от 100 рублей. Доступ к ресурсам — через API OpenStack (релиз Zed), причём используется немодифицированный native OpenStack, поэтому подходят любые стандартные клиенты и библиотеки для работы с API.

Лимиты на данные и тесты

Лимитов на загрузку и выгрузку данных нет. Для новых пользователей действуют квоты по умолчанию: 16 ядер vCPU, 128 ГБ RAM, до 10 томов, до 20 снимков, 1600 ГБ суммарного объёма хранения и 4 виртуальные машины. Квоты можно увеличить запросом в поддержку.

Бесплатный тестовый период до 30 дней или можно запросить индивидуальные тестовые сроки под задачу.

Поддержка

Техподдержка круглосуточная — через чат на сайте, Telegram (или Мах) и по электронной почте, плюс персональный менеджер.

4. Yandex Cloud — виртуальные машины с почасовой тарификацией

Публичная облачная платформа Яндекс.Облако предлагает виртуальные машины с графическими ускорителями NVIDIA Tesla V100 (32 ГБ HBM2), Ampere A100 (80 ГБ HBM2e) и Tesla T4 (16 ГБ GDDR6). GPU предоставляются целиком (без шаринга между клиентами) и доступны конфигурации до 8 GPU на ВМ, включая кластерный режим с объединением нескольких ВМ через высокоскоростную сеть (InfiniBand) для распределенного обучения моделей.

Сценарии использования

Сервис ориентирован на задачи машинного обучения, ИИ и высокопроизводительных вычислений. GPU-ускорители подходят для ускорения обучения нейросетей и инференса, анализа больших данных, а также для ресурсоёмкого 3D-рендеринга и работы с графикой. Пользователи могут разворачивать как одиночные экземпляры для отладки моделей, так и целые кластеры GPU для масштабных экспериментов. Яндекс.Облако интегрировано с экосистемой инструментов (например, платформой DataSphere для ML), упрощающих разработку и деплой решений ИИ.

Формат аренды

Ресурсы предоставляются по модели IaaS с поминутной тарификацией. После подключения GPU-квоты (по умолчанию изначально равна нулю) достаточно создать ВМ нужной конфигурации через веб-консоль, CLI или API. Минимальная конфигурация — 1 GPU (например, Tesla T4) с 4 vCPU и 16 ГБ RAM. Оплата почасовая (с поминутным биллингом), при длительных резервациях ресурсов действуют скидки. Например, доступна бесплатная квота (грант) на тестирование — для юридических лиц до 10 000 руб. на первые два месяца использования облака.

Поддержка и особенности

Инфраструктура Яндекс.Облака размещена в дата-центрах в РФ (соответствие 152‑ФЗ) и предлагает SLA на уровне 99,95%. Имеется круглосуточная техническая поддержка (чат, тикеты) с различными тарифами поддержки под потребности бизнеса. Все операции — от управления ВМ до мониторинга — доступны через удобный веб-интерфейс и API.

VK Cloud — облачные ВМ с GPU и выделенные серверы

VK Cloud (ранее Mail.Ru Cloud Solutions) сдаёт облачные GPU-ресурсы для B2B-заказчиков. В 2024 году платформа добавила графические процессоры NVIDIA L4 (24 ГБ, архитектура Ada Lovelace), которые на 2,5 раза производительнее предыдущего поколения и подходят для ускорения видео и графических приложений. Также доступны тензорные GPU NVIDIA Tesla V100 16ГБ/32ГБ и A100 40ГБ/80ГБ.

Кому подойдет и для каких задач

Сервис рассчитан на задачи ИИ/ML, обработку видео и графики, 3D-моделирование, рендеринг и другие сценарии, требующие высокопроизводительных вычислений. Например, GPU L4 ориентированы на медиаданные (трансляции, кодирование видео, графические рендеры) с поддержкой аппаратного ускорения AI, тогда как A100/V100 используются для обучения крупных моделей глубокого обучения и аналитики данных.

Условия аренды и конфигурации

Облако VK Cloud предлагает как виртуальные машины с GPU, так и выделенные физические серверы. Аренда возможна по модели pay-as-you-go (с помесячной оплатой фактического потребления ресурсов). Минимальная конфигурация — 1 GPU (например, Tesla V100 или L4) на виртуальной машине с выделенными vCPU и RAM; более мощные конфигурации могут включать несколько GPU на одну ВМ. Стоимость использования зависит от выбранной карты и конфигурации; публично тарифы не раскрываются, расчёт производится через персонального менеджера.

Поддержка B2B клиентов и интеграция с платформами

Каждому клиенту назначается персональный менеджер, который консультирует по выбору оптимальной конфигурации и обеспечивает сопровождение. Техподдержка VK Cloud работает 24/7. Возможна интеграция облачных GPU с другими сервисами VK Cloud — например, объектным хранилищем, управляемыми базами данных и инструментами для ML (AutoML, готовые окружения и пр.).

5. Cloud.ru (СберCloud) — широкая линейка GPU до H100

Cloud.ru — облачная платформа, над которой работает компания «Сбер», — предлагают NVIDIA H100 80ГБ (HBM2e/HBM3), а также A100 40/80ГБ, предыдущие Tesla V100 16/32ГБ и графические ускорители NVIDIA A40 48ГБ. Флагманские H100/A100 поддерживают объединение через NVLink и InfiniBand для горизонтального масштабирования — вплоть до связки 8 GPU в одной ноде или распределенного кластера из нескольких узлов (например, решение HGX 8×H100).

Для чего можно использовать

Платформа используется для обучения больших языковых моделей и генеративных сетей — самые требовательные из них эффективно работают на кластерах H100/A100 с высокоскоростным обменом данными. Также облако подходит для научных расчётов и моделирования (HPC) — исследователи могут запускать симуляции на GPU без очередей на доступ к суперкомпьютерам. Для рендеринга видео, обработки медицинских снимков, геологических вычислений и других специализированных сценариев предлагаются конфигурации на основе V100 или A40.

Формат аренды

СберCloud предоставляет несколько моделей аренды: виртуальные машины с GPU (на базе облачной платформы «Advanced»), выделенные физические серверы с GPU (помесячная аренда), а также специализированный ML Space — сервис кластеров GPU с почасовой/поминутной тарификацией.

Виртуальные машины доступны для запуска через консоль (необходим запрос на повышение квоты GPU, после чего ресурс выдаётся в течение минут) — оплата почасовая в рублях.

Выделенные же серверы или мощные конфигурации (например, 8× H100) предоставляются по заявке через менеджера, с минимальным сроком аренды от 1 месяца.

Поддержка и особенности

Cloud.ru ориентирован на корпоративных клиентов, поэтому процесс аренды крупных ресурсов сопровождается персональным менеджером и архитектурной поддержкой. Заявки на GPU рассматриваются оперативно, типовые конфигурации ВМ активируются в течение ~15 минут, нестандартные — до 1 рабочего дня.

Техподдержка работает 24/7, доступна по телефону и через портал, SLA 99,95%. Облачная платформа сертифицирована по требованиям 152‑ФЗ для работы с персональными данными. Также доступны смежные сервисы (облачное хранилище S3, системы контейнеризации, виртуальные рабочие места и пр.).

Как выбирать сервис: несколько ориентиров

Выбирая облачный GPU‑хостинг, стоит смотреть не только на цену за час. Важно понимать, какие задачи вы решаете и какие ресурсы требуются.

1. Тип задач и необходимая гибкость. Для экспериментов и краткосрочных проектов подойдут сервисы с почасовой тарификацией и быстрым стартом. Для длительных расчётов и стабильных нагрузок разумнее выбирать помесячные тарифы и более мощные карты.
2. Доступные модели GPU. Если нужен трансформер с миллиардами параметров, выбирайте провайдера, у которого есть Tesla H100/H200; для инференса хватит А‑серии или потребительских карт.
3. География и сеть. Расположение дата‑центров влияет на задержки и требования по хранению данных. Продумайте, нужно ли вам европейское присутствие или достаточно российских площадок.
4. Управление и поддержка. Наличие API, быстрая выдача ресурсов и понятная панель управления экономят время. Поддержка 24/7 и тестовый период помогут избежать сюрпризов.
5. Тестовый доступ и трафик. Бесплатный тестовый период или пробный запуск на несколько минут помогает оценить производительность и стабильность, а квоты на трафик — планировать бюджеты.

Аренда GPU — инструмент, который нужно подбирать под конкретную задачу. Не гонитесь за абстрактными мегахешами и гигафлопсами; лучше продумайте, какие модели будете запускать, как будете масштабироваться и насколько быстро вам нужно стартовать. Тогда облачные видеокарты станут не игрушкой для ML-ищков, а инструментом, который действительно помогает команде работать быстрее и эффективнее.

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

1. ИХЦ (Интернет ХостингЦентр): конфигурации под нагрузку с NVMe, CPU до 5 ГГц и трафиком без ограничений

Один из самых гибких по конфигурациям хостеров в обзоре. Работает с 2009 года. Поддерживает разные типы виртуализации (KVM и Virtuozzo), предлагает линейки с SSD и NVMe, российские и европейские площадки, разные уровни мощности — от базовых до высоконагруженных.

Линейки VPS и конфигурации

1. ssdVPS — базовая линейка для России. Позволяет собирать конфигурации от 1 до 32 ГБ оперативной памяти, от 1 до 10 виртуальных CPU и от 20 до 300 ГБ SSD-диска.
2. NVMe/ — линейка на базе KVM с более высокой производительностью ввода-вывода. Доступны конфигурации от 1 до 24 ГБ RAM, от 1 до 12 vCPU, SSD от 15 до 300 ГБ.
3. EU-NVMe/ — аналог NVMe-линейки, но размещённый в Амстердаме. Конфигурации расширены: от 1 до 64 ГБ оперативной памяти, от 1 до 18 CPU, от 15 до 1000 ГБ SSD, скорость порта — от 200 до 500 Мбит/с.
4. VPS 5 ГГц — отдельная линейка на KVM, ориентированная на проекты с высокой частотной нагрузкой, до 5 ГГц на ядро, порт до 1000 Мбит/с.

VPS Windows — выделенная категория для задач на Windows.

Особенности и инфраструктура

В ИХЦ можно выбрать между двумя видами виртуализации: KVM и Virtuozzo. Виртуализация KVM подходит для задач, где нужна изоляция ресурсов, стабильность под нагрузкой и совместимость с Linux и Windows. Virtuozzo — более экономный вариант с быстрой настройкой, но с возможной перераспределённой нагрузкой между соседними VPS.

Связь с поддержкой доступна через тикеты, онлайн-чат на сайте, телеграм-бота, телефон и сообщения ВКонтакте. Поддержка работает 24/7. На всех тарифах включена базовая DDoS-защита.

Примеры использования VPS от IHC

Компания предоставляет конкретные кейсы. Примеры:

• Проект 1: VPS NVMe/24 (24 ГБ RAM, ~200 ГБ SSD) используется под бэкенд iOS-приложения. Стек: nginx, PHP, MySQL. Нагрузка: 12 000 уникальных пользователей в сутки. Утилизация CPU — 25%.
• Проект 2: VPS NVMe/12 (12 ГБ RAM, ~120 ГБ SSD) для развлекательного сайта. Стек: nginx, Docker, Node.js. Нагрузка: 7 000 уникальных пользователей в сутки, загрузка CPU — около 20%.

Серверы стабильно держат среднюю и высокую нагрузку — даже с трафиком в 10–12 тысяч пользователей в сутки остаётся запас по ресурсам.

Дополнительные опции

ИХЦ предлагает тестовый период в 3 дня, безлимитный трафик, бесплатный первый месяц ispmanager 6 в подарок, а также предустановку панелей управления (ispmanager, FastPanel) или VPN-шаблонов по выбору при заказе. Также доступны бэкапы, SLA и автоснапшоты.

Цены

Что касается ценовой политики, стоимость VPS в России (линейка «ssdVPS») начинается от 380 руб/мес или 3800 руб/год (12 месяцев по цене 10). Европейские VPS («EU-NVMe/») и VPS на KVM («NVMe/») стартуют от 440 руб/мес или 4400 руб/год, а каждый дополнительный гигабайт памяти стоит 6 рублей.

2. FirstVDS: мощные VDS на AMD EPYC и Ryzen

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Есть VPS для разных сценариев нагрузки — от стандартных сайтов до тяжёлых веб-приложений и проектов с высокими требованиями к CPU и отказоустойчивости. Отдельные решения для Битрикс, установка ОС семейства Linux, FreeBSD и Windows Server.

Линейки VPS: от базовой мощности до кластера Ceph

FirstVDS предлагает три основные линейки, которые отличаются архитектурой и назначением:

1. VDS Форсаж — гибкая конфигурация сервера на базе AMD EPYC, до 128 ядер (до 3,7 ГГц), до 512 Гб оперативной памяти и до 4 000 Гб быстрого NVMe-накопителя. Локации Москва и Амстердам. Стартовая стоимость такой конфигурации составляет от 749 руб/мес.
2. Для нагруженных проектов — CPU.Турбо — гибкая конфигурация сервера на базе AMD Ryzen с частотой до 5,7 ГГц, DDR5 и с быстрыми NVMe-накопителями. Идеально для Битрикс. Локация Москва. Начальная цена CPU.Турбо — от 624 руб/мес. При покупке лицензии Битрикс (1С-Битрикс: Управление сайтом или Битрикс24) есть дополнительная скидка 30% на 3 месяца аренды этого тарифа.
3. Отказоустойчивый VDS Атлант — гибкая конфигурация сервера на базе AMD EPYC — до 192 ядер (до 3,5 ГГц), до 768 Гб оперативной памяти и до 8 Тб быстрого NVMe-накопителя. Репликация данных между узлами кластера Ceph и дублирование сетевого оборудования. Локация Москва. Его стартовая стоимость от 1619 руб/мес, при этом бесплатные автобэкапы уже включены.

Компания использует два центра обработки данных в Москве: IXcellerate (уровень Tier III) и Web DC. Для тарифа Форсаж и готовых тарифов также доступен ЦОД euNetworks (уровень Tier III) в Амстердаме.

Сетевые возможности, трафик и безопасность

В стоимость каждого сервера входит бесплатный выделенный IP-адрес. Клиенты могут выбрать между 100 Мбит/с с безлимитным трафиком или портом 1 Гбит/с с включёнными 32 Тб трафика.

Защита от DDoS-атак и система безопасности BitNinja для сервера и сайта доступны как подключаемые опции. Также предоставляются объектное хранилище S3, автобэкапы и Кибер-бэкап. Для безопасности коммуникаций используются SSL-сертификаты GlobalSign.

Управление, ПО и поддержка

При заказе сервера клиент получает лицензию ispmanager 6  lite: первый месяц панель предоставляется бесплатно, дальше оплачивается по тарифу самой панели. Предлагается гибкий выбор операционных систем, включая Linux, FreeBSD и Windows Server. Под разовые задачи доступны готовые рецепты установки — от Битрикс и GitLab до TeamSpeak, LAMP‑стека и других популярных наборов ПО.

Для установки и решения любых вопросов — доступна живая круглосуточная техническая поддержка 24/7 через чат на сайте, в личном кабинете и по телефону, без использования чат-ботов. Для самостоятельного решения вопросов предусмотрена обширная база знаний.

Клиентские бонусы и программы

Есть тестовый период до 3 дней. Регулярно проводятся акции и предоставляются скидки, в том числе на тарифы для нагруженных проектов.

1) При переходе от другого хостера FirstVDS бесплатно переносит до 10 сайтов. Дополнительно предоставляется скидка 40% на первый месяц аренды VPS при оплате сервера на 1, 3 или 6 месяцев, либо 3 месяца бесплатной аренды VPS при оплате на год.

2) Клиенты с возрастом аккаунта от 5 лет получают постоянную скидку на аренду VPS, начиная от 5% и увеличиваясь ежегодно до 20%.

3) Действует реферальная программа, по которой партнёр получает 10% от расходов привлечённых клиентов, а привлечённый пользователь — скидку 25% на первый месяц аренды VPS.

4) Стоимость продления домена у FirstVDS равна актуальной стоимости его регистрации.

3. InCloud: VPS‑площадки для бизнеса, где важен SLA

InCloud продаёт виртуальные серверы, работающие в отказоустойчивом кластере на базе enterprise хранилищ NetApp и HPE 3PAR. Позиционируется как решение для 1С, малого/среднего бизнеса и аутсорс компаний, которым нужны предсказуемые ресурсы и техподдержка профессиональных инженеров, а не чат‑ботов.

Тарифные планы и ценообразование

InCloud предлагает две основные линейки тарифов:

1. Стандартный тариф: внутри процессоры Intel Xeon 2600v4 2ГГц и оперативная память DDR4 2400 МГц.Стоимость: 1 CPU – 200 рублей, 1 Гб RAM – 200 рублей.
2. Производительный тариф: использует процессоры AMD EPYC до 3.8 ГГц и оперативной памяти DDR5 4800 МГц. Стоимость: 1 CPU – 250 рублей, 1 Гб RAM – 250 рублей.

Стоимость дискового пространства: SATA диски: 3 рубля за 1 Гб. SSD и NVMe диски: 13 рублей за 1 Гб.

Архитектура и поддержка

Теперь про то, что упрощает жизнь и добавляет надежности нашим развернутым сервисам:

• Ежедневные бэкапы: данные ваших серверов будут копироваться каждый день, и храниться они могут до 30 дней.
• Удобная панель управления: через нее можно делать снапшоты и клонировать серверы. Для разработчиков это просто золото – быстро накатить тестовую среду, попробовать новую фичу, а потом откатиться или создать идентичные рабочие среды.
• SLA-договор: есть возможность заключить SLA-договор, чтобы получить гарантированный уровень доступности услуг.
• Новейшие мощные серверы — на базе AMD EPYC 4 поколения.

Одна из фишек – это возможность напрямую проконсультироваться с сертифицированными инженерами InCloud по сложным проектам.

А что с клиентскими кейсами

1. Кейс Vamkamin: производственная компания, которая ускорила работу своей системы 1С и сократила IT-расходы на 35%. У них была проблема с медленной работой 1С при одновременном доступе бухгалтерии, склада и отдела продаж, а также с частыми простоями на локальных серверах. InCloud предложил перенести все сервисы в облако, используя серверы на базе AMD EPYC 9554, что обеспечило прирост производительности более 40% по сравнению с предыдущими решениями. Также были внедрены гибкое масштабирование ресурсов и ежедневное резервное копирование.
2. Кейс Веб-студии 100UP: компания занимается разработкой и поддержкой сайтов для крупных торговых сетей и e-commerce проектов. 100UP переехала к облачному провайдеру InCloud, выбрав тарифы на базе AMD EPYC 9554 с высокой тактовой частотой и большим количеством ядер. Благодаря разнообразию тарифов команда легко распределила проекты по нужным по производительности виртуальным серверам. После переезда 100UP смогла сократить время отклика клиентских сайтов в среднем на 45%, обеспечить бесперебойную работу даже в периоды высокой сезонной нагрузки, ускорить запуск новых проектов, фокусироваться на разработке и маркетинге и улучшить качество предоставляемых услуг.

4. SmartApe: быстрые VPS на NVMe‑SSD

SmartApe подойдет проектам, где дисковая подсистема и CPU работают без простоя: интернет‑магазины, порталы с большим количеством контента, внутренние корпоративные системы, высоконагруженные API. Если нужен быстрый старт — сервер создаётся за одну‑две минуты; если понадобится масштабирование, тариф можно увеличить без миграции.

Преимущества этих VPS

Используются современные серверные NVMe SSD диски в RAID массиве, которые в 600 раз быстрее обычных HDD. Скорость чтения достигает 8000 Мбайт/с, а записи — 2000 Мбайт/с.

Серверы работают на мощных процессорах Intel Xeon Gold или AMD EPYC (до 3.7 ГГц) и быстрой памятью DDR4. Используется полноценная виртуализация KVM с выделенными ресурсами для гарантии их предоставление. Дата-центры уровня TIER-III и TIER-IV обеспечивают Uptime 99.982%. Данные хранятся в хранилище RAID-10.

Дополнительно клиенты получают полный root-доступ (по SSH для Linux и RDP для Windows), возможность установки любых операционных систем (более 20, включая Ubuntu, CentOS, Debian, Windows Server) и ПО, а также полную изоляцию от других клиентов.

Удобство и поддержка

• Бесплатная панель управления (Hestia) или платная ISPmanager для простого управления сервером.
• Бесплатное базовое администрирование и помощь в переносе сайтов.
• Круглосуточная квалифицированная поддержка 24/7.
• Бесплатный тестовый период 10 дней без оплаты и ввода карты.
• Защита от DDoS-атак включена в стоимость.
• Выделенный внешний IP-адрес (возможность купить до 10 IP).

Перед покупкой дают десять дней теста без привязки карты; если сервис не подойдёт, в течение тридцати дней можно вернуть деньги за неиспользованный период.

Пример использования: интернет‑магазин

VPS c 2 vCPU, 4 ГБ RAM, 80 ГБ SSD и портом 100 Мбит/с; при обычном трафике сайт обслуживает 300–500 уникальных посетителей в день, одновременно на страницах бывает 10–20 человек, а в пиковую распродажу до 50; средняя нагрузка 5–10 запросов в секунду, короткими всплесками до 20; заявленный аптайм 99,982 %, реальные замеры отклика после кэширования — 200–300 мс; счёт за такой сервер выходит около 1 300 рублей в месяц.

Пример использования: API на Node.js

4 vCPU, 8 ГБ RAM, 160 ГБ NVMe и канал 200 Мбит/с; сервис стабильно обрабатывает 50–100 запросов в секунду, на пике достигает 200, одновременно подключены 500–1 000 клиентов, максимум 2 500; трафик близок к 200 ГБ в месяц; при том же аптайме 99,982 % средняя задержка ответа укладывается в 50–100 мс; ежемесячная стоимость в зависимости от опций колеблется в диапазоне 2 600–3 000 рублей.

SmartApe имеет смысл брать, когда дисковая скорость и гарантированные ресурсы важнее высокого GUI и почасовой тарификации, для расчёта стоимости есть калькулятор конфигураций на сайте и оперативная техподдержка.

5. PSB Hosting: что даёт их VPS‑платформа

PSB Hosting продвигает VPS-хостинг как решение для сайтов, приложений и SaaS-сервисов, которым нужна предсказуемая мощность и высокий SLA. Провайдер делает упор на новое оборудование, пропускную способность без ограничений и инфраструктуру уровня Tier III+.

Локации и тарификация

Серверы разворачиваются в четырёх точках: Нидерланды, США, Германия и Финляндия. Для каждой площадки доступен одинаковый конструктор конфигураций. Базовый план NL‑100, который включает 1 vCPU, 2 ГБ RAM и 30 ГБ SSD, стоит 6 долларов в месяц. Линейка поднимается ступенчато:

Слайдеры позволяют довести параметры до 32 ядер, 64 ГБ RAM и 510 ГБ SSD; верхняя планка оплаты — 220 $ в месяц.

Трафик безлимитный на любых конфигурациях — дополнительной оплаты за гигабайты нет.

Аппаратная платформа, ОС и предустановки

В хост-узлах применяются процессоры последних линеек AMD и Intel. Оперативная память — DDR5, что снижает задержки при обращении к ОЗУ. Дисковая подсистема полностью на NVMe, объединена в RAID 10: чтение и запись выше, чем у классических SSD, а отказ одного накопителя не выводит хранилище из строя. К каждому VPS подключён выделенный канал с пропускной способностью до 10 Гбит/с.

Сервер можно поднять сразу с Windows Server, Ubuntu, Debian, CentOS или FreeBSD. Для быстрого старта доступны готовые образы: Bitrix, Django-стек, Docker, FastPanel, Hestia CP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, Vesta CP и другие.

Управление и поддержка

Провайдер обещает круглосуточную техническую поддержку, резервные копии (бэкапы) и автоснапшоты. Для автоматизации предусмотрен API; в панели управления можно масштабировать ресурсы, перезагружать сервер и следить за статистикой.

Как выбрать VPS под свой проект

Для сайта с пиковыми нагрузками подойдёт SmartApe, где дисковая подсистема на NVMe-SSD в RAID-10 обеспечивает скорость чтения до 8000 Мбайт/с и записи до 2000 Мбайт/с, а сайт на конфигурации с 2 vCPU, 4 ГБ RAM и 80 ГБ SSD выдерживает 300–500 уникальных посетителей в день с пиком до 50 одновременных пользователей и нагрузкой 5–10 запросов в секунду (короткими всплесками до 20).

Если проект включает высоконагруженный API, например, на Node.js, то оптимален SmartApe с конфигурацией 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe, которая стабильно обрабатывает 50–100 запросов в секунду (пики до 200) при 500–1000 одновременных подключениях (максимум 2500) и трафике до 200 ГБ в месяц.

Для задач с 1С, где важна стабильность и сокращение IT-расходов, выбирайте InCloud на базе AMD EPYC 9554: в кейсе Vamkamin это ускорило работу системы на 40%, сократило расходы на 35% и минимизировало простои, с ежедневными бэкапами до 30 дней и SLA-договором.

Если нужен VPS для Битрикс с высокой частотой CPU, подойдёт FirstVDS на AMD Ryzen (CPU.Турбо) с частотой до 5,7 ГГц и DDR5: скидка 30% на 3 месяца при покупке лицензии Битрикс, плюс отказоустойчивость на кластере Ceph с репликацией данных.

Для веб-студий с разработкой и поддержкой сайтов для e-commerce, где требуется распределение проектов по производительности и бесперебойная работа в сезонные пики, подойдёт InCloud на AMD EPYC 9554: в кейсе 100UP это сократило время отклика на 45% и обеспечило стабильность под высокой нагрузкой.

Если проект ориентирован на международный трафик с предсказуемыми ресурсами и высоким SLA, выбирайте PSB Hosting с локациями в Нидерландах, США, Германии или Финляндии, безлимитным трафиком и каналом до 10 Гбит/с на DDR5 и NVMe в RAID 10.

Для бэкенда мобильного приложения с нагрузкой до 12 000 уникальных пользователей в сутки (утилизация CPU 25%) подойдёт ИХЦ на NVMe/24 с 24 ГБ RAM и ~200 ГБ SSD, стеком nginx, PHP, MySQL.

Если развлекательный сайт с более чем 5000 уникальных пользователей в сутки (загрузка CPU ~20%), то подходит ИХЦ на NVMe/12 с 12 ГБ RAM и ~120 ГБ SSD, стеком nginx, Docker, Node.js. Он обеспечит стабильность с безлимитным трафиком и DDoS-защитой.

Выбор сводится к трём вопросам: где ваши
пользователи, какую пиковую нагрузку вы ждёте и нужен ли формальный SLA.
Сформулируйте эти требования заранее — и любой из пяти хостингов закроет задачу
без проблем в продакшне. Добавить свои рекомендации VPS хостингов — вы всегда
можете в комментариях, желательно описывать короткие кейсы.

Теперь они предлагают решения, которые не хуже, а где-то даже и лучше международных аналогов и по надёжности, и по цене.

Посмотрим, кто из них есть в этом списке, и определим особенности хостингов для сайта.

1. FirstVDS: профессиональные решения для любых проектов

FirstVDS — хостинг-провайдер с опытом на рынке более 20 лет. Предлагают VPS и VDS с виртуализацией KVM для проектов любого размера. Все серверы работают на современном оборудовании. Трижды победитель в номинации «Хостер года» Национальной премии «ЦОДы.РФ».

Хостинг подойдет бизнесу любого масштаба: для любых сайтов — от визиток до высоконагруженных интернет-магазинов, для разработки и тестирования, для сервисов и других проектов. Отдельные решения для Битрикс, установка ОС семейства Linux и Windows Server.

Особенности хостинга

Надёжность

FirstVDS обеспечивает аптайм 99,97–99,99% в 2025 году, подтверждённый замерами (например, отклик из Москвы — 27 мс в апреле 2025). Серверы размещены в трёх дата-центрах уровня Tier III: два в Москве (IXcellerate и Web DC) и один в Амстердаме (euNetworks). Отказоустойчивый кластер Ceph гарантирует работу даже при сбоях точки или канала.

Инфраструктура

Серверы работают на процессорах Intel Xeon и AMD EPYC (до 5,7 ГГц в линейке CPU.Турбо), с быстрыми NVMe-дисками объёмом до 8 ТБ и оперативной памятью DDR5 (до 768 ГБ в VDS Атлант). Это обеспечивает высокую производительность для ресурсоёмких задач, таких как Битрикс или высоконагруженные приложения.

Гибкость

Тарифы масштабируются: от базовых конфигураций (1 CPU, 1 ГБ RAM, 40 ГБ SSD) до мощных серверов (192 ядра, 768 ГБ RAM, 8 ТБ NVMe). Линейки:

• VDS Форсаж: AMD EPYC, до 128 ядер, 512 ГБ RAM, 4 ТБ NVMe, от 749 ₽/мес (Москва/Амстердам).
• CPU.Турбо: AMD Ryzen до 5,7 ГГц, DDR5, от 624 ₽/мес (Москва).
• VDS Атлант: отказоустойчивый, до 192 ядер, 8 ТБ NVMe, от 1619 ₽/мес (Москва).
• VDS Storage: хранилище, от 704 ₽/мес (Москва).Горячее масштабирование (hot-resize) позволяет добавлять CPU, RAM или диск без перезагрузки.

Автоматизация

Шаблоны для быстрого развёртывания: Django, Redmine, Tomcat, Teamspeak, Nextcloud, LAMP, LEMP, Forgejo Git, GitLab, Битрикс. Поддерживаются ОС Linux (Ubuntu, Alma, Debian, Rocky, CentOS, Oracle), FreeBSD, Windows Server. API и панель ispmanager 6 lite (бесплатно на месяц) упрощают управление.

Безопасность

Включена защита от DDoS-атак на сетевом уровне, BitNinja для защиты сервера и сайта, SSL-сертификаты GlobalSign. Доступны автобэкапы, снапшоты, Кибер-бэкап и объектное хранилище S3 для больших данных.

Поддержка

Круглосуточная поддержка 24/7 без чат-ботов, ответ до 15 минут через чат, личный кабинет или телефон. Бесплатно: помощь с активацией и первичной настройкой. Платно: установка ПО, администрирование. Экспертная линия для мониторинга и устранения сбоев.

Бонусы

• Тестовый период 3 дня.
• Бесплатный перенос до 10 сайтов с другого хостера.
• Скидки: 40% на первый месяц при оплате на 1/3/6 месяцев или 3 месяца бесплатно при оплате за год.
• Лояльность: скидка 5–20% для клиентов от 5 лет.
• Реферальная программа: 10% от расходов привлечённых клиентов для партнёра, 25% скидка для нового пользователя на первый месяц.
• Домены: продление по цене регистрации.

Тарифы и условия

Тестовый период 3 дня, после него подключаете один из основных тарифов:

• Линейка готовых конфигураций от 1 CPU, 1 Гб RAM, 40 Гб SSD-накопителя и от 219 руб/мес. до сервера с 8 CPU, 12 Гб RAM, 150 Гб NVMe-накопителя. Локация в РФ и Нидерландах.
• VDS Форсаж: на AMD Epyc от 749 ₽/мес. Локации: РФ и Нидерланды.
• CPU.Турбо: гибкая конфигурация на базе высокочастотных AMD Ryzen 9 от 624 ₽/мес. При покупке лицензии Битрикс дополнительная скидка 30% на 3 месяца аренды CPU.Турбо. Локация в РФ.
• VDS Атлант: отказоустойчивый с автобэкапами от 1 619 ₽/мес. Локация: РФ.
• VDS Storage: сервис как хранилище с гибкой конфигурацией от 704 ₽/мес. Локация: РФ

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

2. UltraVDS: для малого бизнеса и стартапов

Компания UltraVDS, провайдер услуг виртуальных серверов (VPS/VDS), работает на рынке с 2014 года — предлагает решения для разных операционных потребностей. Сервисы UltraVDS можно использовать для развертывания торговых роботов, запуска чат-ботов, хостинга веб-сайтов, а также для создания FTP-хранилищ данных. Есть предложения для фрилансеров, цифровых агентств, корпоративных пользователей и стартапов, которым требуются функциональные инфраструктурные решения.

Технические особенности

Серверы UltraVDS размещены в современном дата-центре, расположенном в Москве. Доступность сервиса (аптайм) составляет 99,98%, что обеспечивает высокую стабильность работы. Сетевая пропускная способность превышает 200 Мбит/с, при этом трафик предоставляется без ограничений.

Система защиты от DDoS-атак способна обрабатывать трафик до 1,5 Тбит/с и поддерживает стабильность работы сервера даже при интенсивном внешнем воздействии. Лицензия на Windows Server входит в стоимость обслуживания в данном предложении. Это упрощает развертывание сервера: вам не нужно отдельно покупать и устанавливать лицензию. Плюс снижает общие операционные расходы для пользователей этой операционной системы.

Тарифные планы

Для новых пользователей UltraVDS предусмотрена возможность 3-дневного тестового периода, позволяющего оценить функциональность и производительность сервиса.

После тестового периода стоимость тарифов начинается от 119 рублей в месяц. На сайте доступен онлайн-калькулятор, позволяющий подобрать конфигурацию сервера и рассчитать итоговую стоимость.

Клиентам доступны различные варианты оплаты, включая ежемесячную систему без предоплаты. При авансовой оплате на период от 3 до 12 месяцев предоставляются скидки до 20%, размер которых зависит от выбранного срока. В случае досрочного прекращения использования сервиса, неиспользованный остаток средств возвращается на баланс пользователя.

Поддержка и обслуживание

Техническая поддержка UltraVDS работает круглосуточно, 7 дней в неделю. Среднее время ответа на запросы составляет до 15 минут. Связь со службой поддержки возможна по электронной почте и телефону, указанным на официальном сайте.

3. RUVDS: 10 лет на рынке облачных решений

RUVDS — облачный провайдер, имеющий десятилетний опыт работы на рынке услуг виртуальных серверов (VPS/VDS). Является официальным партнером Huawei в России, работает по SLA. Компания предоставляет инфраструктурные решения, которые могут быть применены для широкого спектра задач, включая хостинг высоконагруженных интернет-магазинов, корпоративных порталов, игровых серверов, сложных backend-систем и чат-ботов.

Платформа RUVDS спроектирована для оптимизации процесса развертывания ресурсов. Одной из ее особенностей является маркетплейс, который позволяет быстро запускать серверы с предустановленным программным обеспечением. Это способствует ускорению старта проектов, снижая потребность в ручной настройке распространенных CMS, игровых серверов и сред разработки.

Тарифная политика и варианты оплаты

RUVDS предлагает различные тарифные планы. Например, стоимость конфигурации Linux-сервера (1 CPU, 512 МБ RAM, 10 ГБ HDD, 1 IPv4) начинается от 139 ₽/месяц. Это может быть рассмотрено как экономичное решение для запуска небольших проектов и проведения тестирования.

Клиентам доступны разные опции оплаты:

1. Ежемесячные платежи или предоплата на срок от 3 до 12 месяцев, при которой предоставляются скидки до 20%, зависящие от продолжительности периода.
2. Для проектов с динамической нагрузкой предусмотрена посекундная тарификация, оплата по которой взимается только за фактически использованные ресурсы. Неиспользованный остаток средств в рамках этой модели возвращается на баланс пользователя

Дополнительно, до конца 2025 года панель управления ISP Manager для сервера и сайта предоставляется без дополнительной платы при создании любого VPS.

Глобальная инфраструктура и стабильность

Инфраструктура включает 17 дата-центров уровня Tier III, расположенных по всему миру. Это один из самых больших показателей по количеству геолокаций среди российских провайдеров. Для работы используются корпоративное оборудование и накопители (HDD, SSD, NVMe), чтобы обеспечить стабильную работу и производительность размещенных проектов.

Поддержка клиентов и доступные ресурсы

Техническая поддержка RUVDS доступна круглосуточно, 7 дней в неделю. Среднее время ответа на запросы через тикет-систему или онлайн-чат составляет 15 минут. Клиентам предоставляются полные административные права и консультации по вопросам запуска и настройки серверов. Для самостоятельного изучения доступна база знаний, включающая инструкции и руководства.

Безопасность и масштабирования

В контексте безопасности данных, RUVDS предлагает несколько решений:

- Встроенная защита от DDoS-атак, способствующая поддержанию бесперебойной работы серверов при внешнем воздействии.

- Стандартный IPv4-адрес включен в стоимость каждой виртуальной машины, с опцией аренды дополнительных IP-адресов.

- API, соответствующий OpenAPI 3.0.0, предоставляет возможности для интеграции и автоматического масштабирования серверных ресурсов в зависимости от нагрузки.

- Компания официально подтверждает соответствие требованиям ФСТЭК и ФЗ-152 по защите персональных данных, что обеспечивает соблюдение соответствующих законодательных норм.

4. McHost: решения для бизнеса разного масштаба

McHost предоставляет комплексные хостинговые решения, включая виртуальный хостинг и VPS/VDS с NVMe-накопителями. Сервис поддерживает популярные CMS (WordPress, Joomla, 1С-Битрикс) с оптимизированными настройками и автоматической установкой через панель управления.

McHost ориентирован на широкий круг клиентов:

• владельцы сайтов-визиток, блогов и лендингов — благодаря низким тарифам и полному набору опций;
• интернет-магазины с небольшой нагрузкой — тарифы с SSD-накопителями и автоматическим резервным копированием обеспечивают стабильную работу;
• разработчики, которым нужны
  VPS/VDS с root-доступом — работают серверы на KVM-виртуализации с ОС Linux и Windows;
• госучреждения и компании,
  работающие с персональными данными — соответствие 152-ФЗ и размещение в дата-центрах Tier III в Москве.

Особенности сервиса

McHost поддерживает стабильную работу с аптаймом 99.9% за счет размещения оборудования в дата-центрах уровня Tier III — в Москве и Нидерландах.

Сервис предоставляет защиту от DDoS-атак, автоматическое резервное копирование раз в два дня с хранением данных в течение 30 дней для виртуального хостинга и 14 дней для VPS, а также поддержку российских криптографических стандартов. Клиентам доступны различные варианты размещения: от виртуального хостинга с SSD (от 157.5 ₽/мес) до выделенных серверов с NVMe-накопителями.

Технические параметры и условия

Инфраструктура McHost базируется на серверах Dell с NVMe-накопителями и процессорами Intel Xeon (частота ядер от 2.35 ГГц). Для виртуального хостинга используется CloudLinux с технологией CageFS, обеспечивающей изоляцию аккаунтов. Поддержка российских ОС («Альт») подтверждена для VPS-тарифов.

В техподдержку можно обратиться по телефону, через тикет или в Telegram-боте. Время ответа — до 10 минут.

Текущие тарифы:

• Виртуальный хостинг: от 157 ₽/мес
  (3 ГБ SSD, 1 сайт).
• VPS: от 396 ₽/мес (15 ГБ SSD, 1
  ядро CPU).
• Выделенные серверы: от 3 000 ₽/мес
  (32 ГБ RAM, 2×1 ТБ HDD).

5. UFO Hosting: VPS/VDS и выделенные серверы с портом до 10 Гбит/с и безлимитным трафиком

UFO Hosting предлагает VPS/VDS и выделенные серверы на партнёрской инфраструктуре IXcellerate (Tier III). В портфолио — недорогие виртуальные машины и серверы с портом 10 Gbps для проектов, которым нужна стабильность без завышенных цен.

Сервис подходит для пользователей разных масштабов: от фрилансеров и веб‑студий до средних и крупных компаний. Для DevOps‑специалистов доступны API и инструменты автоматизации.

Основные сценарии использования

• корпоративные сайты, CRM‑системы и веб‑приложения;
• аналитические сервисы и SaaS‑продукты;
• инфраструктура для разработки и тестирования;
• задачи фрилансеров, агентств и digital‑команд.

Формат работы, особенности и интеграции

Серверы установлены в российском дата‑центре Tier III (IXcellerate), что означает резервирование по питанию и каналам связи. Заявленный аптайм — 99,98 %. Поддержка работает круглосуточно в тикетах, чате и по телефону; среднее время ответа 5–10 минут.

Сервис UFO Hosting делает акцент на безопасности и гибкости. Есть сеть с защитой от DDoS, возможность горячего расширения ресурсов, автоматическое развёртывание из шаблонов и API для интеграции. Поддерживаются популярные фреймворки и CMS, есть интеграции с GitLab, Telegram и DockerHub. Бэкапы, снапшоты и резервирование входят в стандартный набор, так что восстанавливать тестовую среду не придётся вручную.

В панели управления можно автоматически установить популярные CMS, панели управления, хранилища и DevOps‑инструменты. Это экономит время на настройку и подходит тем, кто не хочет поднимать всё с нуля.

Условия использования и тарифы

Базовые конфигурации начинаются от 577 руб./месяц. Заявленная скорость порта — до 10 Gbps, что подходит для проектов, где много трафика.

Есть возможность бесплатно попробовать сервис присутствует, но предоставляется по запросу в поддержку, а при оплате на срок от трёх месяцев действуют скидки, а также регулярно проводятся акции: это поможет оптимизировать бюджет.

В целом, UFO Hosting выглядит как практичное решение для тех, кому нужны производительные VPS/VDS и выделенные серверы в России. При выборе стоит оценить, насколько конфигурации подходят под конкретные нагрузки и есть ли необходимость в интеграциях из коробки.

6. Timeweb: хостинг для веб-проектов

Timeweb предоставляет услуги хостинга для различных типов веб-проектов. Сервис поддерживает популярные CMS, включая WordPress, 1C-Битрикс и Joomla, что делает его подходящим как для личных блогов, так и для корпоративных сайтов.

Платформа использует собственную панель управления с инструментами для работы с сайтами, базами данных и резервными копиями. Ежедневное автоматическое резервное копирование с хранением данных до 30 дней включено во все тарифные планы. Базовая защита от DDoS-атак доступна для всех клиентов без дополнительной платы.

Инфраструктура Timeweb размещена в дата-центрах уровня Tier III в России (Санкт-Петербург) и Казахстане (Алматы). Гарантированный показатель uptime составляет 99.98%. Поддерживаются современные технологии: PHP версий от 5.3 до 8.4, MySQL от 5.6 до 8.0, а также Perl, Python, SSH, FTP и Cron.

Тарифные планы:

• Year+: от 164 ₽/мес (2 сайта, 15
  ГБ NVMe, 2 БД);
• Optimo+: от 248 ₽/мес (15 сайтов,
  40 ГБ NVMe, безлимитные БД);
• Century+: от 347 ₽/мес (35 сайтов,
  50 ГБ NVMe, безлимитные БД);
• Millennium+: от 482 ₽/мес (60
  сайтов, 60 ГБ NVMe, безлимитные БД).

Все тарифы включают бесплатный SSL-сертификат, 10 ГБ почтовой квоты с неограниченным количеством ящиков и DNS-хостинг. При оплате годового тарифа предоставляется домен в зонах .RU/.РФ в подарок.

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

7. Reg.ru: комплексные решения для сайтов и доменов

Reg.ru сочетает услуги хостинга и регистрации доменов, что упрощает управление веб-проектами. Компания работает с 2005 года, имеет статус аккредитованного регистратора доменных имён в зонах .RU и .РФ.

Функциональные возможности

Платформа предоставляет доступ к трём панелям управления: ISPmanager, cPanel и Plesk. Это позволяет выбрать наиболее удобный интерфейс для работы с сайтами. Все тарифы включают бесплатный SSL-сертификат от Let’s Encrypt, который автоматически устанавливается при создании сайта.

Начинающим пользователям доступен конструктор сайтов с готовыми шаблонами. Поддерживаются популярные CMS, включая WordPress, Joomla и 1С-Битрикс. Ежедневное резервное копирование данных с хранением копий в течение 30 дней входит в стандартный набор услуг.

Техническая инфраструктура

Серверы размещены в дата-центрах уровня Tier III в Москве. Средний показатель uptime составляет 99.9%, что подтверждается ежемесячной статистикой. Подключение к сети осуществляется по выделенным каналам со скоростью до 1 Гбит/с на выделенных серверах.

Поддержка и тарифы

Техническая поддержка доступна 24/7 через онлайн-чат и тикет-систему. Среднее время ответа составляет 15-20 минут. Для срочных вопросов можно обратиться по телефону.

Тарифы — от 151 ₽/мес (7 ГБ SSD, 15 сайтов). При регистрации домена в зонах .RU или .РФ предоставляется скидка на другие доменные имена.

8. Спринтхост: хостинг с персональным подходом

Sprinthost предлагает услуги хостинга с акцентом на индивидуальную поддержку клиентов. Сервис работает с 2011 года и специализируется на VPS-решениях для различных веб-проектов.

Особенности сервиса

Компания предоставляет персонального менеджера для каждого клиента, который помогает с настройкой сервера и решением технических вопросов. А если вы остались недовольны услугами, то в течение 30 дней сервис вернёт деньги. Sprinthost проводит бесплатные обучающие вебинары по DevOps и администрированию серверов.

Технические характеристики и тарифы

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга с аптаймом 99.9%. Поддерживаются современные технологии разработки, включая Ruby on Rails, Node.js, Python и Docker. Все серверы используют SSD-накопители с гарантированной скоростью чтения/записи.

Тарифные планы:

• Start: 290 ₽/мес (1 ядро, 1 ГБ
  RAM, 15 ГБ SSD);
• Turbo: 1 900 ₽/мес (4 ядра, 8 ГБ
  RAM, 100 ГБ NVMe).

Поддержка

Техническая помощь доступна 24/7 через тикет-систему и онлайн-чат. Среднее время ответа составляет 10-15 минут. Для корпоративных клиентов предусмотрена приоритетная поддержка по телефону.

Как выбрать хостинг в 2025 году

Выбор хостинга зависит от типа проекта и его требований. Для небольших сайтов и блогов подойдет виртуальный хостинг с поддержкой популярных CMS — важно проверить наличие автоматических бэкапов и базовой защиты от DDoS. Если проект связан с обработкой персональных данных, убедитесь, что провайдер соответствует 152-ФЗ и использует сертифицированное оборудование.

Для высоконагруженных сервисов и интернет-магазинов лучше рассматривать VPS или выделенные серверы. Обратите внимание на тип накопителей (SSD/NVMe), возможность масштабирования ресурсов и аптайм дата-центров (рекомендуется от 99.9%).

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

Главное правило — выбирайте решение, которое покрывает текущие потребности проекта. Важно, чтобы конфигурацию можно было оперативно менять по мере роста запросов и масштабирования бизнеса. Технологии меняются быстро, и гибкость конфигурации часто важнее сиюминутной экономии.

FAQ

Что такое виртуальный хостинг и когда его выбирать?

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

Преимущества: низкая стоимость, простота управления через панели, автоматические обновления и базовая защита. Минусы: ограниченные ресурсы; производительность зависит от соседних сайтов; минимальный контроль над настройками.

Что такое VPS/VDS и для каких проектов он подходит?

VPS (Virtual Private Server) или VDS — это виртуальный сервер с выделенными ресурсами (процессор, память, диск), предоставляющий доступ для полной настройки. Идеален для проектов среднего масштаба: интернет-магазинов, API, SaaS, чат-ботов, корпоративных порталов или приложений с умеренным трафиком.

Преимущества: гибкость конфигураций, выбор ОС, изоляция ресурсов. Минусы: требует базовых навыков администрирования, стоимость выше, чем у виртуального хостинга.

Что такое выделенный сервер и когда его использовать?

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

Преимущества: максимальная производительность, полный контроль, высокая отказоустойчивость. Минусы: высокая цена, сложность настройки и обслуживания.

В чём основные различия между виртуальным хостингом, VPS и выделенным сервером?

Виртуальный хостинг — самый дешёвый и простой, но ресурсы делятся между пользователями, что ограничивает производительность (до 1000–2000 посетителей в сутки).

VPS обеспечивает выделенные ресурсы и гибкость, справляясь с нагрузкой до 5000–10 000 пользователей в сутки.

Выделенный сервер — максимум мощности для пиков свыше 10 000 пользователей, но требует значительных затрат и технических знаний.

Выбор зависит от масштаба: виртуальный для старта, VPS для роста, выделенный для enterprise.

Нужны ли навыки администрирования для хостинга?

Для виртуального хостинга навыки не нужны — управление идёт через интуитивные панели, а провайдеры обеспечивают обновления и базовую поддержку. Для VPS желательны базовые знания (настройка ОС, установка ПО), хотя многие провайдеры предлагают помощь. Для выделенного сервера навыки администрирования необходимы, так как вы полностью отвечаете за сервер, хотя провайдеры могут предлагать платное администрирование.

Для этого нужны системы высокой доступности (High Availability, HA). Речь не о полном исключении ошибок, а о способности системы продолжать работу даже при сбоях.

Высокая доступность основывается на трёх ключевых элементах: архитектуре, культуре разработки и процессах. Вместе с Борисом Кузоваткиным, директором облачной платформы One-cloud в VK, рассказываем, как создавать такие системы и что лежит в их основе.

Архитектура

Архитектура строится на принципах горизонтального масштабирования, изоляции компонентов, многоуровневого кэширования, автоматического восстановления и мониторинга на основе SLO.

Разберем на нашем кейсе: сегодня в VK активно развивается облачная платформа One-cloud. Вместо того чтобы привязываться к конкретным серверам, мы используем внутреннее облако. Это даёт гибкость: если в «классических» системах ночью сервера простаивают, то у нас эти ресурсы перераспределяются на другие задачи.

Ещё одна важная цель — обработка запроса в рамках одного ЦОД. Обычно, при сбое в одном ЦОД, часть трафика уходит на другой, и запускается эффект домино: узлы начинают падать один за другим. Обработка в рамках одного ЦОД позволяет избежать каскадных обращений между дата-центрами и минимизирует задержки. Такую стратегию применяют и другие крупные компании, разрабатывая свои сетевые решения вроде Minipack и FBOSS.

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

Культура разработки

Технологии сами по себе не обеспечивают надёжность. Важно то, как они применяются. Важно закладывать fallback-поведение: если, например, рекомендации не могут быть загружены, страница должна остаться рабочей.

Инженер должен уметь сам замечать, что «что-то идёт не так». Бывает, метрики показывают, что всё нормально, а пользователи уже начинают массово жаловаться. Или, наоборот, система присылает тревоги, но причина совсем в другом. Здесь решающим становится опыт команды и отлаженные on-call процессы.

В крупных компаниях по ключевым направлениям должны работать круглосуточные дежурные инженеры. Для них заранее важно подготовить инструкции, планы эскалации, шаблоны общения, рекомендации по первичной диагностике. Эти инструменты работают только в культуральной среде, где есть вовлечённость и ответственность.

Чтобы её поддерживать, необходимо регулярно проводить ретроспективы, обучающие сессии и внутренние симуляции сбоев (chaos drills).

Процессы и мониторинг

Надёжная система невозможна без процессов наблюдения и анализа. Центральное место здесь занимает мониторинг. Он должен уметь фиксировать отклонения раньше, чем это заметят пользователи. Важно отслеживать:

• частоту ошибок,
• квантили длительности запросов,
• загрузку CPU, RAM и дисков,
• бизнес-метрики (например, количество видео, просмотренных за минуту).

Для сбора метрик — Prometheus, VictoriaMetrics, Forge, а для визуализации использовать Grafana. Падение бизнес-метрик может быть вызвано не только сбоями в системе, но и внешними факторами — например, перебоями связи в праздничный день.

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

В VK есть и аварийные инструменты — для быстрого перемещения данных, поднятия сервисов, ручной настройки. Все действия сопровождаются мониторингом, чтобы видеть, как именно они влияют на систему в реальном времени.

После любого серьёзного сбоя обязательно проводится анализ:

• Что произошло?
• Как это починили?
• Что можно было сделать лучше?
• Как предотвратить повторение?
• Как система переживает сбои

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

• Пропадают рекомендации со страницы, но остаётся доступ к основному контенту;
• Увеличивается срок доставки, чтобы пользователи перестали совершать слишком много заказов;
• На стриминговых сервисах пользователь может слушать только предзагруженные треки — никаких новых загрузок и поисков.

На некоторых видеосервисах применяется load shedding: часть запросов сбрасывается, чтобы сохранить качество видео.

Такая деградация требует проектирования с самого начала. Иначе вместо стабилизации можно обрушить цепочку зависимых компонентов.

Уроки надёжности для любой команды

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

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

В мае 2024 по всему миру разлетелись скриншоты писем от HR с внезапными повышениями зарплат на 40%. Текучка кадров в сфере производства полупроводников выросла с 40% до 53%, и теперь компании дерутся за каждого специалиста.

Масштаб проблемы

169 отраслей пострадали из-за дефицита чипов — от автомобилестроения до бытовой техники. Tesla и Volvo останавливали заводы, цены на подержанные автомобили выросли на 10% за квартал. Даже стиральные машины подорожали из-за недостатка микросхем.

Но настоящая битва кипит в кабинетах бигтехов. США заблокировали экспорт технологий в Китай, Европа запустила программу на €43 миллиарда, а Азия удерживает 77% мирового производства чипов.

Технологическая война изменила ИТ-индустрию навсегда. Компании теперь не могут просто купить больше серверов — приходится искать тех, кто умеет делать софт быстрее и эффективнее. Apple создала собственные M1 и M2, Google разработал TPU, Amazon — процессоры Graviton. Каждый хочет стать независимым от поставок.

Обрушение цепей поставок

В 2020 автопроизводители массово отменили заказы чипов, думая, что спрос на машины упадет. Но случилось обратное — спрос на автомобили восстановился быстрее ожидаемого во второй половине года, а производственные линии уже переключились на потребительскую электронику.

Мир оказался в заложниках у нескольких азиатских гигантов. Тайвань контролирует 65% мирового рынка чипов, TSMC делает процессоры для Apple, AMD и NVIDIA. Samsung доминирует в производстве памяти и накопителей.

Различные отрасли посыпались, как домино. Время ожидания полупроводников Broadcom выросло до 22 недель против 12 недель в феврале 2020. Автоиндустрия потеряла миллионы машин, дата-центры замедлили расширение, даже PlayStation 5 стали дефицитом.

США первыми объявили технологическую войну. Пошлины уже изменили процессы производства у Nvidia, Intel и AMD. Китай ответил санкциями против Micron Technology.

Ключевые игроки разделились на два лагеря. На стороне США — Intel, NVIDIA, AMD, Qualcomm. Китай развивает SMIC и вкладывает миллиарды в собственные технологии. TSMC и Samsung балансируют между сторонами, строя заводы и в Америке, и в Азии.

Национальные программы превратились в гонку вооружений. CHIPS Act выделил $50 миллиардов на американское производство. Европейская программа нацелена на производство 20% мировых чипов к 2030 году. Китай инвестирует $143 миллиарда в полупроводники.

Гонки в мире чипов

Рынок AI-чипов взлетел в 15 раз за десятилетие. Компании научились делать процессоры умнее, но каждое новое поколение требует больше денег и экспертизы.

Техпроцессы сжимаются в размере. TSMC освоила 3-нанометровый процесс, Samsung догоняет. Каждый нанометр стоит миллиарды инвестиций и годы разработки. Apple M4 имеет Neural Engine в три раза быстрее M1, но производство одного такого чипа требует сотни инженеров.

AI-чипы стали новой золотой жилой. Intel запустила Gaudi 3, который на 50% быстрее NVIDIA H100. NVIDIA ответила платформой Blackwell с 208 миллиардами транзисторов. Qualcomm Cloud AI 100 обошел H100 по энергоэффективности — 227 запросов на ватт против 108.

Квантовые технологии пока остаются в лабораториях, но IBM и Google уже тестируют прототипы. Нейроморфные чипы, которые имитируют работу мозга, обещают революцию в энергоэффективности.

Делать чипы стало сложнее и дороже. Современная фабрика стоит $20 миллиардов, срок окупаемости — 10 лет. Поэтому крупные компании строят собственные решения: Apple создала M-серию, Google — TPU, Amazon — Graviton.

Компании поменяли философию. Вместо покупки большего количества серверов они нанимают инженеров для оптимизации кода. Netflix использует персонализированные рекомендации и алгоритмы ранжирования для оптимизации вычислений. Meta* оптимизировала машинное обучение и уменьшила количество GPU на 40%.

Массовый переход на ARM изменил рынок. Amazon перевела часть ресурсов на собственные процессоры. Microsoft адаптировала Windows под ARM-архитектуру. Даже Intel вынуждена выпускать подобные решения.

Россия также планирует наладить массовое производство 28 нм чипов к 2030 году. Росатом присоединился к разработке нейроморфных процессоров. Сбер тестировал отечественный Эльбрус-8С, но выявил проблемы с памятью и оптимизацией.

*– компания признана в РФ экстремистской и запрещена.

Айтишники в центре шторма

Зарплаты разработчиков взлетели вместе с ценами на чипы. Средняя зарплата embedded-инженера выросла до $153,383, а топовые специалисты получают до $175,000 в год. Performance-инженеры зарабатывают в среднем $100,522, но спрос превышает предложение. Оптимизация под ARM-архитектуру, разработка драйверов для AI-ускорителей, программирование FPGA — навыки, за которые компании готовы переплачивать. IT-зарплаты в Северной Америке выросли в среднем до $113,211.

Embedded-разработчики неожиданно стали востребованнее ML-инженеров. Когда Tesla не может купить нужные чипы, она нанимает программистов, которые выжмут из имеющихся процессоров максимум. Один такой специалист экономит компании миллионы долларов на железе.

География возможностей сместилась. Калифорния лидирует по зарплатам — $126,707 в Сан-Хосе, но спрос есть везде. Даже компании из Техаса и Флориды переманивают embedded-разработчиков зарплатами в $120,000-150,000.

Системные администраторы, знающие Kubernetes и контейнеризацию, стали дефицитом. Компании переходят на микросервисы и edge-решения — нужны те, кто умеет управлять распределенной инфраструктурой.

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

Свет в конце туннеля

Эксперты расходятся в прогнозах восстановления. CEO Intel Пат Гелсингер ожидал дефицит до 2024 года, но рынок полупроводников уже показал рост на 15,2% в начале года. К 2023-му автоиндустрия в основном восстановилась, глобальное производство автомобилей выросло на 3%.

Новые фабрики меняют географию производства. Intel строит заводы в Аризоне за $20 миллиардов и расширяется в Огайо. TSMC открыла завод в Японии в феврале 2024 и планирует второй к 2027 году. Samsung инвестирует в производство в Техасе.

Европа также входит в игру. European Chips Act нацелен на производство 20% мировых чипов к 2030 году с бюджетом €43 миллиарда. Intel проектирует заводы в Ирландии и Германии, Micron строит завод в Нью-Йорке, а GlobalFoundries расширяется на Мальте.

Будущее отрасли — в диверсификации. Тайвань по-прежнему контролирует 65% производства, но объемы будут снижаться. К 2030 году США планируют удвоить свою долю в мировом производстве чипов.

За четыре года индустрия изменилась больше, чем за предыдущее десятилетие. Компании научились строить собственные чипы, программисты — выжимать максимум из доступных ресурсов, а правительства — инвестировать в технологическую независимость.

Бигтехи готовы переплачивать за надежность поставок и «мозги». Программисты в выигрыше: чем сложнее становится производство чипов, тем больше нужно людей, которые умеют эффективно их использовать.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

Когда мы говорим об углеродном следе ПО, важно понимать: код не существует в вакууме. Каждая строка, каждый запрос и каждая операция требуют физических ресурсов — электричества, серверного оборудования, систем охлаждения. В 2025 году эта цепочка стала еще сложнее из-за взрывного роста облачных вычислений и ИИ.

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

Эти тренды нацелены на долгосрочное действие и в перспективе должны полностью изменить текущую концепцию в разработке.

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

Каждая лишняя операция в коде — это не только миллисекунды процессорного времени, но и реальные граммы CO₂. В 2025 году энергоэффективность кода перестала быть теоретической концепцией и превратилась в конкретный навык, который влияет на карьеру разработчика. Рассмотрим три ключевых направления оптимизации.

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

В 2025 году выбор стека технологий влияет не только на производительность, но и на экологичность проекта. Разберем ключевые аспекты, которые помогут снизить углеродный след вашего приложения.

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

Супероблака — следующий этап эволюции распределенных вычислений. В отличие от традиционных облачных провайдеров, эти системы автоматически переносят нагрузку между дата-центрами в зависимости от доступности возобновляемой энергии.

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

Компании, внедрившие принципы устойчивого развития в IT, уже в 2025 году получают на больше инвестиций и быстрее проходят аудит регуляторов. Экологичность перестала быть затратой — теперь это конкурентное преимущество.

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

Экологичность в IT — не благотворительность и не актуальная повестка, а реальная экономия. Плюс работа на перспективу. Оптимизация кода снижает счета за облака и повышает производительность.

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

В этом материале вместе со Станиславом Погоржельским, технологическим евангелистом платформы VK Cloud, разберем особенности решений для хранения и работы с большими данными.

Особенности локальных хранилищ

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

Семь «грехов» локальных кластеров

Теперь поговорим о том, какие неприятные особенности встречаются во время эксплуатации локальных кластеров.

Структура данных и хаос

В реальных системах данные редко бывают аккуратными. Вместо красивых таблиц разработчик часто сталкивается с миллионами мелких файлов по 1-2 Кб и, например, видео по несколько Гб. Такие крайности требуют противоположных стратегий хранения и кэширования.

Файловая система, не оптимизированная для работы с малыми файлами, быстро забивается inode'ами (переполнение файловых дескрипторов). Системы хранения начинают задыхаться не от общего объема, а от количества объектов, что критически влияет на производительность. Например, известны случаи, когда после миллиона объектов OpenStack Swift начинал терять метаданные, а в хранилищах висели призраки удаленных объектов.

RAID — не универсальное спасение

Настройка RAID-массивов кажется очевидным решением, но не все так однозначно:

• RAID 5 и 6 плохо переносят большие объемы из-за длительного времени восстановления.
• RAID 10 требует удвоения или утроения объема хранения ради скорости и отказоустойчивости.
• На петабайтных объемах пересборка массива после сбоя может занимать больше недели.

Поддержка архивов и ZIP-файлов

Архивирование данных (например, с помощью ZIP) спасает место, но приводит к другим проблемам: невозможность выборочного доступа к отдельным файлам без полной распаковки, рост времени обработки запросов, сложность мониторинга целостности данных.

Массовая работа с архивами требует настройки кэширования и часто вынуждает строить параллельные системы для индексации содержимого архивов.

Автоматизация мониторинга и ремонта

Любая система хранения живет с постоянным риском деградации: умирают диски, выходят из строя контроллеры, падают сети. На уровне сотен и тысяч узлов мониторинг «вручную» невозможен: требуется автоматизированная оркестрация алертов, самовосстановление, динамическая миграция данных на здоровые узлы. Иначе разрастание локальных отказов перерастает в потерю данных.

Шардирование данных: неизбежность и боль

На больших объемах данных (более 250 Тб) приходится шардировать — разбивать на независимые логические части, чтобы сохранить производительность. Но с шардированием есть проблемы:

• усложняет маршрутизацию запросов;
• увеличивает сложность восстановления данных при сбоях;
• требует отдельных механизмов ребалансировки шардов при добавлении новых узлов.

Более того, встроенные механизмы шардирования некоторых популярных СУБД (MongoDB, PostgreSQL с партиционированием) не рассчитаны на миллиарды записей и начинают деградировать.

Проблемы метаданных

Каждый файл и объект требуют метаданных: даты создания, размера, доступа, хеш-суммы. При росте числа объектов метаданные сами по себе становятся огромными: терабайты информации, требующие отдельного хранения, индексирования и защиты.

Резервное копирование на практике

Бэкап петабайта данных требует продуманной стратегии инкрементальных копий, дедупликации, постоянного тестирования восстановления. Локальное хранение больших объемов данных — это не про покупку железа и развертывание файлового сервера. Это бесконечная инженерная работа по балансировке между скоростью, надежностью, стоимостью и сложностью системы.

Хранение больших объемов обостряет вопросы производительности, резервного копирования и автоматизации мониторинга, где каждый аспект требует балансировки между скоростью, надежностью и сложностью ИТ-инфраструктуры.

Облачные хранилища

С локальными хранилищами разобрались, теперь рассмотрим технические особенности альтернативного решения.

Гибкость и масштабируемость без ограничений

В облаке увеличение объемов хранения происходит мгновенно:

• без ожидания закупки нового оборудования;
• без сложного планирования миграций;
• без перебоев в обслуживании приложений.

Эксплуатация и разработчики могут динамически добавлять терабайты и петабайты данных в рамках одного API-запроса. Облачное хранилище предлагает готовое решение для масштабирования от стартапов до международного уровня компаний.

Финансовая прозрачность и удобная модель оплаты

Модель Pay-As-You-Go (оплата по факту использования) дает бизнесу и разработчикам:

• предсказуемость расходов;
• возможность мгновенно адаптировать инфраструктуру под изменяющиеся требования;
• отсутствие необходимости капитальных затрат на старте;
• гибкость в выборе тарифов хранения (горячие, холодные, архивные данные).

Такая прозрачная модель помогает экономить бюджет без потери качества сервиса.

Надежность и отказоустойчивость «из коробки»

S3-совместимый Object Storage обеспечивает высокую доступность данных благодаря:

• автоматической репликации данных в нескольких географических регионах;
• встроенным механизмам самовосстановления данных;
• резервированию оборудования на уровне дата-центров;
• постоянному мониторингу целостности объектов.

Оптимизация работы с любыми типами данных

Хранилище позволяет одинаково эффективно работать:

• с миллионами мелких файлов (фото, документы, логи);
• с тяжелыми объектами (видео или архивами).

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

Высокий уровень безопасности данных

В облаке предоставляется комплексная защита данных с помощью:

• шифрования на стороне клиента и сервера;
• гибкого управления правами доступа (ACL, IAM);
• соответствия требованиям хранения ПДН и прочих стандартов безопасности;
• автоматического обнаружения потенциальных уязвимостей.

Безопасность данных обеспечивается на каждом уровне инфраструктуры и подтверждается регулярными внешними аудитами.

Инструменты для разработчиков и автоматизации

Хранение данных в облаке ориентировано на удобство интеграции и масштабирование за счет:

• полного набора API и SDK для популярных языков программирования;
• готовых модулей для работы с данными в распределенных системах;
• продвинутых средств мониторинга, алертинга и автоскейлинга;
• поддержки DevOps практик через IaC-инструменты.

Автоматизация всех процессов упрощает разработку и сопровождение проектов, значительно снижая риски человеческих ошибок.

Опыт хранения больших данных

Когда речь идет о масштабных системах хранения — таких как S3-совместимый сервис Object Storage на платформе VK Cloud, — производительность определяется не только скоростью сети и дисков. Ключевую роль играют архитектурные особенности приложений: как именно данные распределяются, обрабатываются и индексируются.

Особенно важно это в системах с огромным количеством объектов, где миллионы или миллиарды файлов разного размера постоянно создаются, обновляются и удаляются.

Как измеряется производительность облачного хранилища

Для реальной оценки производительности облачного хранилища важно замерять:

• Количество операций в секунду (RPS): сколько запросов на чтение/запись способна обработать система.
• Среднюю и 99-ю персентиль задержек: критично для оценки качества обслуживания конечных пользователей.
• Производительность на больших объемах объектов: важно не просто тестировать один файл, а моделировать реальную работу приложений с множеством параллельных операций.
• Влияние мелких и крупных файлов: системы по-разному работают при миллионах маленьких объектов и гигабайтных видео.

Практические сценарии измерений:

• многопоточная загрузка 100 миллионов объектов размером 1–10 КБ;
• массовое чтение миллионов объектов через S3 API;
• удаление больших объемов объектов для оценки работы сборки мусора;
• сценарии с версионированием объектов, чтобы проверить нагрузку на метаданные.

Почему шардирование критически важно для облачного хранилища

Правильная организация шардирования данных — один из ключевых факторов производительности больших хранилищ.

Что происходит без правильного шардирования:

• «Горячие» бакеты (S3-бакеты) с высокой нагрузкой становятся узким местом.
• Распределение нагрузки по серверам становится неравномерным.
• Метаданные начинают тормозить операции доступа.
• Снижается общая масштабируемость системы.

Реальная практика VK Cloud:

• Метаданные объектов распределяются по кластерам через шардирование по диапазонам ключей.
• При превышении нагрузки шард автоматически расщепляется (split) для перераспределения нагрузки между нодами.
• Для хранения метаданных используется Tarantool как высокоскоростная in-memory база данных, способная выдерживать сотни тысяч операций в секунду на один шард.

Такой подход позволяет обеспечить:

• низкие задержки доступа даже при миллиардах объектов;
• линейное масштабирование — добавление новых серверов дает реальный прирост пропускной способности;
• быструю обработку как мелких, так и больших файлов без перегрузки одной ноды.

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

За что мы любим Tarantool

Принцип работы СУБД Tarantool кардинально отличается от классических SQL-баз (PostgreSQL, MySQL) в хранилищах:

Tarantool позволяет работать с облачным хранилищем на скорости, которую классические базы не способны обеспечить без радикальных усилий по оптимизации.

Как правильно проектировать нагрузку на S3-совместимое облако

Если вы проектируете высоконагруженную систему, важно:

• Использовать естественное шардирование ключей (например, вставлять случайные префиксы в имена объектов).
• Ожидать миллионы объектов в бакете и строить приложения так, чтобы они не зависели от скорости листинга всех файлов.
• Минимизировать количество операций массового удаления объектов — использовать batch-удаление через S3 API.
• Понимать, что работа с метаданными так же важна, как и сама передача данных.

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

Заключение

Работа с петабайтными объемами данных требует серьезного подхода к проектированию инфраструктуры. На этом пути локальные решения сталкиваются с проблемами масштабирования, отказоустойчивости, обновления оборудования и обеспечения безопасности. Управление инфраструктурой превращается в отдельный проект со своими ресурсами.

Облачное хранилище обеспечивает:

• автоматическое масштабирование объема хранения без потерь в производительности;
• высокую доступность данных благодаря распределению по зонам отказа;
• прозрачную модель оплаты — вы платите только за реально используемые ресурсы;
• эффективную работу как с миллионами мелких файлов, так и с крупными объектами;
• безопасность данных с помощью встроенного шифрования и управления доступом через IAM;
• богатый инструментарий API для полной интеграции в любые архитектуры приложений.

Облачные хранилища предоставляют возможность компаниям сосредоточиться на развитии своих продуктов и бизнес-логики, передав инфраструктурные задачи профессиональной облачной платформе.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

Обучение программированию в этот период кардинально отличалось от современных подходов. Онлайн-курсы практически отсутствовали. Основными источниками знаний служили бумажные книги:

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

Этот кейс хорошо иллюстрирует дух эпохи: отсутствие готовых безопасных решений заставляло программистов изобретать велосипеды. Многие подобные наработки позже легли в основу ORM-библиотек, но тогда они рождались в муках — через пробелы в безопасности и километры самописного кода.

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Почему так? В 2024–2025 годах США ужесточили ограничения: VMware NSX и Cisco ACI официально заблокированы. Казалось бы, идеальный момент для отечественных решений вроде Basis SDN от «Базиса». Но сегодня их доля на рынке — не выше 3%.

Выясним, почему российские SDN, несмотря на импортозамещение, пока так и не стали массовыми, и что мешает бизнесу переходить на отечественные продукты — от дефицита специалистов до проблем с legacy-инфраструктурой. Только факты, кейсы внедрений и прогнозы на 2026–2030 годы с опорой на отчеты Ростелекома, аналитику 6Wresearch и документы OFAC.

SDN в России-2025: почему мир перешел на «сети из кода», а мы настраиваем маршрутизаторы вручную

SDN (Software-defined networking) — это когда сетью управляют не железки, а код. Представьте, что вместо того, чтобы вручную прописывать правила на каждом коммутаторе, вы просто пишете скрипт, и сеть мгновенно перестраивается под ваши задачи. Контроллер SDN решает, куда направить трафик, как распределить нагрузку и какие политики безопасности применить. Все это — без манипуляций с командной строкой и конфигурационных файлов.

Мировой контекст: SDN как новая норма

Глобальный рынок SDN к 2025 году оценивается в $12+ млрд, а темпы роста превышают 18% в год. Причины просты:

• Облака и гибридные инфраструктуры требуют гибкости, которую традиционные сети дать не могут.
• Киберугрозы теперь атакуют не отдельные устройства, а всю сеть. SDN позволяет изолировать зараженные сегменты за секунды — например, отрезать атакованный филиал до того, как он заразит головной офис.
• 5G и IoT без SDN просто не работают. Виртуальные срезы сети (network slicing) — единственный способ гарантировать приоритет критичному трафику, будь то телемедицина или беспилотники.

Но главный драйвер — экономика. Компании устали переплачивать за «умное» железо Cisco и Juniper, когда всю логику можно перенести в софт. К 2025 году 70% корпоративных сетей в ЕС и США управляются через SDN-контроллеры — просто потому, что это дешевле и быстрее.

Россия: технологический суверенитет vs. реальность

В 2024–2025 годах санкции добили то, что не успели в 2022-м:

• VMware NSX официально заблокирован для российских компаний.
• Cisco ACI и Huawei CloudFabric доступны только через «серые» схемы, но их поддержка практически не работает.
• Оборудование попало под прямые ограничения: даже нейтральные производители вроде Arista отказываются поставлять коммутаторы из-за риска вторичных санкций.

Казалось бы, идеальный момент для российских SDN-решений. Но доля отечественных продуктов на рынке — единицы. Причины такой ситуации вполне объективны:

• «Железная» зависимость. Большинство российских SDN работают только с оборудованием конкретных вендоров — YADRO, Aquarius, «Бифорком». Если у компании инфраструктура на старых Cisco или Huawei, миграция потребует полной замены «железа».
• Функциональные пробелы. Тот же Basis SDN декларирует 80% функционала VMware NSX, но ключевые фичи вроде автоматического восстановления после сбоев (self-healing) или глубокой аналитики трафика через ИИ пока в разработке.
• Дефицит экспертов. В России менее 1000 сертифицированных специалистов по SDN — против 25 000 в США и ЕС. Обучение нового инженера с нуля занимает 1.5–2 года — бизнес не готов ждать.

Спрос есть, но внедрять некому

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

При этом Basis SDN — единственное решение, которое хоть как-то закрывает дыру. Его пилоты запустили Ростелеком, СберТех и несколько госструктур. Но даже они признают: продукту не хватает открытости API и поддержки мультивендорных сред.

Вывод: мир уже живет в эпоху «сетей как кода», а Россия только учится настраивать контроллеры. Без массовых инвестиций в R&D (Research and Development, научные исследования и разработки) и образование разрыв будет расти. К 2030 году мы рискуем остаться с SDN «на бумаге», пока глобальные игроки перейдут на следующую ступень — IBN (intent-based networking) — сеть, основанную на намерениях с полной автономией ИИ.

Свои SDN: роскошь или необходимость?

Блокировки лишили российские компании доступа к обновлениям и техподдержке. Санкции против YADRO и других производителей сетевого оборудования усугубили проблему: даже если «железо» физически есть, его нельзя масштабировать без лицензий. Сложность в том, что технологический суверенитет нельзя купить — его нужно строить.

Технологический суверенитет — не лозунг, а вынужденная мера

В 2025 году термин «импортозамещение» уже не вызывает иронии. Сегодня российский бизнес столкнулся с простым фактом: зарубежные SDN-решения либо недоступны, либо работают с перебоями.

Компании, которые в 2024-м надеялись на «серые» поставки VMware NSX, теперь тратят на 40% больше на поддержку устаревших версий.

Basis SDN — пока единственная рабочая альтернатива. Разработка «Базиса» и Angie Software изначально создавалась под санкционные реалии:

• полная независимость от зарубежного ПО — даже гипервизор работает на KVM;
• поддержка российского «железа» (YADRO, Aquarius) без необходимости доработок;
• цена ниже VMware NSX до его ухода с рынка.

Но главное — это не просто клон VMware, а адаптация под российские условия. Например, здесь изначально заложена поддержка требований ФСТЭК к шифрованию трафика, что для госсектора критично.

Преимущества, которые оценит даже скептик

Рассмотрим подробно плюсы перехода на отечественные программно-определяемые сети.

Централизованное управление: оптимизация времени и расходов

Вместо настройки каждого коммутатора вручную вы управляете всей сетью через одну веб-панель. Нужно изменить политику безопасности для филиала? Все делается элементарно: не надо ехать на место или объяснять по телефону — правила применяются мгновенно.

Так работает Basis SDN:

• единый контроллер заменяет десятки разрозненных консолей Cisco Prime или Huawei eSight;
• автоматизация рутинных задач — например, выделение VLAN под новый отдел занимает минуты вместо часов;
• мониторинг в реальном времени — аномалии трафика (DDoS, утечки) система обнаруживает сама и предлагает решения.

Микросегментация: безопасность без головной боли

В 2025 году кибератаки стали точечными: злоумышленники не ломают всю сеть, а ищут слабые звенья — бухгалтерию, базы данных, IoT-устройства.

SDN позволяет изолировать критичные сегменты без физического разделения:

• финансовые системы можно отрезать от общего трафика, даже если они используют те же коммутаторы;
• доступ к данным регулируется не только логинами, но и контекстными правилами (например, запрет копирования файлов после 18:00);
• в случае атаки зараженный сегмент автоматически блокируется — без остановки всей сети.

Совместимость: работает здесь и сейчас

Типичная претензия к российскому ПО — «а вот у Cisco…». Но Basis SDN уже сегодня поддерживает:

• Astra Linux и «Альт» — без костылей в виде дополнительных драйверов;
• оборудование YADRO, БСТ, Aquarius — с гарантией обновлений;
• облачные платформы на базе KVM и отечественных гипервизоров.

При этом система не требует полного отказа от legacy-инфраструктуры. Например, можно оставить старые коммутаторы Cisco, но управлять ими через SDN-контроллер — это вдвое дешевле, чем менять все железо.

Рыночные перспективы: куда движется отрасль

Объем рынка SDN в России пока относительно невелик, но к 2031-му прогнозируют его рост до 32 млрд.

Основные драйверы:

• Госсектор: с 2024 года все госкомпании обязаны использовать «третьи ключи шифрования» — без SDN это нереализуемо.
• Телеком: Ростелеком и МТС тестируют SDN для 5G-сетей — ручное управление таким трафиком уже невозможно.
• Средний бизнес: облачные CRM и ERP требуют гибких сетей, а аренда VMware NSX теперь недоступна.

Вывод: свои SDN — это про выживание

В 2025 году вопрос уже не в том, «зачем свои SDN», а в том, как быстро компании смогут перейти на них. Ожидать возвращения VMware бессмысленно и нерационально.

При этом:

• Basis SDN — не идеален, но это практически единственное рабочее решение;
• без микросегментации скоро не получится пройти даже базовый аудит ФСТЭК;
• гибридные облака без SDN превращаются в кошмар админа.

Те, кто внедрит российские SDN сейчас, через 2–3 года получат снижение затрат на 25–40% по сравнению с теми, кто цепляется за «серые» Cisco и Huawei. Остальные рискуют остаться с сетью, которую некому и нечем администрировать.

Проблемы отечественных SDN: почему российские «сети из кода» пока не взлетели

Однако в 2025 году российские SDN-решения пока далеки от совершенства. Basis SDN от «Базиса» и аналоги от VK Tech («Спрут») — первые ласточки, но их внедрение сталкивается с тремя группами проблем: технологическими, экономическими и рыночными. Разберем каждую.

Технологические вызовы: когда железа много, а экспертов нет

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

Дефицит экспертизы. Для разработки конкурентоспособного SDN нужны специалисты высшего уровня, которых в РФ катастрофически не хватает.

Функциональные пробелы. Basis SDN декларирует 80% функционала VMware NSX, но критичные фичи вроде автономного восстановления после сбоев или глубокой аналитики трафика через ИИ появятся не раньше 2026 года. Для корпоративных клиентов это риск: например, без self-healing атака на один сегмент может парализовать всю сеть.

Совместимость с legacy-инфраструктурой. Большинство российских SDN работают с оборудованием YADRO, Aquarius или «Бифорком». Если у компании стоят старые Cisco или Huawei, миграция потребует полной замены «железа» — а это +30–50% к бюджету проекта.

Пример: В 2024 году Ростелеком-ЦОД пытался интегрировать Basis SDN с унаследованными коммутаторами Juniper. Проект забуксовал — пришлось докупать российские аналоги, что увеличило сроки внедрения на 4 месяца.

Экономические и регуляторные барьеры: санкции vs. окупаемость

Высокая стоимость разработки. Создание Basis SDN обошлось в сотни миллионов рублей. Для сравнения: бюджет VMware NSX превышает $1 млрд, но его распределяют на глобальный рынок. Российским вендорам приходится компенсировать затраты за счет узкой локальной аудитории.

Давление санкций. С июня 2024 года США запретили ИТ-консалтинг и облачные услуги для российских компаний. Это ударило по поддержке гибридных инфраструктур. Стало невозможно заказывать аудит сети у зарубежных вендоров, а облачные платформы вроде VMware Cloud Foundation недоступны даже через «серые» схемы.

Долгая окупаемость. По прогнозам «Базиса», Basis SDN окупится за 2–3 года. Но малый бизнес не готов ждать — ему нужны решения здесь и сейчас.

Рыночное недоверие: почему бизнес не верит в свои SDN

Культ «проверенных» зарубежных решений. Даже санкционные Cisco ACI и VMware NSX остаются в топе запросов у российских интеграторов.

Причины:

• Документация. У Cisco — 500+ страниц детальных мануалов, у Basis SDN — 80, и половина на уровне «как включить контроллер».
• Сообщество. Для VMware NSX есть 1000+ готовых скриптов на GitHub, для Basis SDN — меньше 50.

Низкая осведомленность малого бизнеса. Опрос бизнес-лаборатории «КРОК» показал: 60% компаний с оборотом до 1 млрд руб. считают SDN «дорогой игрушкой для корпораций». При этом они не знают, что микросегментация в Basis SDN снижает риски утечек на 40% — но об этом не пишут в СМИ.

Российские SDN не смогут конкурировать с зарубежными, пока:

• не сократится разрыв в экспертизе — нужны образовательные программы уровня Cisco Networking Academy;
• не появятся гарантии долгосрочной поддержки — например, госсубсидий на 5–10 лет;
• не изменится восприятие рынка — тут нужны кейсы уровня «Сбербанк полностью перешел на Basis SDN».

Сейчас Basis SDN остается нишевым продуктом для госсектора и Ростелекома.

Кейсы и перспективы: где российские SDN уже работают и куда движутся

В 2025 году российские SDN-решения перестали быть лабораторными проектами — они постепенно внедряются в реальную инфраструктуру. Но масштабы пока несопоставимы с зарубежными аналогами.

Разберем, где Basis SDN и другие решения уже доказали свою жизнеспособность, какие рынки могут стать для них перспективными и что мешает ускорить развитие.

Basis SDN: первый крупный кейс — «Ростелеком-ЦОД»

В мае 2025 года «Базис» завершил пилотное внедрение своего SDN-решения в дата-центрах Ростелекома.

Проект показал:

• Сокращение времени настройки VLAN с 4 часов до 15 минут за счет централизованного управления.
• Микросегментация финансовых сервисов — изоляция платежных систем снизила риски атак на 40% по данным внутреннего аудита.
• Совместимость с оборудованием: 70% старых коммутаторов Cisco удалось интегрировать через шлюзы на базе KVM, хотя изначально Basis SDN разрабатывался для российского «железа» YADRO и Aquarius.

Потенциальные рынки: где российские SDN могут закрепиться

В июне 2025 года «Базис» анонсировал партнерство с телеком-оператором в ЮАР.

Причины интереса:

• Цена: $15 000 за контроллер против $30 000 у VMware NSX.
• Санкционная нейтральность: в Африке нет давления на использование российского ПО, а китайские аналоги (например, ZTE SDN) проигрывают в функционале.

Планируются поставки в Бразилию (интеграция с облачной платформой на базе OpenStack) и Казахстан (совместный проект с «Казтелеком»).

Согласно прогнозам, к 2031 году объем рынка SDN в РФ вырастет в 2-3 раза, но 80% спроса будет приходиться на госсектор и госкомпании.

Малый бизнес пока остается в стороне. Проблема в том, что Basis SDN ориентирован на крупные внедрения. Для малого бизнеса нет «облегченных» версий — аналогов Cisco ACI Essentials.

Рекомендации: как сделать российские SDN массовыми

Российские SDN-решения доказали свою жизнеспособность, но для перехода из нишевого сегмента в массовый нужны системные изменения. Рассмотрим ключевые направления, без которых не обойтись.

Кадры — основа всего. Чтобы ускорить подготовку специалистов, нужно:

• ввести грантовые программы по типу «Цифровых профессий», но с фокусом на сетевые технологии;
• интегрировать модули по SDN в вузовские программы — пока лишь единицы технических университетов включают их в учебные планы.

Без этих шагов бизнес будет сталкиваться с той же проблемой, что и сейчас: даже купив Basis SDN, компании не смогут его эффективно использовать из-за нехватки компетенций.

Госсектор стал основным драйвером спроса на отечественные SDN, но для массового внедрения нужны меры, стимулирующие переход коммерческих компаний. Опыт Китая показывает, что субсидии на 50% затрат при миграции с VMware/Cisco резко увеличивают долю локальных решений.

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

Одна из главных претензий к Basis SDN — слабая интеграция со сторонними платформами. Для сравнения: VMware NSX поддерживал свыше 200 приложений, а у российского аналога их на порядки меньше.

Без этого Basis SDN так и останется «закрытым» продуктом для узкого круга заказчиков. Российские SDN не станут массовыми сами по себе — нужна скоординированная работа бизнеса, образовательных учреждений и регуляторов.

Итоги: отечественные SDN требуют долгосрочной стратегии

Российские решения вроде Basis SDN доказали, что могут работать в реальных условиях. Но чтобы конкурировать глобально, нужно:

• увеличить долю рынка внутри страны — пока она менее 5%;
• снизить порог входа для малого бизнеса;
• выйти за пределы госзаказов — иначе продукт останется нишевым.

Жизнеспособность у проекта есть. Basis SDN закрывает 80% базовых потребностей бизнеса: микросегментация, централизованное управление, совместимость с российским «железом». Но критичные функции вроде автономного восстановления сетей появятся только к 2026 году.

Аналитики предсказывают рост рынка SDN в России, но это произойдет только если появятся новые фичи: например, интеграция с ИИ для прогнозирования сетевых аномалий, снизится порог входа и вырастет число специалистов.

Что может сделать каждый:

• Тестировать. «Базис» активно привлекает IT-комьюнити к доработке Basis SDN. Участие в пилотах — способ повлиять на развитие продукта.
• Развивать open-source. Проекты вроде OpenDaylight и OpenStack — основа для российских SDN. Чем больше контрибьюторов, тем быстрее сократится разрыв с зарубежными аналогами.
• Требовать документирования. Одна из главных претензий к Basis SDN — скудные мануалы. Если разработчики увидят запрос от сообщества на детальные гайды, они быстрее их выпустят

Главный вывод: SDN — не просто технология, а новая сетевая парадигма. Россия может занять в ней свое место, но для этого нужны не точечные успехи, а системные изменения.

Больше инфоповодов — в нашем тг-канале.

Почему «тормоза» — это не всегда про код

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

Современное приложение — это сложный организм: десятки микросервисов, базы данных, кэши, брокеры, сети. И тормозить может любой из этих компонентов. А ты в это время профилируешь ни в чём не виноватый for.

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

Многие из них — не баги, а последствия архитектурных решений. В дев-среде всё летает, потому что:

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

Когда приложение тормозит, мы часто копаемся в отдельных компонентах — фронте, бэке, базе. Но bottleneck может быть не внутри компонента, а между ними: в конфигурации, связях, сетевых задержках, очередях вызовов.

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

Оптимизация кода важна. Но если система тормозит, искать нужно по всей цепочке — от кнопки на фронте до брокера в соседнем дата-центре.

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

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

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

Архитектура доступа к данным: как закладываются тормоза

Архитектура доступа к данным — фундамент, на котором держится производительность всей системы. Даже идеальный алгоритм или быстрый backend не спасут, если данные извлекаются медленно, неэффективно или избыточно.

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

• Очередь перегружена, и событие просто стоит в хвосте.
• Обработчик падает или рестартится, и событие ждёт.
• Политики повторной обработки не настроены — событие крутится бесконечно.
• Слишком много этапов внутри одного воркера: валидация, запись в БД, вызов API — всё это задержки, которые суммируются.

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

Очередь продолжает принимать события, но обрабатываются они с огромным отставанием. Новое сообщение встаёт в хвост и ждёт своей очереди десятки секунд или минут. Такую ситуацию легко не заметить, если у вас не настроен грамотный мониторинг.

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

Если тормозит хотя бы один, сыплется всё. Получается эффект домино и каскадные отказы, где неполадка в одном звене рвёт всю цепочку.

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

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

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

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

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

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

А если кэш сбрасывается при каждом изменении, он вообще не успевает выполнять свою роль. В итоге: нестабильное поведение, непредсказуемая производительность и раздражённые пользователи.

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

• работают на одной машине без шардинга;
• содержат тяжёлые объекты;
• используются как универсальный ответ на все проблемы.

В таких случаях кэш из «ускорителя» может падать под нагрузкой быстрее, чем база данных.

Кэш-миссы и лавины запросов

Классическая проблема: TTL у популярных ключей истекает одновременно, и тысячи запросов идут мимо кэша в базу. Это может случиться после деплоя, сброса кэша или при пиковой нагрузке.

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

Почему мощные сервера с десятками ядер и гигабайтами памяти тормозят? Потому что производительность упирается не в «железо», а в то, как именно это железо используется. От плохого управления памятью до блокирующих операций — в системе может быть множество узких мест, которые незаметно душат throughput.

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

Так можно увидеть, что, например, сторонний сервис отвечает 3 секунды, или Redis стал отдавать ответ за 300 мс вместо обычных 3 мс.

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

После изменений обязательно перепроверьте метрики, чтобы убедиться, что оптимизация действительно дала эффект — и не добавила новых узких мест.

Итоги: как не попасть в архитектурную ловушку

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

Главная проблема в том, что узкие места проявляются не сразу, а под нагрузкой. В разработке и тестах всё летает, потому что ресурсов хватает. А вот в проде — особенно при росте аудитории — на поверхность всплывает всё, что не выдерживает реального объёма данных или конкуренции за ресурсы.

Чтобы избежать таких проблем, важно не просто писать чистый код, а мыслить системно: проектировать архитектуру так, чтобы она могла жить под давлением. Вот несколько принципов, которые помогут.

Думайте об объёмах и росте

Архитектура должна выдерживать не только текущую нагрузку, но и разумный рост. Строить систему на «миллиард пользователей» с первого дня — избыточно. Но если вы рассчитываете, что пользователей станет в 5 раз больше через год — закладывайте это сейчас. Узкие места не любят сюрпризов.

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

Микросервисы, шины, очереди, event-driven — всё это мощные инструменты. Но сложность должна быть оправданной. Простая, понятная архитектура с мониторингом и масштабируемыми точками зачастую выигрывает у перегруженной модульной схемы, которую никто не может отладить.

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

Больше новостей в нашем тг-канале Представляешь

Идея проста: вместо утилизации или бессмысленного хранения в ящиках, устройства получают вторую жизнь как вычислительные узлы. Учитывая, что ежегодно производится более 1,2 млрд новых телефонов, а средний срок их использования — 2–3 года, такая схема позволяет радикально снизить нагрузку на природу. Тем более, что большая часть техники остаётся работоспособной даже после списания.

Прототип ученых стоил всего 725 рублей по текущему курсу. Смартфоны были лишены аккумуляторов и подключены к внешнему питанию, чтобы исключить утечки вредных веществ. Затем их объединили в пластиковом корпусе, напечатанном на 3D-принтере. Получившийся кластер успешно справился с реальными задачами — например, автономным мониторингом морской фауны под водой. Раньше для таких операций требовались водолазы и последующая ручная обработка видео. Теперь всё происходит прямо в толще воды, в реальном времени.

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

Рассмотрим, что представляет собой MFA и как помогает избежать утечек.

Проблемы с паролями и принципы MFA

Несмотря на развитые технологии, простые пароли остаются уязвимыми. Фишинг обманывает пользователей через фальшивые сайты или имейлы, brute-force использует автоматизированный перебор комбинаций, а утечки происходят при взломе внешних сервисов, где пароли повторяются.

MFA противостоит этому, требуя не менее двух факторов аутентификации. Основные типы:

• То, что известно пользователю: пароль или PIN-код — наиболее распространенный, но и самый слабый фактор.
• То, что есть у пользователя: устройство вроде смартфона, USB-токена или аппаратного ключа.
• То, кем выступает пользователь: биометрия типа отпечатка пальца, распознавание лица или сканирование сетчатки.

От двухфакторной аутентификации (2FA) MFA отличается гибкостью: 2FA обычно ограничивается паролем плюс одноразовым кодом (например, из SMS), в то время как MFA позволяет добавлять третий фактор для критических систем.

С MFA часто интегрируют связанные технологии. Единый вход (SSO) упрощает доступ: пользователь авторизуется один раз и получает права на несколько сервисов. Модель нулевого доверия (Zero Trust) проверяет каждый запрос заново, учитывает IP, время и устройство, независимо от источника. Вместе они создают многоуровневую защиту, идеальную для распределенных команд.

Общие принципы работы MFA-систем

MFA-системы обычно развертываются как облачные сервисы (SaaS) или on-premise решения, с акцентом на совместимость с существующими инфраструктурами. Они поддерживают протоколы вроде RADIUS, LDAP, SAML и OpenID Connect/OAuth, что позволяет интегрировать их с VPN, VDI, RDP, SSH, межсетевыми экранами (например, Check Point, Cisco, UserGate), облачными платформами (VMware, Huawei Cloud) и приложениями (G Suite, Salesforce).

При выборе MFA стоит обратить внимание на:

• Методы доставки факторов: SMS/звонки, push-уведомления в мобильных приложениях, боты в мессенджерах (например, Telegram), OTP-токены (аппаратные или программные), U2F/FIDO-ключи и биометрия. Разнообразие методов повышает удобство и адаптивность.
• Политики доступа: Возможность задавать правила на основе IP, времени суток, дней недели или групп пользователей. Это помогает ограничить доступ, например, только из офисной сети или в рабочее время.
• Инфраструктура и надежность: Размещение в сертифицированных дата-центрах с защитой от DDoS, высоким уровнем доступности (SLA не ниже 99.9%) и резервированием данных.
• Интеграция и развертывание: Минимальные требования к аппаратным ресурсам (например, 4 ядра CPU и 4 ГБ RAM для агентов), открытый код для прозрачности и быстрая настройка (от нескольких часов).
• Аудит и мониторинг: Журналы событий с фиксацией IP, страны, результатов аутентификации и алертами на подозрительную активность.
• Самообслуживание: Порталы, где пользователи самостоятельно настраивают факторы или сбрасывают пароли.
• API для кастомизации: Для встраивания MFA в собственные приложения, с поддержкой регистрации пользователей и генерации токенов.

Важно учитывать конфиденциальность: системы должны маскировать чувствительные данные в уведомлениях и соответствовать регуляциям, по типу GDPR или российским законам о защите ПДн.

MULTIFACTOR как пример MFA-решения

В качестве практического примера можно рассмотреть российскую систему MULTIFACTOR, которая применяется для защиты удалённых подключений — RDP, VPN, VDI и SSH.

Решение разворачивается в гибридной модели: часть компонентов работает в облаке, часть устанавливается у заказчика. Облачная часть расположена в российских дата-центрах (Selectel, LinxCloud), сертифицированных по стандартам PCI DSS и ISO 27001. В инфраструктуру встроена защита от DDoS-атак, SLA по доступности заявлен на уровне 99,99%, состояние сервисов можно отслеживать на публичной статус-странице.

Что требуется со стороны клиента:

• служба каталогов (Active Directory или аналог);
• RADIUS-адаптер для обработки запросов;
• портал самообслуживания для пользователей.

Адаптер проверяет первый фактор (логин/пароль) локально, а второй передаёт в облако. Для работы необходима базовая конфигурация (4 ядра CPU, 4 ГБ RAM на Windows Server), а портал самообслуживания требует ещё меньше ресурсов. Ключевые компоненты системы доступны в открытом коде.

Интеграция занимает от нескольких часов: установка агентов и настройка по документации. Поддерживаются стандартные протоколы RADIUS, LDAP, SAML, OpenID Connect/OAuth, что позволяет встроить решение в большинство инфраструктур — файрволы (Check Point, Cisco, UserGate), облачные платформы (VMware, Huawei Cloud), VDI (Citrix, VMware Horizon), RDP/SSH, а также в приложения вроде G Suite, Salesforce и Slack.

Совместимость охватывает Windows (включая Outlook Web Access, Remote Desktop Gateway), Linux (SSH, PAM-модули, sudo), а также российские дистрибутивы (ALT Linux, Astra Linux, РЕД ОС). MULTIFACTOR внесён в реестр отечественного ПО, имеет лицензию ФСТЭК и может использоваться в проектах импортозамещения.

Методы аутентификации:

• мобильное приложение (iOS/Android) с push-уведомлениями и QR-регистрацией;
• Telegram-бот;
• SMS и телефонные звонки;
• OTP-токены (аппаратные и программные, включая Rutoken и ЯКлюч);
• U2F/FIDO-ключи;
• биометрия (Face ID, отпечаток пальца) — при этом приватные ключи остаются на устройстве.

Политики доступа можно задавать так: по IP-диапазону, времени суток, дню недели или группам пользователей. Внедрён единый вход (SSO), портал самообслуживания для настройки 2FA и сброса паролей, а также журнал событий с алертами на подозрительные попытки входа.

Для разработчиков предусмотрен REST API — регистрация пользователей, вызовы на аутентификацию, интеграция MFA в сторонние продукты. Это позволяет адаптировать систему под SaaS-сценарии и корпоративные приложения.

Кейс MULTIFACTOR демонстрирует, как можно построить MFA с поддержкой разных факторов, протоколов и сценариев использования в российском контексте. Перед внедрением важно протестировать совместимость с инфраструктурой и оценить удобство для сотрудников — от этого зависит реальная эффективность защиты.

Рекомендации по выбору и внедрению MFA

При внедрении MFA оценивайте совместимость с вашей инфраструктурой, удобство для пользователей и стоимость владения. Начните с анализа рисков: определите критичные ресурсы (серверы, облачные приложения) и протестируйте решение в пилотном режиме. Обратите внимание на поддержку биометрии и токенов для сценариев с высокой безопасностью, а также на инструменты аудита для оперативного реагирования на инциденты.

MFA — не панацея, но в сочетании с Zero Trust и SSO значительно повышает устойчивость к атакам. Выбирайте системы с гибкими политиками и открытой документацией, чтобы минимизировать зависимость от вендора и облегчить масштабирование.

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

Больше новостей — в нашем тг-канале «Представляешь»

Проект реализуется компанией ADA Space в сотрудничестве с Zhijiang Laboratory и Neijang High-Tech Zone.

Технические характеристики

Каждый из запущенных спутников оснащен ИИ-моделью с 8 млрд параметров и способен выполнять до 744 тераопераций в секунду (TOPS). В совокупности эти 12 спутников могут достигать производительности до 5 петаопераций в секунду (POPS), что в десятки раз превышает возможности современных ИИ-платформ, таких как Microsoft Copilot (около 40 TOPS).

В перспективе, сеть из 2800 спутников должна выйти на уровень 1000 POPS, что сделает ее одним из самых мощных суперкомпьютеров в мире.

Как это работает

Спутники объединены в так называемую «Трехтельную вычислительную сеть» (Three-Body Computing Constellation) и обмениваются данными со скоростью до 100 Гбит/с с помощью лазерных каналов. Суммарный объем их внутренней памяти достигает 30 ТБ.

Такие скорости обмена и вычислительные мощности позволяют обрабатывать данные непосредственно на орбите, что снижает задержки и уменьшает нагрузку на наземные станции.

Применение технологии

Первые 12 спутников уже несут научное оборудование, включая детекторы рентгеновской поляризации для регистрации кратковременных космических явлений, таких как гамма-всплески.

Кроме того, спутники способны создавать трехмерные цифровые двойники Земли для применения в экстренном реагировании, геймдизайне и туризме.

Преимущества космического суперкомпьютера

По данным South China Morning Post, создание космического суперкомпьютера позволяет значительно сократить время обработки данных, т.к менее 10% информации, собранной спутниками, обычно передается на Землю из-за ограниченной пропускной способности и недостатка наземных станций.

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

Для поколения Z и альфа дискеты, кассеты и CD — такая же архаика, как патефон для миллениалов. Но именно эти носители стали мостом между эпохой аналоговых технологий и цифровой революцией. Некоторые до сих пор помнят скрежет модема, загружающего игру с аудиокассеты, или волнение при записи первого CD — этот ритуал требовал идеального буфера в Nero и молитв, чтобы электричество не отключили в процессе.

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

Носители информации: эволюция

Сегодня данные окружают нас, как воздух — невидимые, но жизненно важные. В наших смартфонах — навигаторы, приложения для заказа еды, интернет-банкинг, весь Лев Толстой в текстовом или аудиоформате. Фотографии автоматически загружаются в облако, рабочие документы синхронизируются между устройствами, а музыка и фильмы доступны по первому требованию без необходимости записывать что-либо на пленку или вставлять диск в дисковод.

Мы живем в эпоху, когда информация стала нематериальной, а ее хранение — виртуальной услугой, за которую ежемесячно платят подпиской. При этом цена за удовольствия, информацию и духовную пищу (музыка, кино, книги и т.д.) несоизмеримо ниже, чем несколько десятилетий назад.

Но так было не всегда. Было время, когда никто не доверял интернет-хранилищам — да их и не было в том виде, к которому мы сегодня привыкли. Важные файлы хранили на чем-то осязаемом — дискетах, дисках, пленках. Данные были привязаны к физическим объектам, которые можно было потерять, сломать или случайно очистить.

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

Первые носители информации были аналоговыми и требовали физического контакта. Бумага, перфокарты, магнитная лента — все это работало по принципу «записал один раз и следи, чтобы не испортилось». Но с появлением продвинутой техники понадобилось что-то более гибкое, что позволило бы не только хранить, но и быстро перезаписывать данные. Так началась эра магнитных носителей.

Магнитные кассеты использовались не только для записи и воспроизведения музыки, но и стали первым массовым способом хранения цифровой информации для домашних компьютеров. Пользователи писали на пленку игры типа Pacman или Dizzy, а также прикладные программы для компьютеров АТМ Турбо и Spectrum.

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

Затем пришли дискеты, и мир узнал, что такое «портативность» в цифровом смысле. Если кассеты были еще слегка похожи на предыдущее поколение (массивные бобины), то флоппи-диски уже вполне выглядели как технология из будущего. Первые модели хранили жалкие 80 КБ, но к 1980-м емкость выросла до 1.44 МБ — достаточно для текстовых документов и простейших программ. Правда, надежность оставляла желать лучшего: магнитные диски боялись пыли, влаги и просто времени.

Оптические носители, такие как CD и DVD, стали следующим шагом. Они предлагали куда больший объем (от 700 МБ до 4.7 ГБ) и теоретически — вечное хранение данных. Правда, на практике царапины, солнечный свет и некачественные болванки приводили к быстрому обнулению файлов. Но главный минус — эти диски нельзя было просто так перезаписать. CD-RW и DVD-RW решили проблему, но их распространение было медленным: люди уже начали привыкать к тому, что данные можно копировать бесконечно.

Конец XX века принес еще несколько любопытных форматов вроде ZIP-дисков, которые пытались заменить флоппи, но проиграли войну, поскольку оказались слишком дорогими и неудобными.

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

Как хранили и передавали информацию до флешек и облаков

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

Аудио и видеокассеты: не забудьте перемотать на начало

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

Магнитная лента появилась задолго до кассет — первые бобинные магнитофоны использовались еще в 1940-х, но они были громоздкими и дорогими. Все изменилось в 1963 году, когда компания Philips представила компакт-кассету — небольшой, удобный и, что важно, дешевый формат. В отличие от винила, кассеты можно было записывать повторно, носить с собой и даже ронять без катастрофических последствий.

К 80-м годам кассеты стали основным способом слушать музыку. Их продажи в США достигли пика в 442 миллиона штук в 1990 году, но затем началось стремительное падение — CD-диски предлагали лучшее качество звука и отсутствие изматывающей перемотки. Однако кассеты не исчезли полностью: даже в 2012 году в Штатах продали 13 миллионов штук, в основном благодаря автолюбителям, чьи старые машины были оборудованы кассетными магнитолами. В России формат держался примерно до середины 2000-х, после чего кассеты почти исчезли из обихода.

Пока аудиокассеты правили балом в музыке, VHS делал то же самое с видео. Этот формат, появившийся в 1970-х, быстро вытеснил конкурентов (например, Betamax от Sony) благодаря простоте и доступности. Видеомагнитофон стал почти обязательным устройством в каждом доме, а прокат кассет — целой индустрией.

Но у VHS были свои причуды:

• Длинный фильм на двухчасовой кассете мог закончиться в самый напряженный момент, заставляя зрителя в недоумении хлопать глазами.
• Качество изображения ухудшалось с каждой перезаписью, превращая картинку, над которой так трудилась съемочная группа, в движения размытых или крупнозернистых силуэтов.
• Размагничивание, скручивание ленты и вечная борьба со «снегом» и полосами на экране — все было неотъемлемой частью пользовательского опыта.

Несмотря на это, VHS формат продержался до начала 2000-х, пока его не вытеснили DVD, а затем и стриминговые сервисы.

Магнитная лента использовалась не только для музыки и фильмов — в 1980-х она стала первым массовым носителем данных для домашних компьютеров. Владельцы ZX Spectrum и Commodore 64 загружали программы с аудиокассет, подключив магнитофон к компьютеру. Процесс напоминал шаманский ритуал: нужно было выставить правильный уровень громкости, надеяться, что маг не зажует ленту, и ждать несколько минут, пока игра загрузится (если, конечно, в середине не возникала ошибка, заставляющая начинать все сначала).

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

Казалось бы, эпоха магнитной ленты бесповоротно миновала, но это не совсем так. В дата-центрах до сих пор используют ленточные библиотеки (например, LTO), потому что они дешевы, энергоэффективны и отлично подходят для долгосрочного хранения больших объемов данных. Современные картриджи LTO-9 вмещают до 45 ТБ информации — это в тысячи раз больше, чем могла предложить кассета 1980-х.

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

Флоппи-диски (дискеты): 1,4 Мб славы

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

Флоппи-диски, или просто дискеты, стали символом компьютерной революции 1980-1990-х: они были везде, их боялись потерять, ими обменивались, как сейчас ссылками, и их регулярно проклинали, когда на экране возникало сообщение «Диск не отформатирован».

Первая дискета, представленная IBM в 1971 году, была 8-дюймовой и вмещала смехотворные по современным меркам 80 КБ данных. Она создавалась как альтернатива перфокартам — более надежная и удобная, но по-прежнему громоздкая. К середине 1980-х индустрия перешла на 5,25-дюймовые гибкие диски, а затем и на 3,5-дюймовые, которые стали стандартом. Последние, кстати, были не такими уж «гибкими» — прочный пластиковый корпус защищал магнитный диск внутри, хотя слово «флоппи» (от английского floppy — «гибкий») так и осталось в названии.

Объем памяти рос медленно: если в 1984 году дискета на 3,5 дюйма хранила 720 КБ, то к 1987-му — уже 1,44 МБ. Этого хватало для текстовых документов, простых программ и даже некоторых игр. Microsoft Word 2.0, выпущенный в 1991 году, умещался на одной дискете, а его современный аналог требует около 4 ГБ — в 3000 раз больше.

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

Еще одна проблема — ограниченный срок жизни. Даже идеально хранимая дискета могла потерять данные через 5-10 лет из-за размагничивания. Архивы на флоппи требовали регулярного перезаписывания, что превращало хранение информации в постоянную головную боль.

В 1980-х развернулась настоящая битва форматов. Компания Apple сделала ставку на 3,5-дюймовые дискеты, в то время как IBM и другие производители первое время держались за 5,25 дюймов. Победил, как известно, меньший размер — отчасти благодаря тому, что новые носители были прочнее и компактнее.

Любопытно, что следы дискетной эпохи до сих пор встречаются в цифровом мире. Буква «A:\» в Windows, которая изначально обозначала дисковод, осталась в системе как дань традиции. Иконка «Сохранить» во многих программах до сих пор изображает флоппи-диск, хотя большинство современных пользователей и в руках-то его никогда не держали.

К началу 2000-х дискеты начали стремительно исчезать. В 2011 году компания Sony, последний крупный производитель, прекратила их выпуск. Но, как это часто бывает, технология не умерла полностью.

Оказалось, что множество промышленных станков, медицинского оборудования и даже некоторых банковских систем до сих пор используют флоппи-диски. В 2018 году выяснилось, что американские ядерные силы все еще управляются с помощью 8-дюймовых дискет (хотя позже систему все же модернизировали).

На вторичном рынке дискеты до сих пор в ходу. Предприниматель Том Перски в 2010 году скупил около миллиона 3,5-дюймовых флоппи и создал целый бизнес по их продаже. Основные клиенты — владельцы старого промышленного оборудования, для которого переход на современные носители оказался слишком дорогим.

Флоппи-диски — это не просто архаичный способ хранения данных. Они были важным этапом в эволюции персональных компьютеров, сделавшим информацию по-настоящему мобильной. Сегодня, когда мы можем переносить терабайты данных в кармане, стоит вспомнить, с чего все начиналось — с хрупких квадратиков, которые нужно было беречь от магнитов и всегда переворачивать правильной стороной.

Сиди и Дивиди: эпоха лазерного ренессанса

В конце 1990-х дискеты уже выглядели архаично, а облачных хранилищ еще не существовало. На сцену вышли оптические диски — сначала скромные CD на 700 МБ, после — DVD на 4,7 ГБ, а затем и Blu-ray с их 50 ГБ. В определенный период записать фильм на болванку считалось технологическим подвигом. Нужно было также красиво написать название на внешней стороне специальным маркером.

Изначально компакт-диски создавались для музыки — первый коммерческий CD выпустили в 1982 году с записью альбома ABBA «The Visitors». Объем в 650 МБ (74 минуты аудио) выбрали не случайно: разработчики из Sony и Philips хотели, чтобы на один диск целиком поместилась Девятая симфония Бетховена. К концу восьмидесятых большинство звукозаписывающих компаний перешли на CD-формат.

Когда технологию адаптировали для компьютеров (CD-ROM), эти же 700 МБ стали стандартом для софта, игр и даже операционных систем, например, Windows 95.

Запись CD представляла собой сложную процедуру . Программа Nero Burning ROM с ее интерфейсом, напоминающим кабину пилота, требовала идеально настроенного буфера записи. Ошибка «Buffer underrun» означала, что диск испорчен, а 30-50 рублей за болванку (по меркам 2000-х — немалая сумма) летели в мусорку.

Когда в 1996 году появились DVD, их емкость в 4,7 ГБ казалась фантастической. Почему не 5? Все просто: инженеры Sony и Philips изначально планировали 5 ГБ, но пришлось пожертвовать частью объема ради совместимости с форматом CD. Впрочем, даже 4,7 ГБ хватало для фильмов в приличном качестве — пиратские копии расходились быстрее, чем студии успевали считать убытки.

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

В середине 2000-х разгорелась война форматов высокой четкости: Blu-ray от Sony и HD DVD от Toshiba. Технически Blu-ray был лучше — большая емкость (50 ГБ против 30 ГБ у HD DVD), но исход противостояния решил не этот фактор. Sony, которая владела киностудией Columbia Pictures, обеспечила Blu-ray эксклюзивными релизами. А когда за синий формат неожиданно выступила индустрия фильмов для взрослых (на тот момент — один из главных драйверов продаж любых носителей), судьба HD DVD была предрешена.

К 2010-м оптические диски начали сдавать позиции. Скорость интернета росла, стриминговые сервисы набирали популярность, а производители ноутбуков массово отказывались от дисководов. Последний гвоздь в крышку гроба забила Apple, выпустив в 2012 году MacBook Pro без CD-привода — тогда это казалось смелым шагом, а сегодня воспринимается как норма.

Но диски не исчезли полностью. Blu-ray до сих пор используют для фильмов в 4К, а некоторые госструктуры предпочитают архивные DVD — они дешевы и, в отличие от флешек, не подвержены спонтанному размагничиванию. Да и любители ретро-техники продолжают охотиться за редкими релизами игр на CD — например, оригинальная Half-Life на диске сегодня стоит дороже, чем в Steam.

Оптические диски стали переходным звеном между эрой физических носителей и современным цифровым миром. Они научили нас терпению (установка игры была ответственным мероприятием), бережливости (царапина на диске означала существенные финансовые потери) и даже стратегическому мышлению (когда приходилось решать, что удалить с жесткого диска ради места под новый фильм). Сегодня, когда любой контент доступен по клику, эти ритуалы кажутся странными — но именно они сделали нас теми пользователями, которыми мы стали.

Почему все это исчезло

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

Три причины краха:

• Первая и главная — объем. В 1990-х 1,44 МБ дискеты хватало для текстовых документов, но уже к началу 2000-х этого было недостаточно даже для одной MP3-песни. CD на 700 МБ казались спасением, но и они быстро устарели, когда размеры софта перевалили за гигабайты. Современные игры и видеофайлы просто не поместились бы на десятках дисков, которые пришлось бы таскать с собой.
• Вторая причина — скорость. Загрузка программы с кассеты занимала минуты, запись DVD — десятки минут, а копирование файлов с дискеты напоминало медитацию. Когда на смену пришли USB-накопители с их мгновенным доступом к данным, терпеть эти задержки стало невозможно.
• Наконец, надежность. Магнитные ленты размагничивались, дискеты боялись кофе и магнитов, а царапины на CD превращали их в елочные украшения. Потерять данные было проще, чем сохранить — особенно если учесть, что резервные копии требовали такого же ненадежного носителя.

Некоторые архаичные носители до сих пор используются там, где важнее стабильность, а не прогресс. В авиации, например, часть бортовых систем Boeing 747 до недавнего времени обновлялась через 3,5-дюймовые дискеты — потому что проверенная временем технология надежнее экспериментальных решений.

Промышленные станки, медицинское оборудование и даже банковские системы иногда работают на технологиях 1980-х просто потому, что их модернизация стоит дороже, чем покупка партии старых дискет на eBay. А энтузиасты ретро-компьютеров сознательно используют кассеты и флоппи-диски — для них это не просто носители, а часть культурного кода.

Что мы потеряли и что приобрели

Физические носители учили нас ценить данные. Когда файл нельзя было скопировать в два клика, а каждый мегабайт занимал место, люди тщательнее подходили к хранению информации. Переписка кассет требовала времени, коллекцию CD бережно держали на книжных полках, стирая пыль с футляров, а игры на 10 дискетах устанавливали с замиранием сердца — вдруг последняя окажется битой.

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

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

Флешки, SD-карты и облака: вы находитесь здесь — что дальше

Флешки, которые еще недавно казались чудом технологий, уже выглядят архаично на фоне облачных хранилищ. SD-карты, вмещающие терабайты информации, размером не больше ногтя на мизинце. Но что дальше?

Твердотельные накопители, основанные на кремниевых чипах, приближаются к физическим пределам. Производители научились упаковывать данные невероятно плотно — современные 3D NAND-чипы содержат до 200 слоев памяти. Однако закон Мура (формулирующий неизбежность технологического прогресса) хотя и универсален, имеет определенные физические ограничения: стоимость новых фабрик по производству микросхем измеряется десятками миллиардов долларов.

Параллельно растет спрос на хранение информации: только за 2023 год человечество создало больше данных, чем за всю предыдущую историю. Архивы научных исследований, нейросетевые модели, медицинские записи — все это требует новых решений.

Будущее, которое уже тестируют в лабораториях:

• ДНК-хранилища. В 2017 году гарвардские ученые записали на ДНК кишечной палочки GIF-анимацию и изображение. Технология CRISPR позволяет редактировать геном, превращая его в биологический жесткий диск. Пока процесс дорогой и медленный, но потенциал огромен: один грамм ДНК может хранить 215 петабайт данных — эквивалент 14 тысяч современных SSD.
• Молекулярные диски. Исследователи из Университета Брауна (Провиденс, США) создали прототип накопителя, где информация кодируется органическими молекулами. Метод напоминает древние глиняные таблички, только вместо клинописи — бинарный код из присутствия или отсутствия конкретных молекул.
• Кварцевые кристаллы. Технология «5D-памяти» использует фемтосекундные лазеры для записи данных в кварцевое стекло. Такие носители выдерживают температуру до 1000°C и могут хранить информацию миллиарды лет. В 2018 году Илон Маск отправил в космос Tesla с кварцевым диском, содержащим трилогию А. Азимова «Основание».
• Арктические архивы. На Шпицбергене уже работает «Арктический мировой архив», где данные хранятся на специальной пленке в стальных контейнерах. Туда поместили исходники GitHub, цифровое искусство и даже конституции некоторых стран — на случай глобальной катастрофы.

Парадоксально, но будущее может вернуть нас к чему-то очень древнему: подобно тому, как египтяне высекали иероглифы в камне, мы будем записывать информацию в молекулы и кристаллы — носители, которые переживут не только нас, но и предположительно саму человеческую цивилизацию.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Как работает database sharding

Database sharding (шардирование базы данных) — это техника горизонтального масштабирования, при которой большая база разделяется на несколько частей. Их называют шардами. Эти шарды распределяются по другим серверам и связываются в одну систему. Рассмотрим подробнее.

Принцип: разбиение данных на независимые сегменты (шарды)

Каждый шард работает как отдельная независимая база данных. Ключевым элементом здесь выступает ключ шардирования (shard key). Это правила, которые определяют, в какой именно шард попадёт конкретная строка данных.

Например, мы можем задать правило: если у нас есть user_id и его значение меньше тысячи, то данные попадают в шард 1, если значение больше тысячи, то в шард 2.

Главная цель такого разделения — добиться независимости шардов. В идеале запрос, касающийся данных одного пользователя (или одного документа, заказа и т. д.), должен обрабатываться только одним шардом.

Так, мы можем параллельно обрабатывать много запросов и увеличивать пропускную способность системы.

Общая архитектура: клиент — роутер — шард

Чтобы приложение могло понять, в какой шард отправить запрос, нужна особая архитектура.

Клиент: Программа на стороне пользователя, которая отправляет стандартный запрос к базе данных (например, SELECT * FROM users WHERE user_id = 123).

Маршрутизатор запросов или роутер (Query Router): Это что-то вроде посредника между клиентом и шардом, который выполняет роль диспетчера. Он принимает запрос, при помощи sharding ключа определяет, что это за данные, в какой шард и с какой целью их надо отправить. Далее он отправляет запрос на нужный шард.

Шард (Shard): Получает запрос, выполняет и возвращает результат обратно маршрутизатору, который затем передаёт его клиенту.

Благодаря такой архитектуре мы можем «скрыть» database sharding на стороне клиента и обеспечить централизованное управление запросами. Не надо сильно заморачиваться с кодом и архитектурой приложений, ведь вся логика будет на серверах.

Основные компоненты: шард, маршрутизатор, реплика-сеты

Мы уже рассмотрели, что такое шарды и маршрутизаторы, теперь обратим внимание на реплика-сеты. Это сервера с копией данных шардов. Если главный сервер шарда выходит из строя, одна из реплик автоматически берёт на себя его роль. Так, мы можем повысить отказоустойчивость нашей системы.

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

Виды шардинга

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

Горизонтальный sharding (по строкам): самый популярный

При горизонтальном шардинге мы «нарезаем» нашу базу данных по строкам. Допустим, у нас таблица с клиентами. Мы задаём диапазон ключу шардирования с user_id от 1 до 1 000 000. Данные в этом диапазоне, построчно будут храниться в шадре 1. Если user_id попадает в диапазон от 1 000 001 до 2 000 000, то эти данные отправляем на шадр 2. И так далее.

Благодаря этому способу мы можем равномерно распределять данные, и нам будет проще масштабировать систему при помощи создания новых шадров и добавления серверов.

Горизонтальный sharding — идеальный вариант, когда основная проблема — это огромное количество строк в таблицах и высокая нагрузка на чтение/запись.

Вертикальный шардинг (по столбцам): разделение по функциональности

Если горизонтальный шардинг режет таблицу поперёк (по строкам), то вертикальный — вдоль, разделяя столбцы. Таблица делится на несколько с меньшим количеством столбцов. Обычно они группируются по частоте использования или по смысловой нагрузке. Например, в таблице юзеров можно выделить часто запрашиваемые user_id, username, email в одну таблицу, а редко используемые — biography, preferences, last_login_details — в другую.

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

Directory-based sharding: использование хеш-таблицы маршрутов

При горизонтальном и вертикальном шардинге маршрутизатор часто сам, при помощи специальных функций, определяет, какие данные в какой шадр отправить. Это не всегда удобно. При таком подходе мало гибкости. Поэтому был придуман вид шардинга, который опирается на хеш-таблицы и называется directory-based. Его суть в том, что мы создаём централизованный каталог, который связывает наши ключи шардирования и шарды.

Вот пример того, как это работает:

• Клиентское приложение отправляет запрос (например, получить данные для order_id = 98765).
• Маршрутизатор запросов перехватывает его.
• Маршрутизатор обращается к каталогу: с запросом, где найти order_id = 98765.
• Каталог ищет в своей таблице соответствий правило, под которое подпадает order_id = 98765. Для быстрого поиска он часто использует эффективные структуры данных, такие как хеш-таблицы или B-деревья (это внутренняя деталь реализации самого каталога).
• Допустим, каталог находит правило «Диапазон order_id 90000-99999 → Shard-3» и сообщает это маршрутизатору.
• Маршрутизатор перенаправляет исходный запрос на Shard-3.

При таком подходе удобнее перемещать данные между шардами, изолировать их и менять логику.

Range-based sharding: разбиение по диапазонам значений

По сути, это тот же горизонтальный sharding с разбиением данных на кусочки по строкам при помощи диапазонов.

Администратор системы (или автоматизированный инструмент) определяет границы диапазонов для ключа шардинга. Маршрутизатор получает запрос, смотрит на значение этого ключа и сравнивает его с известными диапазонами, чтобы определить целевой шард.

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

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Когда пользователи начнут регистрироваться, у нас будет активен шард 1, потом шард 2. Далее вся нагрузка перейдёт на шард 3. Они не будут одновременно равномерно работать. Это может стать проблемой при оптимизации.

Hash-based sharding: равномерное распределение по хешу ключа

Этот подход помогает добиться максимально равномерного распределения нагрузки по всем шардам. Работает следующим образом:

Берём значение ключа для конкретной строки данных (например, user_id = 2001).

Применяем к нему хеш-функцию. Хеш-функция (например, MD5, SHA-1, MurmurHash) — это алгоритм, который превращает входные данные (наш user_id) в строку или число фиксированной длины (хэш), которое выглядит почти случайно. Даже небольшое изменение на входе (например, user_id = 2001 и user_id = 2002) обычно даёт совершенно разные хеши.

Вычисляем номер шарда. Чаще всего делим значение хеша на количество шардов и берём остаток от деления. Например, 548291 % 3 = 2. Далее в зависимости от остатка распределяем данные по шардам. Значение с остатком 2 пойдёт в шард 2, если остаток 1, то в шард 1 и так далее.

Так мы получаем более равномерное распределение данных. Но из минусов — в такой базе сложно обрабатывать диапазоны и добавлять новые шарды в систему.

Примеры реализации

MongoDB: встроенная поддержка шардинга

MongoDB — это NoSQL база данных, которая была разработана с закосом на горизонтальное масштабирование. То есть она адаптирована к тому, чтобы работать на нескольких серверах и расширять это число по мере необходимости. Поэтому sharding здесь доступен из коробки, нам не надо заморачиваться со внешними расширениями.

Рассмотрим пример, как настроить sharding и работать с ним:

• sh.addShard() — добавляем сервер в кластер как шард. MongoDB понимает, что может использовать этот сервер для хранения части данных.
• use socialApp; sh.enableSharding("socialApp") — переключаемся на базу данных «socialApp». При помощи команды sh.enableSharding() разрешаем шардинг в этой БД.
• sh.shardCollection("socialApp.users", { "user_id": 1 }) — применяем sharding к коллекции users. Мы указываем полное имя коллекции (socialApp.users) и ключ шарда ({ "user_id": 1 }). Цифра 1 означает, что мы используем шардинг по диапазонам. Эти диапазоны не нужно задавать вручную, MongoDB определяет их самостоятельно.
• db.users.insertMany([...]) — вставляем данные в коллекцию users. MongoDB автоматически определяет, на какой шард поместить каждого пользователя.
• db.users.findOne({ user_id: 1 }) — запрашиваем данные пользователя user_id = 1. Mongos сам определит, на каком шарде они находятся.

PostgreSQL + Citus

В PostgreSQL нет поддержки встроенного шардинга, поэтому приходится устанавливать на сервер Citus. Это популярное расширение, которое как раз добавляет возможности горизонтального масштабирования и шардинга. Оно превращает кластер стандартных серверов PostgreSQL в распределённую базу данных.

Посмотрим на пример использования SQL-команд для настройки шардинга с помощью Citus:

• CREATE EXTENSION citus; — активируем Citus в текущей базе данных.
• CREATE TABLE app_logs (...) — создаём таблицу app_logs на узле-координаторе точно так же, как создали бы обычную таблицу в PostgreSQL.
• SELECT create_distributed_table('app_logs', 'service_name'); — при помощи этой команды включаем sharding. Citus понимает, что таблицу app_logs нужно распределить по рабочим узлам, используя поле service_name как ключ шардинга. Citus по умолчанию применяет Hash-based sharding, то есть, равномерно распределяет по шардам при помощи хеш-функций.
• INSERT INTO app_logs — добавляем данные логов. Citus перехватывает запрос, вычисляет хеш от значения service_name для каждой строки и распределяет данные по шардам.
• SELECT ... FROM app_logs — запрашиваем данные. Если фильтруем по service_name (как в первом SELECT), Citus направит запрос на нужный шард.

MySQL + Vitess

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

Vitess вместо прямых команд для шардинга определяет его правила в отдельном JSON-файле, который называется VSchema (Vitess Schema).

Допустим, у нас есть база данных commerce. Вот как она выглядит в виде кода:

А вот так она выглядит в виде таблицы:

В базе данных есть таблица orders, её мы и хотим шардировать по customer_id при помощи хеширования (hash-based sharding).

Файл VSchema (vschema.json) может выглядеть примерно так:

• "sharded": true — указываем, что база данных шардирована.
• "vindexes" — определяем hash_index типа hash, который будет использовать хеш-функцию для распределения.
• "tables" — описываются правила для конкретных таблиц.
• "orders" — настраиваем таблицу orders.
• "column_vindexes" — определяем, какой столбец является ключом ("column": "customer_id") и какой vindex ("name": "hash_customer_id") использовать для него.

Проблемы шардирования

Перераспределение шардов (resharding)

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

При решардинге часто приходится перегонять большие объёмы данных между серверами. Если используется хеш-шардинг, и мы меняем количество шардов, то пересчитываются ключи, по которым распределяются данные.

Например, раньше у нас было 4 шарда. Мы брали user_id, например 9, делили на 4 и получали остаток — 1. Значит, данные шли на шард номер 1. После масштабирования стало 5 шардов, и 9 % 5 = 4 — теперь те же данные должны храниться на шардe 4.

Такое перемещение затратно по ресурсам: грузит сеть, диски, может занять часы или даже дни. Иногда для этого приходится останавливать запись, что делает процесс ещё рискованнее.

Неравномерная нагрузка (hot shards)

Вспомним вид шардирования Range-based sharding. Это когда мы разбиваем данные по диапазонам. У нас был пример выше с форумом и шардингом user_id:

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Мы столкнулись с проблемой, что шард 1 и шард 2 после завершения диапазонов простаивали, а вся новая нагрузка приходилась на шард 3.

Такую проблему называют горячим шардом (hot shards). Производительность всей системы начинает зависеть от самого загруженного шарда. Преимущества шардирования снижаются.

Чтобы этого избежать, приходится либо более въедливо продумывать ключи шардирования, либо вручную разделять слишком нагруженный шард.

Сложности с глобальными транзакциями и агрегациями

Допустим, нужно перевести деньги со счёта А на счёт Б — операция состоит из двух шагов: списание и зачисление. Транзакция позволяет объединить их в единое целое: либо всё выполнится, либо ничего. Это защищает от потери данных и ошибок. В классических базах данных за это отвечают принципы ACID — они гарантируют надёжность в пределах одного сервера.

Но если счёт А находится на одном шарде, а счёт Б — на другом, стандартная транзакция не сработает. Между независимыми серверами нельзя просто так обеспечить ACID-гарантии. Для этого нужны сложные и медленные механизмы координации, например двухфазный коммит (2PC). Либо приходится идти на компромисс и использовать eventual consistency — когда данные приходят в согласованное состояние с небольшой задержкой. Например, деньги уже списались, но ещё не зачислились.

Аналогичная проблема и с агрегациями: посчитать сумму продаж или число пользователей уже не получится одной SQL-командой. Каждый шард сначала считает свою часть, а потом результат нужно собрать и объединить — это требует дополнительной координации и может усложниться при фильтрации или группировках.

Сложность управления и мониторинга

Шардированный кластер — это распределённая система, управлять которой сложнее, чем одним сервером.

Больше компонентов: Вместо одной базы данных появляется множество шардов (часто с репликами), маршрутизаторы запросов, серверы конфигурации. Всё это нужно настраивать, обновлять и обслуживать.

Мониторинг: Требуется отслеживать состояние каждого шарда, равномерность распределения нагрузки, задержки в сети, работу маршрутизаторов. Нужны более сложные инструменты мониторинга.

Отладка: Найти источник проблемы в распределённой системе сложнее. Ошибка может быть где угодно: в приложении, маршрутизаторе, на одном из шардов или в сети.

Резервное копирование: Создание согласованных резервных копий и восстановление данных со множеством независимых шардов требует более сложных процедур.

Когда стоит применять Sharding

Рост объёма данных и нагрузок

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

Иногда серверу приходится одновременно читать и записывать слишком много запросов. Система становится перегруженной, пользователи замечают задержки и нестабильную работу. Здесь тоже поможет sharding.

Не справляется один сервер/реплика

Допустим, у нас один сервер и он не справляется с запросами и большими данными. Конечно, мы можем заняться вертикальным масштабированием, поставить CPU производительнее, добавить больше ОЗУ и так далее. Однако у этого подхода есть ограничения. Во-первых, каким бы мощным ни был бы сервер, он со временем упрётся в потолок своей производительности. Во-вторых, иногда дешевле купить несколько новых серверов помощнее, чем прокачивать старый. Поэтому создание кластера и распределение в нём нагрузки при помощи шардинга — часто более выигрышное решение, чем один сервер.

Потребность в геораспределённости или отказоустойчивости

Если пользователи находятся в разных частях света, то деление данных и хранение ближе к ним может ускорить работу приложения. Мы можем при помощи шардинга размещать данные в разных дата-центрах, ближе к определённым группам пользователей. Например, так делает Youtube. Компания размещает свои сервера в разных странах, чтобы видео прогружались быстрее и в более высоком качестве.

Мы можем хранить все данные и обрабатывать запросы на одном сервере и сделать его реплику с копией данных. Если этот сервер падает, то его заменяет реплика. Но что, если эта реплика тоже упадёт? Тогда нам и помогает sharding с репликацией. В случае сбоев отвалятся только отдельные серверы с некоторыми наборами данных. Конечно, здесь тоже, в теории, можно положить весь кластер, включая реплики, но сделать это сложнее.

Шардирование — полезный инструмент при работе с СУБД. А узнать про большее число подобных инструментов можно в нашем телеграм канале!

Больше новостей — в нашем тг-канале «Представляешь»

Оно позволяет делить ресурсы одного физического GPU между несколькими виртуальными машинами без значительных потерь производительности.

Зачем нужен SR-IOV

Технология SR-IOV (Single Root I/O Virtualization) используется для разделения ресурсов устройств ввода-вывода между виртуальными машинами. Вместо классической эмуляции или проброса устройств, SR-IOV позволяет выделять каждой машине отдельную виртуальную функцию, напрямую связанную с физическим устройством.

В случае с видеокартами — это означает доступ к «настоящему» GPU с минимальной прослойкой, что критично для задач, где важна производительность: ML, HPC, визуализация.

Что умеет GIM

Драйвер GIM написан на C и распространяется под лицензией MIT. Готовые пакеты уже доступны для Ubuntu 22.04.

Сейчас модуль поддерживает лишь карты с архитектурой MxGPU — в первую очередь это AMD Instinct MI300X, предназначенные для дата-центров и ИИ-нагрузок.

Возможности модуля:

• Инициализация SR-IOV на GPU
• Управление виртуальными функциями (VF)
• Планирование ресурсов между ВМ
• Выявление зависаний и сброс состояния (FLR)
• Взаимодействие между физическим GPU (PF) и виртуальными функциями

Работает драйвер с гипервизорами на базе KVM.

Планы на будущее

В AMD сообщили, что GIM может быть адаптирован и под обычные дискретные видеокарты.

Это открывает перспективы использования SR-IOV не только в облаках и дата-центрах, но и в рабочих станциях — например, для разделения GPU между контейнерами или разработчиками в одной системе.

По прогнозам, рынок HCI вырастет с $16,7 до $51 млрд к 2030 году — рост в 3 раза всего за 5 лет. Это значит, что компании массово переходят на гиперконвергенцию — иначе не выжить.

В статье расскажем, что такое гиперконвергенция, как этот подход помогает бизнесу оставаться гибким. Рассмотрим на примере возможностей гиперконвергентной платформы vStack HCP — полностью российского решения для виртуализации и управления IT-ресурсами.

Что такое гиперконвергенция и чем она отличается от конвергенции

В конвергенции вычислительные ресурсы и система хранения объединены в единой интегрированной системе, но управляются по-прежнему по отдельности. У каждого компонента — свои интерфейсы, свои администраторы, своя логика. Например, сервер и СХД могут стоять в одной стойке, но управлять ими нужно по-разному.

Гиперконвергенция (HCI) идет дальше: все ресурсы объединяются в программно-определяемую среду. И здесь главную роль играет ПО, которое управляет всеми компонентами.

В основе гиперконвергентной системы лежат серверы, объединенные в кластер. Каждый узел выполняет сразу три роли:

• Обработка вычислений (Software Defined Computing) — серверные мощности - процессоры и оперативная память, которые отвечают за обработку данных. У vStack HCP один из самых низких показателей overhead — 2-5% на виртуализацию, плюс есть возможность ограничить ресурсы vCPU в реальном времени, чтобы повысить производительность.
• Хранение данных (Software Defined Storage) — объединяет дисковые ресурсы серверов, организуя механизмы распределенного хранения. В гиперконвергентной инфраструктуре уже присутствует встроенный программно-определяемый слой хранения, поэтому использование внешней физической СХД изначально не требуется. vStack HCP дополнительно реализует возможность подключения к слою хранения внешних систем (другие платформы виртуализации, отдельные сервера и т.п.) реализуя концепцию Unified Storage.
• Управление сетью (Software Defined Networking) — включает коммутацию, маршрутизацию и коммутацию с внешними системами, чтобы соединение было стабильным между всеми компонентами. vStack HCP поддерживает до 2.5 Mpps на виртуальном порту ВМ (Intel Xeon Scalable 3rd Gen).

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

Гиперконвергенция решает две главные проблемы традиционных дата-центров:

• Сложное управление — в HCI все объединяется, есть единая точка управления и администрирования.
• Низкая эффективность использования ресурсов — в гиперконвергенции ресурсы масштабируются по потребности и используются гибко.

Какие есть преимущества у HCI и почему она выгодна компаниям

Как мы уже говорили, у конвергентных систем есть минусы: высокая стоимость оборудования, сложное масштабирование, а еще нужно содержать штат сотрудников, чтобы они отвечали за различные компоненты такого решения. Гиперконвергенция закрывает эти проблемы. Ниже рассмотрим преимущества такой инфраструктуры подробнее на примере vStack HCP.

Единая система управления

В HCI все аппаратные и программные элементы объединены в одну платформу. Это упрощает управление, снижает сложность администрирования и управления. Например, vStack HCP предлагает единый WEB интерфейс и API для управления и автоматизации работ, а также функции корпоративного уровня, которые делают инфраструктуру более цельной, удобной и управляемой, например:

• Unified Storage — оно позволяет одновременно использовать программно-определяемое хранилище (SDS) как для запуска виртуальных машин, так и для прямого доступа к данным через RDM-диски или внешние приложения.
• Stretched Cluster — кластер, растянутый на две площадки, с избыточностью 2N и отказоустойчивостью на уровне целых площадок. Даже если одна из них упадет, сервисы продолжат работать.

Все работает на стандартном железе — так можно сильно сэкономить на инфраструктуре.

Более того, можно быстро мигрировать с зарубежных платформ, таких как VMware, Microsoft, Nutanix и других. vStack HCP поддерживает форматы OVF/OVA и инструменты миграции (например, MIND Migrat). Также поддерживаются гетерогенные сети, работа с гипервизором, без привязки к конкретному вендору.

Экономичность

Так как используется стандартное серверное оборудование и отсутствуют зависимости от проприетарных решений, стоимость владения падает. В vStack HCP — полностью собственная разработка на базе FreeBSD, без GPL-зависимостей (в отличие от KVM+oVirt/openstack). Это снижает риски, затраты и дает гибкость развития.

Масштабируемость

Ресурсы в HCI можно быстро наращивать под текущие нужды, просто добавляя узлы. vStack HCP поддерживает гибкие варианты резервирования (N+1, N+2, N+3, 2N), а также механизм CPU overcommit — до 900%. Так компания может распределять вычислительные мощности между узлами даже при высокой нагрузке.

Минимум сбоев

Меньше отдельных компонентов — меньше точек отказа. vStack HCP показывает стабильную работу даже под высокой нагрузкой. При этом платформа остаётся высокопроизводительной: например, сетевой порт виртуальной машины способен обрабатывать до 2.5 миллионов пакетов в секунду.

Нет привязки к вендору (vendor lock-in)

HCI полностью определяется программным обеспечением, поэтому не нужно привязываться к конкретному оборудованию. vStack HCP — полностью российское решение. Платформа поддерживает гетерогенные виртуальные сети и позволяет быстро переехать с зарубежных платформ в условиях импортозамещения — VMware, Microsoft, Nutanix и других.

Технические характеристики vStack HCP. Главное, на чем нужно базировать сравнения с другими решениями:

• Большая часть архитектуры лежит внутри решения. Так, у платформы есть свой кластерный фреймворк, слой управления с контроллерами (SDS, SDN, SDC, API) и собственная виртуальная сеть.
• API. vStack HCP — единая платформа с дистрибутивом, который довольно просто установить.
• Эффективная виртуализация. vStack HCP поддерживает создание моментальных снапшотов и клонов виртуальных машин, в том числе с сохранением сетевой конфигурации.
• Сети. Поддержка изолированных и маршрутизируемых сетей и возможность настройки MTU (размеров пакетов), плюс платформа автоматически выдает IP-адреса.
• Хранилище поддерживает самовосстановление, коррекцию ошибок, а также механизмы компрессии и дедупликации данных.
• Миграция с других систем. vStack HCP поддерживает форматы OVF/OVA (для переноса ВМ) и дружит с MIND Migrat (online-миграция со сторонних решений).
• Поддержка нескольких ОС — Linux (Ubuntu/ Debian/ CentOS), Windows Server, FreeBSD, Astra Linux, RedOS, Alt.
• Высокая кастомизация виртуальных машин — возможность не просто создавать виртуальные машины, а уже с определенными сценариями их использования после создания

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

Где применяется гиперконвергентная инфраструктура

HCI-подход применяют в разных сценариях:

• Гибкая и масштабируемая инфраструктура. HCI нужна в компаниях, где часто меняются нагрузки и резко растут потребности в ресурсах.
• Высоконагруженные среды (базы данных и пр.). Подходит для работы с БД и другими приложениями, где важны высокая производительность и надёжность.
• Инфраструктура распределенных филиалов: HCI помогает филиалам и офисам, где нужны локальные вычисления и хранилища, но с централизованным управлением
• Облачная и гибридная инфраструктура. Это оптимальное решение для создания частных или гибридных облаков, которые могут быть как изолированными, так и интегрированными с публичными сервисами.
• Высокая отказоустойчивость и защита данных. Встроенные механизмы репликации, восстановления и распределения нагрузки гарантируют стабильную работу, даже если что-то упадет. Поэтому все критически важные приложения будут в безопасности.
• Экономия при построении инфраструктуры. HCI снижает расходы на оборудование и обслуживание, поскольку объединяет СХД, вычисления и сеть в единую платформу.

Итоги

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

Хочется протестировать — заходите на сайт, попробуйте демо, оставляйте заявку.

Реклама. Рекламодатель: ООО «ВиСтэк РУС», ИНН 7840110259. erid: 2W5zFJVTZvG

В результате разработчики обновили инструмент — теперь он поддерживает до 8192 ядер.

Больше новостей — в нашем тг-канале «Представляешь»

Что за утилита

Turbostat — это консольный инструмент для мониторинга частот, температур, энергопотребления и простоев CPU. Им активно пользуются в дата-центрах и HPC-средах, но попробовать его может любой — достаточно установить соответствующий пакет.

Ранее утилита имела жесткий потолок — не больше 1024 ядер. Но в ядре Linux максимальное количество ядер на систему давно установлено на 8192, так что Turbostat теперь приведён к общему стандарту.

Что за система у HPE

Какой именно сервер тестировала HPE — неизвестно. Есть версия, что использовался Intel Xeon 6900E на 288 ядер в 4-сокетной конфигурации. Есть и другая догадка — что это ранние испытания Diamond Rapids, будущих чипов Intel. Так или иначе, тестовая конфигурация имела 1152 ядра, чего хватило, чтобы обнаружить лимит Turbostat.

Почему это важно

Хотя 8192 ядра звучит как фантастика, серверные и кластерные системы уже приближаются к таким масштабам.

Обновление Turbostat делает инструмент более «продуманным на будущее» и избавляет инженеров от ненужных ограничений при работе с передовыми архитектурами. Новая версия уже доступна и станет частью Linux 6.15.

Главное отличие от существующих решений вроде livepatch — обновляется не кусочек кода, а всё ядро целиком, и при этом никакие устройства не отключаются.

Система уже отправлена на обсуждение в ядро Linux и может изменить то, как админы, разработчики и облачные платформы работают с обновлениями.

Как это работает

LUO построена на базе kexec — механизма, который позволяет загрузить новое ядро прямо из запущенного Linux, без ребута железа. Google расширила его возможностями сохранения и восстановления состояния устройств, включая сетевые интерфейсы, накопители, прерывания и даже операции DMA.

Всё это делается так, чтобы приложения ничего не заметили. Устройства продолжают «жить» и после перезапуска ядра.

Главное — для облаков

Основной сценарий — обновление гипервизора KVM, на котором работают десятки виртуалок. С LUO можно временно заморозить виртуальные машины, перезагрузить ядро с новым гипервизором — и продолжить работу, не теряя подключения устройств и без простоя.

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

Интерфейс и управление

Управление LUO происходит через простые файлы в /sys/kernel/liveupdate/:

• state — показывает статус,
• prepare — готовит систему к переключению,
• finish — завершает обновление.

Весь процесс можно автоматизировать и встроить в CI/CD для инфраструктуры.

Кто может подключиться

Google предусмотрела API для других подсистем — например, гипервизора, драйверов или IOMMU. Они могут подключать свои обработчики, чтобы сохранить состояние и корректно продолжить работу после загрузки нового ядра.

Для передачи состояния между ядрами используется механизм Kexec HandOver (KHO) — уже знакомый тем, кто работает с kexec.

Что это значит

Если LUO примут в основное ядро, обновления Linux станут такими же незаметными, как обновление браузера. Особенно это оценят облачные платформы, хостинги и крупные инфраструктурные проекты, где каждое обновление сейчас — это риск, простои и неудобства.

Почему S3-хранилища популярны

Когда говорят «S3-хранилища», чаще всего имеют в виду не сервис AWS S3, а его аналоги, поддерживающие тот же API. Это как «джип» для внедорожников или «памперсы» для подгузников — ставший нарицательным термин. Например, MinIO и Ceph полностью совместимы с S3-протоколом, но работают в разных инфраструктурах.

S3 — это объектное хранилище. В отличие от традиционных систем, в которых файлы организованы в папках, здесь все проще: есть объект (например, картинка или текстовый документ) и его метаданные (имя, размер, тип содержимого, атрибуты жизненного цикла, URL, дополнительные данные, определенные пользователем). Вместо навигации по вложенным папкам можно быстро находить нужные объекты по уникальному идентификатору. Это упрощает управление данными и ускоряет доступ к информации.

Как все устроено: основные компоненты S3

1. Бакеты и объекты. S3-хранилища организованы в бакеты (аналог корневых папок). Внутри бакета лежат объекты, доступ к которым осуществляется по уникальному ключу.
2. Версионирование. Позволяет восстанавливать старые версии файлов. Это полезно, если случайно перезаписали важные данные.
3. Политики доступа. Контролируются с помощью ACL (списки управления доступом) и IAM-политик. Можно открывать доступ к данным как для отдельных пользователей, так и для групп.
4. Жизненные циклы объектов. Автоматическое управление хранением: можно настроить удаление или перемещение объектов в другое хранилище через определенное время.
5. S3 API. S3 использует REST API, позволяя загружать, скачивать и управлять объектами через стандартные HTTP-запросы.

Основные преимущества S3-хранилищ

• Гибкость. Можно хранить любые типы данных — от логов и резервных копий до видео и ML-моделей. Благодаря отсутствию иерархии легко управлять большими объемами информации без сложных файловых структур.
• Масштабируемость. S3-хранилища способны без ограничений расти вместе с потребностями компании. Можно хранить миллионы объектов без необходимости перераспределять ресурсы. Но важно учитывать ограничения провайдера. Например, в EdgeЦентре одно S3-хранилище может содержать до 1000 бакетов. В каждом бакете можно разместить до 10 млн объектов, для оптимальной работы рекомендуется ограничиться 100 тыс. объектов в одном бакете.
• Отказоустойчивость. Объекты можно реплицировать на несколько узлов или даже в разные географические зоны. Это гарантирует доступность данных даже в случае аппаратных сбоев, выхода из строя одного из дата-центров или сетевых проблем.

Как подключиться к S3-хранилищу: простая инструкция

Чтобы было удобно загружать и скачивать данные, можно использовать специальные инструменты: AWS CLI — командную строку от Amazon или S3cmd — простую утилиту для работы с файлами в S3. Оба инструмента делают одно и то же, выбирайте тот, который будет удобнее.

Подключаем AWS CLI к S3

• Скачайте последнюю версию AWS CLI с сайта Amazon и установите ее.
• Проверьте установку командой:

• Откройте командную строку и настройте подключение:

• Введите:

— Access Key — ключ, полученный при создании хранилища.

— Secret Key — секретный ключ.

— Регион — например, s-dt2.

• Теперь можно работать с файлами.

Подключаем S3cmd к S3

• Откройте командную строку.
• Введите команду настройки:

• Укажите:

— Access Key и Secret Key.

— S3 Endpoint — URL хранилища (например, s-dt2.cloud.edgecore.ru).

• Если все введено верно, появится сообщение об успешном подключении.

Проверить подключение можно командами:

— Для AWS CLI:

— Для S3cmd:

Если в хранилище есть файлы, они появятся в списке. Если оно пустое — команда не выдаст ошибки.

Что делать, чтобы работа с S3-хранилищами была беспроблемной

Минимизируйте публичный доступ. Открытый доступ к бакету может привести к утечке данных. Чтобы контролировать доступ, используйте ACL для назначения прав на файл (например, сделать его общедоступным или закрытым). Политики доступа позволяют настроить более сложные правила, например, ограничить доступ по IP-адресам.

Настраивайте шифрование. Шифрование защищает данные от перехвата. Оно может быть как серверным (SSE), так и клиентским (CSE), когда данные шифруются до отправки, а ключи хранятся у вас.

Используйте версионирование. Оно сохраняет все изменения файлов, позволяя восстановить предыдущие версии, если данные были удалены или изменены.

Оптимизируйте хранение. Перемещайте неактивные данные в более дешевые хранилища, такие как AWS S3 Glacier, чтобы сэкономить. Эти хранилища подходят для архивов и резервных копий, но восстановление может занять несколько часов. Тарифы для «холодного хранения» есть и у других провайдеров.

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

Зачем и как подключить S3-хранилище к CDN

Подключение S3-хранилища к CDN (Content Delivery Network) ускоряет доставку контента пользователям по всему миру. Это достигается за счет того, что CDN размещает кэшированные файлы на серверах, расположенных ближе к конечным пользователям. Такой подход снижает время отклика, уменьшает нагрузку на хранилище и повышает стабильность доступа к контенту.

Как подключить S3 к CDN

1. Создайте ресурс CDN. В разделе CDN вашего облачного провайдера создайте новый ресурс.
2. Выберите настройки для статических файлов. Подойдет для изображений, видео и других неизменяемых данных.
3. Укажите источник файлов. Источником должен быть бакет S3, в котором хранятся ваши файлы.
4. Настройте персональный домен. Без него раздача контента через CDN невозможна.
5. Подтвердите подключение. После завершения настройки CDN начнет кэшировать файлы.

Чтобы получить файлы через CDN, просто используйте ссылку, которая будет выглядеть как адрес вашего домена + путь к файлу. Например, http://cdn.mywebsite.com/photos/image.jpg.

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

Хаос необходимо упорядочить — и тут на помощь приходит As Code. Это не просто методология, а философия, где все — от инфраструктуры до документации и политик безопасности — становится кодом. В этой статье я расскажу, почему подход As Code стал критически важен для современных IT-компаний и как он эволюционировал.

С чего все началось

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure as Code, API First, unit-тесты, компонентное тестирование, TBD (Trunk Based Development), GitOps, Doc As Cod. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояния в другое.

Каждый коммит — шаг в будущее, где код становится не просто текстом, а нитью в живой ткани новой реальности. Число коммитящих — это не просто метрика, это сигнал, что система жива, дышит, развивается. И когда кто-то спрашивает «Зачем?», я отвечаю: «Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. Мы строим мир, где As Code не просто слова, код — наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной».

В момент осознания вопроса я провалился на другой слой реальности, задумался об истории As Code и собрал этот текст из разбросанных по сети слепков. Эта статья — не руководство по Terraform или Kubernetes, а скорее практический взгляд на культуру As Code в масштабах крупной IT-компании.

Эволюция As Code: от истоков до современности

Концепция As Code возникла как ответ на ключевые вызовы IT-индустрии: рост сложности систем и ускорение темпов изменений. Она был естественным продолжением эволюции разработки — код стал не только инструментом создания программ, но и способом управления инфраструктурой, документацией, архитектурой и политиками.

У появления этого подхода было несколько предпосылок:

1. Автоматизация и стандартизация. В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
2. Распространение систем контроля версий. В 2005 году появился Git, который стал инструментом для управления изменениями, что позволило хранить и версионировать не только код, но и документацию, конфигурации и архитектуры.

Корнями As Code уходит в 1970-е годы. Ранние инструменты, такие как Unix “Make” и PXE boot, заложили фундамент для автоматизации конфигураций. Позже они эволюционировали в современные подходы: Infrastructure as Code, Documentation as Code, GitOps и другие. Это подчеркивает, что As Code — не просто тренд, а естественное развитие технологий, которое упрощает управление сложными системами.

Почему все теперь в Git?

С развитием подхода As Code универсальным инструментом управления изменениями стал Git. Это произошло благодаря нескольким ключевым причинам.

• История изменений: Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что делал. Это критически важно для анализа и отката ошибок.
• Коллаборация: над проектом может работать несколько человек, и они не будут мешать друг другу.
• Прозрачность: все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
• Автоматизация: Git интегрируется с CI/CD — Continuous Integration / Continuous Deployment. Это позволяет автоматизировать тестирование, сборку и деплой. Работа в Git позволяет «все иметь под рукой» и упрощает создание систем поддержки и контроль стандартов ИТ-производства.
• Безопасность: Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

Как появился Git?

Git был создан в 2005 году как ответ на кризис в разработке ядра Linux. Ранее команда Linux использовала проприетарную систему контроля версий BitKeeper, но юридические споры лишили программистов этой возможности. Linux-сообщество осталось без инструмента для управления кодом. Существующие системы — например, CVS или Subversion — не подходили для масштабных проектов.

Линус Торвальдс, создатель Linux, решил разработать собственную систему, которая бы отвечала потребностям крупных проектов:

• была быстрой,
• поддерживала распределенную разработку,
• гарантировала сохранность данных (через хеши SHA-1).

Git был создан всего за 10 дней. Первая версия была настолько проста, что Торвальдс называл ее «игрушечной». При этом она уже решала ключевые задачи. Инструмент разработали с акцентом на децентрализацию: каждый разработчик имеет полную копию репозитория, что делает процесс гибким и устойчивым.

Создание Git — прекрасный пример проактивной позиции: если тебя что-то не устраивает, ты сам создаешь инструмент для решения задачи. Реагируешь на боль не нытьем, а делом, и оставляешь проблему позади. Этот инструмент родился из необходимости и стал революцией в мире разработки. Простота, скорость и распределенный подход сделали его незаменимым инструментом для команд любого масштаба.

Эволюция Git:

• 2005: первый релиз Git;
• 2008: появление GitHub, который популяризировал Git среди разработчиков;
• Сейчас: Git де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.

Основные подходы As Code

Infrastructure as Code (IaC)

IaC — это описание в виде кода инфраструктуры: серверов, сети баз данных. Например, с помощью Terraform, Ansible, CloudFormation. Инструмент позволяет сделать инфраструктуру воспроизводимой, предсказуемой и легко управляемой. Вместо ручного создания серверов в облаке вы можете описать их в коде и развернуть одной командой.

Когда мы слышим термин Infrastructure as Code, то обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления инфраструктурой и конфигурациями через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизировать управление парками машин, будь то физические или виртуальные системы.

Одним из первых инструментов, позволявших автоматизировать сборку и настройку программного обеспечения, был Unix “Make” (1976). Хотя Make не стал полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации. Следующим важным шагом к автоматизации стал PXE boot (1981). Он позволял загружать и настраивать по сети целые машины — это стало прообразом современных подходов к управлению инфраструктурой.

Хотя эти ранние инструменты не считаются полноценными решениями для управления инфраструктурой, они создали основу для современных подходов. Unix “Make” и PXE boot показали, что автоматизация конфигураций возможна и необходима, особенно с ростом сложности систем.

Как дальше складывалась эволюция IaC:

• 1990-е: следующий этап развития начался с появлением CFEngine (1993). Это был один из первых инструментов, позволявших управлять конфигурациями на множестве машин.
• 2000-е: с развитием облачных технологий и DevOps появились более мощные инструменты, такие как Puppet (2005) и Chef (2009). Они сделали управление через код отраслевым стандартом. 2010-е: Ansible (2012) и Terraform (2014) стали лидерами в области IaC. Они предложили более гибкие и мощные решения для управления облачной инфраструктурой.
• 2013: появился Docker, который произвел революцию в контейнеризации. Он обеспечил легкость в создании, развертывании и масштабировании приложений, а также упростил процессы управления инфраструктурой.
• 2014: Kubernetes предложил автоматизацию развертывания, масштабирования и управления контейнизированными приложениями.
• 2017: создан Pulumi, который позволил управлять ресурсами облачной инфраструктуры с использованием таких языков программирования, как Go, JavaScript, TypeScript, Python, Java, C# и YAML. Благодаря этому инструменту разработчики смогли быстрее интегрировать IaC в свои процессы и создавать более сложные сценарии для автоматизации.
• 2021: появился Brainboard, который значительно упростил разработку, визуализацию и управление инфраструктурой как кодом. Он предложил графический интерфейс для создания и изменения архитектуры облаков. Это помогло сделать IaC доступным не только для разработчиков, но и для более широкого круга пользователей, в том числе для аналитиков и проектировщиков.

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

Documentation as Code (Docs as Code)

Подход Docs as Code позволяет разрабатывать техническую документацию с помощью тех же инструментов, что и код. Документы создаются в формате, который легко версионировать и хранить в Git, — например, Markdown или AsciiDoc. Это дает значительные преимущества:

• актуальность — документация API или архитектуры хранится в репозитории рядом с кодом, благодаря чему всегда остается актуальной;
• версионирование — легко отслеживать изменения и возвращаться к предыдущим версиям;
• интеграция в процесс разработки — документация становится частью DevOps-практики и развивается в Git вместе с кодом.

Подход Docs as Code начал развиваться в 2000-х годах. В это время крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework уже создавалась с помощью автоматизированных процессов.

В 2010-х годах термин Docs as Code был популяризирован. Тогда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использовать для создания и управления документацией в репозиториях Git.

Architecture as Code (AaC)

AaC позволяет описывать архитектуру системы в виде кода — например, с помощью DSL. Благодаря этому она становится понятной, проверяемой и легко изменяемой. С помощью таких инструментов, как Structurizr или PlantUML, можно генерировать архитектуры программного обеспечения в коде, чтобы интегрировать их в процессы разработки.

Подход Architecture as Code начал развиваться в 2010-х годах с появлением Structurizr (2014) и других инструментов. Сегодня AaC используют для описания в формате, который можно версионировать и тестировать. Например, C4-модель помогает разработчикам и архитекторам лучше понимать сложные системы.

Хотя конкретные компании редко публично афишируют использование C4-модели или Aac, есть несколько примеров, где эти подходы активно применяются.

Крупные технологические компании

• Microsoft использует C4-модель, чтобы документировать архитектуры своих облачных сервисов, таких как, допустим, Azure. Подход AaC помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
• Внутренние команды Amazon Web Services используют C4-модели для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

Финансовые организации

Многие банки и финтех-компании используют C4-модели, чтобы документировать сложные распределенные системы. Например, ING и Goldman Sachs применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

Консалтинговые и IT-компании

• Разработчик и поставщик программного обеспечения ThoughtWorks активно продвигает использование C4-модели и подхода Architecture as Code в своих проектах. Компания создает инструменты и практики для интеграции AaC в процессы разработки.
• Производитель программного обеспечения Red Hat использует C4-модели для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.
• Также активно использует и применяет C4-модели X5 Tech — основной цифровой партнер торговых сетей и бизнесов X5 Group.

Policy as Code

Этот подход позволяет описывать политики и управлять ими, например безопасностью или доступом. Policy as Code дает возможность автоматизировать проверку на всех этапах жизненного цикла ПО и обеспечить compliance — соответствие требованиям.

Подход Policy as Code стал популярным с появлением таких инструментов, как Open Policy Agent (OPA) и Hashicorp Sentinel. Они позволили описывать политики безопасности и compliance в виде кода, что стало особенно востребованным в облачных средах.

GitOps

GitOps — подход, в котором Git становится единым источником истины для управления инфраструктурой и приложениями. Они описываются в коде — например, с помощью Kubernetes manifests — а все изменения автоматически применяются через CI/CD.

Концепцию GitOps в 2017 году формализовала компания Weaveworks, этот подход дает несколько преимуществ:

• прозрачность — все изменения видны в Git;
• автоматизация — процессы деплоя и обновления автоматизированы;
• безопасность — изменения проходят код-ревью и тестирование.

GitSecOps

GitSecOps — расширение GitOps с акцентом на безопасность, которое стало развиваться в 2020-х годах. С помощью этого инструмента можно интегрировать безопасность в процесс разработки и эксплуатации через код, он позволяет внедрить в CI/CD инструменты статического анализа кода (SAST) и анализа зависимостей (SCA).

Преимущества этого подхода:

• раннее выявление уязвимостей;
• автоматизация проверок безопасности;
• соответствие стандартам — например, GDPR или HIPAA.

Будущее с As Code

Мы постепенно внедряем лучшие практики и шаг за шагом приближаемся к моменту, когда актуальность инженерной культуры будет соответствовать состоянию мастер-системы, которая тем временем бежит вперед, — и я вижу в пространстве новые коммиты актуальной реальности.

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

Footnotes:

• Everything as Code Explained

• Write the Docs Guide: Docs as Code

• Understanding Docs as Code

• The Origins of Infrastructure as Code

• Canary Deployment Strategies

• AWS Whitepaper: Blue-Green Deployments

Ключевыми участниками инициативы стали IT-гиганты: OpenAI, SoftBank и Oracle. Все три корпорации планируют инвестировать до $500 млрд в течение следующих 4 лет.

Масштаб и цели проекта

Инициатива Stargate предусматривает начальные инвестиции в размере $100 млрд с перспективой увеличения до $500 млрд.

Основное внимание будет уделено строительству современных дата-центров и объектов по производству электроэнергии в Техасе, что обеспечит необходимую инфраструктуру для развития ИИ.

Ожидается, что проект создаст более 100 000 рабочих мест в США и укрепит позиции страны в глобальной гонке ИИ, особенно в соперничестве с Китаем.

Технологические партнеры и сотрудничество

В рамках Stargate ключевыми технологическими партнерами выступят ARM, Microsoft, NVIDIA, Oracle и OpenAI.

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

Это сотрудничество опирается на ранее установленные партнерские отношения между OpenAI и NVIDIA, а также на новое партнерство между OpenAI и Oracle.

Роль Microsoft в проекте

Microsoft пересмотрела ключевые условия своего соглашения с OpenAI после объявления о создании Stargate.

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

Тем не менее, Microsoft сохраняет эксклюзивные права на предоставление API-сервисов OpenAI и продолжает стратегическое партнерство, включая совместное использование доходов, действующее до 2030 года.

Наталья Царева, директор по продуктам ISPsystem — российского разработчика платформ для комплексного управления ИТ-инфраструктурой, рассказала как зарождался отечественный рынок серверного оборудования, на кого сегодня ориентируются российские производители и кому удалось заместить иностранное «железо».

Пара слов о становлении рынка

Российский рынок серверного оборудования зародился в начале 1990-х годов. Фактические его развитие началось с бурного роста поставок компьютеров на платформе x86 из-за рубежа. Эти ПК и стали для российского бизнеса первыми серверами. Вслед за ними на рынок хлынули специализированные серверные решения из-за рубежа.

Ближе к середине десятилетия начала формироваться ниша российских производителей серверов. Появились компании Kraftway Corporation, DEPO Computers, существовавший уже несколько лет на этом рынке «Аквариус» запустил производство серверного оборудования.

Шли годы, ситуация на российском рынке ИТ-оборудования складывалась совершенно не в пользу отечественных игроков. Вендоры были, но популярностью их решения не пользовались. Продуктам российских производителей компании предпочитали серверы иностранного производства — HP, IBM, Cisco, Dell.

Об отечественных игроках рынка вспомнили в 2022 году, когда западные вендоры в спешке покинули российский рынок. И оказалось, что в России есть компании, которые не только могут производить серверное оборудование, но и уже делают это.

Ниже обсудим, какие вендоры представляют наш «железный» рынок, что движет этот сегмент.

Российские производители серверного оборудования — обзор

«Аквариус»

«Аквариус» — ветеран отечественного ИТ-рынка. Компания появилась на свет в 1989 году и стала первым в СССР негосударственным предприятием, открывшим заводское производство IBM-совместимых персональных компьютеров.

Производственные комплексы «Аквариус», расположенные в городах Шуя и Тверь, входят в число крупнейших российских ИТ‑производств. Компания выпускает ПК, ноутбуки, моноблоки, информационные терминалы, СХД, телеком-оборудование и серверы.

Особенности и преимущества

• Мощность производства — 2,5 млн устройств в год.
• Полный производственный цикл выпуска высокотехнологичного оборудования, включая печать плат, поверхностный монтаж компонентов и сборку изделий.
• Продукция включена в реестр Минпромторга.
• Компания планирует выходить на международные рынки и начать поставки во Вьетнам, Нигерию, ЮАР, Конго, на Филиппины и другие страны.
• В портфеле есть решения для бизнеса любого уровня, но, судя по ассортименту продукции, производитель ориентируется на средний и крупный сегмент бизнеса, а также государственные компании.

Серверы «Аквариус» используют Почта России, Росреестр, Минсельхоз, Центральное информационно-техническое таможенное управление,

Ассортимент серверной продукции

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

• Серверы начального уровня — решения с базовыми техническими характеристиками и функциональными возможностями.
• Серверы среднего уровня — сбалансированные по производительности и возможностям расширения решения для предприятий из разных сегментов бизнеса.
• Серверы уровня предприятий и ЦОД — решения с широкими функциональными возможностями, высокой производительностью и надежностью.
• Специализированные серверы — оборудование для размещения за пределами традиционного ЦОД и построения встраиваемых решений.

DEPO Computers

Компания основана в 1995 году и изначально позиционировалась как дистрибьютор компьютерной техники. С 2002 года под маркой DEPO приступила к массовому производству компьютеров, рабочих станций и серверов.

Компания совмещает производство вычислительного оборудования с деятельностью системного интегратора в области инженерной инфраструктуры, виртуализации и информационной безопасности. Сегодня DEPO Computers является одним из учредителей АНО развития радиоэлектронной отрасли «Консорциум «Вычислительная техника», объединяющей производителей ИТ-оборудования.

Особенности и преимущества

• Продукция включена в реестр Минпромторга.
• Собственные производственные мощности: 11 конвейерных линий, более 25 тыс. серверных и 320 тыс. компьютерных систем в год.

Ассортимент серверной продукции

DEPO Computers выпускает несколько линеек серверов, отличающихся уровнем производительности и назначением.

• Однопроцессорные серверы DEPO Storm 1000 для региональных офисов и небольших филиалов компаний.
• Двухпроцессорные серверы DEPO Storm 3000 для облачных вычислений, выполнения задач ИИ и робототехники, виртуализации, big data, облачного хранения данных.
• Четырехпроцессорные серверы DEPO Storm 4000 с возможностью размещения максимального количества процессоров и оперативной памяти в пересчете на юнит для построения ферм виртуализации, вычислительных кластеров и решения сложных расчетных задач.
• Специализированные серверы DEPO Storm 5000 для создания центров обработки данных и решения задач корпоративного класса с повышенными требованиями к обеспечению непрерывной доступности критичных ИТ-систем.
• Высокопроизводительные серверы DEPO Storm 6000 для ИИ и других ресурсоемких задач.
• Сетевые серверы DEPO Stream 1000 для управления программно-определяемыми сетевыми и вычислительными инфраструктурами.

Kraftway

Одна из крупнейших российских производственно-инжиниринговых компаний, основанная в 1993 году. Ключевое направление деятельности — разработка и производство доверенных платформ с интегрированными средствами защиты информации.

Kraftway производит клиентские решения (ПК, моноблоки, АРМ), серверы, СХД, телеком оборудования, платформы для сетевых устройств и СЗИ, а также периферию — принтеры, МФУ, мониторы.

Особенности и преимущества

• Широкий спектр доверенного ИТ-оборудования с высоким уровнем локализации — от микросхем и материнских плат до мощнейших корпоративных серверов.
• Доверенность обеспечивается использованием материнских плат собственной разработки и интеграции модулей безопасности и управления на уровень UEFI BIOS.
• Продукция входит в реестр Минпромторга.
• Разработкой решений занимается собственное конструкторское бюро, специализирующееся на проектировании аппаратной составляющей доверенных платформ, включая материнские платы, контроллеры, электронные узлы, шасси и конструктивы.
• Производство консолидировано в Обнинске — на заводе функционируют 4 производственные линии, автоматизированная зона тестирования и участок сложных серверных систем. Производственная зона комплекса занимает площадь 6000 кв. м.

Ассортимент серверной продукции

Портфель серверной продукции Kraftway предлагает две категории серверов.

• Серверы общего назначения Kraftway Express (1U, 2U) на базе Intel Xeon Scalable 3-го и 4-го поколения/AMD EPYC

Ориентирован на коммерческих заказчиков без особых требований к степени локализации производства в РФ. Подойдет для задач в области высокопроизводительных вычислений (НРС), серверной виртуализации, крупных баз данных, искусственного интеллекта.

• Серверы общего назначения Kraftway Express (напольное исполнение)

Решение начального и среднего уровня с одним процессором Intel Xeon W или Intel Xeon E. Подойдет в качестве веб- или файлового сервера, для размещения несложной системы виртуализации или других нетребовательных к вычислительным ресурсам задач.

• Доверенные серверы общего применения Kraftway Trusted

Решение на базе Intel Xeon Scalable Gen3 (1 или 2 процессора в зависимости от конкретной модели и выбора заказчика). Подойдет для различных сценариев использования: In-memory и многопользовательские БД, аналитика и обработка Big Data, анализ AI и ML, HPC-вычисления, виртуализация, визуализация и построение гиперконвергентных структур.

Гравитон

Российский разработчик и производитель отечественной вычислительной техники. Ведет деятельность с 2018 года. Выпускает широкий спектр оборудования: клиентские устройства (ПК, ноутбуки, мониторы и пр.), серверы и СХД, программно-аппаратные комплексы.

Особенности и преимущества

• Продукция входит в реестр Минпромторга.
• Есть собственная база R&D, разработки в сфере ИИ, больших данных, облачных технологий.
• Компания осуществляет полный цикл создания высокотехнологичной вычислительной техники: от идеи до внедрения, включая разработку, конструирование и прототипирование, промышленный дизайн, печать материнских плат, монтаж компонентов и сборку.

Ассортимент серверной продукции

Производитель предлагает несколько линеек серверов:

• Серверы начального уровня на базе lntel Xeon Gen2.
• Серверы среднего уровня на базе lntel Xeon Gen3 и AMD EPYC 7002/7003.
• Флагманские высокопроизводительные серверы на базе lntel Xeon Scalable Gen4/5 и AMD EPYC Gen 4.

OpenYard

Выпуском серверов под брендом OpenYard занимается компания «Центр Открытых Разработок», которая ежегодно производит более 60 000 единиц серверной продукции. Предприятие владеет производственной площадкой в Рязани и собственным R&D-центром, специализирующимся на разработке и исследованиях в области инфраструктурных решений, дизайна и кастомизации стоек и оборудования.

Особенности и преимущества

• Продукция входит в реестр Минпромторга.
• Серверное оборудование OpenYard производится на собственных мощностях завода в 15 километрах от Рязани на территории индустриального парка «Рязанский».
• Есть собственный R&D-центр.
• Выпускает не только классические стоечные серверы, но и OCP-решения.

Ассортимент серверной продукции

Продуктовая линейка включает два направления: классические стоечные серверы и серверы в архитектуре OCP.

• Enterprise. Базовая линейка серверов для широкого круга задач на базе 2хAMD EPYC Rome/Milan или 2хIntel Xeon Gen3. OCP.
• Решение для ЦОД на архитектуре OCP с AMD EPYC 7002/7003 и Intel Xeon Gen3.

GAGAR>N

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

Особенности и преимущества

• Продукция входит в реестр Минпромторга.
• Есть собственная команда разработчиков и программистов.
• Единственная в России сертифицированная лаборатория – Центр опыта, инноваций и внедрения OCP Experience Lab Moscow.
• Оборудование производится на территории РФ.
• Вендор также предлагает российский UEFI и программное обеспечение BMC разработки GAGAR>N.
• Ориентируется на государственный сектор, крупные компании и ЦОД.

Ассортимент серверной продукции

GAGAR>N предлагает две линейки серверного оборудования.

• GAGAR>N Оракул

Серверы для широкого спектра задач — GAGAR>N Оракул Gen 1 на базе 2xIntel Xeon Scalable Gen2, GAGAR>N Оракул Gen 2 на базе 2хIntel Xeon Scalable Gen3, GAGAR>N Оракул Gen 3 на базе 2хIntel Xeon Scalable Gen3.

• GAGAR>N Простор

Относительно новая линейка серверов GAGAR>N. Сейчас в ней представлено лишь одно решение — GAGAR>N Простор Gen 1 на базе 2хIntel Xeon Scalable Gen2.

Yadro

Российский производитель ИТ-оборудования, входит в состав ИКС Холдинга. Специализируется на разработке и производстве вычислительных платформ, систем обработки и хранения данных, телекоммуникационного и сетевого оборудования, персональных и «умных» устройств, микропроцессорных ядер и fabless-разработке микропроцессоров.

Особенности и преимущества

• Продукция входит в реестр Минпромторга.
• Есть собственные R&D-центры в Москве, Санкт-Петербурге, Екатеринбурге, Нижнем Новгороде и Минске.
• Компания работает над созданием высокопроизводительных ИИ-серверов, которые можно использовать для обучения.
  

Ассортимент серверной продукции

• Серверы X

Серверы для малых и средних предприятий — X3-105 / X3-205, двухпроцессорные платформы на базе Intel Xeon Scalable Gen3.

• Серверы VEGMAN

Высокопроизводительные серверы для ресурсоемких задач — VEGMAN R на базе Intel Xeon Scalable Gen3 для общих нагрузок, VEGMAN N на базе Intel Xeon Scalable Gen2 для обработки сетевого трафика.

Как управлять российским железом

Существует два типа ПО для управления ИТ-оборудованием — вендорский софт и мультивендорные платформы.

Вендорский софт

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

Однако есть и недостатки. Нередко такие продукты совместимы с оборудованием только этого вендора, с которым они поставляются. Заказчику, сделавшему выбор в пользу софта от вендора оборудования, в будущем придется либо мириться с ограничениями при выборе «железа» в будущем, либо использовать сразу несколько систем управления одновременно.

Мультивендорное ПО

Мультивендорное ПО из коробки совместимо с оборудованием самых разных производителей. В число наиболее зрелых российских решений для управления физической ИТ-инфраструктурой сегодня входит DCImanager от ISPsystem. Платформа позволяет управлять геораспределенной инфраструктурой ЦОД из единого интерфейса. К DCImanager можно подключить не только серверы любых вендоров, но и другое оборудование — сетевые устройства, системы распределения питания, ИБП.

DCImanager закрывает широкий спектр задач в части управления физической ИТ-инфраструктурой:

• контроль использования инфраструктуры;
• работа с географически распределенными локациями в одном окне;
• визуализация состояния инфраструктуры;
• управление мультивендорным оборудованием;
• учет и управление адресным пространством (IPAM);
• инвентаризация оборудования (ITAM);
• управление и прошивка BMC/BIOS.

Использование мультивендорных решений для управления ИТ-инфраструктурой обеспечивает высокий уровень гибкости при выборе железа и возможность оптимизировать затраты на ИТ-инфраструктуру — заказчик может выбирать решения с наиболее оптимальным соотношением цены и качества в разрезе конкретной задачи.

Сегодня в сторону мультивендорных решений смотрят не только заказчики такого софта — дата-центры, хостинг-провайдеры, государственные структуры, ИТ-подразделения коммерческих предприятий — но и производители «железа»,, обеспечивая совместимость своих решений с популярным в отрасли ПО для управления им.

Платформа DCImanager официально совместима с серверным оборудованием нескольких отечественных производителей:

• успешно завершена сертификация совместимости серверных систем «Аквариус» и платформы управления мультивендорной ИТ-инфраструктурой DCImanager;
• проведена официальная сертификация совместимости серверов OpenYard линейки Enterprise и платформы управления мультивендорной ИТ-инфраструктурой DCImanager, планируется проведение аналогичной процедуры для серверов линейки OCP;
• подтверждена совместимость DCImanager и вычислительного оборудования от компании «Гравитон»;
• подтверждена полнофункциональная совместимость программного обеспечения DCImanager и серверного оборудования «Сила».
  

Список совместимых с DCImanager решений постоянно расширяется.

Благодаря совместным усилиям компаний конечные пользователи продуктов получают не просто набор качественных инструментов для решения своих ИТ-задач, а целостные импортонезависимые решения, что особенно важно в условиях сегодняшней экономической обстановки.

ПАКи — на стыке софта и «железа»

Прямо сейчас, на наших глазах, в России формируется еще одни важный сегмент технологического рынка — рынок программно-аппаратных комплексов.

Программно-аппаратным комплексом (ПАК) называют некую интегрированную систему, состоящую из оборудования и ПО, «заточенную» под решение конкретной задачи. В отрасли выделяют несколько характерных черт ПАК:

• глубокая интеграция программных и аппаратных компонентов, которая не может быть достигнута на базе стандартной платформы и ПО;
• высокий уровень оптимизации;
• подходит для решения какой-то определенной задачи.

Сегодня российский рынок ПАК включает решения более 300 отечественных компаний, чьи решения значительно помогают облегчить процесс построения ИТ-инфраструктуры. Согласно классификации TAdviser, продукты можно разделить на 4 сегмента:

• ПАК для высоконагруженных систем;
• функциональные ПАК;
• автоматизированные рабочие места;
• нишевые решения.

Отечественные ПАКи, как и серверы, до 2022 года мало интересовали заказчиков, привыкших к иностранным технологиям. Когда западные вендоры отвернулись от российских потребителей, оказалось, что альтернатив на рынке мало, а те, что есть, не всегда предназначены для решения задач уровня предприятия или ЦОД.

Преодолевает этот дефицит рынок благодаря коллаборации производителей ИТ-оборудования и разработчиков программных решений. Такие альянсы позволяют объединить экспертизу и ресурсы различных компаний, что приводит к появлению на рынке эффективных решений, закрывающих потребности конечных пользователей.

Вот несколько примеров:

• ПАК для управления виртуальными машинами и резервного копирования данных — российское решение на базе платформы виртуализации VMmanager от ISPsystem, аппаратной платформы «Аквариус», операционной системы Astra Linux и ПО RuBackup.
• ПАК Helius.Astra для быстрого развертывания виртуальной ИТ-инфраструктуры для поддержки работы небольших организаций от 50 рабочих мест на базе серверов, СХД «Гравитон» и платформы VMmanager.
  

Что ждет российское «железо»

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

Однако пока государственный сектор импортозамещается, коммерческий в этом направлении двигаться не спешит. По данным «Ведомостей», в 2023 году 69% российских компаний продолжали использовать серверы зарубежного производства, несмотря на санкции, отсутствие поддержки, сложности в приобретении и другие ограничения. Как правило, в качестве причин отказа от импортозамещения компании называют:

• высокую стоимость отечественных решений;
• низкие темпы производства;
• отсутствие необходимости замещать иностранное оборудование российским;
• возможные трудности внедрения отечественных решений в сложную корпоративную инфраструктуру.

Эксперты считают, что в ближайшие несколько лет темпы импортозамещения не только не снизятся, но и существенно вырастут.

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

Однако работа ИИ требует огромных затрат ресурсов, особенно воды и электроэнергии.

Исследования показывают, что каждый запрос к ChatGPT, использующему модель GPT-4, требует значительного количества воды для охлаждения серверов.

Ежегодные затраты воды

Один запрос к ChatGPT на 100 слов тратит 519 мл воды. Если предположить, что каждую неделю совершается, в течение года, совершается хотя бы один такой запрос, то это потребует около 27 литров, что эквивалентно полутора кулерам для воды.

А если представить, что 1 из 10 работающих американцев будет использовать ИИ раз в неделю, то на это уйдет около 435 млн литров воды. Это количество равно объему воды, который потребляют все домохозяйства штата Род-Айленд за полтора дня.

Региональные различия

Что интересно, количество воды, необходимое для работы ИИ, зависит от региона, где находятся дата-центры.

Например, в Вашингтоне на каждую сгенерированный ответ из 100 слов, ChatGPT требуется около 1468 мл воды, в то время как в Техасе этот показатель значительно ниже — всего 235 мл.

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

Потребление электроэнергии

Кроме воды, для работы ChatGPT требуется значительное количество электроэнергии.

Один запрос к ИИ эквивалентен 0.14 кВт⋅ч, что равноценно работе 14 светодиодных лампочек в течение одного часа.

Ежегодное использование ChatGPT 1 из 10 американцев потребует около 121 тыс мегаватт⋅часов электроэнергии, что сопоставимо с энергопотреблением всех домохозяйств Вашингтона в течение 20 дней.

Об этом случае вспомнил Теодор Смит из PHP Experts.

Как это случилось

Разработчики Knight Capital срочно переносили своего высокочастотного торгового бота на новый сервис NYSE, который должен был запуститься через 33 дня.

Они работали по 80 часов в неделю, чтобы успеть к дедлайну. В коде бота они оставили старые методы и классы, чтобы избежать необходимости пересборки.

Также разработчики убрали старый тестовый код и вставили новый рабочий. Тесты прошли успешно, и утром 1 августа в 8:00 код развернули в продакшн. Всё выглядело отлично.

Катастрофа

Во время утреннего совещания в 9:30 рынок открылся и бот начал безудержно покупать акции по самым высоким ценам. За две минуты системы Knight Capital обнаружили, что деньги компании стремительно исчезают.

Связаться с разработчиками не удавалось, так как они находились в удаленном офисе и оставили свои телефоны на столах.

Через 11 минут боты уже скупили акции на сумму свыше $3 млрд, а компания оказалась на грани краха.

Единственным решением оказалось физическое уничтожение серверов в дата-центре с помощью топоров. Торги прекратились через 28 минут, оставив бумажные убытки в $10.8 млрд.

Почему это произошло

Расследование показало, что ошибка была вызвана неправильным вводом данных при релизе. Один из операторов ввел неверную команду rsync, из-за чего один из серверов остался с тестовым кодом, который скупал акции по самым высоким ценам.

После выявления ошибки разработчики решили откатиться к предыдущему релизу, что лишь усугубило ситуацию. В итоге за 28 минут было потеряно $8.65 млрд.

Последствия

Эта катастрофа привела к потере всех корпоративных клиентов Knight Capital и компания закрылась через несколько недель.

Сегодня у нас в гостях Евгений Антонов — старший технический менеджер проектов в Yandex Infrastructure, IT-консультант, автор телеграм-канала «Тимлид Очевидность» и ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Как прошла неделя? Над чем работаешь в последнее время?

Как у менеджера и тимлида, у меня обычно столько разных контекстов, между которыми я переключаюсь, что даже нет смысла всё это перечислять. Ощутимую часть недели точно занимает операционная деятельность: рутинное ведение проектов, команд, стыковка планов со смежными командами, отчётность и т.д.

Из не рутинного:

• У нас в службе происходит реструктуризация, и я помогаю готовить планы, как пройти через неё с меньшим количеством боли и вреда для людей и для производительности труда. А в идеале даже ещё получить удовольствие и профит.
  
• Моя команда – инфраструктурная, и занимается она работой с опенсорсом, поэтому я был озабочен новыми потребностями некоторых команд по интеграции внутреннего репозитория и опенсорса.
  
• Подготовил контент для двух докладов: первый – «Должен ли тимлид писать код?» Второй – «Как тимлиду найти синергию с рекрутером».
  
• Делал посильный вклад в ИТ-сообщество. Помогал в организации митапа и конференции, писал со своими товарищами новые выпуски подкастов для тимлидов.

Какая из последних IT новостей запомнилась тебе больше всего? Почему?

Мне было интересно прочитать про то, что Microsoft закрыл свой проект Natick по расположению дата-центра под водой.

Интересно ещё и то, что он был более отказоустойчивым в сравнении с наземными. Но закрыли не со словами «не работает, отменяем», а с чем-то, показавшимся мне более обтекаемым (каламбур, фьють-ха): «While we don’t currently have data centers in the water, we will continue to use Project Natick as a research platform to explore, test, and validate new concepts around data center reliability and sustainability, for example with liquid immersion.»

С какой сложной задачей ты столкнулся в последнее время и как решил?

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

1. Кросскомандные проекты, которые нужно координировать и доводить до нужного результата. Тут простой совет – контроль и дисциплина.
2. Очень много задач в целом. Тут простой совет – приоритизация и делегирование части задач.

Что слушал на неделе? Поделись треками или подкастами

Я люблю слушать много аудио-подкастов (в подписках около 30 разных). Вот тут я делился скрином и списком в телеграме.

Из музыки либо какой-то лаунж для сосредоточенной работы, либо что-то более динамичное типа Billy Idol, 69 Eyes, Black Sabbath, Ozzy Osbourne.

Что советуешь почитать?

Сейчас читаю книгу Анны Старобинец «Лисьи броды». Эдакая мистика, фэнтези, триллер. Очень нравится. А на букмейте ещё и круто озвученная аудиокнига имеется.

Недавно закончил читать «Замок» Кафки. Это было очень странно и нудно, но одновременно любопытно и необычно.

Из нон-фикшена читаю «Искусство спора» Поварнина. Ранее у него читал книгу про то, как читать книги. Развивающее и структурирующее чтиво, рекомендую.

А еще люблю рекомендовать «Дом, в котором», «Ложная слепота», «Рифтеры» и «Задача трех тел».

Окей, а что посмотрел и можешь порекомендовать?

Только закончил смотреть сериал «Олененок». Очень напряжённый и драматичный сериал с довольно интересной концовкой.

Недавно еще посмотрел «Идеальные дни». Совершенно чудесный, умиротворяющий и мотивирующий к созерцанию жизни фильм.

«Все страхи Бо» тоже понравился, особенно сразу после прочтения «Замка» Кафки. Есть в этом какая-то криповая синергия.

Твой топ-3 приложения

Telegram – очень много общения там + мой телеграм-канал.

Todoist – невероятно нужная штука, которая помогает держать много контекстов, не терять кучу дел и дисциплинированно их выполнять.

Букмейт – люблю читать. А еще там есть удобная функция бесшовного переключения между текстом и аудио.

Планы на выходные: как планируешь проводить и что посоветуешь нам?

В субботу я обязательно отдыхаю и не делаю ничего, связанного с работой, или общественной деятельностью про IT (канал, подкасты, доклады, конференции и митапы). Ходим с женой на завтрак в кофейню, гуляем по городу, разговариваем. Куда-то можем сходить (в прошлую субботу ходили на флоатинг), что-то посмотреть, во что-то на компьютере поиграть вместе и т. д.

Воскресенье вбирает в себя всякие заботы по домашним делам и часть про доклады, подкасты и прочую подобную деятельность.

Как итог — любимый IT-мем недели!

Будет актуально что для разработчиков и других линейных работников руками, что для менеджеров. Просто каждого из этих категорий торопят немного разные люди и разными словами.

Следите за новыми выпусками «Ретроперспективы недели» на Tproger — будет ещё больше интересного! Если у вас есть идеи, кого бы вы хотели видеть в следующем выпуске, дайте нам знать!

Ожидается, что запуск спутника-сервера состоится уже в 2022 году. Ракетой-носителем должен выступить аппарат серии «Союз». Учитывая, что разработка RuVDS и Orbital Express будет весить около 5 кг, цена отправки составит около 75 тыс долларов (5,7 млн рублей).

Основной целью орбитального сервера станет фильтрация контента. С его помощью, например, специалистам не придётся отправлять на Землю некачественные снимки. Также в качестве преимущества разработки называется «безопасность хранения информации».

RuVDS известна тем, что предоставляет услуги по серверному хранению и обработке данных. Чаще всего её клиентами являются крупные игроки.

В свою очередь Orbital Express занимается созданием систем по запуску спутников в космос. Также компания является резидентом инновационного центра «Сколково».

Источник: Ведомости

Как сообщает издание Bleeping Computer, инцидент произошел 18 апреля 2018 года рано утром и был вызван инертным газом. В подобных системах пожаротушения газ высвобождается из специальных баллонов в случае возгорания. Неправильная настройка приводит к резкому непреднамеренному высвобождению газа из баллона с оглушительным звуком, который может повлечь за собой сбой в работе жестких дисков.

На видео Брендана Грегга (Brendan Gregg) из Sun Fishworks наглядно показано, почему даже простое повышение голоса может привести к сбою в работе жестких дисков:

Итоги аварии

В результате пострадала примерно треть серверов, расположенных в Швеции, Дании, Исландии, Финляндии, Норвегии и Прибалтике. Все финансовые операции таких банков, как FIM Bank и OP Bank Group, были заблокированы с 08:00 до 14:00 — к этому времени уже удалось развернуть необходимые бэкапы.

Компания Digiplex заявила, что Nasdaq арендует у них пространство в центре обработки данных, но использует при этом свое собственное оборудование. Представители биржи добавили, что прямо сейчас в Швеции недостаточно серверов для замены уничтоженных, и им приходится импортировать новое оборудование.

Это не первый случай, в котором причиной сбоя оборудования становится внешняя причина. О пяти самых худших багах в истории мы рассказали в нашем материале.