Изначально был только сервер

В котором мы жили по уже сложившимся канонам внутри известного и подконтрольного периметра и исповедовали Zero Trust — подход к безопасности, при котором никто никому не доверяет по умолчанию. И однажды у нас появилась задача «въехать» в облако. Но не в ещё один собственный ЦОД, а во внешнее облако.

Пример выезжающих в облако в рамках пилотов команд говорил, что всё будет быстро и легко. Но быстро и легко пришло только осознание, что нельзя просто так взять и перенести on-prem в облако.

Почему?

Потому что традиционные средства и подходы не работают. Само по себе облако имеет специфику безопасности, а риски отличаются от традиционной инфраструктуры. Возможно, по этой причине за 2024 год больше 60% компаний столкнулись с инцидентами безопасности, связанными с облаком, а в 2025 — уже 65%?

Если, как упоминал ранее, мы жили за неким сетевым периметром, где можно было отгородиться блокирующими или разрешающими правилами или «белыми списками», то облако — это API-first инфраструктура, где используемые сервисы (особенно managed services) не стоят за какими-то фаерволами, а имеют в первую очередь публичные API, доступ к которым регулируется иными правилами: RBAC, политики, ACL.

Возникает новая модель ответственности, где часть задач берет на себя платформа и её сотрудники. Это так называемый Cloud Trust — модель безопасности, которая предполагает разделение обязанностей между провайдером и клиентом.

Но даже если ответственность поделена, отпускать контроль мы не можем. Но и тормозить команды оправданиями «уникальной специфики облака» тоже не будем. Так что мы решили не изобретать велосипед, а просто учесть специфику облака в виде вариантов технической реализации наших текущих процессов. Ниже я пройду по базовому набору действий: сеть, доступы, конфигурации и SOC.

№1. Сетевой доступ

Мы сделали практически полный маппинг ресурсной организации on-premises с ресурсной организацией Yandex Cloud (ЯО далее).

Как и говорил ранее, у нас появляется новый периметр — IAM. Но и старый никуда не исчезает. Сетевая изоляция и микросегментация остаются чуть ли не самыми важными вопросами ИБ до сих пор. Потому первый же вопрос, который мы задали себе при выезде, был таков: «А как нам с ним общаться?» То есть как строить интеграции, как пускать управляющий трафик и трафик этих интеграций и так далее.

Ответом на вопрос стал интерконнект. Это оптика с тёмным волокном между Банком и Платформой, поверх которой накладывается ГОСТ-шифрование. В интерконнект мы заворачиваем весь свой трафик, ходим из сети Банка в консоль, строим внутри интеграции и т.д.

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

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

Такую же структуру мы организовали в облаке: система — это облако, а фолдеры – среды, каждая из которых имеет свои сети/подсети и набор правил фаерволинга, реализованных через Security Groups (как механизм сетевой изоляции).

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

Команда, как и раньше, согласовывает проект, заказывает подсети и сетевые доступа, как в on-prem, но в облаке. И даже если система поделена между on-prem и облаком, то её связность никак не нарушается. Все проекты, выезжающие в облако, получают пул IP-адресов с банковской сетью. Эти сети анонсируются в интерконнект и выглядят так, будто просто находятся в другом ЦОДе, и в нашей системе учета сетей пул заводится как обычная подсеть.

Мы выбрали контроль через сохранение текущей модели управления доступом, но делегировали реализацию этого процесса облачным сервисам — тем же Security Groups, которыми мы управляем через Terraform.

Единственное, что внешний трафик («интернет-интернет») в облако и из облака пока не пускаем — только через внутреннюю инфраструктуру. Но когда-нибудь сможем.

№2. Пользовательский доступ

Осознавая критичность пользовательских доступов в новой парадигме, мы решили, что и процесс управления последними также должен быть универсальным и повторять свою реализацию в новом окружении. Внутри все пользовательские доступы, доступы систем, технических учетных записей, управляются централизованно через Active Directory (AD) и KeyCloak, которые также поделены по средам. Облако позволяет их интегрировать со своим IAM и построить на их базе федерации для каждой из сред со своими наборами политик.

Фактически процесс аутентификации происходит в банке и транслируется в ЯО — то есть мы продолжаем использовать именно банковские корпоративные УЗ через банковскую же инфраструктуру для доступа к ресурсам и консоли облака.

А что с авторизацией и правами?

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

Мы начали переход в облако давно, и на первых этапах роли были примитивнее, чем сервисные. Со временем у ЯО появилась отличная грануляция сервисных прав, которая очень удобно позволяет собирать роли, соблюдая принципы наименьших привилегий. И также позволяет сопоставлять упомянутые ранее группы A D и группы пользователей IAM в ЯО. Фактически мы и здесь реализовали текущий процесс управления доступом в новом облачном окружении, сохранив командам привычный флоу работы и скорость без потери контроля.

Получился отличный баланс – аутентификация как в on-prem, но логичное делегирование авторизации в облако.

№3. Контроль конфигурации

Ну а что насчет самого разворачивания в облаке? Как вообще выезжать и контролировать то, что едет?

Чуть ранее я говорил, что мы используем ту же модель объектов в облаке, что и в банке, т.е. условно созданный Compute Cloud в облаке фиксируется в нашей системе инвентаризации как обычная WM. То же самое с сетями, то же и с другими сервисами.

Но что изменилось?

Например, мы стали вести реестр и критерии применимости Managed Services – каждый из них имеет свои возможности и нюансы, и мы начали с того, что провели анализ и составляем некую карту применимости того или иного managed services в том или ином проекте, с помощью которой можем решить, что один сервис разрешен одной команде, а другой запрещен.

Каждый проект должен создать свою проектную документацию – фактически отрисовать архитектуру с применяемыми в том числе облачными ресурсами. По итогу он получит согласование (сам процесс согласования сейчас не важен). И далее команда идет не в ЯО, а в нашу внутреннюю платформу, интегрируемую с облаком и через неё заказывает все необходимые ресурсы —> всё будет поднято для них в облаке. А мы на своей стороне сможем проверить ту же конфигурацию этих ресурсов.

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

Далее на развернутую инфраструктуру надо деплоить приклад — мы выбираем платформу CI/CD. Но здесь всё просто – у нас есть требования к платформам CI/CD и фактически такую систему можно сделать полностью облачной, что мы пробовали. Но использовать внутреннюю, уже построенную и готовую, куда удобнее: все сканеры настроены, все гейты построены.

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

А так как в облаке у нас довольно внушительная инфраструктура, много новых тяжелых подпроцессов, новых требований и моделей угроз, а команда маленькая, то без автоматизации никак. Потому с самого начала мы перекладывали все требования в код. Сейчас наши требования выглядят как набор проверок в коде — фактически это сканер облаков, являющийся клиентом над API облака, со всеми необходимыми нам функциями. Так, фактически, у нас появился собственный CSP (Cloud Security Posture Management — управление состоянием безопасности облака).

Этот подход позволяет писать любые требуемые нам проверки. Но порой нам может не хватать экспертизы в каких-то вопросах, и без экспертизы ЯО не обойтись, поэтому мы также можем использовать сервис Yandex Security Deck с его модулями.

На данном этапе мы всё ещё сохраняем преимущественно Zero Trust подход, но частично отдаём ответственность ЯО.

№4. SOC

Мы всё развернули, задеплоили, прошли проверки ИБ. А значит пора мониторить, детектить и реагировать. В on-prem мы знаем всё: у нас свои правила и полный контроль логов — на это отдельно выделена функция SOC.

Но в облаках у нас нет полного контроля над логами, так как:

• мы можем использовать только те сервисы сбора логов, что нам предоставляет площадка: Control Plane и Data Plane (= Audit Trail/Cloud Logging), а также логи действия самого провайдера;
• в ЯО постоянно появляются сервисы (которые, конечно же, сразу нужны командам), а фичи (в плане логирования) за ними не поспевают.

Но одно дело получить, другое — обработать (нужен детект). На это нужно нанимать команду, чтобы собирать, обрабатывать, а это дорого (да и свою экспертизу надо наращивать).

Поэтому мы всё ещё пользуемся сервисом YCDR от платформы, который позволяет нам закрывать эту функцию в облаке.

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

Итого

На данный момент в облаке у нас довольно большая инфраструктура: разные среды, разные системы, 1500 виртуальных машин, 100 managed services, 1000 пользователей — сотрудники и члены команд и сервисных аккаунтов.

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

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

На связи команда облачного провайдера Beget – сегодня мы расскажем, как можно сэкономить на хранении данных, когда их становится всё больше.

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

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

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

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

В этих реалиях возникает задача – как сократить расходы на хранение данных и не потерять к ним доступ.

Расскажем о решении, которое может в этом помочь.

Когда серверу становится тесно

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

Однако не всей информации нужны ресурсы основного сервера – вот примеры данных, которые так хранить необязательно:

· резервные копии;

· архивы и старые версии файлов;

· логи и истории событий;

· изображения, видео и другой медиаконтент;

· документы, которые редко используются;

· выгрузки и результаты обработки данных;

· дистрибутивы, установочные файлы и образы;

· данные для долгосрочного хранения и аудита.

Ко многим из этих данных обращаются редко, а хранить их нужно постоянно.

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

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

Что дает объектное хранилище

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

· Надежность и доступность – при аренде S3-хранилища данные хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности.

· Гибкое управление – версионирование, настройка доступа и классы хранения позволяют контролировать, где и как хранятся данные.

· Доступ к данным 24/7 из любой точки мира и из любого браузера.

· Удобная модель оплаты Pay as you go – оплачивайте только тот объем, который используете.

В настоящее время S3 хранит сотни эксабайт данных в сотнях триллионов объектов, обрабатывая в среднем более 200 миллионов запросов в секунду.

Разберем конкретнее, какую пользу объектное хранилище может принести бизнесу.

S3 на практике: кто и как использует

Итак, объектное хранилище может пригодиться для:

· хранения бэкапов, отчетов, медиафайлов и другого контента отдельно от серверов – чтобы сэкономить и снизить риск потери данных при сбоях;

· архивирования – сохраняйте редко используемые документы, логи и старые версии файлов без нагрузки на основные диски;

· обмена данными между сервисами – можно организовать единое хранилище для микросервисов и упростить передачу файлов между ними;

· масштабирования проектов – увеличивайте объем хранимых данных без пропорционального расширения серверных дисков.

S3 используют более 398 тысяч компаний – и вот лишь несколько примеров результатов:

· производитель шин Apollo Tyres – на 90% снизил затраты на резервное копирование за 2 года на трех из семи своих заводов;

· платформа EZJobs – снизила затраты на 50% благодаря интеллектуальному многоуровневому хранению;

· маркетплейс Ozon – благодаря дедупликации в среднем сэкономил на обработке данных около 13% по всем бакетам;

· технологическая компания Bynder – сэкономила 65% затрат на хранение данных о клиентах благодаря системам интеллектуального многоуровневого хранения S3;

· финансовый маркетплейс “Сравни” – уменьшил затраты на инфраструктуру БД в 1,5 раза.

На примере этих и других компаний заметно, что объектное хранилище S3 помогает решать сразу несколько бизнес-задач – сокращать расходы на хранение, разгружать серверную инфраструктуру и масштабировать объем данных без сложных перестроек.

Если у вашего проекта большое количество данных и вы хотите оптимизировать расходы на их хранение, то создать объектное хранилище S3 в Beget буквально в один клик можно уже сейчас.

Заключение

Примерно 90% из генерируемых пользователями данных являются неструктурированными.

В этой ситуации S3-хранилище может помочь бизнесу хранить растущие объемы файлов отдельно от серверной инфраструктуры, не переплачивая за дисковые ресурсы и сохраняя быстрый доступ к нужной информации.

При этом экономия на хранении данных – далеко не единственная задача, которую могут помочь решить продукты Beget, например, вы также можете:

· развернуть производительный VPS с готовностью за 10 секунд и готовыми решениями для ваших задач;

· подключить мощные облачные базы данных для разработки сложных веб-сервисов и приложений;

· настроить сеть доставки контента для снижения нагрузки на сервер и увеличения скорости загрузки сайта;

· удобно управлять инфраструктурой – с Kubernetes;

· обеспечить контроль и прозрачность изменений – с Terraform.

А еще облако Beget – это:

· глобальный охват – выбирайте локацию серверов в России или Казахстане и будьте ближе к вашей аудитории;

· новейшее железо – мощные серверные решения на базе Amd Epyc с NVMe-дисками;

· надежность и стабильность – благодаря uptime 99,98% и дата-центрам Tier III (стандарт с защитой от аварийных ситуаций);

· бесплатные автоматические бэкапы – копии создаются раз в 2–5 дней и хранятся на двух независимых серверах в разных дата-центрах;

· универсальный интерфейс – единая панель для управления всеми облачными решениями;

· комфортный мониторинг с возможностью кастомизировать правила для отслеживания состояния серверов;

· защита от атак – серверы защищены на сетевом и транспортном уровне (L3/L4), а наша собственная разработка Syncookied обеспечивает защиту от SYN/ACK/DATA-флуда;

· функциональный API – управляйте серверами и доменами без необходимости заходить в панель управления.

Если у вас остались вопросы, вы хотите обсудить эту статью или просто пообщаться с коллегами по цеху и сотрудниками Beget, будем рады видеть вас в нашем уютном Telegram-чате – с удовольствием на всё ответим и пообщаемся.

Также сейчас для новых пользователей мы начисляем 10% кешбэка за первое пополнение баланса – чтобы вы могли начать хранить данные еще выгоднее с самого первого дня.

Реклама. ООО «Бегет», ИНН 7801451618, erid: 2W5zFJqF2Y9

На момент публикации (19:00 мск) полностью закрыт только короткий утренний инцидент Anthropic. У Claude ошибки остаются на Opus 4.8 и Opus 5, OpenAI применила исправление и «наблюдает за восстановлением», xAI сроков не называет. Ниже хронология по статус-страницам, цифры Downdetector, что известно о причине и что делать, если у вас на этих API завязан рабочий процесс.

• Anthropic: инцидент с 16:26 мск на Mythos 5.1, Fable 5.1, Opus 5, потом список расширился до Mythos 5, Fable 5, Opus 4.8 и Opus 4.6. К 18:25 мск все модели, кроме Opus 4.8 и Opus 5, вернулись к обычному уровню ошибок.
• OpenAI: инцидент с 17:58 мск, 19 компонентов ChatGPT и Codex в статусе «degraded», исправление применено в 18:22 мск, инцидент не закрыт.
• xAI: все восемь компонентов Grok в статусе «outage», доступность API в американских регионах по данным самой xAI около 84–85%, европейский регион 100%.
• Downdetector: до 37 тысяч жалоб на OpenAI за час (пик около 18:35 мск), около 1 400 на Claude и на Grok. Для Claude и Grok это в 20–30 раз выше обычного фона.
• Причину ни одна компания не назвала. Единый корень не подтверждён: у Cloudflare и Azure инцидентов на это время нет, а сбои начались с разницей в полтора часа.

Что и когда сломалось: хронология по статус-страницам

Время везде московское, источники: статус-страница Anthropic, страница инцидента OpenAI, статус xAI и статус Cursor, который зависит от всех троих и потому удобен как независимый свидетель.

• 15:37 — Anthropic открывает первый за день инцидент: рост ошибок у Claude Sonnet 5. Закрыт в 15:56, за 19 минут.
• 16:26 — Anthropic открывает второй инцидент: ошибки на Claude Mythos 5.1, Fable 5.1 и Opus 5. В 16:41 причина «найдена», в 16:50 список затронутых моделей расширен: Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, Opus 4.6.
• 16:41 — Cursor фиксирует деградацию «всех моделей Grok», автоматизаций, облачных агентов и агента ревью. Это первое зафиксированное время проблем у xAI: собственная статус-страница компании времени начала не показывает.
• 17:17 — Cursor подтверждает ошибки на Fable 5.1, Fable 5, Opus 5, Opus 4.8 и Opus 4.6 «из-за проблемы на стороне Anthropic».
• 17:30 — Си-Джей Авилла из developer relations Anthropic пишет в X: «Инфраструктурная проблема вызывает частичный сбой в Claude Code, API и claude.ai. Мы работаем над этим, но срока восстановления пока нет» (перевод редакции).
• 17:58 — OpenAI открывает инцидент «Elevated errors across ChatGPT and Codex». Затронуты 19 компонентов: диалоги, вход, загрузка файлов, генерация изображений, голосовой режим, поиск, Deep Research, агент, GPTs, коннекторы, браузер Atlas, Codex Web, Codex API, Codex в десктопном ChatGPT, расширение VS Code, CLI, Compliance API, ChatGPT Work и Sites.
• 18:17 — Cursor фиксирует ошибки на моделях OpenAI «из-за проблемы на стороне OpenAI».
• 18:22 — OpenAI: «Мы применили исправление и наблюдаем за восстановлением». В 18:50 та же формулировка, инцидент не закрыт.
• 18:25 — Anthropic: «Сейчас затронуты только Opus 4.8 и Opus 5. Остальные модели вернулись к базовому уровню ошибок».
• 18:33 — Cursor по Grok: «Мы нашли причину и работаем над исправлением».

Порядок важен для версии о единой причине: Claude и Grok начали сбоить в 16:26–16:41, а ChatGPT почти через полтора часа, в 17:58. У Cloudflare на статус-странице за это время инцидентов нет: последний, о росте ошибок 5xx в Гонконге, закрыт в 12:36 мск. У Microsoft Azure в истории за 3 сентября инцидентов тоже нет. Всё, что пишут о «проблеме у Azure» или «проблеме у Cloudflare», пока остаётся версией читателей, а не заявлением провайдеров.

Сколько людей это задело: цифры Downdetector

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

На OpenAI Downdetector получил около 37 тысяч жалоб на пике, около 18:35 мск. 80% жалоб касаются ChatGPT, 8% Codex, 7% приложения. Обычный фон на этом графике не виден вовсе: сотни жалоб в час против десятков тысяч.

По Claude и Grok пики около 1 400 жалоб в час при обычном фоне в 20–50. У Grok 48% жалоб на приложение, 25% на генерацию ответов, 24% на сайт. На главной Downdetector в 18:58 мск карточки OpenAI, Claude AI, Grok и Google Gemini стояли рядом со всплесками на графиках, это и есть обложка этой новости. По Gemini сервис зафиксировал рост жалоб с 18:15 мск, но Google инцидент не объявляла, а мониторинг StatusGator показывал сервис работающим. Разница в масштабах объяснима аудиторией: у ChatGPT на порядок больше пользователей, готовых пожаловаться.

Почему упали сразу трое: что известно и чего нет

Официально: Anthropic говорит об «инфраструктурной проблеме» без деталей, OpenAI ограничилась словами «расследуем» и «применили исправление», xAI не написала ничего, кроме статуса компонентов. Ни одна компания не назвала общего поставщика.

На Hacker News тред «ChatGPT and Codex Is Down» собрал 92 очка и 225 комментариев, отдельный «Ask HN: почему OpenAI, Claude и Grok упали одновременно» ещё 48 и 36. Полезного там три наблюдения. Первое: пользователи Codex CLI по всему миру получали ошибку unexpected status 404 Not Found от chatgpt.com/backend-api/codex/responses, и в идентификаторах cf-ray стояли коды аэропортов разных узлов Cloudflare: ORD, DTW, YYZ, IST. Это значит, что запрос доходил до edge-сети и отбивался на границе, а не терялся по дороге; 404 здесь не «страница не найдена», а отказ бэкенда за прокси. Второе: у части людей уже открытые сессии продолжали работать, а новые соединения не устанавливались. Третье: некоторые регионы, например Австралия, Индия и часть Европы, восстановились раньше остальных.

Самая распространённая гипотеза в обоих тредах: не общий поставщик, а каскад. Когда лёг один сервис, разработчики массово переключили агентов на соседний, и тот не выдержал нагрузки. Хронология этому не противоречит: Claude и Grok упали первыми, ChatGPT через полтора часа. Против гипотезы говорит то, что Claude и Grok сбойнули в пределах четверти часа друг от друга, а общей причины у них не видно. Отдельный контекст: 3 сентября OpenAI намекала на скорый анонс новой модели Astra (аккаунты компании писали «The stars are almost aligned»), и в тредах предполагают, что инфраструктуру перенастраивали под запуск. Подтверждений этому нет.

Для OpenAI подобные инциденты не редкость: в июле компания пережила четыре сбоя за четыре дня, после чего сбрасывала лимиты платным подписчикам ChatGPT и Codex. О компенсациях за сегодняшний сбой ни OpenAI, ни Anthropic пока не сообщали. Для Anthropic это третий инцидент за двое суток: 2 сентября Sonnet 5 отваливался на 14 минут, 3 сентября на 19, а потом начался текущий.

Что делать разработчику

• Смотреть на статус-страницы, а не на соцсети: status.claude.com, status.openai.com, status.x.ai. У xAI есть раздел «Live service data» с процентом успешных запросов по регионам, он обновляется даже без объявленного инцидента.
• Не пересоздавать аккаунт и не сбрасывать авторизацию: при частичном сбое это не помогает, а у OpenAI среди деградировавших компонентов сегодня был и Login.
• Если у вас Claude через API, переключать модель, а не провайдера: с 18:25 мск проблемы только на Opus 4.8 и Opus 5, Fable 5.1 и Sonnet 5 отвечают в штатном режиме. В Cursor это делается в выборе модели без перезапуска агента.
• Ретраи с экспоненциальной задержкой на 5xx и на 404 от backend-api: часть запросов проходит даже в разгар инцидента, но бить в API каждую секунду означает добавлять нагрузку на то, что и так лежит.
• Держать второго провайдера в конфиге, а не в голове: сегодняшний день показал, что «переключусь, если что» занимает полтора часа, если ключ и адаптер не были прописаны заранее. В Европе Grok, по данным самой xAI, весь день отвечал на 100%, регион eu-west-1 не пострадал.

Мы обновим материал, когда Anthropic, OpenAI и xAI закроют инциденты или назовут причины. Если у вас прямо сейчас не отвечает что-то из перечисленного, это не у вас одних, и сброс сессии не поможет.

Источники: Anthropic: Elevated errors for multiple models, OpenAI: Elevated errors across ChatGPT and Codex, Статус-страница xAI, Статус-страница Cursor, Си-Джей Авилла (Anthropic) о частичном сбое, Downdetector: OpenAI, Hacker News: ChatGPT and Codex Is Down

Изображение на обложке: Скриншот: Downdetector

До 1.37 для этого нужен был сторонний компонент либо alpha-гейт. Теперь это часть ядра, и владельцы очередей и batch-обработчиков могут перестать платить за поды, которые часами ждут задач. Экономия заметнее всего там, где под резервирует дорогие ресурсы: выделенные ядра или GPU. Обычным HTTP-сервисам функция не подходит в чистом виде, и авторы предупреждают об этом прямо.

• Beta по умолчанию: feature gate HPAScaleToZero включён и в kube-apiserver, и в kube-controller-manager Kubernetes 1.37.
• minReplicas: 0 работает только с объектной или внешней метрикой (например, длина очереди); HPA только на CPU и памяти API-сервер отклонит.
• Kubernetes Service не буферизует запросы, пока нет готовых подов, поэтому для HTTP нужен отдельный слой буферизации.
• Условие ScaledToZero=True отличает автоматическое уменьшение до нуля от ручной паузы: HPA не разбудит workload, который остановил не он.
• Перед откатом версии или выключением гейта нужно вернуть minReplicas не меньше 1 и поднять всё, что стоит на нуле.

Почему CPU и память для этого не годятся

Обычно HPA масштабирует по загрузке CPU или памяти, а эти метрики приходят из работающих подов. Когда реплик ноль, измерять нечего, и сигнала «пора подниматься» не будет. Объектные и внешние метрики от подов не зависят: длина очереди существует независимо от того, есть ли у неё потребители. Поэтому minReplicas: 0 требует хотя бы одной такой метрики в спецификации, а HPA, где есть только ресурсные метрики, API-сервер отклоняет.

В блоге приводится пример с метрикой Prometheus queue_consumer_lag. Чтобы HPA её увидел, нужен адаптер, который отдаёт значение через External Metrics API, например Prometheus Adapter с правилом в externalRules. Перед созданием HPA авторы советуют проверить, что метрика читается:

Если запрос не возвращает значение, сначала чинится конвейер метрик: HPA не сможет поднять workload с нуля, пока метрика недоступна. В этом случае он выставляет условие ScalingActive=False с причиной вроде FailedGetExternalMetric, и восстановить мощность придётся либо починкой метрики, либо ручным масштабированием.

Как выглядит HPA с нулём реплик

Пример из блога нацелен на Deployment queue-worker, допускает от нуля до десяти реплик и просит по одной реплике на каждые 30 задач в очереди:

Когда очередь пуста, HPA уменьшает Deployment до нуля. Когда приходят задачи, внешняя метрика по-прежнему доступна, контроллер пересчитывает число реплик и поднимает поды в пределах maxReplicas. Остальные правила HPA продолжают действовать: в частности, окно стабилизации при уменьшении по умолчанию пять минут, так что короткий провал длины очереди не снесёт всех воркеров разом. Окно настраивается через spec.behavior.scaleDown.

Есть важная деталь: Deployment нужно запускать хотя бы с одной репликой. Ручная установка нуля реплик всегда означала паузу автоскейлинга, и это поведение сохранено: HPA не разбудит workload, который остановил не он сам.

Как контроллер отличает «ноль» от «паузы»

Ноль реплик двусмыслен: либо HPA сам всё погасил, либо оператор руками остановил сервис. Разрешает это условие статуса ScaledToZero. Когда HPA уменьшает workload с одной и более реплик до нуля, он записывает ScaledToZero=True, и последующие циклы согласования знают, что нулевое состояние принадлежит контроллеру и метрики нужно продолжать читать. После подъёма условие меняется на ScaledToZero=False с причиной NotScaledToZero. Workload на нуле без условия ScaledToZero=True считается поставленным на паузу. Посмотреть условия можно командой kubectl describe hpa queue-worker.

Кому это не подходит и чем грозит откат

Плата за нулевые реплики называется cold start: HPA должен заметить изменение метрики, планировщик разместить под, приложение подняться. Для очереди, которая надёжно хранит задачи, это нормально. Для HTTP это проблема: Service в Kubernetes не буферизует запросы, пока нет готовых подов, поэтому запросы, пришедшие в «ноль», просто не будут обслужены. Запросным нагрузкам нужен отдельный буферизующий слой, и блог его не предлагает, это остаётся на стороне пользователя.

С обновлением тоже есть оговорки. В 1.37 гейт HPAScaleToZero включён по умолчанию в обоих компонентах: API-сервер принимает minReplicas: 0, а controller-manager выполняет масштабирование по условию. При поэтапном обновлении control plane создавать HPA с нулём стоит только после того, как оба компонента обновлены и гейт активен на обоих: controller-manager без гейта воспринимает нулевые реплики как ручную паузу и может оставить workload лежать. Перед выключением гейта или откатом на версию без реализации на условиях нужно перевести затронутые HPA на minReplicas: 1 и выше и поднять до одной реплики всё, что сейчас стоит на нуле.

Что делать и что дальше

1. Проверьте версию кластера: по умолчанию функция включена начиная с 1.37. Что ещё вошло в этот релиз, мы разбирали в новости про потоковое чтение коллекций из etcd: https://tproger.ru/news/kubernetes-1-37-chitaet-bolwie-kollekcii-iz-etcd-potokom-i-ekono
2. Выберите кандидатов: потребители очередей, batch-обработчики, задачи на GPU. HTTP-сервисы без буфера оставьте на minReplicas: 1.
3. Убедитесь, что метрика читается через External Metrics API, до создания HPA с нулём.
4. Стартуйте Deployment с одной репликой и следите за условиями ScaledToZero и ScalingActive в describe hpa.
5. Оцените cold start для своего образа: время подъёма пода плюс инициализация приложения задают задержку первой задачи после простоя.

Путь у функции длинный: первая alpha-реализация появилась ещё в Kubernetes 1.16, версия 1.36 добавила условие ScaledToZero и поведение контроллера, которое отличает автоматику от ручной паузы, а 1.37 включила всё по умолчанию после интеграционных и end-to-end тестов на уменьшение до нуля и подъём по внешней метрике. Дизайн описан в KEP-2021, функцией владеет SIG Autoscaling. Про GA авторы пока не говорят: следующий шаг, по их словам, собрать эксплуатационный опыт с беты; обратную связь ждут в канале #sig-autoscaling в Slack Kubernetes.

Источники: Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (блог Kubernetes, Johannes Würbach), KEP-2021: HPA supports scaling to and from zero pods, Prometheus Adapter: external metrics

Изображение на обложке: Логотип: The Kubernetes Authors

Где резервная копия теряет защиту

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

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

Быстрая синхронизация снижает RPO, то есть допустимый объём потери данных. Одновременно сокращается время, за которое команда может заметить заражение до записи данных на резервной площадке. Для восстановления нужна история версий, защищённая от изменений после записи.

Как Object Lock сохраняет версии

Object Lock реализует модель WORM, Write Once, Read Many. Записанную версию объекта нельзя изменить или удалить до окончания установленного срока. Подробно эта механика описана в документации Amazon Web Services S3.

Object Lock работает вместе с версионированием. При записи объекта под существующим ключом хранилище создаёт новую версию, а защищённая версия сохраняется. Если для бакета задано правило удержания по умолчанию, оно применяется к новым версиям автоматически. Без такого правила срок удержания нужно устанавливать для каждой версии объекта отдельно.

Само включение Object Lock ещё не защищает записанные объекты. После этого необходимо настроить retention для отдельных версий или для всех новых версий, попадающих в бакета. Примеры обеих конфигураций приведены в базе знаний Linx Cloud.

При обычном запросе на удаление S3 может создать delete marker. Объект перестанет отображаться как текущий, но его заблокированная версия сохранится. Для восстановления потребуется выбрать нужную версию или удалить маркер. Поведение delete marker при включённом Object Lock разобрано в документации AWS.

Как выбрать режим удержания

Object Lock поддерживает два режима:

• Governance: защищённую версию может удалить пользователь с разрешением s3:Bypass Governance Retention, если он явно запросит обход защиты. Это разрешение следует отделить от повседневных административных и резервных учётных записей.
• Compliance: защищённую версию нельзя удалить до окончания срока удержания, включая действиями root-пользователя. Режим также запрещает сокращать уже установленный срок.

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

Как рассчитать срок хранения

Правило 3-2-1 определяет структуру резервирования: три копии данных, два типа носителей и одна копия за пределами основной площадки. Такое определение приводит CISA в рекомендациях по резервному копированию. Глубина истории рассчитывается отдельно.

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

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

Увеличение срока влияет на стоимость: заблокированные версии занимают место и не могут быть удалены правилами жизненного цикла до окончания retention. Расчёт должен учитывать объём ежедневных изменений и количество создаваемых версий.

Что проверить перед восстановлением

Object Lock сохраняет записанную версию, но не проверяет её содержимое. Если заражённые данные попали в копию до блокировки, хранилище сохранит их вместе с остальными объектами.

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

Перед восстановлением:

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

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

Бэкапы Шрёдингера

Народная мудрость гласит: “Если никто не проверяет бэкапы, они одновременно существуют и не существуют. Чаще всего — второе.”

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

Как часто надо проверять? Чем чаще, тем лучше.

Идеальный вариант — сразу после завершения создания резервной копии. Да, это непросто в настройке (хотя некоторые СРК умеют в автоматическую проверку), да, это затратно с точки зрения ресурсов и стоимости исходящего трафика (если он есть в тарифе). Но все эти недостатки нивелируются максимальным снижением риска, что в час X что-то пойдёт не так.

Компромиссный вариант — восстанавливаться из резервных копий хотя бы раз в месяц. Так получится выявить системные ошибки в архитектуре, баги ПО, недоработки в самом процессе восстановления да и сверится с целевой скоростью восстановления (RTO) поможет.

Как сервисы Linx Cloud участвуют в этой схеме

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

Объектное хранилище S3 поддерживает версионирование и Object Lock. Режим Governance или Compliance, а также срок удержания задаются для отдельных объектов или всего бакета. А вариант тарификации без дополнительной оплаты за исходящий трафик позволит на регулярной основе тестировать восстановление, не боясь переплатить за трафик.

Резервное копирование для бизнеса используется для создания и хранения копий виртуальных машин, серверов и баз данных.Аварийное восстановление (DRaaS) отвечает за максимально быстрый запуск инфраструктуры на резервной площадке при аварии. Набор сервисов зависит от требуемой глубины хранения, времени восстановления и устройства основной инфраструктуры.

Порядок действий во время атаки шифровальщика отдельно разобран в материале Linx Cloud «Киберсхватка: как действовать во время атаки вируса-шифровальщика».

Что должно быть настроено

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

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

• Март 2026 года: API-ключ для инференса публичных моделей украден с личного EC2-инстанса исследователя, где стояло самодельное приложение за Google-аутентификацией.
• Приложение имело уязвимость fail-open: при ошибке проверки доступ открывался; инстанс был намеренно публичным за Google-аутентификацией.
• Атакующий попросил агента показать ключ, получил его и добавил на сервер собственный SSH-ключ; чужие запросы шли около трёх недель.
• Май 2026 года: сканирование сервисов, подбор паролей по утёкшим базам, попытки через OAuth-токены; в публичном просмотрщике транскриптов нашли ошибку с read-only SQL, признаков её эксплуатации нет.
• METR остановила и сняла образ инстанса, заменила учётные данные; описанные меры актуальны на 30 июля 2026 года.

Как украли ключ

Исследователь METR поднял на личном инстансе EC2 небольшое веб-приложение, написанное с помощью ИИ, и защитил его входом через Google. В коде была классическая ошибка fail-open: если проверка авторизации по какой-то причине не срабатывала, приложение считало пользователя допущенным, а не отказывало. Инстанс намеренно был публичным за входом через Google, и ошибка fail-open сняла эту защиту; этого хватило.

The vibe-coded app included a fail-open vulnerability.

Дальше атакующий, по описанию METR, попросил агента показать ключ API, и тот его раскрыл, а для постоянного доступа добавил на сервер собственный SSH-ключ. Ключ использовали для запросов к публичным моделям примерно три недели. Заметить это оказалось трудно по двум причинам: METR не платила за эти кредиты деньгами, так что счёт не рос, а внутренняя панель METR не показывала запросы, отклонённые по лимитам, для всех пользователей ключа.

Вторая волна: май

В мае METR зафиксировала другую активность: сканирование публичной инфраструктуры, перебор паролей по утёкшим базам и попытки получить OAuth-токены. Попутно выяснилось, что публичный просмотрщик транскриптов позволял выполнять SQL-запросы только на чтение, но через эту ошибку в теории можно было добраться до неопубликованных данных оценок. Признаков, что атакующие этим воспользовались, компания не нашла. Описанные меры, по словам METR, актуальны на 30 июля 2026 года.

Правила, которые из этого следуют

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

Контекст

METR получает от разработчиков моделей ранний доступ для оценок безопасности, поэтому её инфраструктура — заметная цель. То, что оба инцидента пришлись на периферию (личный сервер, публичный просмотрщик), а не на основные системы, говорит скорее о сегментации, чем об удаче. Но именно периферия и есть то место, где у большинства команд лежат ключи «на время». Сумму METR оценивает примерно в $600 тыс. бесплатных кредитов, которые она не оплачивала деньгами.

Источник: Security update (METR, 31 августа 2026)

Изображение на обложке: METR

Для обычного пользователя PyCharm без плагина Cadence новость ничего не меняет. Для тех, кто подключал сервис, JetBrains даёт жёсткую рекомендацию: все учётные данные, к которым Cadence имел доступ, считать скомпрометированными и заменить, включая ключи облаков, токены GitHub и GitLab, SSH-ключи и ключи подписи. Региональной разбивки пострадавших компания не даёт; если сервис у вас был подключён, рекомендации те же.

• Период доступа атакующих: 8–24 августа 2026 года; JetBrains заметила эксплуатацию 23 августа и отключила сервер 24-го.
• Вектор: CVE-2026-63077 в TeamCity, который оркестрировал облачные задачи Cadence; патч на сервер не поставили.
• Утекли имена пользователей, реальные имена, email, время последнего входа и IP; полный бэкап сервера Cadence за 2024 год; AWS IAM-пользователи и их учётные данные; файлы в S3-бакетах JetBrains.
• Мог быть доступен исходный код, синхронизированный из PyCharm; затронуты ли бакеты клиентов, компания не установила.
• Токены плагина Cadence в PyCharm аннулированы; JetBrains просит заменить все секреты, доступные сервису, и проверить репозитории, облака, реестры пакетов и системы деплоя.

Что такое Cadence и при чём тут TeamCity

Cadence — облачный сервис JetBrains, который через необязательный плагин PyCharm позволяет отправлять тяжёлые вычисления, например обучение моделей, на удалённые машины. Чтобы запускать эти задачи, сервис использовал TeamCity, собственный CI-сервер JetBrains, как оркестратор облачных нагрузок. Именно в этой инсталляции TeamCity была уязвимость CVE-2026-63077, позволяющая удалённо выполнять команды без входа. Компания признаёт, что для этого сервера действовало то же правило, что и для остальных: патчить сразу после выхода исправления. Правило не сработало.

The server should have been patched, but it was not.

Хронология

• 8 августа: атакующие воспользовались уязвимостью TeamCity и получили доступ к серверу api.cadence.jetbrains.com.
• 8–24 августа: период активности; в это время были доступны данные пользователей, бэкап, учётные данные AWS и файлы в S3.
• 23 августа: JetBrains обнаружила эксплуатацию.
• 24 августа: сервер отключён, токены плагина Cadence в PyCharm аннулированы.
• 31 августа: первое обновление отчёта с перечнем затронутых данных.
• 1 сентября, 12:05 CEST: второе обновление; расследование ещё включает несколько проверок.

Что именно утекло

Компания перечисляет четыре категории. Первая — персональные данные пользователей Cadence: логины, реальные имена, адреса почты, время последнего входа и IP-адрес, с которого он был. Вторая, самая неприятная, — полная резервная копия сервера Cadence за 2024 год: JetBrains подтвердила, что атакующие получили доступ к её содержимому, а в нём могло быть всё, что сервис хранил на тот момент. Третья — AWS IAM-пользователи с учётными данными, то есть доступ к части облачной инфраструктуры JetBrains. Четвёртая — файлы в S3-бакетах компании; проверить, были ли затронуты бакеты клиентов, JetBrains на момент публикации не смогла.

We have confirmed that the threat actors accessed data contained in the Cadence server backup from 2024.

Отдельно компания допускает, что атакующим мог быть доступен исходный код, который пользователи синхронизировали из PyCharm в Cadence для запуска задач. Доказательств извлечения секретов из текущего окружения сервиса, по словам JetBrains, не найдено. Между «не найдено доказательств» и «не было» большая разница, и компания сама рекомендует исходить из худшего: список секретов, которые нужно считать скомпрометированными, включает облачные учётные данные, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи и ключи подписи.

Что сделать, если вы пользовались Cadence

• Проверьте в PyCharm, стоял ли плагин Cadence; его токены JetBrains уже аннулировала, но это закрывает только вход в сервис.
• Замените всё, что было доступно из задач Cadence: ключи AWS, Google Cloud и Azure и любых других облаков, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи, ключи подписи.
• Пересмотрите репозитории, которые синхронизировались в сервис, на предмет секретов в коде и истории коммитов: они могли уйти вместе с исходниками.
• Проверьте журналы облачных аккаунтов за 8–24 августа на действия от имени сервисных пользователей, которыми пользовался Cadence; JetBrains отдельно называет AWS и S3, IAM, реестры пакетов и системы деплоя.
• Если в 2024 году вы пользовались Cadence, а потом ушли, ваши данные могли находиться в бэкапе за 2024 год; состав пользователей в нём компания не раскрыла.
• Ждите финальный отчёт: расследование не закончено, и список затронутых данных может расшириться.

Урок для всех остальных

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

Источник: Cadence security incident, August 2026 (JetBrains)

Изображение на обложке: JetBrains

Если у вас на Workers Free крутится пет-проект, бот или небольшой сервис с базой в D1, это касается напрямую: в один день трафик чуть выше обычного, и после обеда по Москве запросы к базе начинают завершаться ошибкой до трёх часов ночи, а приложение без обработки этой ошибки показывает её пользователям. Cloudflare обещает письмо при достижении лимита, но письмо не починит прод.

• Лимиты Workers Free для D1: 5 млн прочитанных строк и 100 тысяч записанных строк в сутки, 5 ГБ хранилища на аккаунт.
• С 1 сентября при превышении запросы к D1 завершаются ошибкой до сброса счётчика в 00:00 UTC (03:00 мск); сохранённые данные не затрагиваются.
• На Workers Paid за $5 в месяц включено 25 млрд чтений и 50 млн записей в месяц, дальше $0,001 за миллион прочитанных строк и $1 за миллион записанных; 5 ГБ хранилища включено, дальше $0,75 за ГБ в месяц.
• Строки считаются по факту прочитанного движком, а не по числу строк в ответе: SELECT без индекса по таблице в 100 тысяч строк — это 100 тысяч чтений.
• Cloudflare советует посмотреть статистику запросов за прошлые дни и добавить индексы: полное сканирование таблицы съедает лимит чтений быстрее всего.

Что изменилось на самом деле

Сами лимиты не новые, они давно указаны на странице тарифов. Изменился режим их применения: до 1 сентября Cloudflare не блокировала запросы при превышении, теперь блокирует. Ограничение действует и на вызовы из кода Worker через биндинг, и на REST API, которым пользуются внешние интеграции и админки. В тексте ошибки предлагается два выхода: перейти на платный план или подождать до завтра.

Upgrade to a paid plan or wait until tomorrow.

Компания подчёркивает, что хранилище остаётся нетронутым: речь только о временной недоступности запросов, а не о потере или заморозке данных. Счётчик сбрасывается в полночь по UTC, в три часа ночи по Москве. Уведомление по электронной почте приходит при достижении дневного лимита, и Cloudflare отдельно рекомендует посмотреть активность запросов за прошлые дни, чтобы понять, насколько проект близок к границе.

Почему один запрос может стоить 100 тысяч чтений

Главная ловушка D1 — учёт по прочитанным строкам, а не по запросам. Запрос SELECT * FROM events WHERE user_id = ? без индекса по user_id заставляет движок пройти всю таблицу, и каждая пройденная строка засчитывается в лимит, даже если в ответе одна запись. Поэтому небольшой сервис с парой тысяч посетителей в день может упереться в 5 млн чтений на одном неудачном запросе в цикле. Cloudflare в changelog прямо называет виновника: запросы с полным сканированием таблиц, и советует индексы как первое средство.

Сколько строк реально прочитал запрос, D1 возвращает в объекте meta ответа: поля rows_read и rows_written. Именно по ним, а не по числу вызовов, стоит оценивать, насколько вы близки к лимиту. Суммарную картину за день показывают GraphQL Analytics API и дашборд Cloudflare; страница тарифов перечисляет все три способа отслеживать расход.

С записями та же логика: учитываются записанные строки, а не вызовы. Объединение вставок в один батч сокращает число запросов и задержку, но не уменьшает rows_written, так что от лимита в 100 тысяч записей в сутки оно не спасает. Единственный способ уложиться — писать меньше строк: агрегировать события, не хранить в D1 логи на каждый запрос, выносить телеметрию в Analytics Engine или KV.

Сколько стоит платный план

Workers Paid стоит $5 в месяц и снимает дневные лимиты. По странице тарифов в него включены 25 млрд прочитанных строк и 50 млн записанных строк в месяц, сверх этого чтение стоит $0,001 за миллион строк, запись — $1 за миллион строк. Хранилище: 5 ГБ включено, дальше $0,75 за гигабайт в месяц. Бесплатный план даёт те же 5 ГБ, но при их превышении не тарифицирует, а блокирует новые записи и изменение схемы; но 5 млн чтений и 100 тысяч записей в сутки, то есть примерно 150 млн чтений и 3 млн записей в месяц.

Что сделать до вечера

• Откройте статистику D1 в дашборде за последние две недели: если пиковые дни выше 3–4 млн чтений, по нашей оценке вы в зоне риска; порог редакционный, Cloudflare его не задаёт.
• Пройдитесь EXPLAIN QUERY PLAN по самым частым запросам и добавьте индексы там, где видите SCAN.
• Кэшируйте горячие ответы в KV или Cache API: одно чтение из кэша вместо тысячи строк из базы.
• Записи ограничены сильнее чтений: считаются записанные строки, а не вызовы, батчи не помогут; пишите меньше строк, агрегируйте события и не кладите логи в D1 на каждый запрос.
• Обрабатывайте ошибку D1 в коде: показывайте пользователю понятное сообщение и отдавайте кэшированные данные, а не пятисотую страницу.

Контекст

D1 вышла из беты в 2024 году как «SQLite на краю сети» для Workers: база живёт рядом с кодом и тарифицируется по строкам, а глобальная репликация чтения доступна как отдельная бета-функция, а не по процессорному времени. Учёт по строкам — осознанный выбор Cloudflare, и до сих пор он был безболезненным для бесплатных проектов. Для D1 «бесплатно» теперь читается буквально: в пределах квоты сервис работает, за пределами останавливается, а не копит счёт. Распространится ли такой режим на другие бесплатные лимиты Workers, changelog не говорит.

Источники: D1 free tier limit enforcement (Cloudflare Changelog), D1 pricing

Изображение на обложке: Cloudflare

Выручка сервисов и инфраструктуры для работы с ИИ составила 19,3 млрд рублей, или 51,3% общей выручки компании. За первые восемь месяцев 2026 года объём потребления языковых моделей на платформе Cloud.ru в токенах вырос в 18 раз. Общий объём потребления достиг 480 млрд токенов.

В первом полугодии Cloud.ru продолжил стратегию по расширению практического применения облачных сервисов и ИИ-технологий. Компания предоставляет сервисы крупнейшим потребителям из финтеха, ритейла и ИТ. Чтобы стоимость инфраструктуры и сервисов не ограничивала масштабирование проектов крупнейших потребителей, Cloud.ru в течение длительного времени удерживает цены. Это позволяет клиентам активнее переходить от экспериментов и пилотов к коммерческому внедрению.

«Сегодня один из главных вызовов для бизнеса и общества — переход к широкому практическому применению искусственного интеллекта. Скорость этого перехода зависит не только от технологий. Это вопрос готовности людей и организаций к изменениям, потому что в центре трансформации остаётся человек. Наша задача — формировать технологическую и экономическую основу для ответственного внедрения ИИ: безопасного, эффективного и сбалансированного. Мы хотим, чтобы компании могли свободнее экспериментировать, находить эффективные сценарии и масштабировать их, а современные ИИ-инструменты становились доступнее людям», — прокомментировал Михаил Лобоцкий, генеральный директор Cloud.ru.

Стабильное финансовое положение Cloud.ru позволяет продолжать инвестиции и проводить выбранную ценовую политику. В первом полугодии 2026 компания подтвердила высокую оценку кредитоспособности, получив кредитные рейтинги ruАА+ от Эксперт РА и АА+ (RU) от АКРА. Также компания успешно реализовала дебютный выпуск облигаций.

«Cloud.ru сохраняет высокую рентабельность и низкую долговую нагрузку. Это позволяет нам инвестировать в инфраструктуру, безопасность и новые продукты и одновременно поддерживать ценовые условия, стимулирующие рост потребления у крупнейших клиентов. В первом полугодии мы вышли на публичный долговой рынок, диверсифицировав источники финансирования. При этом отношение чистого долга к EBITDA LTM за год снизилось с 0,60x до 0,35x. Устойчивая финансовая позиция позволяет нам принимать решения с расчётом на долгосрочный рост бизнеса и рынка», — отметила Наталия Толченникова, финансовый директор Cloud.ru.

В первом полугодии 2026 года Cloud.ru инвестировал 8,5 млрд рублей в закупку оборудования, разработку программного обеспечения и другие нематериальные активы. Основные направления инвестиций — инфраструктура, безопасность и новые технологии.

Инфраструктура Cloud.ru включает более 46 тыс. единиц ИТ-оборудования, в том числе более 32 тыс. серверов, размещённых в девяти дата-центрах. Общая мощность используемых стоек составляет 58 МВт.

В сфере безопасности Cloud.ru развивает защищённые облачные платформы для государства и крупного бизнеса. Решения компании позволяют размещать государственные информационные системы и объекты критической информационной инфраструктуры и соответствуют наиболее строгим требованиям российских регуляторов. В ИИ-направлении компания развивает платформы и сервисы для практического применения технологий и расширяет доступ к ним как для корпоративных, так и для массовых пользователей.

Cloud.ru — один из крупнейших облачных и ИИ-провайдеров России. Компания основана в 2019 году и за несколько лет вошла в число лидеров рынка инфраструктурных, платформенных, а также ИИ-решений. В портфеле Cloud.ru — более 130 инфраструктурных и платформенных сервисов, публичное облако Cloud.ru Evolution на базе собственных технологий, аттестованная инфраструктура для размещения ГИС и КИИ, платформа для частных и гибридных облаков Cloud.ru Evolution Stack, а также цифровая среда для промышленной работы с генеративным ИИ — AI Factory. В команде компании — более 2 000 специалистов в области ИТ, кибербезопасности и ИИ.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFGH4yKw

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

По прогнозу Gartner, мировые расходы на публичные облачные сервисы в 2025 году должны были достигнуть $723,4 млрд, а к 2027 году около 90% организаций будут использовать гибридные облачные подходы. При этом локальная инфраструктура не исчезает: исследование Uptime Institute за 2025 год показало, что 45% рабочих нагрузок по-прежнему размещаются в корпоративных дата-центрах.

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

Критерии выбора инфраструктурной модели

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

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

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

Доступность и восстановление. Важно определить, какой простой допустим и насколько быстро должны восстанавливаться сервисы и данные. Обычно эти требования описывают через показатели RTO — допустимое время восстановления — и RPO — допустимый объем потерянных данных.

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

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

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

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

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

Что на самом деле требуют регуляторы

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

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

Похожий принцип действует при соблюдении PCI DSS — стандарта защиты данных платежных карт. Облачный провайдер может отвечать за безопасность физической инфраструктуры и платформы, но это не освобождает клиента от настройки доступов, защиты приложений и контроля обработки данных. PCI Security Standards Council прямо описывает безопасность в облаке как разделенную ответственность, границы которой должны быть определены между заказчиком и поставщиком.

Собственные серверы: когда контроль важнее гибкости

Собственная инфраструктура, или on-premise, означает, что компания приобретает оборудование, размещает его в серверной или дата-центре и самостоятельно отвечает за эксплуатацию: обновления, безопасность, резервное копирование и восстановление после сбоев.

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

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

Однако контроль имеет свою цену. Покупка серверов — только начало. В течение всего срока эксплуатации компания оплачивает:

• замену и обслуживание оборудования;
• лицензии и обновления программного обеспечения;
• электропитание и охлаждение;
• каналы связи;
• резервные площадки;
• работу инженеров и специалистов по безопасности.

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

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

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

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

Облако: скорость становится конкурентным преимуществом

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

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

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

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

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

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

Почему компании не переносят в облако всё

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

Первая причина — сложность миграции. Крупный ритейлер может быстро развернуть в облаке мобильное приложение или новый аналитический сервис. Но перенос старой ERP-системы, связанной со складским оборудованием, бухгалтерией и десятками внутренних приложений, потребует переработки интеграций и бизнес-процессов.

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

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

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

Частное облако: контроль без собственной серверной

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

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

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

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

Гибридная инфраструктура – давно не компромисс

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

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

Например:

• финансовые данные и внутренние системы работают в локальном контуре или частном облаке;
• веб-приложения размещаются в публичном облаке;
• тестовые среды создаются по мере необходимости;
• резервные копии хранятся на отдельной площадке;
• дополнительные мощности подключаются во время пикового спроса.

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

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

Когда гибридная инфраструктура оправдана

Гибридный подход стоит рассмотреть, если компания сталкивается сразу с несколькими условиями:

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

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

Как различаются основные модели

Частное облако Linx как элемент гибридной инфраструктуры

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

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

Linx предоставляет облачные ресурсы по модели IaaS, частные облака, сервисы резервного копирования и аварийного восстановления, а также услуги размещения оборудования и объединения площадок. Это позволяет построить гибридную архитектуру, в которой собственное оборудование, выделенная облачная среда и дополнительные вычислительные ресурсы работают как части единого IT-ландшафта.

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

Что делать на практике

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

1. Составьте карту систем. Отдельно перечислите приложения, базы данных, аналитические платформы, хранилища, тестовые контуры и средства резервного копирования.
2. Зафиксируйте среднюю и пиковую нагрузку. Определите, какие системы работают стабильно, а какие испытывают сезонные или непредсказуемые скачки.
3. Определите требования к доступности. Укажите допустимое время простоя, RTO и RPO для каждой системы.
4. Проверьте требования к данным. Уточните, где должна находиться информация, какие сертификаты и документы нужны от поставщика и кто отвечает за каждый уровень защиты.
5. Рассчитайте полную стоимость владения. Сравнивайте не цену сервера и тариф облака, а все расходы за несколько лет: оборудование, лицензии, персонал, обслуживание, резервирование и масштабирование.
6. Оцените возможности команды. Определите, какие компоненты специалисты компании готовы поддерживать самостоятельно, а какие рациональнее передать провайдеру.
7. Учтите стоимость перехода. В расчеты должны входить миграция, изменение приложений, тестирование, обучение сотрудников и возможные простои.
8. Выберите среду для каждой нагрузки отдельно. Критичные и стабильные системы можно оставить в контролируемом контуре, а переменные, временные и быстрорастущие нагрузки — разместить в облаке.

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

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

Как составить карту нагрузок

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

Для каждой нагрузки нужно ответить по пунктам на несколько вопросов:

• Какие данные она хранит и какие требования распространяются на их обработку;
• Какую задержку допускает приложение и где находятся его пользователи и зависимые системы;
• Насколько предсказуемо потребление CPU, памяти, диска и сетевого трафика;
• Какие интеграции перестанут работать при потере связи между площадками;
• Каковы целевые RTO и RPO: допустимое время восстановления и допустимая потеря данных.

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

Как связать площадки

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

Для связи офисов, ЦОД и облачных ресурсов используют выделенное подключение к сети провайдера, например, по схеме L2VPN, либо VPN через интернет. L2VPN объединяет сегменты на канальном уровне, а необходимость дополнительного шифрования определяют по модели угроз и требованиям к данным.

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

Какие задачи решает гибридное облако

Первый сценарий связан с данными, для которых установлены особые требования.

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

Распределённые команды могут работать с общими средами разработки в облаке. Dev- и staging-среды можно разместить в Managed Kubernetes. Отдельные кластеры обеспечат изоляцию от производственной среды. Если достаточно раздельного масштабирования, можно использовать разные пулы узлов внутри одного кластера. Доступ настраивают через единую систему учётных записей, а конфигурации и версии инструментов фиксируют для всех участников. Производственный релиз при этом проходит в контуре, выбранном для рабочей нагрузки.

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

Облачная площадка также может принимать резервные копии из локальной инфраструктуры. Задания создают в системе резервного копирования, а готовые копии передают в облачное хранилище по настроенному каналу. Площадка должна находиться в отдельном домене отказа относительно основной инфраструктуры. Если после сбоя нужно быстро запустить всю инфраструктуру, резервное копирование дополняют DRaaS и заранее описывают порядок восстановления сервисов.

Объектное хранилище может стать общим слоем для архивов, медиаконтента, логов и резервных копий. Приложения из разных сред обращаются к данным по S3 API, а правила доступа и сроки хранения задаются централизованно. Мы отдельно разбирали, где объектное хранилище действительно помогает, а где не заменит файловую систему. Перед внедрением нужно проверить совместимость приложений с конкретной реализацией S3 API и стоимость сетевого обмена. Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище с поддержкой S3 API.

Порядок перехода

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

Как посчитать стоимость

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

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

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

Как защитить обе среды

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

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

До запуска рабочей нагрузки проверьте следующие элементы:

• Классификацию данных и разрешённые направления их передачи между площадками.
• Единую модель ролей, многофакторную аутентификацию и регулярный пересмотр прав.
• Шифрование трафика и хранимых данных, а также порядок управления ключами.
• Сегментацию сетей и правила доступа между приложениями, средами и административными зонами.
• Централизованный сбор событий, аудит действий и передачу сигналов в систему мониторинга безопасности.
• Защиту резервных копий от изменения и удаления, сроки хранения и регулярные тесты восстановления.

Как подготовить восстановление

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

Резервные копии позволяют восстановить данные до точки, которую определяет RPO. DR-план описывает последовательность запуска приложений, сетей и зависимых сервисов. Во время тестов команда проверяет, укладывается ли восстановление в заданные RTO и RPO.

Какие сервисы Linx Cloud использовать

В Linx Cloud публичную часть гибридной схемы можно построить на IaaS. Для изолированной среды доступна платформа частного облака. Площадки соединяются сетевым каналом, после чего команда распределяет приложения и данные по согласованной карте нагрузок.

Для защиты данных доступны резервное копирование в облако, DRaaS и объектное хранилище S3. Конкретный набор сервисов зависит от требуемого времени восстановления, объёма данных, используемых платформ и выбранной модели ответственности.

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

Как работают Kubernetes Deployments

Начать можно с руководства по Kubernetes Deployments DevOps-инженера Пуру Туладхара. Автор объясняет, как Deployment управляет ReplicaSet и подами, поддерживает нужное количество реплик и выполняет обновления приложения.

В Kubernetes Deployment встроены две стратегии обновления: RollingUpdate (постепенное обновление подов) и Recreate (полная остановка старой версии перед запуском новой). Canary- (канареечная — постепенное открытие новой версии части пользователей) и Blue-Green-выкладку (сине-зелёная — переключение трафика между двумя параллельными версиями) собирают с помощью нескольких Deployment и дополнительного управления трафиком. Для сложной маршрутизации могут потребоваться Ingress-контроллер, API-шлюз или service mesh. Среди практических советов: держать K8s-конфигурации в системе контроля версий и подключать их к CI/CD-конвейеру, для сбора метрик можно использовать Prometheus, а для их визуализации — Grafana. Набор доступных показателей зависит от источников данных и настроенных экспортёров.

Более компактный формат у подборки Kubernetes 101 под лицензией Apache 2.0. У репозитория около полутора тысяч звёзд на GitHub, а материал разбит на четыре блока: базовые советы по Dockerfile, инфраструктура (безопасность, сети, нагрузки), ключевые концепции Kubernetes с той же канареечной и сине-зелёной выкладкой и короткий финальный раздел про деплой и ревью.

Развернуть кластер без лишних компонентов

Пошаговая инструкция по запуску K8s-кластера ориентирована на минимальный набор компонентов на виртуальных машинах с Debian 11. Прежде чем переходить к развёртыванию самого кластера, автор отключает swap, загружает модули ядра overlay и br_netfilter, а затем устанавливает kubelet, kubeadm, kubectl и CRI-O. В современных версиях Kubernetes swap можно оставить включённым при соответствующей настройке kubelet, хотя по умолчанию он по-прежнему не запускается на Linux-узле с активным swap.

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

Уточнение: материал опубликован в мае 2023 года, поэтому его стоит использовать для знакомства с устройством кластера, а команды перед запуском проверять с актуальной документацией Kubernetes и CRI-O.

Официальные рекомендации

Компактный гайд от GitLab показывает связку GitLab Agent, CI/CD и FluxCD. В примере конвейер упаковывает Kubernetes-манифесты в OCI-артефакт и помещает его в GitLab Container Registry, после чего FluxCD получает и применяет артефакт в кластере. Одной из практик оттуда является использование OCI-репозитория как кеширующего слоя между Git и FluxCD: конвейер GitLab упаковывает манифесты в OCI-артефакт и отправляет его в реестр. FluxCD следит за указанным OCIRepository, получает новую версию артефакта и применяет содержащиеся в нём манифесты.

Некоторые разделы доступны только в платных редакциях GitLab. Остальная часть руководства показывает общую схему GitOps: конвейер упаковывает манифесты в OCI-артефакт, а Flux получает его из OCI-репозитория и применяет в кластере. Источником истины при этом остаётся Git, а OCI-репозиторий работает лишь промежуточным слоем доставки.

Свой блок практик есть и у самой команды Kubernetes. В нём собраны и базовые пункты вроде «указывайте стабильные версии API», и более прикладные советы по сервисам, меткам и работе с kubectl. Разработчики рекомендуют избегать подов без привязки к ReplicaSet или Deployment и не задавать hostPort напрямую.

Как устроен Kubernetes у нас в Linx Cloud

Кластеры работают в режиме Multi Master: etcd работает в кластерном режиме на выделенных SSD-дисках, поэтому отказ одного мастера не останавливает работу остальных. Хранение данных построено на нескольких storage-классах: SSD Ceph, HDD Ceph, геораспределённый Ceph между дата-центрами, а также блочные диски по iSCSI и файловое хранилище с NFS-протоколом для legacy-приложений. Кластер масштабируется автоматически через Cluster Autoscaler: узлы добавляются и удаляются по нагрузке. Создать и удалить кластер можно через панель управления, API или собственный Terraform-провайдер.

Более свежая часть платформы — Kubernetes as a Service на базе Deckhouse Kubernetes Platform: встроенный мониторинг, управление сертификатами и безопасность из коробки, без ручной настройки инфраструктуры. Конкретный состав компонентов и версии для обеих линеек стоит уточнять у технической команды Linx Cloud перед внедрением. Документация по Kubernetes у крупного облачного провайдера обновляется часто, и часть деталей может не совпадать с формальной датой последней правки страницы.

Open Source-инструменты для Kubernetes

Glasskube был менеджером K8s-пакетов, вдохновлённым Homebrew, npm и apt: каждое обновление проходило проверку на наборе тестов, а в каталоге были доступны Ingress-NGINX, Kube Prometheus Stack, cert-manager и другие распространённые компоненты Kubernetes. В 2024 году проект вошёл в CNCF Landscape. Но 17 июня 2026 года репозиторий заархивирован владельцем и переведён в режим read-only — для нового проекта Glasskube уже не стоит рассматривать как активное решение, хотя документация (архитектура, установка на разные ОС, шаблон для ArgoCD) остаётся доступной, если инструмент уже внедрён.

K0rdent запустила Mirantis в начале 2025 года как инструментарий для проектирования распределённых сред управления контейнерами (DCME). 0rdent разворачивают как управляющую платформу. Через Cluster API он создаёт и обновляет дочерние кластеры в облачной, локальной или гибридной инфраструктуре. Набор доступных провайдеров и дополнительных сервисов зависит от версии и конфигурации. В мае 2026 года кластеры, развёрнутые и управляемые через k0rdent, прошли проверку CNCF Kubernetes v1.35 на соответствие требованиям conformance и получили статус Certified Kubernetes; сам k0rdent при этом включён в CNCF Landscape как management-платформа для сертифицированных дистрибутивов. В документации есть быстрый старт, настройка управляющего кластера и примеры конфигураций.

DeployKF разработчики описывают как платформу, которая берёт лучшее из Kubeflow, Airflow и MLflow, чтобы дать любому пользователю Kubernetes возможность строить ML-платформу без экспертизы в MLOps. На практике готова пока только экосистема Kubeflow: интеграцию с Airflow и MLflow сами разработчики помечают как «coming soon» в своей документации. Сейчас работают централизованная система конфигураций и интеграция с Istio, cert-manager, Kyverno, S3 и MySQL, хотя раздел про Kyverno в документации тоже пока не завершён.

Managed Kubernetes как сервис от Linx Cloud

Управлять кластером самостоятельно необязательно: у нас есть платформа для развёртки, масштабирования и мониторинга контейнерных приложений на основе Deckhouse Kubernetes Platform. По сравнению с «ванильной» конфигурацией она добавляет метрики и дашборды для мониторинга, готовые компоненты аутентификации и авторизации, преднастроенные Flannel или Cilium для сети.

Подробный разбор возможностей и интерфейса сервиса есть в статье на Хабре, со скриншотами или на сайте Linx Cloud. Сервис можно протестировать напрямую и задать нам вопросы по использованию.

Ответственность распределяется между сторонами, а ее границы зависят от модели облачного сервиса, состава подключенных услуг и условий договора. В базовой IaaS-инфраструктуре провайдер может поддерживать работоспособность серверов, систем хранения и гипервизоров, а клиент — администрировать операционные системы и приложения. При подключении управляемой базы данных, резервного копирования или DRaaS часть операций дополнительно поставщик берет на себя.

Такое распределение называют моделью разделённой ответственности, или Shared Responsibility Model. Она определяет, какие компоненты обслуживает провайдер, какие остаются под управлением клиента и кто отвечает за результат. Состав задач зависит от выбранной услуги, поэтому его нужно проверять в документации провайдера и закреплять в договоре.

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

В Linx Cloud границы ответственности для IaaS есть в отдельной RACI-матрице: в ней указано, какие операции выполняет провайдер, какие — клиент, а где нужны обе стороны. Документ открытый, поэтому можете посмотреть: матрица распределения ответственности Linx Cloud IaaS.

Почему возникают споры об ответственности

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

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

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

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

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

Что такое модель разделенной ответственности

Эта модель (Shared Responsibility Model) описывает, какие уровни информационной системы обслуживает провайдер, а какие остаются под управлением заказчика.

Облачная система состоит из нескольких слоев:

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

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

Однако даже в SaaS часть ответственности остается у заказчика. Компания по-прежнему решает, кому выдавать доступ, какие данные загружать в систему, какие права назначать сотрудникам и как действовать при увольнении пользователя.

Модель разделенной ответственности применяется и при выполнении отраслевых требований. Например, PCI Security Standards Council прямо рассматривает безопасность облачной среды как совместную ответственность поставщика и клиента: стороны должны прописать обязанности и утвердить их для каждого применимого требования.

За что обычно отвечает облачный провайдер

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

Площадка и физическая инфраструктура

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

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

Виртуализация и облачная сеть

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

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

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

Доступность ресурсов и границы SLA

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

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

Что остается на стороне бизнеса

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

Архитектура системы

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

• какие компоненты нужно дублировать;
• в каких зонах или на каких площадках их размещать;
• как переключать нагрузку;
• какие RTO (за сколько сервис должен вернуться в работу) и RPO (какой объем данных допустимо потерять) требуются бизнесу;
• сколько ресурсов понадобится при пиковом потреблении.

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

Операционные системы

В базовом IaaS клиент сам отвечает за операционные системы внутри виртуальных машин:

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

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

Приложения и базы данных

Заказчик отвечает за программное обеспечение, которое он разворачивает поверх инфраструктуры:

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

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

Пользователи и права доступа

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

Поэтому бизнес обычно отвечает за:

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

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

Данные

Компания определяет, какие данные размещаются в облаке, кто имеет к ним доступ и как долго они должны храниться. Если речь идет о персональных данных, передача инфраструктуры провайдеру не снимает обязанностей с оператора. Статья 19 Федерального закона № 152-ФЗ требует от оператора принимать необходимые правовые, организационные и технические меры защиты либо обеспечивать их принятие. Поэтому заказчику необходимо определить:

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

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

Кто отвечает за информационную безопасность

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

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

Заказчик отвечает за безопасность ресурсов, развернутых внутри облачной среды:

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

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

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

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

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

Кто должен настраивать резервное копирование

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

• отказоустойчивость физической платформы;
• репликацию системы хранения;
• снимки виртуальных машин;
• резервные копии;
• аварийное восстановление на другой площадке.

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

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

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

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

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

Кто отвечает за аварийное восстановление

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

Провайдер может отвечать за:

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

Заказчик обычно отвечает за:

• решение активировать DR-план;
• определение приоритетов систем;
• выбор допустимой точки восстановления;
• проверку приложений;
• подтверждение целостности данных;
• работу внешних интеграций;
• информирование сотрудников и клиентов;
• решение о возвращении на основную площадку.

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

Как ответственность меняется в IaaS, PaaS и SaaS

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

Таблица показывает общий принцип распределения ответственности, но фактические границы зависят от состава услуг и условий договора. В IaaS часть задач можно передать провайдеру через дополнительные сервисы, например администрирование ОС, резервное копирование или мониторинг. При этом даже управляемые сервисы не снимают с клиента ответственность за данные, настройки приложений и контроль использования ресурсов.

SLA не описывает всю ответственность

SLA (соглашение об уровне сервиса) фиксирует конкретные показатели для определенной услуги. В SLA могут указываться:

• доступность сервиса;
• время реакции поддержки;
• сроки устранения неисправностей;
• порядок обработки обращений;
• исключения;
• плановые работы;
• компенсации.

При этом SLA не всегда включает восстановление приложений, возврат удаленных данных, исправление ошибок внутри ОС или достижение целевых RTO/RPO. Например, у Linx Cloud есть гарантированное SLA для облачных сервисов до 99,99%. Показатель относится к конкретной услуге и не означает автоматическую доступность приложения на том же уровне.

Матрица ответственности: как убрать серые зоны

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

В строках перечисляют процессы и компоненты:

• физическая инфраструктура;
• гипервизор;
• виртуальная сеть;
• гостевые ОС;
• приложения;
• резервное копирование;
• мониторинг;
• реагирование на инциденты;
• обновления;
• управление доступом;
• тестирование восстановления.

В столбцах указывают участников:

• облачный провайдер;
• внутренняя ИТ-команда;
• служба информационной безопасности;
• разработчики;
• внешний интегратор;
• владельцы бизнес-систем.

Для каждого действия определяют роль. Можно использовать модель RACI:

• R — Responsible: выполняет работу;
• A — Accountable: несет итоговую ответственность;
• C — Consulted: участвует в согласовании;
• I — Informed: получает информацию о результате.

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

В документации Linx Cloud опубликована отдельная матрица распределения ответственности для IaaS. Она использует RACI и показывает, как роли провайдера и клиента распределяются между уровнями облачной инфраструктуры.

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

Типичные ошибки при распределении ответственности

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

Что проверить до подписания договора

Перед переходом в облако важно заранее установить, кто за что отвечает, и закрепить это в договоре, SLA, техническом задании или матрице ответственности.

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

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

Также стоит описать требования к безопасности и поддержке: управление доступами, работу с инцидентами, доступность каналов связи, сроки реакции и порядок эскалации. Все эти условия должны быть закреплены документально, чтобы при возникновении проблем у сторон не возникало разных трактовок ответственности.

Как передать провайдеру больше задач

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

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

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

Как распределяется ответственность в инфраструктуре Linx Cloud

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

В Linx Cloud распределение ролей для IaaS описано отдельной матрицей ответственности. Провайдер отвечает за инфраструктурный уровень облачной платформы, а заказчик — за управляемые им виртуальные ресурсы, приложения, данные и пользовательские настройки в пределах выбранной модели.

Если компании необходимо передать часть дополнительных задач, к облачной инфраструктуре можно подключить сервисы резервного копирования и аварийного восстановления. Linx Cloud предоставляет облачное резервное копирование для виртуальных и физических серверов, а также DRaaS для восстановления инфраструктуры на резервной площадке.

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

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

Что делать на практике

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

1. Разложите сервис на компоненты и назначьте владельцев

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

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

2. Зафиксируйте не только зоны, но и операции

Формулировка «ИТ-отдел отвечает за приложение» слишком общая. Необходимо отдельно определить, кто устанавливает обновления, меняет конфигурацию, отслеживает ошибки, реагирует на предупреждения, проверяет резервные копии и подтверждает восстановление.

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

3. Проверьте модель на учебном инциденте и регулярно обновляйте

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

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

Чек-лист распределения ответственности

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

☐ Определено, какие компоненты входят в услугу провайдера.

☐ Зафиксировано, кто администрирует гостевые операционные системы.

☐ Назначены ответственные за приложения и базы данных.

☐ Определено, кто создает пользователей и управляет правами.

☐ Понятно, входит ли резервное копирование в услугу.

☐ Установлены сроки хранения и периодичность создания копий.

☐ Назначен ответственный за проверку восстановления.

☐ RTO и RPO согласованы с бизнесом.

☐ Описан порядок объявления аварии и запуска DR.

☐ Зафиксирован владелец каждого бизнес-сервиса.

☐ Определены каналы связи и порядок эскалации.

☐ SLA соотнесен с архитектурой приложения.

☐ Матрица ответственности отражает фактическую инфраструктуру.

☐ Назначена дата следующего пересмотра документа.

Главное

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

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

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

Автор оригинального руководства указывает заголовок «за $5/месяц», но на практике минимально жизнеспособная конфигурация обходится в $6–12/месяц. За $5 дроплет даёт всего 1 ГБ ОЗУ — для семимиллиардной модели этого катастрофически мало. Ниже — реальные цифры и честная смета.

Что такое Llama 2 и зачем её self-hostить

Llama 2 — семейство открытых больших языковых моделей от Meta. Версия 7B содержит 7 миллиардов параметров, понимает английский и ряд других языков, умеет писать код, отвечать на вопросы и дополнять текст. Лицензия разрешает коммерческое использование при соблюдении простых правил, а веса можно скачать с Hugging Face.

Self-hosting в данном случае означает, что вы сами устанавливаете модель на арендованный сервер, контролируете окружение, не делитесь данными пользователей с третьими лицами и не зависите от чужих rate limit. Главная экономика: при интенсивном использовании собственный инференс обходится в десятки раз дешевле облачных API.

• Llama 2 7B можно запустить на DigitalOcean Droplet с 2 vCPU и 4 ГБ ОЗУ при 4-битном квантовании.
• Реальная стоимость — $12/месяц за Droplet плюс около $0,50 за трафик, а не $5.
• Docker + FastAPI дают воспроизводимое окружение и HTTP API из коробки.
• Для загрузки весов с Hugging Face нужен токен и принятая лицензия на Llama 2.
• Для публичного доступа обязательны HTTPS, базовая аутентификация и rate limiting.

Что понадобится для развёртывания

Аппаратная часть

• DigitalOcean Droplet на Ubuntu 22.04 LTS.
• Минимум: 1 vCPU / 2 ГБ ОЗУ ($6/месяц) — только для экспериментов.
• Рекомендуемый: 2 vCPU / 4 ГБ ОЗУ ($12/месяц) — стабильная работа с квантованием.
• 80 ГБ SSD: ~13 ГБ уйдёт на Docker-образ, модель и кэш.

Программная часть

• SSH-ключ и базовое умение работать в терминале.
• Docker и Docker Compose для управления контейнером.
• Аккаунт на Hugging Face с принятой лицензией Llama 2 и API-токеном.
• Nginx или аналогичный reverse proxy для вывода API в интернет.

Российская специфика: сайт DigitalOcean периодически попадает под блокировки Роскомнадзора. Для регистрации и управления Droplet может понадобиться VPN. Альтернативы — Hetzner, Selectel, Yandex Cloud или другие европейские и российские провайдеры; логика развёртывания от этого почти не меняется.

Шаг 1. Создаём Droplet и подключаемся по SSH

В панели DigitalOcean нажимаем Create → Droplet. Выбираем ближайший к целевой аудитории регион — для России это обычно Франкфурт или Амстердам. В качестве образа указываем Ubuntu 22.04 x64, тип — Basic Shared CPU, конфигурацию — 2 vCPU / 4 ГБ RAM. Авторизацию настраиваем через SSH-ключ, парольный вход отключаем.

Сгенерировать ключ и подключиться можно так:

Шаг 2. Устанавливаем Docker и зависимости

После подключения обновляем пакеты и ставим Docker официальным скриптом. Добавляем root в группу docker, чтобы не писать sudo перед каждой командой.

Шаг 3. Собираем Docker-образ с FastAPI

Приложение состоит из трёх файлов: Dockerfile, requirements.txt и app.py. Ключевой трюк — CPU-версия PyTorch и библиотека bitsandbytes, которая позволяет загрузить 7-миллиардную модель в 4 ГБ видеопамяти/ОЗУ.

Dockerfile

requirements.txt

Шаг 4. Пишем FastAPI-приложение

Приложение загружает модель при старте, кэширует её в /app/models и предоставляет три endpoint: /health, /info и /generate. Квантование в 4 бита снижает точность незначительно, но уменьшает потребление памяти в 3–4 раза.

Создаём файл с токеном Hugging Face. Никогда не коммитьте его в репозиторий: в продакшене используйте переменные окружения или секрет-менеджер.

Шаг 5. Собираем и запускаем контейнер

Первый запуск занимает 10–15 минут: скачиваются зависимости PyTorch и веса модели. Чтобы не качать веса при каждом перезапуске, подключаем Docker volume.

Для удобного управления добавляем docker-compose.yml:

Шаг 6. Проверяем API

Когда в логах появится Uvicorn running on http://0.0.0.0:8000, тестируем endpoint'ы:

Ответ должен содержать сгенерированный текст, количество токенов и время инференса. На CPU одна генерация из 100 токенов занимает 4–10 секунд — это нормально для бюджетного дроплета.

Шаг 7. Безопасно выводим API в интернет

Открывать порт 8000 напрямую в интернет небезопасно. Ставим Nginx как reverse proxy, настраиваем HTTPS через Let's Encrypt и базовую аутентификацию. Для rate limiting используем limit_req в Nginx или облачный firewall DigitalOcean.

Минимальная конфигурация Nginx выглядит так:

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

Выводы

Self-hosted Llama 2 — рабочий способ снизить затраты на генеративный ИИ в pet-проектах и прототипах. При правильном квантовании семимиллиардная модель помещается в бюджетный дроплет, а Docker + FastAPI превращают развёртывание в рутинную процедуру. Главное — не экономить на RAM и не забывать про безопасность публичного API.

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

Если соберётесь повторить гайд, начните с $12 Droplet и протестируйте нагрузку вручную. А если DigitalOcean недоступен — переносите тот же Docker Compose на Hetzner, Selectel или Yandex Cloud без изменения кода.

Источник: How to Deploy Llama 2 on DigitalOcean for $5/Month: Complete Self-Hosting Guide — RamosAI, Dev.to.

Qwen 3.8-Max — флагман Alibaba с 2,4 трлн параметров (95 млрд активных).

Это первая модель линейки Max, чьи веса выложат в open source.

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

Доступна через API QwenCloud с параметром reasoning_effort и интегрируется с Claude Code, Codex и Qoder.

Что анонсировали

Qwen 3.8-Max построена на архитектуре Qwen 3.5 и насчитывает 2,4 трлн параметров, из которых активируются примерно 95 млрд. Это делает её одной из крупнейших публично анонсированных моделей и первой мультимодальной системой Qwen, преодолевшей отметку в 1 трлн параметров.

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

Ключевые возможности

• Автономный кодинг. В демонстрации модель 16 дней без участия человека развивала проект oh-my-cli: 265 коммитов, 127 pull request'ов и 151 issue. Главная фишка — самообучающийся цикл: требования превращаются в задачи, которые агенты берут в работу, тестируют и сливают в main.
• Научные исследования. Qwen 3.8-Max воспроизвела эксперимент из статьи «Unified Data Selection for LLM Reasoning» с нуля — около 7 600 строк кода, 33 цикла обучения на GPU — а затем улучшила результат на 2,7 балла на бенчмарке AIME24.
• Соревнования. За 24 часа модель построила решение для конкурса WWW2025 Multimodal Dialogue Intent Recognition на платформе Tianchi и обошла 458 из 526 человеческих команд (87%).
• Рабочие сценарии. В тестах Qwen 3.8-Max проектировала интерфейсы, составляла меню ресторана с расчётом себестоимости, проверяла юридические документы и строила сейсмические модели зданий.
• Чип-дизайн. Модель самостоятельно прошла весь фронтенд-флоу цифровой схемы: от RTL до физического layout в OpenROAD, сократив площадь кристалла на 81% и добившись тактовой частоты 500 МГц.

Бенчмарки

В опубликованной таблице Qwen 3.8-Max сравнивается с Claude Opus 4.8, Claude Fable 5, GPT 5.6 Sol и предшественником Qwen 3.7-Max. По внутренним тестам Alibaba новинка обгоняет Qwen 3.7-Max на большинстве задач и приближается к лучшим закрытым моделям в кодинге и мультимодальных бенчмарках. Отдельно отметим PaperBench — 93,0 балла против 90,5 у GPT 5.6 Sol и 64,8 у Qwen 3.7-Max.

Как попробовать

Модель уже доступна через QwenCloud. API совместим с OpenAI и Anthropic, поэтому подключение занимает буквально минуту. Поддерживаются три уровня глубины рассуждений: xhigh, medium и low. По умолчанию включён preserve_thinking.

Минимальный пример на Python:

Кроме прямого API, модель завели в Claude Code, Codex, Qoder CLI, Qwen Code и OpenClaw. Контекстное окно — до 1 млн токенов, максимальная длина ответа — 65 536 токенов.

FAQ

Выводы

Qwen 3.8-Max — это попытка Alibaba вывести флагманскую линейку в open source и при этом конкурировать с лучшими закрытыми моделями. Если открытые веса действительно выйдут под пермиссивной лицензией, у разработчиков появится серьёзная альтернатива для локального запуска и дообучения. Пока же модель можно протестировать через QwenCloud.

Источник: Qwen 3.8-Max: A New Bar for Coding and Cowork.

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

Как публичное облако стало вариантом по умолчанию

Одним из главных пионеров первой волны миграции стал Netflix. Компания начала перенос инфраструктуры в AWS после сбоя собственного дата-центра в 2008 году, а в январе 2016-го завершила семилетнюю миграцию и отключила последние системы стримингового сервиса, работавшие в её дата-центрах. Публичное облако позволило Netflix масштабировать инфраструктуру вместе с ростом аудитории и объёма данных.

В 2016 году McKinsey опросила руководителей более чем 50 крупных организаций из Европы и Северной Америки, чтобы сравнить экономику размещения приложений. Уже тогда они говорили, что финансовые ресурсы на частное и публичное облаком в целом одинаковые. Но компании всё равно продолжали миграцию, поскольку оценивали также скорость масштабирования и объём работы, который получалось снять с внутренних ИТ-команд.

К 2018 году публичное облако уже стало стандартной частью корпоративной инфраструктуры. Согласно RightScale State of the Cloud Report 2018, 52% крупных компаний тратили на него больше 1,2 млн долларов в год, а 71% крупных организаций собирались увеличить расходы как минимум на 20%.

На этом же этапе появилась проблема: компании научились быстро заказывать ресурсы, но хуже контролировали их использование. RightScale оценила долю неэффективных расходов в 35%, а 58% респондентов назвали оптимизацию облачных затрат главным приоритетом.

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

Что означает облачная репатриация

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

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

Такой подход требует выбирать среду отдельно для каждой нагрузки. На решение влияют её характеристики:

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

Разница между собственной инфраструктурой и частным облаком

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

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

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

Когда публичное облако становится дорогим

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

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

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

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

Один из самых известных примеров – оптимизация 37Signals. Компания использовала публичное облако для своих продуктов, но потом решила перенести инфраструктуру в частную среду. Давид Хейнемейер Ханссон, сооснователь 37Signals, признавал главное преимущество облачных платформ: они позволяют поднять сотню серверов за несколько минут – для 37Signals это оказалось избыточным. Этот кейс нельзя переносить на любой бизнес. В публичном облаке есть смысл для компаний, которым нужно быстро получать вычислительные мощности и большие объёмы хранилища без больших затрат. Оно также подходит системам с плавающей и плохо предсказуемой нагрузкой.

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

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

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

Почему ИИ-нагрузки меняют выбор инфраструктуры

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

Поэтому при выборе инфраструктуры компании оценивают несколько параметров:

• какие вычислительные ресурсы нужны модели;
• где хранятся данные для обучения и инференса;
• насколько глубоко придётся настраивать среду;
• можно ли передавать промпты, ответы и логи внешнему сервису.

По прогнозу Gartner, к 2027 году больше половины моделей генеративного ИИ, которые используют компании, будут адаптированы под конкретную отрасль или бизнес-функцию. В 2024 году их доля составляла около 1%.

В Private Cloud Outlook 2025 55% опрошенных компаний выбрали частное облако для обучения, настройки моделей и инференса. Это не означает, что публичная инфраструктура перестала подходить для ИИ, просто большую часть данных, которые компании скармливают в ИИ нельзя свободно передавать во внешний контур. Из-за этого развивается и открытый набор инструментов для конфиденциального инференса. Например, OpenPCC позволяет работать с кастомными моделями в частном облаке, не раскрывая промпты, ответы и логи. Передача данных шифруется, а выполнение запросов проверяется через аппаратную аттестацию.

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

Почему компании выбирают частное облако провайдера

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

1. оборудование устарело и требует замены;
2. мощности собственного ЦОДа закончились;
3. внутри ИТ-подразделения сократились компетенции для обслуживания инфраструктуры.

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

Сегмент private cloud в России растёт быстрее, чем в мире. Более половины объёма приходится на финансовый и телеком-секторы, где необходим максимальный контроль над данными. Государственные структуры, ритейл и медицина также существенно увеличивают потребление.

Один из примеров связан с банком, которому нужно было обновить инфраструктуру. Причина перехода – устаревшее оборудование и сокращение компетенций внутри ИТ-департамента.

Для них это прежде всего способ избавиться от капитальных затрат и снять нагрузку с внутренних ИТ-команд. Часто переломным моментом становится устаревание оборудования или исчерпание ресурсов собственного ЦОДа. Одним из недавно реализованных кейсов у нас было построение частного решения для банка – причиной перехода стали сократившиеся компетенции внутри ИТ-департамента и необходимость обновления оборудования.

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

Какие нагрузки куда размещать

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

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

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

Чем VDS отличается от обычного хостинга

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

На виртуальном хостинге подобные возможности обычно ограничены, поскольку все клиенты используют общую программную среду. Именно поэтому разработчики, системные администраторы и владельцы сложных веб-проектов предпочитают использовать VPS или VDS.

Кроме того, современный виртуальный сервер позволяет работать с Docker, Git, Node.js, Python, PostgreSQL, Redis, Nginx и десятками других инструментов, необходимых для разработки современных приложений.

Когда действительно нужен бесплатный VDS

Тестовый сервер может быть полезен далеко не только начинающим пользователям.

Во-первых, его удобно использовать для проверки производительности сайта после переноса с виртуального хостинга. Во-вторых, это хороший вариант для тестирования новых версий CMS, обновлений, модулей или собственного программного кода без риска нарушить работу основного проекта.

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

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

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

• продолжительность тестового периода;
• характеристики процессора, объём оперативной памяти и дискового пространства;
• использование современных NVMe-накопителей;
• наличие защиты от DDoS-атак;
• возможность выбрать операционную систему;
• наличие VNC-консоли и SSH-доступа;
• возможность сохранить данные при переходе на платный тариф;
• качество технической поддержки и документации.

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

Почему важно протестировать VDS перед выбором

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

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

Такой подход помогает сделать выбор на основе собственного опыта и объективной оценки возможностей платформы, а не только информации, указанной в описании услуги.

Бесплатный VDS как возможность оценить инфраструктуру

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

Одним из примеров является SpaceWeb, который предоставляет бесплатный VDS с доступом к основным возможностям виртуального сервера: выбору операционной системы, root-доступу, установке необходимого программного обеспечения и использованию готовых серверных окружений. Это позволяет протестировать сайт, приложение или среду разработки в условиях, максимально приближенных к реальной эксплуатации, и только после этого принимать решение о дальнейшем использовании сервиса.

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

Реклама. Рекламодатель: ООО «СпейсВэб», ИНН 7813376370, erid: 2W5zFK1N8eV

Решение выросло из собственного опыта: по словам Judson Althoff, главы коммерческого направления Microsoft, привязка оригинального Copilot исключительно к моделям OpenAI была ошибкой. Клиентам важнее не бренд модели, а результат: их данные плюс та архитектура, которая даёт лучший отклик, цену и безопасность.

Microsoft запускает подразделение Frontier Company с бюджетом $2,5 млрд для помощи enterprise-клиентам в выборе ИИ-моделей.

Компания признала: привязка Copilot только к OpenAI была ошибкой, и теперь продвигает мульти-модельную стратегию.

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

Рынок отвечает развитием ИИ-шлюзов и оркестраторов: LiteLLM, Portkey, LangGraph, MCP, Azure AI Foundry, Amazon Bedrock, Google Vertex AI.

Почему одной модели уже недостаточно

В одном типичном корпоративном сценарии может понадобиться суммаризация тикета, анализ 300-страничного договора, генерация письма, расшифровка встречи и ревью кода. Это разные задачи: для длинного контракта выгоднее модель с огромным контекстом, для быстрых ответов — лёгкая и дешёвая, для чувствительных данных — локальная open-weight модель. Вместо того чтобы искать универсального победителя, разработчники строят слой маршрутизации, который отправляет каждый запрос к подходящей модели.

We made a mistake by binding it to OpenAI models only.

Что это меняет для инженеров

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

Кто ещё строит маршрутизацию

• LiteLLM и Portkey — нормализуют API разных провайдеров.
• LangChain / LangGraph — рассчитаны на много-модельные пайплайны.
• Model Context Protocol (MCP) — делает инструменты переносимыми между моделями.
• Azure AI Foundry, Amazon Bedrock, Google Vertex AI — предлагают десятки моделей за единым endpoint.

Выводы

Microsoft закладывает $2,5 млрд на то, что следующий конкурентный рубеж в enterprise ИИ — не сама модель, а умение ею управлять. Для разработчиков это означает рост спроса на инфраструктуру маршрутизации, observability и политики данных. Если облачная эра научила не привязываться к одному серверу, то ИИ-эра учит не привязываться к одной модели.

Оригинал материала: The New Stack — Enterprise AI Model Routing.

Бэкап данных – это не восстановление

Бэкап и аварийное восстановление решают разные задачи. Бэкап хранит копии данных, а аварийное восстановление возвращает приложения в работу.

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

DRaaS (Disaster Recovery as a Service) строит процесс по-другому. Сервис заранее реплицирует данные в виртуальные машины на резервной площадке, и при отказе основного контура переносит на неё нагрузку в полуавтоматическом режиме.

Поэтому DRaaS закрывает три задачи, которые один бэкап не покрывает:

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

На этапе планирования и при тестировании команда отвечает на вопрос: за какое время сервис снова заработает после сбоя. Этот срок задают заранее, двумя параметрами: RTO и RPO. К ним и переходим.

RTO и RPO – две метрики, от которых всё зависит

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

RTO (Recovery Time Objective) отвечает на вопрос «за какое время сервис должен быть поднят». Это срок, за который системы должны вернуться в работу после отказа. RTO в один час и RTO в одни сутки задают разный сценарий восстановления и разную стоимость.

RPO (Recovery Point Objective) отвечает на вопрос «сколько данных допустимо потерять». Это объём изменений между последней синхронизацией и моментом сбоя. RPO в пять минут означает, что при аварии теряются данные за последние пять минут работы. RPO в сутки означает потерю данных за последние сутки.

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

RTO и RPO зависят не только от провайдера сервиса Аварийного восстановления. На них влияют обе стороны:

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

Поэтому целевые значения проверяют на практике. Команда задаёт RTO и RPO, прогоняет переключение и сверяет результат с планом. Если сервис поднимается дольше расчётного времени, параметры пересматривают или меняют схему репликации. Как именно работает само переключение, разберём дальше.

Как это работает организационно-технически

Примечание: Ниже описываем реализацию нашего сервиса Аварийное восстановление (DRaaS), которой подходит только клиентам с VMware на основной площадке. При этом подход используется и другими облачными сервисами с другим ПО.

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

Шаг 1. Настройка сетей. Для того, чтобы сервисы при запуске требовали минимальной донастройки, важно чтобы они запускались в сети максимально похожей на продуктивную. Поэтому в идеале на резервной площадке сделать серые сети с такой же адресацией, а также повторить правила FireWall и NAT.

Шаг 2. Репликация. Виртуальные машины основной площадки реплицируются на площадку Linx через VMware Cloud Director Availability. Инструмент делает копию виртуальных машин и поддерживает их в актуальном состоянии.

При этом можно настроить множество параметров, главные из которых:

• На каких типах дисков будут хранится данные. Чем более быстрые, тем дороже хранение.
• В каких сетях (из шага 1) и с какой адресацией будет запускаться сервер.

• Target RPO: чем чаще идёт синхронизация, тем меньше данных теряется при аварии. RPO задают индивидуально под каждую систему. Чем меньше, тем лучше, но можно уткнуться в ограничение канала связи или в рост нагрузки на СХД, поэтому нужен баланс.
• Retention policy: позволяет задать количество возможных точек восстановления и глубину их хранения. Чем больше больше таких точек, тем больше шанса, восстановить не повреждённые/не зашифрованные данные, но это увеличивает занимаемое на хранилище место. Поэтому тоже нужен баланс.

Шаг 3. Тестовое восстановление каждой ВМ.

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

Шаг 4. Настройка очерёдности восстановления.

Инфраструктура обычно состоит из большого количества ВМ. Часто их надо запускать в определённом порядке, да ещё и иметь возможность делать промежуточные ручные проверки. Эту очерёдность можно заранее записать в специальный скрипт, называемый Recovery Plan. Это позволит ускорить процесс восстановления, а также минимизировать ошибки при ручном запуске.

Шаг 5. Переключение (failover и failback). При аварии на основной площадке, представитель Клиента ответственный за запуск плана восстановления заходит на консоль управления Cloud Director Availability и инициирует преднастроенный Recovery Plan (делает failover). ВМ восстанавливаются, инженеры проверяют работоспособность ИТ сервисов, а бизнес пользователи проверяют и подтверждают восстановление Информационных систем.

Если авария на основной площадке устранена, можно запустить reverse replication, чтобы новые данные начали реплицировать с резервной площадки обратно. А потом в спокойном режиме (например в час наименьшей нагрузки) провести failback и переключить нагрузку обратно на основную площадку.

План аварийного восстановления, который реально сработает

План аварийного восстановления (DRP) задаёт последовательность действий при сбое: какие системы поднимать, в каком порядке и с какими параметрами. План фиксирует логику переключения заранее, чтобы в момент аварии команда выполняла настроенный сценарий, а не собирала его на ходу.

Сам по себе план ничего не гарантирует. Гарантию даёт тест. Команда проверяет, что системы стартуют на резервной площадке и поднимаются в нужном порядке, и только после этого считает план рабочим.

Тестирование строят в несколько этапов:

1. Тестовый запуск. Команда проверяет, что системы стартуют на резервной площадке сразу после репликации и настройки плана. VMware Cloud Director Availability запускает реплику в тестовом режиме, поэтому проверка идёт без влияния на основную площадку.
2. Первое реальное переключение. После теста команда планирует реальный переезд на резервную площадку. Его проводят в нерабочий день или в час наименьшей нагрузки и подключают к проверке как можно больше ролей в компании.
3. Регулярные прогоны. Тестовое переключение проводят раз в месяц, реальное – раз в полгода-год. Регулярность подтверждает, что план продолжает отрабатывать по мере изменений в инфраструктуре.

План устаревает вместе с инфраструктурой. Любое изменение в критичных системах либо не затрагивает план, либо требует обновить его сразу. Чтобы шаг не терялся, пункт про обновление DRP добавляют в стандартный шаблон Change request. Тогда план обновляется в момент изменения, а не задним числом после сбоя.

Где всё это разворачивать

Резервная площадка требует мощностей. Команда либо держит второй ЦОД с собственным оборудованием, либо арендует готовую площадку и репликацию как услугу. Первый вариант закрывает задачу своими силами, но требует железа, каналов и людей, которые поддерживают всё это в актуальном состоянии. Второй вариант снимает часть этой нагрузки с команды.

В случае с услугой Аварийное восстановление (DRaaS) от Linx Cloud Клиент получает резервную площадку в облаке, а также получает инструмент для репликации и восстановления VMware Cloud Director Availability. RPO задаётся под каждую систему, переключение запускается с веб-портала. Подключение идёт по анкете: команда указывает количество виртуальных машин, объём данных и ресурсы (CPU, RAM), получает доступ к порталу и инструкции. Сервис работает в двух сценариях:

• Стандартный – репликация и запуск виртуальных машин по заранее настроенному плану на резервной площадке;
• Расширенный – аудит инфраструктуры, подготовка плана восстановления, настройка сетей и круглосуточная поддержка.

Проверить схему можно до оплаты: Linx даёт бесплатный тест-драйв на 14 дней, чтобы прогнать тестовое переключение и сверить результат с целевыми параметрами. Условия и подключение на странице DRaaS Linx Cloud.

Итого

Аварийное восстановление настраивают до сбоя, а не во время него. Бэкап сохраняет данные, но не возвращает сервис в работу. Для этого нужна реплика на резервной площадке и заранее настроенное переключение. Параметры RTO и RPO задают рамку: за какое время поднять сервис и сколько данных допустимо потерять. Репликация держит копию инфраструктуры в актуальном состоянии, план фиксирует порядок подъёма систем, регулярный тест подтверждает, что план срабатывает.

Главный показатель готовности – не наличие плана, а дата его последнего прогона. План, который не проверяли полгода, отстаёт от инфраструктуры и в момент аварии работает не так, как записано. Проверьте, когда вы в последний раз запускали тестовое переключение. Если ответа нет, это и есть первая задача.

Макхост — низкий порог входа и российские документы.

UFO.Hosting — широкая линейка VPS и выделенных серверов.

SmartApe — гибкие конфигурации и быстрый старт.

PSB Hosting — зарубежные локации и безлимитный трафик.

FirstVDS — бюджетный массовый вариант для простых проектов.

Hetzner Cloud — иностранная облачная альтернатива с ограничениями для РФ.

Как мы выбирали

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

1. Макхост — низкий порог входа

Макхост — российский хостинг-провайдер с собственными панелями управления и низким стартовым тарифом. Входит в реестр хостинг-провайдеров, работает с юрлицами и предлагает VPS в России и Европе.

Кейсы клиентов и кому подойдёт

• Сайты-визитки и лендинги на минимальной конфигурации с 1 CPU и 1 GB RAM.
• Интернет-магазины на популярных CMS и телеграм-боты: по данным провайдера, часто выбирают KVM-2 с 2 GB RAM.
• 1С:Предприятие и корпоративные сайты с модулем синхронизации: рекомендуют конфигурации от 4 GB RAM.
• VPN-серверы личного использования и небольшие тестовые окружения.

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

• Операционные системы: Ubuntu, Debian, AlmaLinux, CentOS Stream.
• Панели управления: ISPmanager, FastPanel; на тарифах VPS первый месяц ISPmanager 6 в подарок.
• Готовые образы и стеки: WordPress, 1С, Docker, LAMP, почта, DNS, SSL.
• SSH и root-доступ для произвольной настройки окружения.

Инфраструктура и экосистема

• Виртуализация KVM с гарантированными ресурсами.
• Дата-центры: DataPro в Москве и площадка в Амстердаме.
• Диски: NVMe и DDR4 на всех VPS-тарифах, кроме самого дешёвого KVM-NEW с SSD.
• Сеть: порт до 1 Гбит/с, безлимитный трафик на всех тарифах, кроме KVM-NEW (2 ТБ).
• Соответствие 152-ФЗ, реестр хостинг-провайдеров; закрывающие документы для юрлиц.

Отзывы и репутация

На странице VPS у Макхоста указана средняя оценка 5 на основе 13 оценок. Пользователи отмечают круглосуточную поддержку и быструю помощь в сложных ситуациях; провайдер позиционирует себя как лидер авторитетных рейтингов.

Поддержка и каналы связи

• Каналы: тикет-система и онлайн-чат на сайте.
• Среднее время первого ответа: 10–20 минут.
• Для корпоративных клиентов и крупных проектов возможен персональный менеджер.
• База знаний, блог со статьями и платное администрирование VPS при необходимости.

Тарифы, ограничения и условия

• Стартовый KVM-NEW: 1 CPU, 0.6 GB RAM, 5 GB SSD, 2 ТБ трафика — 143 ₽/мес.
• Популярный KVM-2: 1 CPU, 2 GB RAM, 30–60 GB NVMe — от 693 ₽/мес при оплате за год.
• Топовый VPS KVM-12: 6 CPU, 12 GB RAM, 180–360 GB NVMe — от 3465 ₽/мес при оплате за год.
• Скидки за предоплату: 3%, 6%, 12%, 24% за 3, 6, 12, 24 месяца соответственно.
• Тестовый период: 3 дня с активационным платежом 290 ₽, который остаётся на балансе.
• Апгрейд без пересоздания сервера, обычно с кратковременной перезагрузкой.

Официальный сайт: Макхост

2. UFO.Hosting — широкая линейка

UFO.Hosting предлагает виртуальные и выделенные серверы в России с акцентом на широкую линейку конфигураций и NVMe-диски. Подходит тем, кто рассматривает и VPS, и bare-metal в одном кабинете.

Кейсы клиентов и кому подойдёт

• Небольшие проекты и сайты-визитки на тарифе Naos с 1 CPU и 1 GB RAM.
• Интернет-магазины, корпоративные сайты и телеграм-боты с вебхуками на Brachium с 2 CPU и 4 GB RAM.
• 1С:Предприятие и нагруженные CMS: рекомендуют от 4 CPU и 8 GB RAM.
• Проекты, которым нужны выделенные серверы без соседей.

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

• Операционные системы: различные дистрибутивы Linux и Windows (ISO-образы доступны на старших тарифах).
• Панели управления: ISPmanager, Vesta, Hestia, Cyberpanel, Virtualmin.
• Готовые шаблоны ПО в зависимости от выбранной ОС.
• Дополнительные IP-адреса, аренда подсетей, настройка BGP.

Инфраструктура и экосистема

• Виртуализация KVM; процессоры Intel Xeon E5-2697A v4.
• Дата-центр IXcellerate в Москве, сертифицированный Tier III+.
• NVMe-диски в RAID10 на VPS/VDS; Enterprise SSD на выделенных серверах.
• Сеть: порт до 10 Гбит/с на ноде, 32 ТБ трафика в месяц на VPS (далее ограничение 100 Мбит/с); на выделенных серверах — без ограничений.
• Работа по 152-ФЗ, реестр хостинг-провайдеров; документы для юрлиц через ЭДО.

Отзывы и репутация

Публичные отзывы и агрегированные рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на Tier III+ инфраструктуре и запуске серверов до 15 минут.

Поддержка и каналы связи

• Каналы: онлайн-чат на сайте и тикет-система в биллинге 24/7; телефон в будни с 9:00 до 18:00.
• Среднее время первого ответа: не более 30 минут в любое время суток.
• База знаний в блоге ufo.hosting/blog.
• Продажи и поддержка готовы консультировать B2B-клиентов.

Тарифы, ограничения и условия

• Минимальный VPS Naos: 1 vCPU, 1 GB RAM, 25 GB NVMe — 605.85 ₽/мес.
• Популярный Brachium: 2 vCPU, 4 GB RAM, 60 GB NVMe — 1025.85 ₽/мес.
• Топовый VPS Intercrus: 32 vCPU, 64 GB RAM, 510 GB NVMe — 16 800 ₽/мес.
• Выделенный сервер Восток-1: 2x E5-2697v4, 384 GB RAM ECC, 4x960 GB Enterprise SSD — 43 050 ₽/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Тестовый период: 3 дня на VPS после полной верификации аккаунта; на выделенных серверах — обсуждается персонально.
• Апгрейд тарифа из личного кабинета без пересоздания сервера, вступает в силу после перезагрузки.

Официальный сайт: UFO.Hosting

3. SmartApe — гибкие конфигурации

SmartApe делает ставку на гибкость: кроме фиксированных линеек есть полностью конфигурируемые тарифы, где можно менять ресурсы под задачу. Провайдер использует процессоры Intel Xeon Platinum, AMD EPYC и AMD Ryzen.

Кейсы клиентов и кому подойдёт

• Лендинги и сайты-визитки на минимальных конфигурациях с 2 CPU и 1 GB RAM.
• WordPress, корпоративные сайты и интернет-магазины до 10 тыс. посетителей в сутки.
• Bitrix, CRM, ERP и 1С: рекомендуют от 4 CPU и 8 GB RAM.
• Нагруженные API, базы данных и высоконагруженные проекты на конфигурируемых тарифах.

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

• Linux- и Windows-серверы, панели управления ISPmanager, Hestia и другие.
• Готовые стеки под Docker, базы данных, веб-приложения.
• Автоматическое развёртывание сервера за 1–2 минуты; бесплатная помощь с переносом сайтов при использовании ISPmanager или Hestia.

Инфраструктура и экосистема

• Виртуализация KVM с изоляцией и гарантированными ресурсами.
• Процессоры: Intel Xeon E5-2696 v4, Intel Xeon Platinum, AMD EPYC, AMD Ryzen 9.
• Диски: серверные NVMe SSD или HDD + SSD-кэш, RAID-10.
• Дата-центры: DataPro Moscow I, II, III в России; Host-Telecom в Чехии; Partner Group в Израиле; уровни Tier III и Tier IV.
• Сеть: безлимитный трафик на всех VPS, канал до 200 Мбит/с.
• SLA 99.9%, заявленный фактический uptime 99.982%.
• Соблюдение 152-ФЗ, договор на обработку персональных данных.

Отзывы и репутация

Публичные отзывы и рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на показателях NVMe-хранилища: до 680 тыс. IOPS на чтение и до 185 тыс. IOPS на запись.

Поддержка и каналы связи

• Каналы: тикеты в личном кабинете, онлайн-чат, телефон.
• Среднее время первого ответа: 10–15 минут.
• Раздел помощи на smartape.ru/help.
• Персональный менеджер обсуждается индивидуально для B2B.

Тарифы, ограничения и условия

• Минимальные тарифы: HDD S1 (2 CPU, 1 GB RAM, 50 GB HDD+SSD) — 345 ₽/мес; NVMe X1 (2 CPU, 1 GB RAM, 10 GB NVMe) — 495 ₽/мес; Turbo R1 AMD Ryzen (2 CPU, 1 GB RAM, 20 GB NVMe) — 645 ₽/мес.
• Топовый VPS NVMe X64: 24 CPU, 64 GB RAM, 640 GB NVMe — 11 870 ₽/мес.
• Скидки за предоплату: 5%, 15%, 30%, 50% за 3, 6, 12, 24 месяца.
• Тестовый период: 10 дней без привязки банковской карты, нужно подтверждение номера телефона.
• Резервное копирование со стороны провайдера не предусмотрено; можно настроить самостоятельно или заказать FTP-хранилище.
• Апгрейд фиксированных тарифов — по запросу в поддержку с перезагрузкой; конфигурируемые тарифы меняются в личном кабинете.

Официальный сайт: SmartApe

4. PSB Hosting — зарубежные локации

PSB Hosting ориентирован на международные дата-центры и широкий выбор операционных систем. Подходит проектам, которым важны европейские и американские площадки, безлимитный трафик и подсеть IPv6 /64 на всех тарифах.

Кейсы клиентов и кому подойдёт

• Сайты и веб-приложения, ориентированные на аудиторию в Европе и США.
• VPN-серверы, прокси и сетевые сервисы благодаря безлимитному трафику и IPv6 /64.
• Проекты на Node.js, Django, Docker, WordPress и других стеках.
• Разработчики, которым нужна нестандартная ОС или загрузка собственного ISO.

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

• Операционные системы: Ubuntu, Debian, CentOS, Windows, Astra Linux, AlmaLinux, Rocky Linux, FreeBSD, Oracle Linux; можно загрузить свою ОС через ISO.
• Предустановленное ПО: Docker, LAMP, Keitaro, FastPanel, Node.js, Portainer, WordPress, Django, Outline, OpenVPN, Wireguard, HestiaCP, VestaCP, Bitrix.
• Полноценная панель управления DNS-записями доменов.

Инфраструктура и экосистема

• Виртуализация KVM, NVMe-диски.
• Дата-центры: euNetworks в Амстердаме, Frankfurt 1 Data Center в Германии, Digita в Хельсинки, Long Island Interconnect в Нью-Йорке.
• Сеть: порт до 10 Гбит/с, безлимитный трафик, подсеть /64 IPv6 на всех тарифах.
• SLA 99.7%; мониторинг состояния сервера встроен в панель.
• Договор на обработку персональных данных; оплата картами РФ, СНГ, ЕС и криптовалютой.

Отзывы и репутация

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

Поддержка и каналы связи

• Каналы: тикеты и Telegram 24/7.
• Время ответа зависит от загрузки; поддержка работает круглосуточно.
• Документация и API на сайте.
• Персональный менеджер доступен для B2B-клиентов.

Тарифы, ограничения и условия

• Популярная конфигурация: 4 vCPU, 8 GB RAM, 100 GB SSD — $25/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Бесплатного тестового периода нет.
• Резервные копии платные, создаются ежедневно; количество не ограничено.
• Апгрейд без потери данных с перезагрузкой сервера.
• Сервер выделяется за 5–10 минут после установки ОС.

Официальный сайт: PSB Hosting

5. FirstVDS — бюджетный VPS/VDS для простого старта

FirstVDS — российский VPS/VDS-провайдер с готовыми тарифами и быстрым запуском сервера. Он подходит для простых веб-проектов, тестовых окружений и задач, где важны понятная стартовая цена, российские площадки и базовые дополнительные услуги.

Кейсы клиентов и кому подойдёт

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

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

• Linux/VDS для сайтов, блогов, небольших баз данных и веб-приложений.
• Windows-серверы: на сайте есть отдельная линейка VDS для Windows Server 2019 и 2022.
• Дополнительные услуги: S3, автоматическое резервное копирование, администрирование, DDoS-защита, мониторинг сайтов.

Инфраструктура и экосистема

На официальной странице FirstVDS указаны серверы в России, Нидерландах и Казахстане, запуск готового сервера за 2 минуты, отдельные линейки VDS Форсаж, CPU.Турбо, VDS Atlant, Storage и GPU. Это вариант для тех, кто хочет выбрать готовую линейку, а не собирать конфигурацию вручную.

Тарифы и ограничения

• Стартовая цена на сайте: VPS/VDS от 249 ₽/мес.
• Плюс: круглосуточный бесплатный телефон 8 800 775-38-37 и большое количество отзывов на сайте.
• Особенность: параметры под конкретный сценарий лучше дополнительно проверять в конфигураторе и на тестовой конфигурации.

Официальный сайт: FirstVDS

6. Hetzner Cloud — зарубежное облако для международных проектов

Hetzner Cloud — европейский облачный провайдер с API и дата-центрами в Германии, Финляндии, США и Сингапуре. Он подходит для международных проектов, тестовых окружений и команд, которым важны автоматизация, сети, firewalls и понятная облачная модель. Для российских юридических и регуляторных требований условия нужно проверять отдельно.

Кейсы клиентов и кому подойдёт

• Тестовые окружения, личные проекты, международные веб-сервисы и инфраструктура для разработчиков.
• Команды, которым нужны API, CLI, Terraform/Ansible-интеграции, private networks и firewalls.
• Проекты с аудиторией в Европе, США или Азии, где российская юрисдикция и документы не критичны.

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

• Linux-дистрибутивы: Ubuntu, Debian, Fedora и другие образы.
• One-click apps: Docker, WordPress, Nextcloud, GitLab, Grafana, Jitsi Meet, WireGuard и другие.
• Облачная инфраструктура с networks, firewalls, load balancers, API, CLI и интеграциями для CI/CD.

Инфраструктура и экосистема

Hetzner описывает shared cloud как вариант для разработки, тестов, личных сайтов, небольших баз данных и веб-серверов со средней нагрузкой. Dedicated cloud рассчитан на бизнес-приложения и устойчивую высокую нагрузку. На сайте также указаны GDPR, ISO/IEC 27001 для дата-центров в Германии и Финляндии, 99,9% uptime и поддержка 24/7 по email.

Тарифы и ограничения

• Цены и конфигурации зависят от выбранной страны, валюты и типа cloud-сервера; в статье лучше считать их отдельно в калькуляторе Hetzner.
• Плюс: зрелая европейская облачная экосистема и сильная автоматизация.
• Особенность: иностранная юрисдикция и документы отличаются от российских провайдеров, поэтому для проектов с персональными данными и 152-ФЗ условия нужно проверять отдельно.

Официальный сайт: Hetzner Cloud

Сравнение по ключевым критериям

Минимальный вход: у Макхоста самый дешёвый стартовый тариф — 143 ₽/мес, но с ограниченным трафиком и SSD. SmartApe предлагает старт от 345 ₽/мес с двумя ядрами и HDD+SSD-кэшем; FirstVDS начинается от 249 ₽/мес и подходит как бюджетная точка входа. UFO.Hosting, PSB Hosting и Hetzner Cloud стоит считать по конфигурации и требованиям к географии.

Популярные конфигурации: Макхост и UFO.Hosting выделяют тарифы с 2 GB RAM для магазинов и CMS; у SmartApe стартовый NVMe-тариф даёт 2 CPU и 1 GB RAM; у PSB Hosting популярный тариф — 4 CPU и 8 GB RAM за $25/мес. FirstVDS удобен для простых стартовых задач, а Hetzner Cloud — для международных проектов и команд, которым нужны API, сети и автоматизация.

Диски и трафик: у каждого провайдера разные акценты по дискам, портам, бэкапам и ограничениям. FirstVDS даёт массовую VPS/VDS-линейку и дополнительные сервисы вроде S3, бэкапов и мониторинга. Hetzner Cloud силён по API, сетям, firewalls и included traffic; его условия нужно пересчитывать отдельно под регион и валюту.

Тестовый период: SmartApe даёт 10 дней без карты, Макхост и UFO.Hosting — 3 дня с условиями, PSB Hosting — не предусмотрен. Для FirstVDS и Hetzner Cloud тестовый период и условия пробного запуска лучше проверять на момент заказа.

География и документы: Макхост, UFO.Hosting и SmartApe подтверждают работу по 152-ФЗ и наличие российских площадок; PSB Hosting работает только из зарубежных дата-центров и предлагает оплату криптовалютой. FirstVDS имеет российские и зарубежные площадки. Hetzner Cloud работает в иностранной юрисдикции, поэтому для проектов с персональными данными россиян нужно заранее проверить документы, обработку данных и требования 152-ФЗ.

Выводы

Выбор VPS начинается с честной оценки нагрузки: 1 CPU и 1 GB RAM хватит для статического лендинга или простого бота, но для CMS с плагинами, интернет-магазина или 1С стоит закладывать минимум 2 CPU и 4 GB RAM, а лучше — тестировать реальную нагрузку на выбранной панели.

Если важен минимальный бюджет и российские документы — смотрите на Макхост. Если нужна широкая линейка от VPS до выделенных серверов в одном кабинете — на UFO.Hosting. Для гибкого подбора ресурсов под растущую нагрузку подойдёт SmartApe. Если проект ориентирован на зарубежную аудиторию и нужен безлимитный трафик — PSB Hosting.

FirstVDS подойдёт для недорогих и простых запусков с российскими и зарубежными площадками. Hetzner Cloud — для международной инфраструктуры, где важны API, сети и дата-центры за пределами России; юридические и регуляторные требования нужно проверять отдельно.

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

Продукт адресован разработчикам и продуктовым командам, которые хотят запускать инференс LLM на серверах в РФ с предсказуемым бюджетом — без зависимости от зарубежных API-провайдеров и неожиданных счетов.

Что внутри каталога

Каждая модель в каталоге прошла ручную инженерную валидацию с описанием реального прорыва модели, её архитектурных ограничений и сценариев, где она выигрывает у аналогов. Модели добавляются сразу с весами в трёх квантизациях: 4, 8 и 16 бит.

Для каждой модели заранее рассчитаны:

• рекомендуемый размер контекста
• требования к VRAM для каждой квантизации
• доступная память под пользовательские запросы
• максимальное количество одновременных запросов (параллельность)
• скорость генерации и пропускная способность в токенах в секунду (наполняется в процессе валидации)

Система автоматически подбирает конфигурации: от бюджетных решений на одном GPU до кластерных сценариев с балансировщиками нагрузки и аппаратными NVLink/NVSwitch.

Как это работает экономически

В отличие от зарубежных облаков с pay-per-token, immers.cloud тарифицирует по времени работы виртуальной машины или выделенного сервера. Модель разворачивается на арендованном GPU-сервере под полным контролем пользователя: произвольная версия vllm, приватный доступ, кастомные веса, возможность масштабирования.

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

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

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

Для команд, которые не хотят самостоятельно настраивать окружение — доступна круглосуточная техническая поддержка и рекомендованные параметры деплоя.

Попробовать бесплатные модели и запустить приватный инстанс можно на immers.cloud/ai/model/. Там же — видеогайд по деплою приватных инстансов: YouTube, ВКонтакте, Rutube.

Реклама. Рекламодатель: ООО «ДТЛ» ИНН 9717073792, erid: 2W5zFHxMsBf

Выход — поднять собственное S3-совместимое хранилище на том же VPS, где крутится staging. MinIO реализует API Amazon S3, понимает те же SDK и presigned URL, но стоит ровно столько, сколько стоит диск сервера. Один и тот же код приложения работает и с MinIO на dev, и с R2 в проде — меняются только переменные окружения.

Что такое MinIO и почему он подходит для staging

MinIO — это open-source сервер объектного хранилища, написанный на Go. Он поддерживает основные операции S3: бакеты, объекты, multipart upload, versioning, lifecycle, шифрование SSE-S3, CORS и IAM-политики. Для приложения он выглядит как обычный S3-эндпоинт, поэтому подходит почти любой SDK: AWS SDK, boto3, minio-js, aws-sdk-go.

На staging важно не столько масштабирование, сколько идентичность поведения продакшена. Если в проде R2 или S3, а в staging — локальная файловая система, вы тестируете не тот код. MinIO закрывает этот разрыв: тот же PutObjectCommand, те же presigned URL, те же ошибки SignatureDoesNotMatch.

• MinIO — полноценный S3-совместимый сервер, который можно развернуть в Docker на VPS за 10–15 минут.
• Для staging это экономия на хранении тестовых файлов и единый код с продакшеном.
• HTTPS и домен лучше отдавать reverse proxy — Traefik или NGINX — с Let’s Encrypt.
• Presigned URL позволяют загружать и скачивать файлы напрямую из браузера, не проксируя байты через бэкенд.
• Root-ключи MinIO нельзя отдавать приложению: создавайте отдельного пользователя с IAM-политикой только на нужный бакет.

Архитектура: прод против staging

В продакшене обычно используется управляемое хранилище: AWS S3, Cloudflare R2, Yandex Object Storage, Hetzner Object Storage. Там работают репликация, резервное копирование и чужой дежурный. В staging достаточно одного MinIO-контейнера на сервере с регулярным зеркалированием в дешёвое холодное хранилище.

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

Важно: виртуальный хостинг bucket.example.com в MinIO работает, но на staging проще включить path-style и не мучиться с DNS-записями под каждый бакет.

Что понадобится

• VPS с Linux, публичным IP и открытыми портами 80/443.
• Два A-записи: minio-staging.example.com и minio-console.example.com.
• Docker и Docker Compose v2.
• Reverse proxy с TLS — в примере Traefik v2 + Let’s Encrypt.
• Около 10 ГБ свободного места под тестовые данные.

Разворачиваем MinIO в Docker Compose

Минимальный docker-compose.staging.yml заводит один контейнер, внешнюю сеть для Traefik и именованный том для данных.

Два параметра критичны для presigned URL. MINIO_SERVER_URL говорит серверу, на каком публичном домене подписывать ссылки. Без него ссылка будет подписана для http://minio:9000 и браузер отклонит подпись. MINIO_BROWSER_REDIRECT_URL нужен для корректных редиректов веб-консоли.

Прокидываем HTTPS через Traefik

Добавляем лейблы к сервису minio, чтобы Traefik маршрутизировал API и консоль на разные порты и автоматически выпускал сертификаты.

Проверяем здоровье сервера с локальной машины: curl -I https://minio-staging.example.com/minio/health/live должен вернуть HTTP 200.

Cloudflare: для поддомена с API лучше выключить оранжевое облако. Бесплатный тариф Cloudflare обрезает тело запроса на 100 МБ и может убирать S3-заголовки, из-за чего ломается подпись.

Бакеты, политики и отдельный пользователь для приложения

После запуска создаём бакет и отдельного IAM-пользователя. Делать это root-ключами приложения — плохая идея: root может удалить всё.

Теперь создаём пользователя staging-app и IAM-политику, ограничивающую права только этим бакетом.

Логин staging-app и его секрет — это и есть S3_ACCESS_KEY и S3_SECRET_KEY для приложения.

Код приложения не меняется

Пример на AWS SDK v3 для Node.js. Обратите внимание на forcePathStyle: true: без него SDK попытается обратиться к bucket.minio-staging.example.com, и запрос уйдёт в никуда.

Переменные для staging:

Для продакшена — только другой набор значений, код идентичен.

Presigned URL: загрузка и скачивание без проксирования

Presigned URL — это обычный HTTPS URL с короткой подписью в query string. Кто угодно может выполнить ровно то действие, на которое выдана подпись: PUT для загрузки или GET для скачивания. Бэкенд проверяет права, подписывает URL и отдаёт клиенту — сам файл идёт напрямую в MinIO.

Загрузка из браузера

Важный подводный камень: Content-Type, который браузер отправляет при PUT, должен точно совпадать с тем, что было передано в PutObjectCommand. Иначе MinIO вернёт SignatureDoesNotMatch.

Скачивание приватных файлов

Почему это лучше проксирования: при прямой загрузке через ваше API все байты проходят через приложение, съедая CPU, RAM и пропускную способность. С presigned URL трафик идёт между клиентом и MinIO — бэкенд только подписывает ссылку.

CORS, lifecycle и безопасность

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

CORS для браузерных загрузок

Автоудаление старых тестовых файлов

Шифрование данных в покое

И ещё раз: root-ключи храните в менеджере секретов и используйте только для mc admin. Консоль MinIO, если она доступна из интернета, закрывайте IP-allowlist или базовой авторизацией на уровне Traefik.

Бэкапы и мониторинг

Staging не должен хранить что-то ценное, но периодическое зеркалирование в дешёвое холодное хранилище спасает от случайного удаления. Команда mc mirror синхронизирует бакет в Backblaze B2, Yandex Object Storage или другой S3-совместимый бэкенд.

Для метрик MinIO отдаёт Prometheus-экспортёр по пути /minio/v2/metrics/cluster. В Grafana можно импортировать дашборд ID 13502 и сразу видеть занятое место, RPS, задержки и ошибки.

Типичные проблемы

• SignatureDoesNotMatch при PUT — браузер отправил Content-Type, отличный от подписанного. Проверьте заголовок PUT.
• Подписанная ссылка работает локально, но не в браузере — не задан MINIO_SERVER_URL. Ссылка подписана для внутреннего http://minio:9000.
• 403 после Cloudflare — бесплатный тариф Cloudflare модифицирует заголовки. Переведите A-запись в режим DNS-only.
• CORS preflight failed — на бакете не настроены CORS-правила.
• Консоль редиректит на http://minio:9001 — не задан MINIO_BROWSER_REDIRECT_URL.

Выводы

Self-hosted MinIO на staging — это не попытка заменить облако, а способ сделать тестовую среду дешевле и ближе к продакшену. Тот же API, те же SDK, те же presigned URL, но без счетов за хранение битых файлов и ночных сбросов базы.

Ключевые моменты, которые стоит запомнить: всегда указывайте MINIO_SERVER_URL для корректных подписей, не используйте root-ключи в приложении, включайте path-style на staging и настраивайте lifecycle, чтобы мусор не копился.

Самое дорогое в staging — не железо, а различия в кодовых путях между dev и prod. MinIO помогает убрать одну из этих разниц почти бесплатно.

Источник: freeCodeCamp — How to Self-Host an S3-Compatible Object Store with MinIO on Your Staging Server.

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

• Cloud.ru запустила Evolution Stack.ML — платформу для обучения ИИ-моделей в частном и гибридном облаке.
• В основе лежит сервис Evolution Distributed Train: обучение, тюнинг, развёртывание моделей и совместная работа команд.
• Платформа поддерживает изолированные рабочие пространства для более чем 200 команд одновременно.
• По заявлению компании, утилизация GPU растёт с 35% до 90%, а окупаемость серверных мощностей составляет менее 3 месяцев.

Что умеет платформа

Ядро продукта — сервис Evolution Distributed Train. Он объединяет инструменты для разработки, управления экспериментами и мониторинга в единую экосистему. Пользователи могут запускать изолированные рабочие пространства для более чем 200 команд одновременно.

Для распределения нагрузки используются механизмы очередей, приоритетов, аллокаций и спотов. По данным Cloud.ru, это позволяет поднять утилизацию GPU с 35% до 90% и окупить затраты на серверное оборудование менее чем за 3 месяца. Совместное использование кластеров, по оценке компании, ускоряет обучение и разработку новых ИИ-решений на 20%.

Встроенные механизмы self-healing автоматически обнаруживают сбои оборудования, перезапускают задачи и заменяют GPU-ноды. OSS-слой платформы Cloud.ru позволяет отслеживать загрузку инфраструктуры и контролировать расходы.

Evolution Stack.ML помогает преодолеть барьеры для внедрения ИИ в крупном бизнесе и государственных компаниях — решение соответствует строгим требованиям к безопасности и нормам регуляторов. Evolution Stack.ML повышает экономическую эффективность использования собственного «железа» и при этом даёт доступ к самым современным технологиям и методам работы с ИИ.

Для кого это

Решение рассчитано на организации с самыми высокими требованиями к безопасности: государственные и финансовые структуры, операторы ЦОДов и промышленные предприятия. Инфраструктура отвечает требованиям регуляторов к обработке и хранению персональных и финансовых данных, а также размещению ГИС и КИИ.

Cloud.ru также ссылается на собственное исследование: в России растёт спрос на гибридные сценарии. Среди наиболее востребованных — обработка данных и использование ИИ, разработка и тестирование в облаке, георезервирование и disaster recovery.

Выводы

Запуск Evolution Stack.ML — попытка Cloud.ru закрыть спрос на корпоративное ИИ-обучение с соблюдением регуляторных ограничений. Если заявленные цифры подтвердятся в реальных внедрениях, платформа может стать интересной альтернативой самостоятельной сборке инфраструктуры для машинного обучения.

Источник: пресс-служба Cloud.ru.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHcxyBP

SK Hynix — один из крупнейших производителей DRAM и NAND-флеш-памяти в мире, а Nvidia лидирует на рынке ускорителей для ИИ. Вместе компании планируют ускорить развёртывание «фабрик ИИ» (AI factories) — дата-центров, специализированных на обучении и инференсе больших моделей.

Суть соглашения

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

В рамках партнёрства SK Hynix диверсифицирует портфель в три новых направления: инфраструктуру ИИ, персональный ИИ и физический ИИ. Компания будет совместно проектировать память для платформ Nvidia, включая Vera Rubin — следующее поколение ИИ-суперкомпьютеров после Blackwell.

Nvidia и SK Hynix подписали многолетнее соглашение о кодизайне памяти для ИИ.

Партнёрство покрывает Vera Rubin, Vera CPU, RTX Spark и Jetson Thor.

Цель — сократить циклы разработки памяти и ускорить строительство ИИ-фабрик.

SK Hynix внедрит цифровые двойники фабрик на базе Nvidia Omniverse и cuOpt.

Компании будут применять ИИ к проектированию чипов через CUDA-X и PhysicsNeMo.

Технические детали

Ускорение проектирования чипов

SK Hynix внедряет библиотеки NVIDIA CUDA-X и фреймворк PhysicsNeMo для ускорения симуляций полупроводников. Это охватывает TCAD (Technology Computer-Aided Design), вычислительную литографию и внутренние инженерные коды компании.

Распространение этих инструментов на экосистему EDA (Electronic Design Automation) открывает путь к трёхсторонним проектам: производители чипов + Nvidia + вендоры САПР.

Цифровые двойники фабрик

Для автономного управления производством SK Hynix строит цифровые двойники фабрик на базе Nvidia Omniverse и формата OpenUSD. Это позволяет визуализировать, симулировать и оптимизировать сложные производственные процессы в 3D.

Система использует открытый движок оптимизации cuOpt и платформу Nvidia Metropolis для управления автономными мобильными роботами и другими активами на производстве.

ИИ-фабрики — двигатели следующей промышленной революции, а передовая память критична для их производительности. SK Hynix был выдающимся партнёром Nvidia, играя центральную роль в поставке передовых технологий памяти для наших ИИ-платформ. Вместе мы будем совместно проектировать следующее поколение памяти для ИИ-фабрик.

SK Hynix и Nvidia шли к этому годами, и это партнёрство отражает глубину нашей совместной работы. Мы совместно проектируем следующее поколение памяти для ИИ-фабрик и применяем ИИ к тому, как проектируем и производим полупроводники — работа, которая определит будущее ИИ-инфраструктуры.

Выводы

Сделка Nvidia и SK Hynix — не просто контракт на поставку компонентов, а стратегический союз двух лидеров отрасли. Он закрывает критический разрыв между разработкой GPU и памяти, позволяя обеим компаниям синхронизировать дорожные карты.

Для рынка это означает ускорение выхода платформ Vera Rubin и снижение рисков дефицита памяти при масштабировании ИИ-инфраструктуры. Для конкурентов — повышение планки: Samsung и Micron теперь работают в условиях, где ключевой заказчик привязан к SK Hynix на несколько лет вперёд.

Источник: NVIDIA Newsroom, Bloomberg

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

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

1. ITGLOBAL.COM — облако под 1С с гарантией отказоустойчивости

ITGLOBAL.COM построил отдельный кластер под ERP-системы на базе процессоров Intel Xeon Platinum 8558P пятого поколения. Инфраструктура размещена в московском дата-центре IXcellerate MOS5 и оптимизирована конкретно под нагрузки 1С.​

Процессоры работают с базовой частотой 3,1 ГГц на всех 32 ядрах. Когда запускаете ресурсоёмкую задачу (формирование сложного отчёта, проведение пачки документов), частота поднимается до 3,4 ГГц в режиме All-Core Turbo. В пиковых нагрузках система разгоняет отдельные ядра до 4 ГГц благодаря Intel Turbo Boost 2.0.​

Для 1С это важно: платформа активно использует однопоточные операции. Когда пользователь открывает форму документа, система обрабатывает запрос на одном ядре. Чем выше частота этого ядра, тем быстрее выполняется запрос.

Как работает железо

Провайдер не использует переподписку по процессорам. Соотношение 1vCPU:1pCPU означает, что каждое виртуальное ядро привязано к физическому. Вы не делите процессор с соседями по серверу — ваши ресурсы гарантированы. Если кто-то на том же физическом сервере запускает тяжёлый процесс, это не влияет на скорость вашей 1С.​

Оперативная память — DDR5 с частотой 5600 МГц. Провайдер отключил механизмы Swap, Ballooning и TPS — технологии, которые виртуализаторы используют для оптимизации использования RAM. Без них память работает на скорости физического сервера (bare-metal), что даёт предсказуемую производительность при больших нагрузках.​

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

Кэш третьего уровня (L3) — 260 МБ. Это буфер между процессором и оперативной памятью. Чем больше кэш, тем меньше процессору нужно обращаться к RAM за данными.

Диски и хранение данных

Данные хранятся на двух типах систем хранения (СХД): NetApp AFF A800 All-Flash NVMe для "горячих" транзакционных операций и NetApp ASA C60 QLC для хранения архивов, логов и аналитики.​

All-Flash NVMe работает с минимальными задержками и высокими показателями IOPS. Когда 100+ пользователей одновременно проводят документы, читают справочники или формируют отчёты, диски не становятся узким местом.

Хранилища управляются через NetApp ONTAP с встроенной защитой от программ-вымогателей (Autonomous Ransomware Protection). Система анализирует поведение файловых операций в реальном времени: если что-то начинает массово шифровать или удалять файлы, ARP автоматически выявляет аномалии и делает снимки данных; неизменяемость копий при необходимости обеспечивается через SnapLock или объектное хранилище в режиме WORM.

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

Техподдержка работает круглосуточно, инженеры помогают с инфраструктурой: настройка сети, мониторинг, резервное копирование, обновление гипервизора.​

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

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

Инфраструктура соответствует ФЗ-152, ISO 27001. Для компаний, работающих с персональными данными, это закрывает требования регуляторов.​

Среди доступных опций — защита от DDoS-атак, двухфакторная аутентификация (2FA), антивирусная защита, изолированные VLAN-сети и шифрование каналов связи для удаленного доступа к базам 1С.

Резервное копирование настраивается через self‑service‑панель: клиент самостоятельно задаёт расписание и политики хранения. Снимки можно размещать в географически распределённых дата‑центрах, а резервные копии создаются с режимом неизменяемости (immutable backup) — удаление или изменение снимков невозможно в течение заданного периода, что обеспечивает их защиту даже при недоступности основной площадки.

SLA — 99,95% с финансовой ответственностью. Резервирование N+1 на всех уровнях инфраструктуры исключает простои при сбоях оборудования.​

Реальный кейс: как компания SPORA ускорила 1С и получила +37% по тесту Гилёва

SPORA — российская IT-компания, разрабатывающая ПО для медицины (гемодиализ и нефрология). Продукты используются в медучреждениях, поэтому надёжность и скорость IT-систем критичны.​

К середине 2025 года компания столкнулась с проблемой: 1С размещалась на физическом сервере, который не обеспечивал нужной отказоустойчивости и создавал риски остановки работы. Тестирование у другого провайдера затянулось на несколько месяцев, но нужных показателей производительности так и не получили.​

SPORA обратилась в ITGLOBAL.COM с просьбой провести испытания в облаке под реальной нагрузкой. Инженеры развернули выделенный контур в среде VMware vSphere с индивидуальными параметрами виртуализации и оптимизированной конфигурацией хранилища.​

Сначала заказчик отнёсся скептически: предыдущие испытания на процессорах с более высокой базовой частотой не дали результата. Но специалисты ITGLOBAL.COM объяснили, что на производительность 1С влияет не только частота ядра, но и архитектура CPU, настройки виртуализации и работа дисковой подсистемы.​

Результаты тестов

Клиент провёл серию сравнительных тестов:

CPU-тесты:​

• Cinebench R23.2 Single Core: +26% (1109 → 1400)
• Cinebench R23.2 Multi Core: +23% (17503 → 21558)
• CPU-Z Single Thread: +26% (498 → 626)
• CPU-Z Multi Thread: +14% (8727 → 9990)

Тест Гилёва (1С TPC-A Local Throughput):​

• Предыдущий результат: ~35 баллов ("хорошо")
• Облако ITGLOBAL.COM: 48,08 балла ("замечательно")
• Прирост: ~37%
• Максимальная скорость записи: 443 520 КБ/с
• Количество пользователей при тесте: 105

Что получили в итоге:​

• Рост производительности 1С более чем на 30% по результатам синтетических тестов
• Отказоустойчивое размещение вместо одиночного физического сервера
• Оптимальная стоимость за счёт использования общего ERP-кластера вместо выделенного приватного облака
• Стабильная работа при многопользовательской нагрузке и предсказуемое время отклика

Сегодня SPORA использует 1С в облаке ITGLOBAL.COM и рассматривает возможность переноса других сервисов для упрощения управления IT-инфраструктурой.​

Как начать и что по деньгам

Провайдер предоставляет бесплатный тестовый период. Разворачиваете инфраструктуру, переносите тестовую базу 1С, проверяете производительность на реальных задачах — и только потом принимаете решение о переходе.​

Цена зависит от конфигурации: количество vCPU, объём RAM, дисковое пространство. Для небольших баз (до 50 пользователей) есть типовые варианты. Для высоконагруженных систем с сотнями пользователей собирается индивидуальная архитектура с расчётом под проект.​

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

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

2. K2 Cloud — комплексное облако под 1С с экспертизой полного цикла

K2 Cloud — российский облачный провайдер с фокусом на корпоративный сегмент и готовым продуктом под размещение 1С от 50+ пользователей. Подход комплексный: провайдер закрывает всё — от аудита текущей инфраструктуры до поддержки пользователей и поставки лицензий.

Формат работы отличается от простой аренды виртуалок. K2 Cloud сопровождает проект на всём жизненном цикле: проектирование, миграция, тюнинг под требования 1С и проактивный мониторинг после запуска.

Производительность и отказоустойчивость

Инфраструктура построена на базе дата-центров с сертификацией Tier III Gold по Uptime Institute — это один из самых высоких стандартов надёжности для коммерческих ЦОД. SLA достигает 99,98% — выше, чем у большинства конкурентов. Если провайдер не выдержал SLA, компенсация за каждую минуту простоя считается в соотношении 1:20.

​Производительность тюнингуется под требования 1С конкретно: команда K2 Cloud проводит аудит до миграции, выявляет узкие места и оптимизирует конфигурацию. По данным провайдера, компании получают прирост производительности до 30% после переезда в K2 Облако.

Что входит в сервис

Провайдер предоставляет четыре блока услуг:​

• Облачная инфраструктура — вычислительные ресурсы, сеть, хранилище
• Поддержка и администрирование ИТ-инфраструктуры и СУБД
• Предоставление лицензий 1С — купить или взять в аренду
• Поддержка и сопровождение систем 1С — помощь с конфигурациями, обновлениями, ошибками

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

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

Платформа сертифицирована по PCI DSS 4.0, ГОСТ Р 57580.1–2017 и 152-ФЗ до уровня защищённости УЗ-1. Для компаний, которые обрабатывают персональные данные или работают в финансовом секторе, это закрывает требования регуляторов без дополнительных сертификаций. В составе продуктовой линейки есть отдельное «Облако 152-ФЗ» и сервисы кибербезопасности — межсетевое экранирование (NGFW), защита данных от потерь.​

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

K2 Cloud закрывает задачи компаний, которые:​

• Хотят комплексное решение: от аудита и миграции до сопровождения пользователей — в одном контракте
• Работают с высоконагруженными системами 1С от 50+ пользователей
• Переходят на импортонезависимые решения: провайдер помогает с заменой зарубежного ПО на отечественные аналоги
• Должны соответствовать 152-ФЗ УЗ-1, PCI DSS или ГОСТ Р 57580
• Хотят контролируемый процесс миграции с гарантией результата, а не просто «аренду железа»

Среди кейсов — промышленные предприятия, FMCG-компании и IT-интеграторы: «Айсберри» (гибридная инфраструктура с 1С:ERP), завод «Автомобильные технологии» (локализация ИТ-инфраструктуры).​

Как начать и сколько стоит

Провайдер предлагает экспресс-аудит со скидкой 50% на последующее размещение 1С — это способ оценить текущее состояние инфраструктуры и понять, что мешает производительности, ещё до принятия решения о миграции.​

Стоимость рассчитывается индивидуально в зависимости от конфигурации и набора услуг. Можете взять только инфраструктуру, добавить администрирование СУБД или подключить полное сопровождение 1С — всё это собирается по запросу. Контакты, документация и форма заявки доступны на сайте k2.cloud.

3. MWS — комплексный подход к облачной 1С

MWS (MTC Web Services) предлагает под 1С несколько услуг: облачная инфраструктура на базе VMware, сопровождение работы пользователей и гибкое лицензирование.

Сама инфраструктура построена на платформе VMware. Это стандарт корпоративной виртуализации. Провайдер даёт выделенные облачные ресурсы под 1С — виртуальные машины с фиксированными характеристиками, которые не меняются в зависимости от нагрузки соседей.​

Три уровня сервиса:

1С-хостинг — аренда виртуального сервера с заранее настроенными параметрами под 1С. Это не голая виртуалка, которую нужно настраивать с нуля: провайдер уже оптимизировал параметры под специфику платформы. Обслуживание инфраструктуры берёт на себя MWS: мониторинг оборудования в режиме 24/7, обновления гипервизора без участия клиента, регулярное резервное копирование данных. Вы не следите за «здоровьем» серверов — это зона ответственности провайдера.

Помимо хостинга, MWS предлагает 1С-сопровождение (поддержка пользователей по работе с приложениями) и лицензирование (продажа и аренда лицензий 1С от 3 месяцев) — но это уже отдельные услуги, которые подключаются по необходимости.

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

MWS закрывает задачи компаний, которые:

• Хотят передать всю ответственность за работу 1С одному подрядчику — от серверов до консультаций пользователей
• Нуждаются в гибком лицензировании с возможностью аренды на короткий срок
• Ценят комплексный подход, когда не нужно координировать несколько подрядчиков
• Используют виртуальные рабочие места для удалённых сотрудников
• Хотят снизить риски, связанные с зарубежным ПО, но не знают, как это сделать технически

Как начать и сколько стоит

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

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

Контакты и формы заявок доступны на сайте mws.ru. Провайдер работает с партнёрской сетью — если вы интегратор или IT-компания, можете зарегистрировать партнёрскую сделку и получить условия для реселлинга.

4. Selectel — облачные и выделенные серверы под 1С

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

Провайдер — официальный партнёр 1С по аренде программного обеспечения. Платформенные лицензии и конфигурации уровня ПРОФ и КОРП доступны прямо через Selectel: не нужно искать отдельного поставщика.

Облачные серверы

Облачные серверы подходят компаниям с непостоянной или растущей нагрузкой. Ресурсы масштабируются по мере необходимости, оплата — по фактическому потреблению. Инфраструктура соответствует 152-ФЗ (УЗ-1), PCI DSS и GDPR. SLA — до 100%.​

Для управления серверами доступны панель управления, API, Terraform и KVM. Если у вас есть DevOps или системный администратор, настроить инфраструктуру под 1С можно с тем инструментарием, с которым команда уже работает.

Выделенные серверы

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

Железо и дата-центры

Selectel использует высокочастотные процессоры и NVMe SSD-диски. Дата-центры сертифицированы по уровню Tier III: резервирование электропитания, защита от пожаров, климат-контроль. Физическая инфраструктура обеспечивает базу для предсказуемой работы 1С — особенно при многопользовательской нагрузке, когда диски и процессор работают на полную.

Экосистема и интеграции

Помимо серверов, в рамках одной инфраструктуры доступны: управляемые базы данных, Managed Kubernetes, резервное копирование, защита от DDoS, балансировщик нагрузки, глобальный роутер и DNS. Если 1С интегрируется с другими сервисами — CRM, складским учётом, интернет-магазином — всё это можно развернуть внутри одной сети с минимальными задержками.

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

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

Как начать и сколько стоит

Зарегистрируйтесь в панели, выберите формат сервера и конфигурацию. Стоимость зависит от выбранных ресурсов, тарифы и калькулятор — на сайте. Если переезжаете от другого провайдера или с on-premise, инженеры Selectel готовят план миграции и сопровождают на всех этапах. Бонусы на переезд — до 1 000 000 рублей.

5. Beeline Cloud — телеком-провайдер с Enterprise-подходом к 1С

Beeline Cloud — облачное подразделение телеком-оператора с фокусом на корпоративный сегмент. Для 1С здесь предлагают выделенную инфраструктуру и специализированный продукт "1C Cloud Pro" — отказоустойчивое решение для высоконагруженных систем.​

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

Линейка продуктов под разные задачи

Конкретный продукт под 1С у Beeline Cloud — Cloud 1C, специализированное облако с выделенной инфраструктурой для проектов любой сложности.​

Что входит в Cloud 1C

Провайдер берёт на себя весь процесс: от переезда до настройки и поддержки.​

• Выделенная платформа — готовая инфраструктура для реализации проекта, без дележа ресурсов с соседями
• Быстрый переезд — перенос проекта 1С в облако от 1 дня
• Бесплатная настройка — конфигурацию берёт на себя провайдер
• Высокая мобильность — удалённый доступ к 1С для нужных сотрудников из любого места

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

Инфраструктура построена на высокопроизводительных серверах Cisco и HP, системах хранения данных HP и Infinidat, процессорах Intel Xeon Gold нового поколения. Комплексный подход включает выделенные каналы связи, ежедневное резервирование данных и мониторинг производительности.​

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

Инфраструктура аттестована по 152-ФЗ на уровне УЗ-1. SLA — 99,95% с финансовыми гарантиями, техподдержка 24/7. Проекты, требующие соответствия ФЗ-152, размещаются в отдельном аттестованном контуре.​

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

Beeline Cloud выделяет три основных сценария использования Cloud 1C:​

• Снижение расходов — готовая инфраструктура без капитальных затрат на оборудование
• Масштабирование ресурсов — облако гибко масштабируется под текущую нагрузку
• Защита персональных данных — размещение в аттестованной по УЗ-1 инфраструктуре для компаний с требованиями регуляторов

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

Как начать

Заходите на сайт, оставляете заявку — команда предложит решение или рассчитает стоимость сервиса. Можете сразу указать, какой формат нужен: публичное облако, частное, выделенный кластер или специализированное решение для 1С.​

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

База знаний, кейсы, вебинары — всё доступно на сайте.

Что выбрать

Провайдеры решают одну задачу, но по-разному.

Yandex Cloud — для тех, кто хочет использовать PostgreSQL на Linux и строить аналитику через экосистему Яндекса.

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

Selectel — готовая платформа из коробки. Создали кластер, сразу работаете. Миграция за 1 рубль.

Beeline Cloud — для корпораций с требованиями к отказоустойчивости, защищённым каналам связи и 152-ФЗ УЗ-1.

ITGLOBAL.COM — специализированный ERP‑кластер на базе Intel Xeon Platinum Gen 5, оптимизированный под нагрузки 1С. Решение построено на All‑Flash NVMe‑дисками, DDR5‑памятью и без переподписки процессоров (1vCPU:1pCPU), поэтому вы получаете производительность на уровне физического сервера.

Инфраструктура, поддержка пользователей и аренда лицензий — ITGLOBAL.COM предлагает всё в рамках одного договора, через «единое окно».

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

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

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

IaaS-платформа с иммерсионным охлаждением immers.cloud

В immers.cloud можно арендовать виртуальные машины и bare metal-серверы под ресурсоемкие задачи. Сервис ориентируется на обучение нейросетей, работу с LLM, инференс, 3D-рендеринг, обработку видео и сценарии, где локального железа уже мало, а покупать собственный парк серверов пока рано.

Инфраструктура размещена в Москве, в дата-центре уровня Tier-III. Базовый формат работы здесь классический для IaaS: пользователь поднимает ВМ или выделенный сервер и дальше сам собирает нужную среду под свою задачу.

Какие GPU доступны

У платформы собран пул из 13 моделей видеокарт NVIDIA под разные нагрузки. Для ML-задач с большим потреблением памяти доступны H200 на 141 ГБ и H200 на 141 ГБ с NVLink, H100 на 80 ГБ и на 94GB с NVLink, A100 на 80 ГБ и Tesla V100 на 32 ГБ. Отдельно отметим, пожалуй, H100 и A100 с поддержкой GPUDirect и NVLink. Для задач, где нужен быстрый обмен данными между ускорителями, это полезная штука.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4 на 16 ГБ, A2 на 16 ГБ, A10 на 24 ГБ и RTX 3080 на 10 ГБ. Для рендеринга, графических задач и смешанных вычислений можно арендовать RTX 2080 Ti на 11 ГБ, RTX 3090 на 24 ГБ, RTX A5000 на 24 ГБ, RTX 4090 на 24 ГБ или RTX 5090 на 32 ГБ.

Под какие сценарии подходит, как используют

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

1. Если ML-стартапу нужно развернуть MVP или проверить гипотезу, нет смысла сразу брать флагманы. Под пилоты обычно поднимают инстансы среднего ценового сегмента — например, с RTX 3090, RTX 4090 или Tesla V100. Стенд обходится в 65–100 ₽ за час работы и позволяет тестировать модели без капитальных затрат на железо.
2. Для R&D-команд, которые занимаются файн-тюнингом и обучением LLM, критичен объем видеопамяти. Адаптация предобученных моделей (в том числе через подготовку LoRA) уходит на тяжелые конфигурации с H200, H100 или A100.
3. Когда модель готова, её выносят в продакшн для стабильного инференса по API. Здесь выбор железа зависит от аппетитов самой нейросети: легкие модели и агенты спокойно крутятся на Tesla T4 или A10 (от 20 до 40 ₽/час), а высоконагруженные сервисы с крупными LLM забирают мощности с A100.
4. Для потоковой обработки видео, задач компьютерного зрения и 3D-рендеринга собирают стенды на профессиональных картах вроде RTX A5000 или топовых RTX 5090.

Как устроена инфраструктура и экосистема

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

Технически платформа immers.cloud — это инфраструктурный слой на базе OpenStack. Здесь пока нет управляемого Kubernetes-сервиса, а вся работа строится вокруг виртуальных машин. С одной стороны, придется собирать окружение на ВМ самостоятельно. С другой — это дает понятную модель управления, где можно поднимать ресурсы строго под свою сборку и не бороться с абстракциями, которые навязывает провайдер.

Чтобы снять часть рутины с настройкой среды, есть маркетплейс готовых образов. Там лежат преднастроенные шаблоны с CUDA, PyTorch, TensorFlow и Jupyter.

Отдельно развернут Immers Foundation Models — каталог моделей, который закрывает сразу два этапа разработки: от выбора модели до первого запуска. Для прототипирования и проверки гипотез доступны бесплатные публичные эндпоинты. Инженер просто прокидывает токен и адрес модели в код, собирает MVP и тестирует логику продукта без затрат на инфраструктуру.

Когда сервис протестирован и готов к нагрузкам, команда переезжает на выделенные мощности. Для этого в каталоге предусмотрен запуск нужной модели «одной кнопкой». Система сама оценивает требования к VRAM и разворачивает подходящую GPU-конфигурацию.

Каталог сокращает путь и делает проще запуск: инженеру не нужно вручную проверять совместимость, подбирать GPU-конфигурацию и оценивать требования к VRAM под разные сценарии инференса. Вместо разных репозиториев и документации команда получает готовую точку входа для быстрого тестирования моделей, оценки стоимости запуска и развёртывания собственного inference-стека.

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

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

Инфраструктуру можно поднимать не только руками через веб-консоль, но и встраивать в привычный инженерный контур. У сервиса есть CLI через openstack-client и Terraform-провайдер OpenStack. Managed Kubernetes находится в разработке, поэтому оркестрация контейнеров из коробки пока недоступна.

Тарификация

У платформы собран пул из 13 моделей видеокарт NVIDIA под разные нагрузки. Для ML-задач с большим потреблением памяти доступны H200 на 141 ГБ и H200 на 41 ГБ с NVLink, H100 на 80 ГБ и на 94GB с NVLink, A100 на 80 ГБ и Tesla V100 на 32 ГБ. Отдельно отметим, пожалуй, H100 и A100 с поддержкой GPUDirect и NVLink. Для задач, где нужен быстрый обмен данными между ускорителями, это полезная штука.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4 на 16 ГБ, A2 на 16 ГБ, A10 на 24 ГБ и RTX 3080 на 10 ГБ. Для рендеринга, графических задач и смешанных вычислений можно арендовать RTX 2080 Ti на 11 ГБ, RTX 3090 на 24 ГБ, RTX A5000 на 24 ГБ, RTX 4090 на 24 ГБ или RTX 5090 на 32 ГБ.

На платформе действует посекундная тарификация — оплата списывается только за фактическое время работы инстанса. Прерываемых (spot) машин нет.

Самая доступная конфигурация собирается на Tesla T4 16 ГБ (шаблон teslat4-1.4.8.60). Вместе с 4 vCPU, 8 ГБ RAM и сетью она обходится в 19,93 ₽ за час работы.

Стоимость других младших инстансов за час: A2 — 21,94 ₽, RTX 2080 Ti — 25,05 ₽, A10 — 36,55 ₽, RTX 3080 — 42,96 ₽.

Средний сегмент за час аренды: RTX 3090 — 66,76 ₽, RTX 4090 — 82,76 ₽, Tesla V100 — 96,61 ₽, RTX A5000 — 109,77 ₽, RTX 5090 — 130,76 ₽.

Тяжелые конфигурации в час: A100 — 211,77 ₽, H100 — 341,77 ₽, H100 NVL — 367,41 ₽, H200 — 423,04 ₽.

Для долгосрочных заказов предусмотрена скидка от 10 до 50%, а списания при таком формате происходят раз в сутки.

Особенности железа

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

Ограничения и безопасность

Формат работы на платформе подойдет инженерам, которые умеют собирать окружение на ВМ и работать с OpenStack-логикой. Полноценной managed ML-платформы и онбординга для ML-команд здесь нет.

Инфраструктура имеет сертификат ГОСТ Р ИСО/МЭК 27001-2021 по системам менеджмента информационной безопасности, но не соответствует требованиям 152-ФЗ. Это стоит учитывать при работе с персональными данными.

Поддержка и условия работы

Вся базовая документация собрана в подробном FAQ на русском языке. Техническая поддержка отвечает в течение 20 минут через чат на сайте, Telegram, Max или email.

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

Инфраструктура для high-load и ML-проектов ITGLOBAL.COM

На ITGLOBAL.COM разворачивают GPU-инфраструктуру для машинного обучения, высокопроизводительных вычислений (HPC), рендеринга и сложной аналитики. Форматов несколько: классические облачные инстансы, выделенные серверы, гибридные схемы и аренда суперкомпьютера на базе NVIDIA HGX. Платформа заточена под команды, которым нужны серьезные мощности Enterprise-уровня без капитальных затрат на закупку собственного железа.

Какие GPU доступны

В пуле провайдера стоят актуальные корпоративные решения. Главная техническая фича — поддержка vGPU. Физическую видеокарту можно делить между несколькими виртуальными машинами — части изолированы друг от друга, так что данные одной ВМ недоступны другим. Теперь ресурсы масштабируются только под задачу, а команда не переплачивает за ненужные мощности.

Например, NVIDIA RTX Pro 6000 Blackwell Server Edition на 96 ГБ можно нарезать на профили по 12, 24, 48 ГБ или забрать все 96 ГБ под одну ВМ. Для более тяжелых задач доступны инстансы с H200 на 141 ГБ и флагманские B300 на 288 ГБ.

Также в пуле есть A100 и A800 (по 80 ГБ), L40S на 48 ГБ, серверы с NVIDIA A16 (четыре чипа по 16 ГБ) и ускорители Sophgo SC7 HP75. Мощности Enterprise-уровня всегда держат в наличии под высоконагруженные проекты.

География и форматы размещения

Инфраструктура ITGLOBAL.COM размещена в Москве, Минске, Алматы, Ташкенте, Шэньчжэне, Амстердаме, Торонто, Нью-Джерси, Дубае и Сан-Паулу. Если проект требует строго локального размещения или интеграции с внутренним контуром безопасности, провайдер может выдать инфраструктуру с GPU прямо на площадку клиента.

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

Ресурсы забирают под разные этапы для работы с данными. Команды Data Science обучают модели скоринга, прогнозирования оттока или рекомендательные алгоритмы на NVIDIA H200 и NVIDIA RTX PRO 6000 Blackwell Server Edition хорошо тянут видеоаналитику и Computer Vision для промышленных и логистических объектов, где нужно анализировать плотные видеопотоки.

Если речь идет про инференс LLM или запуск AI-приложений в high-load сценариях, инженеры обычно поднимают ресурсы уровня NVIDIA HGX H200 или кластеры NVIDIA HGX B300. Ограничений на фреймворки, оркестраторы или объем данных со стороны платформы нет. Клиент получает IaaS с полным контролем над средой, упираясь только в архитектурные лимиты самих чипов NVIDIA и поддерживаемые драйверы.

Как устроена инфраструктура и экосистема

Для управления ресурсами доступны API, CLI и возможность использования terraform провайдера, поэтому поднимать и гасить инстансы можно программно. Преднастроенные стеки с CUDA, PyTorch, TensorFlow или Jupyter собираются и уточняются на старте под конкретный проект. Для команд, которые хотят снять с себя часть инфраструктурной рутины, доступен Managed Kubernetes и управляемая ML-платформа.

Для хранения объемных датасетов и работы с данными предусмотрен отдельный S3-совместимый сервис объектного хранилища.

Тарификация и условия

Жесткой публичной сетки тарифов за час здесь нет — провайдер работает по проектному ценообразованию. Итоговый чек зависит от модели GPU, конфигурации, сроков аренды и формата размещения. Прерываемых (spot) инстансов не предусмотрено, зато для долгосрочных и крупных проектов действуют индивидуальные скидки.

Пользователь сам управляет ресурсами и может собрать нужную конфигурацию. Рекомендуемая минимальная сборка включает 12 ГБ vGPU, 4 vCPU и 16 ГБ оперативной памяти. При необходимости параметры можно ужать до базового минимума: 12 ГБ vGPU, один vCPU (Xeon 2.8 ГГц), гигабайт RAM и гигабайт быстрого SSD (с возможностью добавить HDD).

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

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

Облако имеет аттестат соответствия требованиям 152-ФЗ. Также компания обладает сертификатами ФСТЭК и ФСБ. Все лицензии и документы выложены в открытом доступе на сайте.

Поддержка и документация

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

Первичные запросы обрабатывают в течение двух часов. Оставить заявку можно через сайт, почту sales@itglobal.com, по телефону +7 812 439 18 72 или через Telegram-бота. Действующие клиенты решают вопросы через личного менеджера, клиентский портал, облачную панель или выделенную почту support@itglobal.com.

Кастомные GPU-серверы и Managed-сервисы от Selectel

В Selectel можно арендовать облачные инстансы и bare-metal серверы под ML-задачи, инференс, работу с графикой и сложные вычисления. Провайдер дает возможность гибко собрать нужную инфраструктуру: от быстрой аренды облачной ВМ на час до сборки кастомных физических серверов на базе процессоров Intel Xeon Scalable и AMD EPYC.

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

Какие GPU доступны

У платформы собран широкий пул профессиональных и консьюмерских видеокарт NVIDIA под разные нагрузки. Для тяжелых ML-задач доступны NVIDIA A100 (в том числе в конфигурации на 40 ГБ) и NVIDIA V100. Из свежего железа в пуле есть NVIDIA A30.

Если речь идет о небольших моделях, агентных сценариях или более легком инференсе, доступны Tesla T4, A2 и консьюмерская линейка — GTX 1080, RTX 2080 Ti и RTX 4090. Для рендеринга, графических задач и рабочих станций VDI можно арендовать профессиональные RTX A2000, A4000 и A5000.

Под какие сценарии подходит, как используют

Платформу чаще используют под конкретные инфраструктурные задачи и этапы разработки:

Для R&D-команд, которые занимаются машинным обучением, файн-тюнингом и глубоким обучением (Deep Learning), берут тяжелые конфигурации с A100 или A30. Мощности позволяют быстро обучать нейросети под классификацию изображений, распознавание речи (face recognition) и проверку на фрод.

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

Отдельный пласт задач — транскодинг видео и работа с графикой. На серверах с GPU разворачивают среды для стриминга (с поддержкой NVIDIA NVENC и разрешением до 8192×8192), 3D-моделирования, видеомонтажа онлайн и развертывания удаленных рабочих мест (VDI). Также инфраструктуру применяют для научного моделирования и сложных параллельных CUDA-вычислений в инженерии, физике и математике.

Как устроена инфраструктура и экосистема

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

Для тех, кто не хочет возиться с голой инфраструктурой, у Selectel есть готовые PaaS-решения. В первую очередь это Managed Kubernetes — он упрощает развертывание контейнеров, масштабирование, настройку микросервисной архитектуры и CI/CD пайплайнов (от 5 958 ₽/мес). Также провайдер берет на себя администрирование облачных баз данных вроде PostgreSQL и Timescale.

Для работы с датасетами, весами и бэкапами к платформе подключается S3-совместимое объектное хранилище (от 0,81 ₽/мес) с тройной репликацией данных. Для сложной инфраструктуры можно использовать файловое хранилище (от 138 ₽/мес) и объединять локальные и облачные сети через глобальный роутер или Direct Connect.

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

Инфраструктуру можно поднимать не только руками через панель управления Selectel, но и встраивать в инженерный контур с помощью API.

Тарификация

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

Ограничения и безопасность

Selectel делает сильный упор на защиту данных. Серверы соответствуют требованиям 152-ФЗ до первого уровня защищенности. Инфраструктура имеет сертификат PCI DSS, ISO 27001, аттестаты ГИС К1 и СТР-К 1Г. Это значит, что на серверах можно хранить чувствительные персональные данные, медицинскую информацию и данные платежных карт.

Дополнительно в Selectel работает IAM-система для разграничения доступов и ролей, которую можно связать с внутренним SSO. Все проекты бесплатно получают базовую защиту от DDoS-атак на уровнях L3 и L4. Если нужна защита серьезнее, можно подключить фильтрацию трафика на уровне приложений L7 (от 2 600 ₽/мес).

Глобальная GPU-инфраструктура и гранты на тесты от Timeweb Cloud

На Timeweb Cloud можно арендовать облачные и выделенные серверы под параллельные вычисления: машинное обучение, аналитику бигдаты, 3D-рендеринг, IoT и гейминг. Инфраструктура развернута в дата-центрах уровня Tier III в России, СНГ, Европе и США. Провайдер делает ставку на быстрый старт — облачные инстансы поднимаются за пару минут, а вычислительные ресурсы можно быстро масштабировать.

Какие GPU доступны

Вычислительный парк провайдера построен исключительно на графических процессорах NVIDIA. Под тяжелые AI-вычисления, работу с бигдатой и профессиональное ПО предоставляются серверы с GPU серии A: A2, A30, A2000, A4000, A5000 и A6000. Для виртуализации и ML-сценариев в облаке доступна Tesla T4.

Для гейминга, стриминга и рендеринга можно арендовать серверы на базе GeForce GTX (1080 DDR5X, 1080 Ti) или RTX с поддержкой тензорных и рейтрейсинг-ядер (2080 Ti, 3080, 3090, 4090).

Топовые корпоративные ускорители под крупные модели — Tesla H200 (141 ГБ), H100 (80 ГБ), A100 (80 ГБ) и L4 (24 ГБ) — пока предоставляются в формате предзаказа.

Под какие сценарии подходит, как используют

Платформу применяют под конкретные инфраструктурные задачи и этапы разработки:

Для ИИ и машинного обучения берут инстансы под обучение нейросетей, deep learning, сборку рекомендательных систем, чат-ботов и распознавание речи и изображений. Здесь в ход идут карточки Tesla T4 и решения серии A.

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

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

Как устроена инфраструктура и экосистема

Архитектура облака построена с тройным региононезависимым резервированием. Это собственная разработка провайдера, которая снижает риск потери данных при локальных сбоях.

Помимо ВМ, в экосистему входят Managed-сервисы. Для оркестрации контейнеров можно развернуть Managed Kubernetes. Для хранения весов моделей и датасетов есть S3-совместимое объектное хранилище и облачные базы данных. Также в пуле сервисов доступны балансировщики нагрузки и маркетплейс. Если команда не хочет тратить время на перенос инфраструктуры, инженеры провайдера берут миграцию данных на себя.

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

Управлять ресурсами можно через веб-панель или программно, встраивая запуск в инженерный пайплайн. Для этого доступны классические инструменты автоматизации: API, CLI, Terraform и Cloud-init.

Тарификация

Тарифы формируются за месяц, но оплата работает по часовой модели — деньги списываются раз в час за реально потребленное время. В любой момент можно добавить процессоры (vCPU), оперативную память (RAM) или диски без простоя системы.

Для проверки гипотез и тестирования среды предусмотрен грант до 1 000 000 ₽ на срок до шести месяцев. Это позволяет обкатать архитектуру перед финальным решением о переезде.

Ограничения и безопасность

Особенность площадки — широкая география присутствия. Дата-центры стоят в Москве, Санкт-Петербурге, Сибири, Казахстане, Нидерландах, Германии, Турции, Финляндии и Нью-Йорке.

Платформа включена в Единый реестр российского ПО, соответствует требованиям 152-ФЗ, международного стандарта PCI DSS и ISO. Облако по умолчанию защищено от DDoS-атак, при необходимости фильтрацию можно точечно усилить на уровнях L3, L4 и L7.

Поддержка и условия работы

Техническая поддержка работает в режиме 24×7×365. Для проектов с бюджетом от 50 000 ₽ в месяц включается премиум-обслуживание: прямая связь с топ-менеджментом (CEO, CTO), ответы в режиме ASAP, возможность овердрафта и повышенные скидки.

Виртуальные серверы с GPU для машинного обучения от Cloud4Y

В Cloud4Y можно арендовать облачные GPU-серверы с видеокартами NVIDIA. Инфраструктура заточена под машинное обучение (ML), искусственный интеллект (AI), параллельные вычисления, работу с большими данными и 3D-графикой. Виртуальные инстансы помогают командам ускорить обработку датасетов и тренировку нейронных сетей без закупки собственного железа.

Какие GPU доступны

Cloud4Y делает ставку на проверенные корпоративные решения. Для машинного обучения, работы с графикой и высокопроизводительных вычислений (HPC) платформа предлагает видеокарты NVIDIA Tesla V100 и NVIDIA Tesla P100.

Ресурсы предоставляются по модели vGPU. Доступны конфигурации с разным объемом видеопамяти под конкретные задачи — например, P100 с 8 ГБ или 16 ГБ, а также V100 с 1 ГБ или 2 ГБ видеопамяти на борту.

Под какие сценарии подходит, как используют

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

Для задач Data Science и обучения нейросетей (Deep Learning) мощности берут под сборку алгоритмов и анализ больших массивов данных. Инстансы можно использовать для разработки приложений виртуальной и дополненной реальности, а также для параллельных вычислений на базе архитектуры CUDA.

Отдельный сценарий — 3D-графика, транскодинг видео и рендеринг. Для этих задач на облачных серверах поднимают удаленные рабочие столы по технологии VDI (Virtual Desktop Infrastructure). Ресурсы vGPU равномерно распределяются между сессиями пользователей, а доступ к рабочему месту с графикой идет через стандартный RDP-клиент.

Как устроена инфраструктура и экосистема

Чтобы сократить время от аренды до первого запуска модели, у Cloud4Y есть готовые образы — DSVM (Data Science Virtual Machine). Серверы разворачиваются с уже предустановленными пакетами приложений: PyTorch, TensorFlow, Keras, XGBoost, Scikit-learn, OpenCV и Jupyter Notebooks.

Также из коробки доступны библиотеки NumPy и Pandas для ускорения процесса обучения. Для сложной оркестрации ML-процессов провайдер может развернуть готовый шаблон с Kubeflow.

В экосистему платформы входит S3-совместимое объектное хранилище, облачные базы данных и сервис Managed Kubernetes. Для надежности предусмотрено резервное копирование в облако и услуга Disaster Recovery (аварийное восстановление).

Тарификация

Арендовать графические мощности можно с почасовым или помесячным биллингом. Расчет стоимости по итогу месяца идет с округлением до целых единиц в большую сторону. Сама услуга vGPU приобретается как дополнение к базовой IaaS-инфраструктуре (облачному серверу). Бесплатно предоставляется интернет-канал на 100 Mbps с возможностью расширения до 1 Гбит/с.

Стоимость зависит от выделенного объема видеопамяти и ресурсов сервера:

• Базовый вариант для VDI и графики (NVIDIA GRID P100 ML vGPU) начинается от 3,39 ₽ за час.
• Конфигурация под вычисления с V100 1 Gb (6 vCPU, 64 RAM, 120 SSD) обойдется от 25 ₽ за час.
• Инстанс с P100 8 Gb (4 vCPU, 32 RAM, 120 SSD) стоит от 24,5 ₽ за час.
• Более тяжелая сборка с P100 16 Gb (16 vCPU, 64 RAM, 120 SSD) тарифицируется от 46 ₽ за час.

Аренда облачного железа позволяет сократить расходы на оборудование до 70%. Если текущих конфигураций недостаточно, провайдер может собрать GPU-сервер по индивидуальному запросу.

Поддержка и условия работы

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

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

Если проект находится на стадии проверки гипотез и вам нужно быстро добежать до инференса без возни с настройкой окружения, логично смотреть в сторону площадок вроде immers.cloud. Там фокус смещен на снятие рутины через готовые хабы моделей и стабильную работу железа под нагрузкой. Когда же продукт обрастает энтерпрайз-требованиями и требует развертывания тяжелых кластеров с прицелом на глобальный рынок, инфраструктурный подход меняется, и здесь можно посмотреть в сторону решений ITGLOBAL.COM.

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

Историю обнародовал журналист Брайан Кребс в материале от 18 мая по наводке исследователя из GitGuardian. Репозиторий назывался без лишней скромности — Private-CISA — и был виден любому, кто откроет GitHub.

• Подрядчик CISA с 13 ноября 2025 года вёл публичный репозиторий Private-CISA размером 844 МБ с паролями, ключами AWS GovCloud, сертификатами Entra ID SAML и Kubernetes-манифестами.
• Пароли лежали в открытом виде в CSV-файле, а среди файлов был importantAWStokens с админ-доступом к трём серверам AWS GovCloud.
• Чтобы такое стало возможным, в аккаунте было выключено стандартное правило GitHub, блокирующее коммиты с секретами.
• GitGuardian называет утечку «худшей в карьере» исследователя, но CISA утверждает, что «нет признаков компрометации чувствительных данных».
• Репозиторий закрыли вечером 15 мая 2026 года, спустя около 26 часов после уведомления исследователей — но он был публичным около полугода.

Что лежало в Private-CISA

GitGuardian, компания, у которой сканер постоянно обходит публичные репозитории GitHub в поисках утёкших секретов, наткнулась на репозиторий 14 мая 2026 года. По объёму это 844 МБ — 498 МБ в рабочем дереве, остальное в истории Git. Среди папок и файлов исследователи нашли:

• importantAWStokens — административные токены к трём серверам AWS GovCloud (изолированный облачный регион Amazon для госструктур США).
• AWS-Workspace-Firefox-Passwords.csv — экспорт сохранённых паролей Firefox с десятками логинов и паролей от внутренних систем CISA в открытом виде.
• CAWS GitHub Token.txt — отдельный токен GitHub-организации.
• Kube-Config.txt — конфигурации Kubernetes для доступа к кластерам.
• Папку ENTRA ID — SAML Certificates с сертификатами для единого входа через Microsoft Entra ID.
• Папки All Backups, Backup-April-2026, LZ-Artifactory, Kubernetes-Important-Yaml-Files — внутренние бэкапы, манифесты ArgoCD и YAML-файлы с секретами.
• Terraform-код инфраструктуры и GitHub Actions, описывающие, как CISA собирает, тестирует и выкатывает свой софт.
• Резервные копии внутренней документации в форматах OneNote и DOCX, плюс скрипты для GitHub, Kubernetes, ArgoCD.

Один из попавших в репозиторий хостов назывался LZ-DSO — по словам исследователей это сокращение от Landing Zone DevSecOps, то есть от среды, в которой CISA «безопасно» собирает свой код. Иронично: ключи от пайплайна, который должен защищать всё остальное, лежали публично.

Это худшая утечка, которую я видел за свою карьеру.

Сначала команда GitGuardian приняла находку за розыгрыш: слишком уж красноречивые названия папок и файлов. Но личные документы, имена хостов и аккуратная структура повторных бэкапов убедили — это рабочая копия чьего-то ноутбука, которую регулярно «синхронизировали» через git push в открытый репозиторий.

Как нашли и сообщили

Согласно подробному разбору GitGuardian, программа Good Samaritan компании первой обнаружила утечку и автоматически отправила девять писем владельцу коммитов. К утру 15 мая в ответ пришли только автоответчики.

Тогда исследователи связались с Брайаном Кребсом, чтобы он передал утечку напрямую своим контактам в CISA. Параллельно подключились партнёры с прямой линией в агентство. Около 16:00 по центральноевропейскому времени удалось дозвониться, а в районе 18:00 по восточному времени США репозиторий стал недоступен. От первого выявленного слива до закрытия прошло чуть больше суток — но создан репозиторий был 13 ноября 2025 года, так что окно для злоумышленника составляло около полугода.

Хронология

• 13 ноября 2025 — создан публичный репозиторий Private-CISA, первые секреты залиты.
• 13 мая 2026 — автоматический сканер GitGuardian Good Samaritan уже успел отправить владельцу репозитория девять писем-предупреждений.
• 14 мая 2026, 16:14 CET — GitGuardian фиксирует инцидент и подаёт его в CERT/CC (координационный центр по реагированию на киберинциденты), параллельно ища личные контакты в CISA.
• 15 мая 2026 — GitGuardian параллельно выходит на Кребса для эскалации через его контакты и на собственных партнёров с прямой линией в агентство; около 16:00 CET до CISA дозваниваются.
• 15 мая, около 18:00 EST — репозиторий удалён.

Почему secret scanning не сработал

GitHub давно предлагает push protection — функцию, которая не даёт залить в публичный репозиторий распознанные секреты вроде токенов AWS, ключей SSH или ключей API. Для бесплатных публичных репозиториев она включена по умолчанию с 2024 года. Но защита от дурака легко выключается одним кликом, и в случае с Private-CISA её действительно отключили — Кребс цитирует исследователей, которые нашли в истории коммитов следы того, что владелец аккаунта вручную убрал блокировку секретов.

Это распространённый паттерн: разработчик сталкивается с блокировкой пуша, не разбирается, почему сработала защита, и снимает её через настройки. Иногда — в личном репозитории «для удобства», иногда — потому что коммит уже содержит что-то более чувствительное, чем тестовый ключ. Результат предсказуем: репозитории, в которых годами лежат «временные» .env-файлы с продакшен-доступами, и автоматические сканеры вроде GitGuardian, TruffleHog или GitHub Secret Scanning, которые рано или поздно их находят.

По версии Gizmodo, сотрудник подрядчика Nightwing использовал GitHub как личную папку «Загрузки»: коммитил файлы с рабочего ноутбука, чтобы открыть их на домашнем компьютере. То же самое многие делают через личную почту, только публичный репозиторий ещё хуже — он проиндексирован поисковиками и сканируется ботами в режиме реального времени.

Кто такая CISA и почему это важно

Особый цинизм истории — в том, кто оказался виновником. CISA (Cybersecurity and Infrastructure Security Agency) — молодое подразделение Министерства внутренней безопасности США, отвечающее за кибербезопасность всех федеральных гражданских сетей. Это именно та организация, которая публикует руководства про «никогда не храните пароли в спредшитах». При этом, по данным TechCrunch, у CISA с 20 января 2025 года нет постоянного директора, агентство потеряло около трети штата после сокращений и отпусков, а ни один временно исполняющий обязанности не был утверждён Сенатом. В таких условиях процессы по контролю подрядчиков и аудиту репозиториев предсказуемо проседают — и тот факт, что утечку у регулятора по кибербезу нашёл частный сканер, а не внутренние инструменты, красноречивее любого внутреннего отчёта.

Что делать в своей команде, чтобы не повторить историю CISA

История CISA читается как готовый чеклист «как не надо». Перевернём его в «как надо» — для команд от стартапа до крупного бизнеса.

1. Включите GitHub push protection на уровне организации и запретите её отключать. Owner organization → Security → Secret protection → Push protection: Enabled.
2. Запретите коммитеры-индивидуумам быть owner репозиториев в проде. Любой публичный репозиторий компании должен принадлежать организации с настроенными правилами.
3. Сканируйте свою историю, а не только новые коммиты. Один раз пропущенный .env остаётся в Git forever — поможет TruffleHog, GitGuardian, GitHub Advanced Security или встроенный git-secrets.
4. Не используйте Git как файлообменник между домашним и рабочим компьютером. Для этого есть VPN, корпоративный OneDrive, S3-бакет с IAM, в конце концов — scp.
5. Включите автоматическую ротацию ключей AWS и сервис-токенов. Даже если они утекут, окно использования закроется через сутки-двое.
6. Настройте мониторинг подозрительных вызовов API в облаке. Для AWS — CloudTrail + GuardDuty с алертами на новые регионы, необычные IAM-действия и обращения к AWS API из неизвестных IP. Если ключ всё-таки утёк — вы узнаете об этом по логам, а не из новостей.
7. Раз в квартал проводите аудит публичных репозиториев: gh repo list ORG --visibility public и быстрая проверка, что там должно лежать публично.

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

Что говорят сами CISA и эксперты

Сводный ответ агентства для Кребса и TechCrunch звучит как стандартная PR-формула. TechCrunch уточняет, что комментарий дал пресс-секретарь CISA Марко ДиСандро:

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

Проблема в формулировке «нет признаков»: при шестимесячном окне публичности любые токены стоит считать скомпрометированными по умолчанию. Стандартный план действий — отозвать всё, выпустить новое, проанализировать логи AWS CloudTrail на предмет обращений с этих токенов и опубликовать честный разбор инцидента. До такого разбора инцидента публично CISA пока не дошла, и в TechCrunch агентство не ответило, отозваны ли ключи.

Что в итоге

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

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

Для разработчиков вывод предельно практичный: включите push protection, проверьте свои публичные репозитории, не подсовывайте секреты в Git ни на минуту. История CISA — это просто очень громкая иллюстрация того, как один человек, перетаскивающий файлы с ноутбука на ноутбук через git, способен поставить под угрозу целое ведомство.

Источники: Krebs on Security — CISA Admin Leaked AWS GovCloud Keys on Github; GitGuardian Blog — How We Got a CISA GitHub Leak Taken Down in Under a Day; TechCrunch — US cyber agency CISA exposed reams of passwords and cloud keys to the open web; Gizmodo — «The Worst Leak That I've Witnessed».

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

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

Мультиклауд уже давно стал полноценной частью нашей жизни. Согласно исследованию MWS Cloud, среди компаний, пользующихся виртуальной инфраструктурой, 31% предприятий размещают свои данные в двух и более облаках, 10% — в трёх и более. Наше партнёрство с Cloud.ru позволит нам упростить использование этой концепции для наших клиентов — помочь им гибко управлять инфраструктурой сразу у двух ведущих российских провайдеров, чтобы эффективнее балансировать нагрузки и снижать затраты. Мы убеждены, что за мультиклаудом — будущее облачного рынка, и намерены формировать его вместе с ведущими провайдерами страны, делая мультиоблачные сценарии доступнее и удобнее для российского бизнеса.

Запуск сервиса запланирован на июнь 2026 года. На первом этапе услуга станет доступна через обращение в поддержку. В дальнейшем компании планируют организовать запуск сервиса «по клику». Это сократит время создания соединений между облаками партнёров до нескольких минут.

Подписание этого соглашения — важный шаг в реализации нашей стратегии по созданию надёжной и гибкой цифровой среды для бизнеса. Объединяя наши компетенции с Cloud.ru, мы предлагаем рынку уникальную синергию ресурсов. Наше сотрудничество позволит клиентам использовать преимущества мультиоблачного подхода, обеспечивая высокий уровень катастрофоустойчивости и доступ к передовым AI-технологиям, таким как интеллектуальные ассистенты и системы управления корпоративными знаниями.

Cloud.ru — один из крупнейших облачных и ИИ-провайдеров России. Компания основана в 2019 году и за несколько лет вошла в число лидеров рынка инфраструктурных, платформенных, а также ИИ-решений.

В портфеле Cloud.ru — более 100 инфраструктурных и платформенных сервисов, публичное облако Cloud.ru Evolution на базе собственных технологий, аттестованная инфраструктура для размещения ГИС и КИИ, платформа для частных и гибридных облаков Evolution Stack, а также цифровая среда для промышленной работы с генеративным ИИ — Evolution AI Factory.

В команде компании — более 2 000 специалистов, преимущественно в области ИТ, кибербезопасности и ИИ.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHDSEaD

Selectel, крупнейший независимый провайдер IT-инфраструктуры в России (более 33 000 клиентов, 17 лет на рынке), на этой конференции не только анонсировал новые продукты, но и предложил системный взгляд на то, как строить AI-инфраструктуру, чтобы она работала на бизнес, а не против него.

Главные анонсы Selectel: новый AI-сервер и развитие платформы

Первый и, пожалуй, ожидаемый анонс — новый высокопроизводительный AI-сервер Selectel. Решение разработано с акцентом на сбалансированную архитектуру. Сервер представляет собой 8U-платформу с собственной материнской платой, поддержкой двух процессоров Intel Xeon 6 (до 144 ядер) и возможностью установки до 8 ТБ оперативной памяти DDR5. Ключевая особенность — до 16 графических ускорителей на ноду и продуманная топология PCI-линий, минимизирующая задержки при передаче данных между CPU, памятью и GPU.

«Новая аппаратная платформа обеспечит стабильную, быструю и предсказуемую работу AI-моделей в реальных условиях с полным контролем над данными и производительностью», — прокомментировал Дмитрий Шиченко, руководитель отдела разработки встроенных систем Selectel.

Второй важный анонс касается AI-платформы Selectel. Обновлённый Foundation Models Catalog переведён в публичный статус и теперь доступен всем клиентам. Каталог позволяет разворачивать LLM на выделенной инфраструктуре с поддержкой автомасштабирования, получать логи и метрики инференса (observability), управлять сервисами через REST API. В качестве основного движка инференса используется vLLM — высокопроизводительный open-source фреймворк, увеличивающий производительность без роста затрат.

В каталог уже добавлены модели IBM Granite, Alibaba Qwen, DeepSeek, Microsoft Phi, Mistral AI, а в ближайшее время появятся Kimi, GLM, Gemma, Whisper и другие. Оплата сейчас идёт за фактические вычислительные ресурсы, а в ближайшее время станет доступна тарификация по токенам.

«Наша задача — обеспечить компаниям быстрый переход от экспериментов с AI к экономически эффективному применению. Мы предоставляем не просто "железо", а комплексный набор решений — от серверов c GPU до платформенных продуктов, закрывающих задачи пилотных проектов и промышленной эксплуатации», — отметил Александр Тугов, директор AI-вертикали Selectel.

Единое окно для внедрения ИИ-агентов

Ещё одно важное событие конференции — начало сотрудничества Selectel с российским вендором Data Sapience и консалтинговой группой GlowByte. Партнёры объявили о создании комплексных решений для корпоративных заказчиков: от бизнес-задачи до промышленной эксплуатации ИИ-агентов и больших языковых моделей.

В рамках партнёрства Selectel подтвердил технологическую совместимость инфраструктуры с платформой Kolmogorov AI от Data Sapience, которая обеспечивает полный цикл работы с моделями — от подготовки данных до мониторинга и оркестрации в промышленном контуре. Selectel предоставляет гибкую инфраструктуру (публичное и частное облако, аренду выделенных серверов, размещение GPU на площадке клиента, в том числе в аттестованных сегментах ЦОД), а GlowByte выступает интеграционным партнёром: консалтинг, архитектура, дообучение моделей и сопровождение.

Такой подход позволяет компаниям получать end‑to‑end предложение «из одного окна», сокращая время от пилота до реального внедрения и обеспечивая соответствие регуляторным требованиям. Решения ориентированы на автоматизацию сложных процессов, поддержку принятия решений, анализ больших данных и построение приватных ИИ-сред в условиях строгой безопасности.

«В партнёрстве с Data Sapience и GlowByte мы объединяем экспертизу инфраструктурного провайдера, вендора платформенных решений и консалтинговой компании, чтобы упростить компаниям путь к эффективному внедрению ИИ», — прокомментировал Александр Тугов.

Экосистема вокруг платформы: что обсуждали на техническом треке

Кроме докладов команды Selectel, на техническом треке выступили эксперты из других компаний. Своим опытом поделились:

• Антон Алексеев, MLOps-инженер AvitoTech рассказывал о построении централизованной ML-платформы;
• Владислав Шевченко, CTO red_mad_robot рассказывал про кризис SDLC и объяснял, почему нельзя просто написать код и ждать результата;
• Максим Пантелеев, руководитель направления Core M&D. Wildberries & Russ поделился последними результатами исследования интерпретируемости LLM по мотивам участия в сообществах и опыта работы над проектами red- и blue-teaming LLM.

Программа технического трека подтвердила главный тренд: ИИ-инфраструктура и платформенный подход становятся сквозной темой для разных отраслей.

Почему AI-инфраструктура — это не просто GPU

AI-инфраструктура не исчерпывается графическими ускорителями. В реальном пайплайне инференса LLM нагрузка распределяется между сетевыми картами, оперативной памятью, CPU (пред- и постобработка, токенизация, формирование батчей), PCI-шиной и только потом — GPU. Каждый этап может стать узким горлышком.

«Просто взять графический ускоритель и запустить на нём модель — это как поехать на болиде Формулы-1 по гравию. Двигатель мощный, но быстрее не станет», — пояснил Дмитрий Шиченко.

Именно поэтому при разработке нового AI-сервера в Selectel сделали упор на баланс ресурсов: процессоры последнего поколения с высокими частотами, 4 ТБ оперативной памяти на частоте 6400 МТ/с, высокоскоростные интерконнекты (до 128 ГБ/с между CPU и GPU, до 900 ГБ/с между GPU через NVLink). И топологию материнской платы с детерминированной архитектурой PCI-линий.

«Привычный закон Мура для AI больше не работает. У нас теперь закон Хуанга: GPU морально устаревают за 2 года, а не за 5–7. Амортизировать серверное железо по старым правилам — значит гарантированно проиграть по TCO», — считает Владислав Кирпинский, директор по облачной интеграции Selectel.

Как выглядит эффективный инференс на реальных задачах

Технические результаты наглядно показывают, что даёт сбалансированная архитектура.

Сценарий 1.

• Модель на 400 млрд параметров (Qwen 3.5), длинный контекст, сотни одновременных пользователей.
• Конфигурация: 8 × H100, 112 ядер CPU, 512 ГБ RAM.
  
• Результат: 500 токенов в секунду.
  

«При 150 токенах в секунду нейросеть уже отвечает быстрее, чем человек читает. А 500 токенов — это инференс с большим запасом для реальных Enterprise-нагрузок», поясняет Дмитрий Шиченко, руководитель отдела разработки встроенных систем Selectel.

Сценарий 2.

• Модель на 1 трлн параметров (Kimi k2, Mixture of Experts), ещё более длинный контекст, до 1000 пользователей.
• Конфигурация: RTX 6000 Pro Server Edition (увеличенный объём VRAM), 2 ТБ RAM.
  
• Результат: 150 токенов в секунду — более чем достаточно для диалоговых систем и ассистентов.
  

Итоги: AI-инфраструктура как стратегический актив

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

Selectel на этом фоне предлагает комплексную историю:

• Инфраструктура — собственные сбалансированные AI-серверы, широкая линейка GPU (от потребительских до enterprise), гибкие модели потребления (BareMetal, облако, аренда на площадке клиента, гибрид).
• Платформа — Foundation Models Catalog в публичном доступе, observability, API‑управление, поддержка vLLM.
• Экспертиза — собственные инженеры, разработка серверов и материнских плат, независимость от поставщиков.
• Развитие направления партнерств с ведущими российскими AI-вендорами, обладающими экспертизой для решения отраслевых и специализированных бизнес-кейсов.
  

Как отметил один из спикеров конференции: «GPU без платформы — это кирка без рудника». Selectel же предлагает и кирку, и рудник, и карту местности. Для Enterprise это означает снижение рисков, предсказуемое TCO и возможность сфокусироваться на бизнес‑результатах, а не на том, почему инференс тормозит или почему GPU не окупаются за 5 лет.

AI‑инфраструктура перестаёт быть историей про «купить железо». Она становится историей про управляемость, экономику и скорость изменений. Именно этот переход — от GPU к платформе — стал главным итогом «MLечного пути».

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

Сначала цифры: как вырос Cloud.ru

На конфренции Cloud.ru впервые публично раскрыла детальную финансовую отчётность. Выручка за 2025 год — 76,5 млрд рублей (+50% год к году). Чистая прибыль — 14,7 млрд(+86%).

Основной драйвер роста — инфраструктура для ИИ: обучение и инференс моделей дали 54% выручки. При этом классические облачные сервисы тоже выросли на 31%, что быстрее темпов роста рынка России.

По инфраструктуре Cloud.ru — один из крупнейших облачных провайдеров в стране. В парке находится 43 000+ единиц оборудования, 29 000+ серверов, 9 ЦОДов суммарной мощностью 56 МВт.

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

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

АФЛТ-Системс, например, уже в активной фазе перехода к регулярной эксплуатации AI. Павел Павленко, руководитель направления развития GenAI, говорит: «GoCloud для меня в этом году — про то, как индустрия перешла от разговоров про потенциал GenAI к разговору про реальные внедрения, метрики и архитектурные решения. Мы строим внутреннюю AI-платформу, выстраиваем процессы и запускаем первые продукты, в том числе AI-фикацию пайплайна разработки. На таком этапе ценность партнёра измеряется не презентациями, а скоростью реакции и готовностью идти в эксперимент».

Что происходит на рынке: от пилотов к промышленной эксплуатации

Последние 2–3 года компании делали пилоты по внедрению генеративного ИИ в основном благодаря визионерской силе лидеров, CEO, директоров. Пилоты часто были точечными и экспериментальными: автоматизировали поддержку и отвечали на частые простые вопросы, генерировали контент.

Сейчас модели стали лучше, а бизнес опытным путем выяснил, какие функции эффективнее передавать ИИ. Результаты пилотов всё чаще признаются успешными.

Например, Артём Бондарь, руководитель направления NLP в Центре искусственного интеллекта Т-Банка, выделяет три ключевых направления GenAI-инструментов. Первое — агенты и копайлоты в полном цикле разработки. Второе — инструменты для HQ-профессий: от генеративных моделей для общих задач до вертикальных решений вроде автоматической генерации креативов «почти без касания людей».

Но прямой финансовый эффект особенно заметен в автоматизации поддержки и операционки. Здесь задействован весь спектр GenAI-подходов:

• пошаговая автоматизация с помощью LLM там, где есть регламентированный процесс,
• агенты, которые ищут решение в сконструированной для них среде,
• и AI-сотрудник Афанасий Иванов (АИ), который работает в компании уже больше года и использует те же интерфейсы, что и люди.

Становится ясно, что перелом скоро наступит. И это точно не год.

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

DevOps-практики тоже перешли в практическую плоскость. В МТТЕХ выстроили модель GitOps, где Git — единый источник истины, а все изменения проходят через ревью и автоматизированный деплой. IaC-подход (Terraform, Ansible) и self-hosted GitLab в облаке позволяют управлять инфраструктурой как кодом.

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

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

Neocloud: GPU как отдельное направление

На этом фоне Cloud.ru выделил AI-инфраструктуру в отдельное бизнес-направление — Neocloud. Это единая управляемая среда для полного цикла работы с моделями: от разработки и обучения до инференса и эксплуатации.

Нагрузки под ИИ сильно отличаются от классических. Для них нужны высокоскоростные соединения между GPU, умный шедулинг (днём — инференс, ночью — дообучение), возможность получить кластер из сотен HGX, а потом отпустить. Но на рынке такого предложения нет. Neocloud как раз решает управление вычислительными ресурсами на масштабе.

В Neocloud есть:

• Доступ к тысячам современных GPU в публичном облаке.
• Поддержка гибридных сценариев (своя инфраструктура + облако).
• Собственная платформа Distributed Train для распределённого обучения с проактивным мониторингом, автоматической заменой отказавших узлов и гибким управлением очередями.

Чем Neocloud выгодно разработчикам

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

Выгодная стоимость для Cloud.ru остается приоритетом. Компания заявляет, что не планирует повышать цены в этом году.

Это не единственный аргумент в пользу облака. Как отмечает Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность, для госсектора и крупных компаний есть ещё одно важное преимущество: «С облаком удобнее проходить закупочные процедуры. Ты сделал рамочный договор, и в любой момент, когда у тебя появился новый госзаказчик, быстро развернул инфраструктуру».

Агенты: EvoClaw, Agent Space и новый способ общения с облаком

Другой инструмент, о котором рассказали на конференции, — EvoClaw. Это управляемый облачный сервис для работы с OpenClaw и другими open source агентными фреймворками. ИИ-агент обеспечивает observability, мониторинг, логирование и поддерживает политики безопасности. Cloud.ru одним из первых в России приступил к открытому тестированию OpenClaw ещё в феврале 2026 года.

Ключевые особенности EvoClaw:

• Агент запускается в пару кликов.
• Политики безопасности приведены к Zero Trust, привилегии — по минимальному принципу.
• Агенты изолированы своим рабочим пространством.
• Интеграция с AI Factory (Foundation Models, AI Agents, Managed RAG).

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

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

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

Ещё одно решение Cloud.ru для работы с агентами — Agent Space — мобильное и десктоп-приложение, которое позволяет чатиться с агентом. Оно работает на протоколе A2A (Agent-to-Agent). А в каталоге представлены уже более 20 бизнес-сценариев, среди которых и «Агент Python-разработчик».

AI Workflows: low-code оркестратор

Бизнес-процесс редко состоит из одного действия. Обычно это цепочка: проверить данные в 1С, прогнать их через LLM, создать задачу в Jira, отправить уведомление в Telegram.

Для таких сценариев Cloud.ru запустил AI Workflows — low-code конструктор, который сейчас находится в публичном тестировании.

Пользователь собирает цепочку шагов в визуальном интерфейсе (как в n8n, но с ИИ-блоками). На каждом шаге можно подключить готовый коннектор к 1С, Jira, Confluence, PostgreSQL, почтовым клиентам, мессенджерам или внутренним сервисам через API. А между ними — вызовы LLM из Evolution Foundation Models, инференс-моделей или даже готовых агентов.

На старте AI Workflows ориентирован на готовые коннекторы и предсобранные кубики. Вставлять кастомные скрипты прямо в цепочку пока нельзя. Но в компании понимают, что разработчикам это нужно и планируют дать такую возможность, подчеркивает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

На пресс-конференции прозвучала интересная мысль: AI Workflows — это тоже промежуточный этап. Через пару лет, когда компании привыкнут делегировать задачи ИИ, и этот уровень оркестрации станет не нужен, всё будет ИИ-фицировано насквозь.

Безопасность: Guardrails и Container Security

Агенты получают доступ к вашей инфраструктуре. Да, это удобно, но возникает закономерный вопрос: как не допустить, чтобы агент случайно (или специально) не отправил чувствительные данные во внешнюю LLM? Или не поднял контейнер с критической уязвимостью?

На GoCloud 2026 анонсировали два инструмента, которые закрывают эти риски — на уровне данных и на уровне инфраструктуры.

Guardrails Filter: чтобы секреты не утекли

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

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

Evolution Container Security: чтобы контейнеры не стали дырой

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

По оценкам экспертов, порядка 80% запущенных кластеров Kubernetes содержат роли с избыточными привилегиями. И Evolution Container Security обеспечивает безопасность контейнерных сред Kubernetes. Сервис уже доступен в публичном тестировании.

Возможности Evolution Container Security:

• Сканирование контейнеров на уязвимости (включая БДУ ФСТЭК).
• Встроенный ИИ-агент для генерации политик безопасности.
• Создание и управление политиками через конфигуратор.
• Проверка конфигураций во время развёртывания.

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

Что еще волнует безопасников

На круглом столе «Облако уже сегодня. Как получить конкурентное преимущество без компромиссов по безопасности» участники честно рассказали о своих страхах. Главный — потеря контроля. «Облако — это чёрный ящик, который необходимо контролировать, обвязывать своими сервисами, чтобы перепроверять подрядчика», — поделился Артём Сычев, первый заместитель генерального директора РТ-Информационная безопасность.

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

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

Но есть и другой уровень безопасности — физический. Антон Фомин, CDO Navio, рассказывает, как GenAI помогает спасать жизни: «Как собрать данные о лобовом столкновении, не отправляя водителя на встречную машину? Мы это делаем с помощью нашего фотореалистичного стимулятора. Вот настоящая польза генеративного ИИ: заглянуть за горизонт и научить машины ездить без риска».

Гибридные облака: почему это сложно и как Cloud.ru стали одними из первых в этом поле

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

Что такое гибрид на самом деле? Если отбросить маркетинговые формулировки, гибрид — это частное облако (on-prem) + публичное облако + связь между ними под единой платформой. Из единого личного кабинета можно управлять ресурсами и там, и там, переезжать виртуальными машинами из публичного облака в свой ЦОД и обратно.

Гибрид для меня — это возможность использования on-prem инфраструктуры, но с биллингом, управлением ресурсами, логированием, личным кабинетом

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

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

Почему индустрия всё равно придёт к гибриду

• Безопасникам проще контролировать конфигурации и видеть всю инфраструктуру.
• Финансистам — смотреть утилизацию оборудования.
• CTO — видеть все виртуальные машины.
• В on-prem сложно инвентаризировать legacy-системы. Гибрид даёт прозрачность.

Cloud.ru начал строить гибридную платформу ещё на ранней стадии публичного облака. В прошлом году анонсировали Evolution Stack — платформу для создания частных и гибридных облаков. Клиенты уже могут получить единые политики безопасности, мониторинг и логирование для on-prem и публичного облака. Единой консоли управления «из облака» (модель Outpost, как у западных гиперскейлеров) пока нет. Но пилоты с единым центром управления готовы запускать уже сейчас.

В России почти нет провайдеров, которые могут предложить гибридное облако как отчуждаемый продукт, который можно установить у себя в ЦОДе. Cloud.ru сделал это за счёт того, что публичное облако и гибридная платформа построены на единой кодовой базе. Сервисы идентичны, пользовательский опыт одинаковый. Разработка начинается в публичном облаке, а прод уезжает на on-prem — и это работает, потому что сервисы внутри одни и те же.

Что будет с разработкой: не паникуем, но не забываем готовиться

Агенты уже пишут код, тестируют, разворачивают инфраструктуру. DevOps-инженер отдаёт помощнику создание виртуальных машин и настройку баз данных. SRE-агент сам поднимает метрики и ищет первопричины инцидентов. Вопрос, который возникает у каждого разработчика: «Меня заменят?»

В ближайшем будущем роли не отомрут, но изменятся. «Разработчику нужно поднимать уровень, становиться тимлидом — а его тиммейтами будут агенты», считает Анастасия Тафеенко, директор блока разработки платформы Cloud.ru Evolution.

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

Новый челлендж — экономика решений. Можно написать агенту одну строчку, а потом 10 тысяч раз переделывать, уточнять, перезапускать. Каждый шаг — это токены. А токены — это деньги. Борьба будет не за то, кто быстрее написал код, а за то, сколько стоило решить задачу.

Новая роль — оркестратор агентов. На круглом столе «DevOps инструменты в облаке» представители МТТЕХ, Familia, Ventra и «Технологии – и точка» сформулировали главный тренд: «Мы движемся к модели, где человек становится оркестратором агентов. Он их направляет, пишет принципы, управляет — как оргструктурой».

Количество агентов будет расти драматически — от десятков до тысяч. И тот, кто научится управлять этой «армией», останется востребованным.

Агенты не приходят на пустое место. Основной барьер для внедрения ИИ-агентов не технологический, а организационный. Если в компании данные разрознены, процессы не формализованы, а культура не готова делегировать решения машине — никакой агент не поможет. И наоборот: в компаниях, где данные структурированы и процессы прозрачны, агенты достигают 60–90% автоматизации.

Lemonade — open-source сервер для локального запуска ИИ-моделей от AMD. Написан на C++ (серверный бинарник ~2 МБ), автоматически настраивается под GPU, NPU и CPU, совместим с OpenAI API. Проект набирает обороты на Hacker News (120+ баллов за несколько часов) и нацелен на то, чтобы сделать локальный ИИ таким же простым, как облачный.

• Lemonade — open-source сервер локального ИИ от AMD, написанный на C++ (бинарник ~2 МБ)
• Автоматически конфигурирует бэкенды для GPU (Radeon), NPU (Ryzen AI) и CPU
• Совместим с OpenAI API — любое приложение, работающее с OpenAI, подключается заменой endpoint
• Мультимодальный: текст, изображения, распознавание речи, синтез речи
• Работает на Windows, Linux и macOS (бета), установка за минуту

Lemonade — не новый проект (первые версии появились в 2025 году), но версия 10.0, вышедшая в марте 2026, добавила поддержку NPU на Linux через FastFlowLM — и именно это привлекло внимание сообщества.

Что умеет Lemonade

Lemonade — это локальный сервер, который принимает запросы по OpenAI-совместимому API и маршрутизирует их к оптимальному бэкенду:

• Текстовая генерация — через llama.cpp, Ryzen AI SW, FastFlowLM
• Генерация изображений — через stablediffusion.cpp
• Распознавание речи — через whisper.cpp
• Синтез речи — через Kokoro
• Vision — мультимодальные модели с анализом изображений

Можно запускать несколько моделей одновременно — ограничение только в доступной оперативной памяти.

Зачем NPU и при чём тут AMD

NPU (Neural Processing Unit) — специализированный процессор для ИИ-задач, встроенный в чипы AMD Ryzen AI 300 и 400 серий. В отличие от GPU, NPU потребляет значительно меньше энергии и работает тихо — идеально для фоновых ИИ-задач на ноутбуке.

До Lemonade 10.0 NPU на Ryzen AI работал только под Windows. Теперь через FastFlowLM 0.9.35 доступна поддержка Linux с контекстом до 256 000 токенов. Это делает Ryzen AI реальной альтернативой для разработчиков, которые работают на Linux.

OpenAI API: подключение за минуту

Главное преимущество Lemonade — совместимость с OpenAI API. Если приложение уже работает с OpenAI, переключение на локальный Lemonade сводится к замене endpoint:

Это уже работает с:

• VS Code — через расширения (Continue и другие)
• Continue — автодополнение кода
• n8n — автоматизация рабочих процессов
• OpenWebUI — веб-интерфейс для чатов с моделями

Установка и запуск

Установщики доступны для Windows (MSI), Linux (DEB, RPM, AppImage, Snap, AUR) и macOS (бета):

Lemonade автоматически определит доступное железо (GPU, NPU, CPU) и настроит оптимальный бэкенд. Для тех, кто предпочитает графический интерфейс, есть десктоп-приложение с менеджером моделей, встроенным чатом и контролем сервера.

Чем Lemonade отличается от Ollama и LM Studio

• Поддержка NPU — Lemonade единственный из крупных проектов поддерживает AMD Ryzen AI NPU нативно
• Мультимодальность — не только текст, но и изображения, речь, транскрипция в одном сервере
• Множество движков — llama.cpp, FastFlowLM, whisper.cpp, stablediffusion.cpp, Kokoro под одним API
• AMD-оптимизация — enterprise-тестирование на Ryzen и Radeon, но работает и на других платформах
• 2 МБ бинарник — легковесный C++ сервер, не Electron-приложение

Выводы

Lemonade — ставка AMD на то, что локальный ИИ станет стандартом. Проект решает реальную проблему: фрагментацию экосистемы локального запуска моделей. Один сервер, один API, автонастройка под железо — и текст, и картинки, и речь.

Для разработчиков на AMD Ryzen AI особенно интересна поддержка NPU на Linux — до Lemonade 10.0 этой возможности не было. Проект open-source и активно развивается сообществом.

Скачать: lemonade-server.ai | Исходники: GitHub | Сообщество: Discord

Что такое Kubernetes

Kubernetes (произносится «кубернетес», сокращённо K8s) — это система оркестрации контейнеров с открытым исходным кодом, которая автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. Kubernetes был создан компанией Google на основе внутренней системы Borg и передан в открытый доступ в 2014 году. Сегодня он управляется фондом Cloud Native Computing Foundation (CNCF).

Если Docker — это технология упаковки приложений в контейнеры, то Kubernetes — это система, которая управляет этими контейнерами в промышленном масштабе: решает, на каком сервере их запустить, следит за их здоровьем, перезапускает упавшие, масштабирует под нагрузку и обновляет без простоев.

- Kubernetes автоматизирует развёртывание, масштабирование и управление контейнерами - Основные сущности: Pod, Node, Cluster, Deployment, Service, Namespace - Архитектура делится на Control Plane (управление) и Worker Nodes (исполнение) - K8s поддерживает самовосстановление: упавший Pod перезапускается автоматически - Kubernetes подходит для больших распределённых систем; для небольших проектов достаточно Docker Compose - Минимальный старт — Minikube или kind на локальной машине за 10 минут - Облачные решения GKE, EKS, AKS берут на себя управление Control Plane - По данным CNCF на 2024 год, Kubernetes используют или оценивают более 84% организаций (CNCF 2023)

Зачем нужен Kubernetes — проблема управления контейнерами в масштабе

Контейнеры решили проблему «у меня работает, у тебя не работает» — приложение вместе со всеми зависимостями упаковывается в изолированный образ. Но с ростом количества контейнеров появляются новые проблемы.

• Высокая доступность. Если контейнер упал — его нужно перезапустить. Вручную это нереально при сотнях сервисов.
• Балансировка нагрузки. Трафик нужно распределять между несколькими экземплярами одного сервиса.
• Масштабирование. В час пик нужно быстро добавить экземпляры, ночью — убрать, чтобы сэкономить ресурсы.
• Обновления без даунтайма. Rolling update или blue-green деплой требуют координации.
• Управление конфигурацией и секретами. Переменные среды, токены, сертификаты — всё это нужно доставлять в контейнеры безопасно.
• Размещение на серверах. Решить, на каком из 50 серверов запустить очередной контейнер, учитывая доступные ресурсы CPU и памяти.

По данным CNCF, организации, использующие микросервисную архитектуру, в среднем управляют более чем 10 сервисами в продакшене, а крупные компании — тысячами. Вручную это не масштабируется. Kubernetes решает все перечисленные задачи декларативно: вы описываете желаемое состояние системы, а K8s сам приводит её к этому состоянию и поддерживает его.

Основные концепции Kubernetes

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

Pod — минимальная единица развёртывания

Pod — это один или несколько контейнеров, которые всегда запускаются вместе на одном узле и разделяют сетевое пространство (один IP-адрес) и тома хранилища. Обычно один Pod = один контейнер с основным приложением. Второй контейнер в Pod используется как sidecar: например, для сбора логов или проксирования трафика.

Node — рабочий узел кластера

Node (узел) — это физическая или виртуальная машина, на которой запускаются Pod-ы. Каждый узел содержит kubelet (агент, который следит за Pod-ами), kube-proxy (сетевые правила) и container runtime (Docker, containerd или CRI-O). В кластере обычно несколько узлов — от 3 до тысяч в крупных системах.

Cluster — совокупность всех узлов

Cluster (кластер) — это набор узлов, управляемых единым Control Plane. Весь Kubernetes работает внутри кластера. Один кластер может объединять сотни серверов в разных датацентрах.

Deployment — управление жизненным циклом приложения

Deployment — это объект, который описывает желаемое состояние для набора Pod-ов: сколько реплик должно работать, какой образ использовать, как выполнять обновления. Deployment следит за тем, чтобы нужное количество Pod-ов всегда было запущено, и управляет rolling-обновлениями.

Service — стабильная точка доступа к Pod-ам

Service — это абстракция, которая предоставляет стабильный IP-адрес и DNS-имя для набора Pod-ов. Pod-ы могут создаваться и удаляться, их IP меняется — Service обеспечивает постоянную точку входа и балансирует нагрузку между ними. Основные типы: ClusterIP (внутри кластера), NodePort (снаружи по порту узла), LoadBalancer (облачный балансировщик).

Namespace — изоляция ресурсов внутри кластера

Namespace — это виртуальный раздел внутри кластера. Позволяет изолировать ресурсы разных команд, проектов или окружений (dev, staging, production) в рамках одного кластера. По умолчанию существуют namespace-ы: default, kube-system, kube-public.

Как работает Kubernetes — архитектура изнутри

Kubernetes состоит из двух уровней: Control Plane (управляющий слой) и Worker Nodes (рабочие узлы). Разберём каждый компонент.

Control Plane — мозг кластера

• API Server (kube-apiserver) — единственная точка входа для всех операций с кластером. Все компоненты общаются только через API Server. kubectl, CI/CD системы, внутренние контроллеры — всё идёт через него. Принимает REST-запросы, валидирует их и сохраняет состояние в etcd.
• etcd — распределённое хранилище типа «ключ-значение», где хранится всё состояние кластера: конфигурации, метаданные Pod-ов, секреты. Это единственное место с состоянием в Kubernetes — если etcd жив, кластер восстановим.
• Scheduler (kube-scheduler) — отвечает за размещение новых Pod-ов на узлах. Учитывает доступные ресурсы узлов, affinity-правила, ограничения и политики. Не запускает Pod-ы сам — только решает, на каком узле их запустить.
• Controller Manager (kube-controller-manager) — набор контроллеров, каждый из которых следит за определённым типом ресурсов. Deployment Controller следит, чтобы работало нужное число реплик. Node Controller реагирует на отказ узлов. ReplicaSet Controller поддерживает заданное количество Pod-ов.

Worker Nodes — исполнители

• kubelet — агент на каждом узле. Получает от API Server описание Pod-ов, которые должны работать на этом узле, запускает их через container runtime и сообщает статус.
• kube-proxy — управляет сетевыми правилами на узле (iptables или IPVS). Обеспечивает работу Service: трафик к виртуальному IP Service перенаправляется на реальные Pod-ы.
• Container Runtime — движок для запуска контейнеров. Kubernetes поддерживает containerd (рекомендован), CRI-O и Docker Engine через специальный shim.

Типичный жизненный цикл запроса: вы применяете YAML через kubectl apply → API Server сохраняет объект в etcd → Scheduler находит подходящий узел → kubelet на том узле получает задание и запускает контейнер → Controller Manager следит, что всё работает как описано.

Kubernetes vs Docker Compose vs Docker Swarm — когда что использовать

Выбор инструмента зависит от масштаба задачи. Не стоит использовать Kubernetes там, где достаточно Docker Compose — это избыточная сложность.

• Docker Compose — идеально для локальной разработки и небольших проектов на одном сервере. Простой синтаксис, быстрый старт, нет оверхеда. Не умеет автоматически восстанавливаться при отказе хоста, не масштабируется горизонтально.
• Docker Swarm — встроенная кластеризация Docker. Проще Kubernetes, подходит для небольших кластеров (2–10 серверов), когда не нужны продвинутые возможности. Экосистема значительно меньше, развитие заморожено.
• Kubernetes — для продакшен-систем с требованиями к высокой доступности, горизонтальному масштабированию, сложным сетевым политикам и богатой экосистеме. Оправдан при наличии хотя бы 3–5 сервисов и команды DevOps.

Если вы можете управлять системой через Docker Compose — используйте Docker Compose. Kubernetes стоит выбирать, когда боль от ручного управления стала больше, чем сложность K8s.

Ключевые отличия в цифрах: Docker Compose запускается за секунды, Kubernetes требует минимум 3 узла для продакшена и несколько часов на начальную настройку. Зато Kubernetes поддерживает до 5000 узлов и 150 000 Pod-ов в одном кластере.

Как начать работу с Kubernetes

Для изучения и разработки не нужен облачный кластер. Есть несколько способов запустить Kubernetes локально.

Minikube — классический локальный кластер

Minikube запускает однонодовый кластер Kubernetes в виртуальной машине или контейнере. Поддерживает macOS, Linux и Windows. Встроен dashboard, поддержка нескольких профилей и дополнений.

kind — Kubernetes в Docker

kind (Kubernetes IN Docker) запускает узлы кластера как Docker-контейнеры. Быстрее Minikube, идеален для CI/CD и тестирования, поддерживает многонодовые кластеры.

Облачные управляемые сервисы

Для продакшена большинство команд выбирает управляемый Kubernetes — облачный провайдер берёт на себя Control Plane, обновления и резервирование etcd.

• GKE (Google Kubernetes Engine) — оригинальный управляемый K8s от Google. Лучшая интеграция с экосистемой Google Cloud, автопилот-режим для полностью управляемой инфраструктуры.
• EKS (Amazon Elastic Kubernetes Service) — Kubernetes на AWS. Глубокая интеграция с сервисами AWS: IAM, ALB, EBS. Самый популярный выбор среди enterprise-компаний.
• AKS (Azure Kubernetes Service) — K8s на Microsoft Azure. Хорошая интеграция с Azure Active Directory, бесплатный Control Plane.
• Yandex Managed Service for Kubernetes — российский вариант с серверами в РФ, интеграция с Yandex Cloud.

Помимо самого кластера, при работе с REST API сервисов внутри Kubernetes понадобится настроить Ingress-контроллер (nginx, Traefik) для маршрутизации внешних HTTP-запросов к нужным Service-ам.

Выводы

Kubernetes — это де-факто стандарт оркестрации контейнеров в 2024–2025 годах. По данным CNCF Annual Survey, более 84% компаний используют или оценивают K8s, а рынок контейнерной оркестрации продолжает расти двузначными темпами.

Kubernetes решает реальные проблемы масштаба: автоматическое самовосстановление, горизонтальное масштабирование, нулевой даунтайм при обновлениях, декларативное управление инфраструктурой. За это приходится платить сложностью — не стоит применять K8s там, где хватает Docker Compose.

Путь в Kubernetes начинается с понимания контейнеров, затем — знакомство с kubectl и Minikube, первые Deployment-ы и Service-ы, потом — изучение Ingress, ConfigMap, Secret, HorizontalPodAutoscaler. Это путь в несколько месяцев, но он открывает доступ к одной из самых востребованных технологий в DevOps.

Изучаете облачные технологии? Прочитайте наши статьи о микросервисной архитектуре и Docker — они помогут выстроить полную картину современной облачной разработки. Автоматизировать деплой в Kubernetes поможет CI/CD: пайплайн собирает образ, прогоняет тесты и автоматически деплоит в кластер.

Если хотите собрать Kubernetes не как отдельный страшный инструмент, а как часть цельного пути, посмотрите план обучения DevOps-инженера. Там видно, почему Kubernetes появляется после Docker, CI/CD и инфраструктуры, а не вместо них.

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

Ключевые выводы:
— fsGroup в Kubernetes рекурсивно меняет владельца всех файлов на PersistentVolume при каждом монтировании — это безопасный дефолт, который становится проблемой на больших томах.
— Параметр fsGroupChangePolicy: OnRootMismatch (доступен с K8s 1.20) проверяет только корневую директорию вместо обхода всех файлов.
— Одна строчка в манифесте сократила время рестарта Atlantis с 30 минут до 30 секунд — экономия ~600 инженерных часов в год.
— Безопасные дефолты Kubernetes рассчитаны на небольшие рабочие нагрузки. При масштабировании их стоит пересматривать.

Проблема — 30 минут на рестарт

Atlantis — это инструмент для автоматизации Terraform через pull/merge request'ы. В Cloudflare он управляет десятками проектов и работает как singleton StatefulSet в Kubernetes. Для хранения состояния репозиториев Atlantis использует PersistentVolume (PV).

Перезапуски нужны регулярно: ротация секретов, onboarding новых проектов, обновления конфигурации. С учётом примерно 100 рестартов в месяц каждый 30-минутный простой складывался в 50+ часов заблокированного инженерного времени ежемесячно. Плюс каждый рестарт триггерил алерт и будил дежурного.

Ситуация обострилась, когда на PV закончились inode'ы. Inode — это запись о файле или директории в файловой системе, и их количество фиксируется при создании ФС. Единственный способ получить больше inode'ов в их конфигурации — увеличить размер тома, а для этого нужен рестарт пода.

Расследование

Первые зацепки

После kubectl rollout restart statefulset atlantis новый под появлялся практически мгновенно, но зависал на стадии инициализации:

События пода выглядели нормально — Kubernetes успешно распределил под на ноду, скачал образ init-контейнера за доли секунды. Но между назначением на ноду и началом скачивания образа был необъяснимый промежуток в 30 минут.

Копаем глубже — логи kubelet

Событий Kubernetes было недостаточно. Инженеры обратились к логам kubelet — компонента, который на каждой ноде координирует создание подов, монтирование томов и другие операции. Поскольку kubelet работает как systemd-сервис, его логи доступны через централизованную систему (в данном случае Kibana).

В логах kubelet было видно, что PersistentVolume монтируется сразу после назначения пода. Секреты тоже монтируются без проблем. Но затем — снова провал, и в логах появляется ошибка:

Kubelet считал, что под готов к запуску, но что-то блокировало монтирование тома и вызывало таймаут.

Разгадка — fsGroup

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

Вот в чём было дело. В spec.securityContext пода было указано fsGroup: 1. Это нужно, чтобы процессы Atlantis (запущенные не от root) имели доступ к файлам на томе. Но способ, которым Kubernetes это обеспечивает, оказался проблемой: при каждом монтировании kubelet выполняет рекурсивный chgrp по всем файлам и директориям на PersistentVolume.

А файлов к тому моменту были миллионы — команда недавно столкнулась с нехваткой inode'ов, что прямо указывало на огромное количество файлов. Рекурсивный обход миллионов записей на каждом рестарте — вот что съедало 30 минут.

Решение — одна строчка

Начиная с версии 1.20, Kubernetes поддерживает поле fsGroupChangePolicy в pod.spec.securityContext. По умолчанию оно установлено в Always — рекурсивный обход при каждом монтировании. Альтернативное значение OnRootMismatch проверяет только корневую директорию тома: если у неё уже правильная группа, рекурсивный обход не запускается.

Фикс целиком:

Важно: устанавливать OnRootMismatch стоит только если вы уверены, что ничто не меняет группу файлов на PersistentVolume извне. В случае Cloudflare инженеры проверили, что никакие процессы не модифицируют права на файлы в томе, и только после этого применили настройку.

Почему это работает

Параметр fsGroup в Kubernetes решает конкретную задачу: контейнеры, запущенные от непривилегированного пользователя, должны иметь доступ к файлам на примонтированном томе. Kubernetes обеспечивает это, выполняя chgrp -R по всему содержимому PV при каждом монтировании.

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

Политика OnRootMismatch меняет логику: kubelet проверяет только корневую директорию тома. Если её группа совпадает с fsGroup, рекурсивный обход пропускается. Поскольку Atlantis сам создаёт файлы с правильной группой (она наследуется от корневой директории), проверять миллионы файлов при каждом рестарте нет необходимости.

Результат

• Время рестарта: 30 минут → 30 секунд (ускорение в 60 раз)
• Экономия: ~50 часов заблокированного инженерного времени в месяц
• В годовом исчислении: ~600 часов продуктивной работы, возвращённых команде
• Ложные алерты: дежурный инженер больше не получает пейджер на каждый рестарт
• Время на фикс: одна строчка в YAML-манифесте

Как отметили в Cloudflare: диагностика заняла больше времени, чем само исправление.

Уроки для разработчиков

1. Проверяйте дефолты при масштабировании. Безопасные настройки по умолчанию в Kubernetes рассчитаны на простые рабочие нагрузки. Когда данные растут, дефолты могут незаметно стать бутылочным горлышком.
2. Ищите не только в событиях Kubernetes. Pod events показывают не всё. Логи kubelet, метрики нод, журналы CSI-драйверов — полезные источники информации при отладке проблем с монтированием.
3. Считайте стоимость «мелких» проблем. 30 минут простоя кажутся терпимыми. 30 минут x 100 раз в месяц = 50 часов. Масштаб меняет приоритеты.
4. Аудит securityContext. Поля fsGroup, runAsUser, runAsGroup и fsGroupChangePolicy напрямую влияют на время старта подов с PersistentVolume. Если у вас большие тома — проверьте эти настройки.
5. Не всякий фикс должен быть сложным. Самые ценные исправления часто оказываются самыми простыми — но требуют глубокого понимания того, как система работает под капотом.

Частые вопросы

Что делает fsGroupChangePolicy в Kubernetes?

Параметр fsGroupChangePolicy определяет, когда Kubernetes рекурсивно обновляет группу-владельца файлов на PersistentVolume. Значение Always (по умолчанию) запускает рекурсивный chgrp при каждом монтировании. Значение OnRootMismatch выполняет обновление только если группа корневой директории не совпадает с fsGroup. Поддерживается с Kubernetes 1.20.

Безопасно ли использовать OnRootMismatch?

Если файлы на PersistentVolume создаются только процессами внутри пода (и наследуют правильную группу от корневой директории), OnRootMismatch безопасен. Но если внешние процессы или другие поды могут менять группу файлов на томе, лучше оставить значение Always и искать другие способы оптимизации.

Как узнать, влияет ли fsGroup на время старта моих подов?

Проверьте логи kubelet на ноде, где запускается под. Если в них есть сообщение "Setting volume ownership... If the volume has a lot of files then setting volume ownership could be slow", значит рекурсивный обход выполняется. Также можно сравнить время между событиями Scheduled и Started для пода — большой разрыв при наличии PV с fsGroup указывает на эту проблему.

Выводы

История Cloudflare — отличный пример того, как безопасный дефолт может превратиться в серьёзную проблему на масштабе. fsGroupChangePolicy: Always — разумная настройка для небольших томов, но на миллионах файлов она съедает минуты при каждом рестарте.

Главный урок: если что-то в вашем кластере работает медленнее, чем должно — не расширяйте окно алертов, а копайте глубже. Иногда ответ — это одна строчка YAML.

По материалам блога Cloudflare.

Selectel Tech Day — ежегодная конференция, где показывают реальную работу облачной инфраструктуры. В 2025 году мероприятие прошлом уже в девятый раз и собрало порядка 6000 участников онлайн и офлайн. Три параллельных стрима: реальный опыт тех, кто работает с нагрузкой 24/7, вся правда о работе с ML-моделями в разработке и трек c техническим бэкстэйджем: от Kubernetes и сетей до грамотно настроенного мониторинга, DevSecOps и систем безопасности.. А также 16 стендов, где можно было руками потрогать серверы и посоревноваться в их сборке. Рекорд — 29 секунд.

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

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

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

Параметры проекта

• Подготовка: старт реализации — за полгода до ивента
• Участники: 6000 онлайн и офлайн зрителей
• Программа: 32 спикера, 16 докладов и дискуссий
• Активности: 16 интерактивных стендов, 50+ активностей для гостей в разных зонах
• Статус: ежегодное флагманское мероприятие Selectel

Архитектура: три стрима под разные задачи

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

Первый стрим — про реальный опыт. Сюда попали истории миграций, построения гибридной инфраструктуры и работа с нагрузкой 24/7.

Второй стрим — ML- и AI-инфраструктура. Только прикладные задачи: как выбрать инфраструктуру для обучения моделей, что нужно для деплоя в продакшен, где реально помогает GPU.

Третий стрим — технический бэкстейдж. Kubernetes, сети, мониторинг, DevSecOps. Всё, что нужно для построения надежной инфраструктуры и ее защиты.

Пять вещей, которые зашли лучше всего

Стенды с реальным железом и софтом

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

Чемпионат по сборке сервера

Соревнование на скорость сборки серверных компонентов стало одной из самых популярных активностей. Участники на время собирали сервер из комплектующих. Победитель справился за 29 секунд — это очень быстро даже для опытных инженеров.

ML без лишних слов

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

Всё сделано своими силами

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

Нетворкинг и живые дискуссии

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

Главная сложность: самостоятельная проработка креативной концепции и создание большого количества визуального контента

🔴 Проблема: команда Selectel приняла решение прорабатывать стиль и концепцию мероприятия in-house, без привлечения внешних агентств

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

✅ Решение: ранний старт и быстрая адаптация

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

Результаты: 6000 участников и сильное комьюнити

Конференция подтвердила статус Selectel как эксперта в области построения IT-инфраструктуры. Анонсы новых продуктов и тематические доклады вызвали интерес у крупных клиентов и СМИ, мероприятие получило более 120 публикаций в медиа и широкий охват в отраслевых каналах и в обзорах IT-блогеров. Гости конференции участвовали в активностях на стендах, смогли лично пообщались с экспертами и спикерами, а также оставили много положительной обратной связи команде Selectel.

Планы на 2026

Selectel Tech Day уже стал традицией. Следующее мероприятие пройдет осенью 2026 года. Ключевые темы: облачные сервисы, инфраструктура для AI и безопасность. Команда провайдера уже начала работу над новой интересной программой. За анонсами можно следить на странице мероприятия.

Реклама. АО «Селектел», ИНН 781096278, erid: 2W5zFJSSYVw

Selectel развивает облачную платформу более 10 лет. Сейчас в команде провайдера более 1200 сотрудников, а мощности развернуты на базе 6 собственных дата-центров в Москве, Санкт-Петербурге и Ленинградской области.

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

За 2025 год в рамках развития облачной платформы команда Selectel запустила первый в России сетевой SSD с управляемой производительностью, управляемые кластеры OpenSearch, хранилище S3 Vault для резервного копирования с полным контролем доступа, облачные серверы с выделенными ядрами, линейку облачных серверов с сетью 10 Гбит/с и ряд других функциональных обновлений.

Задача: дать компаниям контроль над IT-инфраструктурой

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

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

Параметры

• Разработка: c 2015 года
• Команда: 1200+ человек
• ЦОДы: 6 собственных дата-центров
• Регионы: 3 региона, 6 зон доступности
• Реестр Минцифры: номер 9884

Архитектура

• Вычисления — виртуальные серверы фиксированных и произвольных конфигураций. Можно настроить количество CPU и RAM, диски от HDD до NVMe. Более 10 моделей GPU всегда в наличии.
• Хранилище — блочное, объектное, файловое. Всё автоматически реплицируется.
• Сеть — виртуальные сети со скоростью до 10 Гбит/с, балансировщики, BGP, MPLS, IPv4, IPv6, глобальный роутер, direct connect
• Kubernetes — готовые к работе кластеры в облаке, на Bare Metal, с GPU для AI/ML. Масштабируется, поддерживает Helm, Istio. Мониторинг через Prometheus и Grafana.
• Безопасность — облачный файрвол, группы безопасности, WAF, DDoS-защита, шифрование по ГОСТу, системы IAM, двухфакторка, логи всех действий.
• Автоматизация — API, SDK, Terraform, Ansible, CLI, CI/CD.
• Бэкапы — резервное копирование, снапшоты, быстрое восстановление.

Главные фишки

Доступны любые конфигурации

Можно взять стандартную конфигурацию из линеек Shared, Standard, HighFreq, GPU, 10G Net, Dedicated. Или выбрать произвольную конфигурацию и собрать нужный сервер под свою задачу.

Серверы с GPU

Более 10 моделей GPU всегда в наличии: от L4 24GB для запуска небольших моделей до H200 141GB под задачи скоростного инференса больших моделей и файнтюнинга. Под капотом: производительные процессоры с частотой до 4,05 Ггц и возможность подключить локальный диск.

Запуск меньше чем за минуту

Создание виртуальной машины через панель управления в пару кликов, по API или Terraform — она сразу будет готова к работе.

Платишь за то, что используешь

Запустили сервер — оплатили. Остановили работу — не платите. Добавили RAM — платите за новый объем. Убрали — экономите.

Масштабирование на лету

Когда нагрузка растет, можно быстро и легко добавить ресурсы через панель или API. Без перезагрузки.

Прерываемые машины экономят до 80%

Они живут меньше суток и стоят дешево. Подходят для обработки данных, тестов, рендеринга.

Заморозка сервера

Можно сохранить данные на диске, при этом остановив вычисления. И платить только за хранилище.

Что запустили в 2025 году

1. Первый в России сетевой SSD с управляемой производительностью

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

2. Готовый кластер OpenSearch

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

3. Защита от любых DDoS

Базовая защита включена всегда. Продвинутая фильтрует атаки на уровне приложений. Система смотрит на трафик в реальном времени и режет подозрительное.

4. S3 Vault для бэкапов бакетов

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

5. Приватный DNS

Отказоустойчивый изолированный DNS-сервер и резолвер в приватных сетях с откликом до 1 мс и способностью выдерживать нагрузку более 5000 запросов в секунду.

6. Апгрейд производительности облака

• Виртуальные машины с выделенными ядрами

Изоляция нагрузки исключает любые задержки, гарантирует стабильную производительность без Steal Time. Настройка размещения ресурсов виртуальной машины на одной NUMA-ноде позволяет сократить задержки при работе с памятью на 20–50%. А управление технологией Hyper-Threading поможет адаптировать процессор под профиль нагрузки приложения или сервиса.

• ВМ размером с хост

Взять сервер размером с хост целиком. На такой ВМ размещается только один клиент, все ресурсы сервера выделены только под его нагрузки.

• Новая линейка с сетью 10 Гбит/с

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

• Увеличенные лимиты для произвольных конфигураций:

• стандартная линейка — до 232 vCPU, 900 Гб RAM и локальный диск до 2ТБ;
• высокопроизводительные облачные серверы с частотой процессора до 3,6 ГГц — до 176 vCPU, 900 Гб RAM и локальный диск до 2ТБ.

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

Главный вызов: работать круглосуточно без сбоев и падений

🔴 Проблема

Совместить производительность выделенной инфраструктуры с гибкостью и масштабируемостью облака.

✅ Решение

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

Результаты

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

Selectel входит в топ компаний на рынке IaaS (по данным iKS-Consulting) и регулярно занимает лидерские позиции в отраслевых рейтингах и обзорах CNews, Компьютерра,TAdviser и др.

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

Планы до 2031

Selectel планирует инвестировать 10 млрд рублей в продукты для AI до 2031 года. Инвестиции пойдут на создание высокопроизводительной инфраструктуры и специализированных решений для клиентов, которые фокусируются на создании и выводе на рынок продуктов на базе искусственного интеллекта.

Реклама. АО «Селектел», ИНН 781096278, erid: 2W5zFGAQwgD

Главное о формате

Конференция пройдет 9 апреля в Москве на площадке кинотеатра «КАРО 11 Октябрь» в гибридном формате: часть сессий будет транслироваться онлайн, а практические воркшопы и ряд сессий будут доступны офлайн-посетителям. Всего ожидается около 15 live-демозон с сервисами Cloud.ru и партнеров.

Регистрация на мероприятие открыта на сайте конференции.

Ключевые треки конференции

Программа конференции в 2026 году объединит четыре тематических трека:

• AI. Участников ждут сессии о том, как сделать AI удобным инструментом для команд: работать с AI-агентами, AI-workflow и генеративными моделями через простые интерфейсы. Эксперты расскажут про обновление цифровой среды AI Factory для работы с GenAI.
• App & Dev. Трек посвящен инструментам, которые ускоряют запуск продуктов и упрощают весь цикл разработки: от архитектуры и написания кода до тестирования, эксплуатации и поддержки в продакшене.
  
• Data & Analytics. Этот трек объединит доклады и дискуссии экспертов рынка о том, как сделать управление данными экономически эффективным и какие ключевые data-тренды будут определять 2026 год.
  
• Core Infra. На сессиях эксперты и клиенты Cloud.ru обсудят импортонезависимые AI- и облачные решения enterprise-уровня и объяснят, как добиться стабильности и безопасности высоконагруженных систем.
  

Для кого это мероприятие

Конференция рассчитана на CEO, СTO, DevOps-, AI/ML- и дата-инженеров, а также SRE-специалистов, архитекторов и разработчиков.

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

1. Beget — облако для стартапов: быстро запуститься и не сжечь бюджет

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

Инфраструктура размещена в дата-центрах Москвы и Санкт-Петербурга, что обеспечивает низкие задержки и соответствие требованиям российского законодательства. Также есть Tier lll дата центры в Казахстане и Латвии — для стартапов с прицелом на WW — это может быть полезно.

Веб-платформа "БЕГЕТ" включена в Единый реестр российских программ для электронных вычислительных машин и баз данных. Запись в реестре №16697 от 20.02.2023.

Сервисы и возможности

Платформа закрывает базовые инфраструктурные потребности для запуска и развития MVP или SaaS-продукта:

• VPS/VDS на быстрых NVMe-накопителях.
• Объектное хранилище S3 — для статики, медиа и бэкапов.
• Управляемые базы данных (DBaaS) — чтобы не тратить время на настройку и репликацию СУБД вручную.
• CDN — для быстрой доставки контента.
• Выделенные серверы — для тех, кому нужно изолированное «железо» под Highload.

В первом квартале 2026 года ждут запуск Managed Kubernetes, чтобы переехать с самописных Docker-конфигов на оркестрацию.

Экономика и гранты для стартапов

Для новых проектов у Beget работает одна из самых масштабных программ грантов на рынке. Вместо скидок в 10% они дают реальный бюджет на тесты и рост:

• Сумма гранта: до 1,5 млн рублей.
• Срок: до года с возможностью продления.
• Цель: покрыть расходы на инфраструктуру на этапе, когда проект ещё не монетизируется.

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

Тарифы и экономика

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

• Минимальная конфигурация: 1 vCPU, 1 ГБ RAM, 10 ГБ NVMe — 210 ₽/месяц.
• Ориентировочная цена на типовой стек для MVP (веб-сервер + БД + хранилище): в среднем 3 000–5 000 ₽/месяц, зависит от нагрузки и объёма данных.

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

Технологическая панель и поддержка

Одна из сильных сторон Beget — собственная панель управления, она сделана максимально минималистично: создание инстанса занимает минимум времени.

Техподдержка работает быстро, нет бесконечных уровней эскалации:

• Telegram и тикеты: ответ в течение 15 минут.
• Телефон: соединение за 10 секунд.
• Живое сообщество: в Telegram-чате сидят как пользователи, так и сотрудники, часто ответ прилетает за 5 минут.

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

2. Selectel: раздают до 1 000 000 бонусов кешбэком

Selectel — популярный российский провайдер с собственными дата-центрами, который работает на рынке с 2008 года. Компания предлагает полный стек инфраструктурных решений — от виртуальных машин до managed Kubernetes и защиты от DDoS.

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

Продукты и сервисы

Платформа закрывает базовые инфраструктурные задачи для разработки и масштабирования продуктов:​

• Облачные серверы — виртуальные машины с моментальным масштабированием, оплата по потреблению, готовы к запуску за минуту, соответствие 152-ФЗ.​
• Выделенные серверы — физическое железо с изолированными ресурсами, готовые конфигурации запускаются за час, произвольные — за 1–5 дней.​
• Серверы с GPU — облачные и физические серверы с графическими картами для 3D-моделирования, рендеринга, машинного обучения и аналитики.​
• Облачные базы данных (DBaaS) — готовые масштабируемые кластеры PostgreSQL, MySQL, Redis, TimescaleDB, Managed Kafka, OpenSearch с автоматическим резервным копированием.​
• Managed Kubernetes — упрощает развёртывание и масштабирование контейнерной инфраструктуры, помогает построить микросервисную архитектуру и процесс CI/CD.​
• S3-хранилище — для данных, бэкапов, датасетов для ML, моментальное масштабирование, данные хранятся в трёх копиях.​
• CDN — ускоряет загрузку статического контента, снижает нагрузку на серверы.​
• Глобальный роутер — связывает физическую и облачную инфраструктуру в приватную сеть, объединяет серверы из разных регионов внутри Selectel. Бесплатно.​
• Защита от DDoS — фильтрует атаки на уровне L3/L4 и приложений L7.​
• Резервное копирование — настраивается по расписанию, поддерживает диски любого объёма, оплата только за использованное место.​

Всего доступно 50+ продуктов и сервисов.

Программа кешбэка для стартапов

Механика отличается от классических грантов. Здесь не выдают фиксированную сумму авансом, а возвращают процент от реальных расходов:​

• Кешбэк: 30% от суммы, потраченной в предыдущем месяце.
• Максимум: 1 000 000 бонусов за 12 месяцев участия в программе.​
• Конвертация: 1 бонус = 1 ₽.​

Пример: потратили 50 000 ₽ на инфраструктуру в январе — в феврале начислят 15 000 бонусов. Их можно использовать для оплаты любых продуктов Selectel.

Условия участия:​

• Новый клиент — программа доступна тем, кто ещё не пользовался продуктами Selectel.
• Юрлицо или ИП — не зависит от формы собственности или места нахождения.
• Стартап — компания занимается разработкой ПО, цифровых проектов или инновационной деятельностью и обладает исключительными правами на продукт.

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

Тарифы и экономика

Модель pay-as-you-go — платите только за используемые ресурсы. Цены указаны в месяц:​

• Облачные серверы: от 292 ₽.
• Выделенные серверы: от 800 ₽.
• Серверы с GPU: от 21 568 ₽.
• Облачные БД: от 3 814,53 ₽.
• Managed Kubernetes: от 5 958,23 ₽.
• S3-хранилище: от 0,81 ₽.
• CDN: от 500 ₽.
• Резервное копирование: от 4,1 ₽.

Дополнительная экономия до 75% доступна при использовании прерываемых виртуальных машин и заморозки серверов. Работа с юрлицами стандартная: договор, закрывающие документы, оплата по счёту.​

Инфраструктура и автоматизация

Управление инфраструктурой доступно через панель управления, API, CLI и Terraform. Для гибридной инфраструктуры есть приватные сети — можно объединить серверы из разных регионов и пулов внутри экосистемы Selectel. Глобальный роутер связывает физические и облачные ресурсы без дополнительной платы.​

Документация, API-справочники и материалы для разработчиков доступны в разделе Документация на сайте.

3. Timeweb Cloud — стартапам грант 1 000 000 ₽ и помощь с миграцией

Timeweb Cloud — российская облачная платформа, которую используют для запуска и роста цифровых продуктов, когда хочется держать всю инфраструктуру в одном месте. Стартапам здесь дают грант до 1 000 000 ₽ на облачную инфраструктуру и помогают перенести текущие сервисы в облако, чтобы не тратить время команды на тяжелый переезд вручную.

Платформа закрывает типичные задачи MVP и растущих проектов: размещение приложений, работу с данными, хранение файлов и базовую сетевую безопасность.​

Сервисы и возможности

Платформа собирает базовые строительные блоки инфраструктуры стартапа в одном облаке:​

• Облачные серверы для backend’ов, API и фоновых воркеров, конфигурацию CPU, RAM и диска можно наращивать по мере роста нагрузки.​
• Выделенные серверы и GPU‑конфигурации для задач с тяжёлыми вычислениями — от видеообработки до ML и аналитики.​
• Облачные базы данных в формате DBaaS: PostgreSQL, MySQL, MongoDB, Redis, ClickHouse, OpenSearch, Kafka, RabbitMQ — платформа берёт на себя обновления, репликацию и бэкапы.​
• Объектное хранилище S3 для статики, бэкапов, логов и датасетов, с вариантами тарифов и нетарифицируемыми первыми 100 ГБ исходящего трафика.​
• Kubernetes как управляемый кластер для микросервисов: можно выдерживать скачки трафика и обновлять сервисы без простоя, не углубляясь в тонкости администрирования control plane.​
• Сетевые сервисы: VPC для изоляции внутренних сервисов, firewall‑правила, плавающие IP‑адреса, DNS и балансировщики нагрузки, плюс защита от DDoS‑атак в дата‑центрах Санкт‑Петербурга и Москвы.​

С таким набором можно собрать типичную архитектуру стартапа — веб‑приложение, API, очереди, БД, хранилище и сетевой контур — внутри одной экосистемы.​

Экономика и грант для стартапов

Стартап может получить грант до 1 000 000 ₽ на облачные ресурсы и использовать его для серверов, баз данных, хранилищ и сопутствующих сервисов. В описании программы прямо указывают, что команда помогает перенести инфраструктуру в облако и закрыть вопросы по переезду, а грант идёт на оплату ресурсов в рамках этой схемы.​

Оплата основных сервисов строится по модели pay‑as‑you‑go: учитываются фактически задействованные ресурсы, что удобно на этапе, когда нагрузка ещё нестабильная.

Тарифы и конфигурации

Для ориентира можно взять линейку облачных серверов Premium 3.3 ГГц Dedicated CPU в московском сегменте. Конфигурация Cloud MSK 15 включает 1 vCPU 3.3 ГГц, 1 ГБ RAM, 15 ГБ NVMe, канал 1 Гбит/с и публичный IP, стоит от 477 ₽ в месяц при оплате на 12 месяцев со скидкой. Старшая конфигурация Cloud MSK 30 даёт 1 vCPU 3.3 ГГц, 2 ГБ RAM и 30 ГБ NVMe с тем же каналом и публичным IP за 657 ₽ в месяц при годовой оплате.​

Панель управления, поддержка и обучение

Управление инфраструктурой идёт через единую веб‑панель Timeweb Cloud: из одного интерфейса вы создаёте серверы, кластеры БД, Kubernetes, настраиваете сеть и хранилища.

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

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

4. VK Cloud — грант 2 000 000 ₽ на облако со скидкой до 100%

VK Cloud — российская облачная платформа от VK, которая работает на базе собственной инфраструктуры и закрывает типичные задачи команд на этапе MVP и роста продукта.

Стартапам здесь дают грант до 2 млн рублей на использование облачных сервисов в течение 6 месяцев. Условия гибкие: вы сами выбираете, когда взять скидку 50% на IaaS и PaaS, а когда — 100%, распределяя эти месяцы под график запуска и требования проекта. Программа рассчитана на проекты любой стадии — от MVP до продуктов с активной базой пользователей.

Сервисы и возможности

Платформа собирает инфраструктурные компоненты для типичной архитектуры стартапа:​

• Cloud Servers — виртуальные серверы для размещения приложений, API и фоновых задач.
• Object Storage — объектное хранилище для статики, медиафайлов, бэкапов и логов.
• Managed Kubernetes — управляемые кластеры для контейнеризованных приложений с автоматическим масштабированием.
• Cloud Databases — управляемые базы данных: MySQL, PostgreSQL, MongoDB, Redis, ClickHouse, Tarantool. Платформа берёт на себя обновления, репликацию и резервное копирование.​
• Cloud ML Platform, Cloud Spark, Cloud Kafka, Cloud Flink — сервисы для работы с ML-моделями, обработкой больших данных и потоковой аналитикой.​
• Vision и Voice — API для распознавания изображений и голосовых команд.​
• Cloud Backup — резервное копирование данных.​

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

Экономика и грант для стартапов

Программа поддержки работает 6 месяцев и даёт стартапу возможность распределить скидки на инфраструктуру под свой график:​

• Максимальный размер скидки и компенсации: до 2 млн рублей (НДС включён).​
• Механика: 4 месяца работаете со скидкой 50% на IaaS и PaaS, 2 месяца — со скидкой 100%. Вы сами выбираете, в какие периоды использовать тот или иной формат, исходя из требований продукта и графика запуска.​
• Условия участия: есть MVP с понятной концепцией или готовый продукт с пользователями, понимание архитектуры приложения и объёма ресурсов в облаке, аккаунт на VK Cloud зарегистрирован на юрлицо или ИП в 2026 году, вы не являетесь платящим клиентом VK Cloud.​

Заявку рассматривают в течение 5 рабочих дней с даты получения.

Дополнительные сервисы экосистемы VK

Помимо облака, участники программы могут протестировать другие сервисы VK с особыми условиями:​

VK WorkSpace — корпоративная платформа для командной работы:​

• Скидка 50% на тариф «Базовый».
• Включает: 150 ГБ на диске для каждого пользователя, доступ через API, видеоконференции до 100 участников, редактирование документов с настройкой прав, все сервисы в едином Супераппе, доску для командной работы.​
• Почта на вашем домене, защищённый мессенджер с задачами и видеозвонками, облако до 1,5 ТБ для обмена файлами и редактирования онлайн, доступ с любого устройства.​

VK Реклама — единая платформа для запуска рекламных кампаний на проектах VK и в рекламной сети:​

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

Панель управления, поддержка и обучение

Через единую панель VK Cloud вы запускаете серверы, кластеры БД, Kubernetes, настраиваете хранилища и сетевые компоненты.

На период участия в программе доступны:​

• Консультация архитектора о том, как применять облачные сервисы для разработки и размещения проекта в облаке.
• Бесплатная техподдержка: ответы на вопросы, консультации и помощь.

Платформа ведёт документацию, клиентский портал и ИИ-консультанта для быстрого поиска ответов на технические вопросы. Дополнительно у VK Cloud есть мероприятия, кейсы и блог с разборами архитектурных решений.

5. Yandex Cloud — до 1 000 000 ₽ для стартапов за 7 дней

Yandex Cloud — российская облачная платформа от Яндекса, которая работает на собственной инфраструктуре и закрывает типичные задачи команд на этапе от MVP до роста продукта.

Для стартапов здесь запустили программу Yandex Cloud Boost с двумя уровнями участия: Start для начинающих команд даёт 50 000 ₽ на 6 месяцев, Migrate для тех, кто хочет снизить затраты и масштабировать продукт, — до 1 000 000 ₽ на 2 месяца плюс консультации архитекторов и приоритетную поддержк.

Дополнительно есть специальная программа для использования генеративных языковых моделей: грант до 1 000 000 ₽ на тестирование сервисов YandexGPT API и YandexART.

Сервисы и возможности

Платформа собирает базовые инфраструктурные блоки для типичной архитектуры стартапа. Грант Start покрывает сервисы на 6 месяцев, Migrate — на 2 месяца с расширенной поддержкой. Точный список сервисов, на которые распространяется грант, указан в полных условиях программы Cloud Boost.​

Yandex Cloud включает:

• Вычислительные ресурсы для размещения приложений, API и фоновых задач.
• Объектное хранилище для статики, медиафайлов, бэкапов и логов.
• Управляемые базы данных с автоматическим обновлением, репликацией и резервным копированием.
• Сетевые сервисы и инструменты для построения отказоустойчивой инфраструктуры.
• Marketplace с готовыми решениями, которые можно развернуть за несколько кликов.

Экономика и гранты для стартапов

Программа Yandex Cloud Boost разделена на два уровня:​

Программа Start — для начинающих команд и стартапов, которым нужны ресурсы для запуска IT-проекта:​

• Сумма гранта: 50 000 ₽ (включая НДС).​
• Срок: 6 месяцев.​
• Условия: вы создаёте digital-продукт (онлайн-сервис, платформу, агрегатор, игру), проект на стадии MVP и выше (достаточно иметь сайт, приложение или демо), готовы приступить к тестированию сразу после начисления гранта.​

Программа Migrate — для команд, желающих снизить расходы на IT-инфраструктуру и легко масштабировать продукт:​

• Сумма гранта: до 1 000 000 ₽ (включая НДС).​
• Срок: 2 месяца.​
• Дополнительно: консультации архитекторов, приоритетная поддержка уровня «Бизнес».​
• Условия: проект на стадии MVP и выше, но ожидается, что у вас уже есть продажи.​

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

Панель управления, поддержка и обучение

Управление инфраструктурой идёт через консоль Yandex Cloud: из одного интерфейса вы запускаете серверы, базы данных, настраиваете хранилища и сетевые компоненты.

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

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

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

DevOps-инженеры, архитекторы, CTO каждый день принимают решения, от которых зависит скорость запуска новых фич и стабильность сервисов. И облака — одни из их главных инструментов. Суверенные облака, serverless, автоматизация через AI и борьба за миллисекунды отклика — все это уже не хайп, а требования по дефолту.

Вместе с H3LLO CLOUD мы провели исследование рынка облаков и опросили более 1000 специалистов, которые каждый день отвечают за то, чтобы цифровые продукты работали стабильно и не падали под высокой нагрузкой. Узнали у них, чего не хватает разработчикам и бизнесу в инфраструктуре, почему текущее облако — боль, и чего в целом они хотят от облачной платформы.

Главные тренды: из чего состоят облака в 2025

Глобальный рынок облачных технологий достиг $545,8 млрд в 2023 году и, по прогнозам, вырастет до $1,24 трлн к 2027 году с годовым темпом роста 17,9%. Лидеры на мировом рынке — Amazon Web Services (доля рынка — 32%), Microsoft Azure (20%) и Google Cloud (<10%). Российский же рынок облаков в 2024 году вырос на 36,3% и достиг 165,6 млрд ₽.

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

Контейнеры и оркестраторы

C такими инструментами, как Docker и Kubernetes, у разработчиков появилась возможность упаковывать приложения вместе со всеми зависимостями в независимые и воспроизводимые образы. Контейнеры дали облаку гибкость: теперь один и тот же сервис может работать в любой среде — в частном дата-центре, на виртуальной машине или в публичном облаке. Но сами по себе контейнеры — это просто база. Их нужно масштабировать, восстанавливать при сбоях, обновлять без простоев — и здесь не обойтись без Kubernetes.

Серверлесс — когда код важнее инфраструктуры

Следующий шаг в эволюции — серверлесс-архитектура, или FaaS (Function-as-a-Service). Она изменила саму философию разработки. Разработчику больше не нужно задумываться о серверах, ресурсах, масштабировании. Он просто пишет функцию, загружает её в облако (например, AWS Lambda или Google Cloud Functions), и она выполняется по триггеру. Все остальное — забота облачного провайдера. Сейчас серверлесс — стандарт в большинстве кейсов: от микросервисов до IoT-решений и бэкендов мобильных приложений.

AI внутри облака

Одна из самых больших инноваций — искусственный интеллект и машинное обучение внутри облаков. Раньше ИИ в облаках использовали в основном клиенты (например, для распознавания изображений или прогнозирования спроса). Теперь же сами облака стали умными. Сейчас ИИ используется для предсказания нагрузки на серверы, автоматического масштабирования, распределения трафика, выявления уязвимостей и даже для самообслуживания: системы могут восстанавливаться после сбоев без вмешательства человека. Появился даже отдельный класс решений — AI Ops, которые анализируют логи, метрики и события, помогая администраторам не утонуть в огромном объеме данных.

Безопасность и Zero Trust

Сейчас простая изоляция не работает, учитывая удаленку, подключение IoT-устройств и множество API-интерфейсов. Поэтому модель безопасности сместилась к Zero Trust: по умолчанию не доверять ни одному пользователю или устройству, даже если они уже внутри сети. Все действия проверяются, каждый доступ логируется, а соединение — шифруется. Большинство крупных облачных провайдеров в 2025 году реализуют Zero Trust на уровне инфраструктуры, предлагая клиентам встроенные средства шифрования, менеджеры секретов, токенизации данных и поведенческую аналитику на базе ИИ.

IaC

Если раньше развертывание инфраструктуры было ручным и трудоемким, то теперь всё делается через Infrastructure as Code (IaC). Разработчики описывают конфигурации в коде (с помощью Terraform, Pulumi или AWS CloudFormation), хранят их в Git, запускают CI/CD-пайплайны и управляют инфраструктурой так же, как приложениями.

Мультиоблако и гибрид

Большинство компаний в 2025 году используют мультиоблачные или гибридные стратегии. Они разворачивают сервисы одновременно на AWS, Azure и Google Cloud, а в России — на Yandex.Cloud или Cloud.ru, чтобы минимизировать риски. Сейчас 89% компаний используют мультиоблачный подход, комбинируя несколько публичных или частных облаков, чтобы избежать зависимости от одного провайдера. В России в 2022 году, согласно исследованию VK, 80% компаний выбирали именно гибридные облака — сейчас эта тенденция сохраняется, поскольку компании стремятся к максимальной безопасности.

Хранилища: от архивов до потоков

Облачные хранилища стали намного умнее. Теперь есть «горячие»,«теплые» и «холодные» данные. Например, облака могут автоматически переводить неиспользуемые данные в архив (cold storage), а при необходимости моментально восстанавливать их. А разработка object storage (например, Amazon S3), блочных хранилищ (EBS, Persistent Disks) и сетевых файловых систем сделала возможным хранение пета- и эксабайтов данных. Еще популярным становится real-time data streaming — хранилища интегрируются с Apache Kafka и другими системами, чтобы поддерживать потоковую аналитику и событийные системы.

Как айтишники (и не только) пользуются облаками

Мы провели опрос в телеграм-каналах Tproger и Библиотеки программиста среди тысяч подписчиков. Среди вопросов были:

• Для чего вы используете облако?
• Чего сейчас не хватает в облачном сервисе?
• Что бесит в облаках больше всего?
• По каким критериям вы выбираете провайдера?
• Какие облачные сервисы вы используете?
• Сколько вы платите за облако в месяц?
• Какой минимальный uptime вам нужен?
• Что нужно, чтобы вы перешли на новое облако?

Большинство читателей используют облака в личных целях: почти треть — только для себя, а ещё около 28% — в основном для личных задач, но иногда и для работы. Примерно четверть пользователей совмещают облака и для личных дел, и для бизнеса — в равной степени. И только небольшая часть применяет их в первую очередь или исключительно для бизнеса.

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

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

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

Самое популярное облако среди подписчиков — Yandex Cloud. Почетное второе место занимает Timeweb Cloud, а третье место разделили Cloud.ru и Selectel.

Половина пользователей платят за облако менее 1000 рублей, а 16,7% — от 5 000 до 15 000 рублей. Это зависит от того, для каких целей читатели используют облака.

А вот с аптаймом произошла интересная ситуация. Да, большинство ждет от сервиса максимальный аптайм — 99,99%, но при этом 20% подписчиков этот критерий не важен.

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

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

Что происходит на российском рынке облаков: проблемы и решения

Непрозрачный биллинг

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

Переподписка и низкая производительность при высокой стоимости

Переподписка (overcommitment) в облачных сервисах подразумевает, что провайдер выделяет больше виртуальных ресурсов, чем есть физически на сервере, рассчитывая, что не все клиенты используют их одновременно. Например, на сервере с 48 физическими ядрами и Hyper-Threading (96 логических процессоров) можно разместить до 96 vCPU без переподписки. Если провайдер выделяет больше (например, 120 vCPU), начинается переподписка, и производительность может снизиться при пиковых нагрузках.

Согласно небольшому исследованию публичных облаков, которое провели H3LLO CLOUD, некоторые российские провайдеры могут вас переподписывать.

В исследовании — две группы синтетических тестов Geekbench 6: Single Core и Multi-core, у каждого провайдера брали по три виртуальные машины, технические характеристики — 2 vCPU и 4 ГБ оперативной памяти (исключение — Рег.ру: 2 vCPU и 2 ГБ RAM).

Вот результаты:

• Single Core. Лидеры — Yandex Cloud, Cloud.ru и Selectel — показали стабильные и высокие результаты без признаков сильной переподписки. Более низкая производительность у VK (на 15-20%), Reg-ru и Timeweb.
• Multi-core. Selectel сохранил производительность, у Яндекса она осталась на уровне Single Core, у Cloud.ru хорошие показатели, но со странными просадками.

Также H3LLO CLOUD протестировали облака на скорость PostgreSQL. По результатам: Timeweb, несмотря на низкую производительность, предлагает конкурентоспособную цену за вычислительные ресурсы. У VK Cloud и Яндекса оказалась низкая производительность, при этом стоимость тоже довольно высокая. Плюс у Яндекса был зафиксирован ограничитель на максимальную производительность. H3LLO CLOUD установил свои тарифы, ориентируясь на медианное значение между Cloud.ru и Selectel.

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

Техническая поддержка крупных провайдеров часто может ограничиваться стандартными ответами, либо заставляет пользователей долго ждать (более 30 минут). Это критично для МСБ, где сбои нужно устранять немедленно. Более того, платформы, такие как SberCloud и Yandex.Cloud, могут требовать глубоких технических знаний для настройки.

Как выбрать облако в 2025 году

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

Кейс 1: выгодный переход с legacy-инфраструктуры

Для e-commerce стартапов, особенно в периоды пиковых нагрузок (например, распродаж), облачная платформа — это не просто тренд, а необходимость. Устаревшие серверы не выдерживают высокого трафика и могут привести к потерям и простоям. Миграция в облако, например, на H3LLO CLOUD, решает эту проблему за два дня с помощью Kubernetes. Инфраструктура автоматически масштабируется, задержка — меньше 10 мс, а расходы снижаются до 30% благодаря почасовой модели оплаты.

Кейс 2: Когда облако не принесёт выгоды

Да, облако действительно подходит не всем. Например, для небольшой юридической фирмы с 10 сотрудниками, которая работает с малым объемом данных (до 1 ТБ), миграция в облако будет неэффективной. Стоимость подписки, обучение сотрудников и миграционные расходы могут очень высокими. В таком случае локальная инфраструктура, которая гарантирует полный контроль над данными, будет более выгодной и безопасной.

Кейс 3: гибридный подход

Многие компании выбирают гибридную модель. Например, производственная фирма с собственной ERP-системой может оставить её на локальных серверах для критичных бизнес-приложений, а ресурсоемкие задачи — аналитику и машинное обучение — можно перенести в облако. Так можно сэкономить до 25% на вычислительных ресурсах с помощью мощных GPU-инстансы и при этом соблюдать требования российского законодательства (ФЗ-152).

Гайд по ключевым метрикам

При выборе облачного провайдера в 2025 году стоит ориентироваться на следующие метрики — они напрямую влияют на эффективность и стоимость:

• Стоимость. Все, что связано с облаком, — это не только подписка, но и совокупная стоимость владения: миграция, обучение команды, защита данных и резервное копирование. В отличие от собственного железа, где трудно заранее посчитать расходы на 3–5 лет, у H3LLO CLOUD есть прозрачная поминутная тарификация, и эти затраты проще прогнозировать и контролировать.
• Производительность. Оцените скорость обработки данных, и возможность масштабировать инфраструктуру с учетом пиковых нагрузок. Для тестирования стоит использовать пилотные проекты, а для больших проектов — проверить наличие Kubernetes и высокоскоростных сетей (например, 400G).
• Безопасность. Учитывайте соответствие ФЗ-152, защиту от DDoS, шифрование, IAM-системы (управление доступом). Выбирайте провайдеров с интегрированными решениями безопасности (например, VK Cloud использует SIEM и DevSecOps) и регулярными тестами на проникновение. H3LLO CLOUD, в свою очередь, предлагает базовую DDoS-защиту и шифрование без доплат, что снижает риски для МСБ.
• Задержки. Здесь важны расположение дата-центров и поддержка высокоскоростных сетей. Поэтому выбирайте провайдеров с дата-центрами в России (например, Москва, Санкт-Петербург) и проверяйте метрики latency в реальных тестах.
• Поддержка и uptime. Не менее 99,9% uptime — это стандарт, на который стоит ориентироваться. Также стоит обратить внимание на скорость реагирования технической поддержки и SLA. Так, Timeweb Cloud предлагает круглосуточную поддержку с ответом за 20 минут, но H3LLO CLOUD выделяется персонализированным подходом и быстрым откликом.
• Понятный интерфейс. Это особенно важно для небольших компаний, где нет большого IT-отдела. Удобный и простой интерфейс для управления ресурсами сделает вашу работу гораздо эффективнее и сэкономит время.
• Масштабируемость. Проверяйте, насколько быстро и легко можно увеличивать или сокращать ресурсы в зависимости от потребностей. Например, VK Cloud поддерживает автоматическое масштабирование, но H3LLO CLOUD показал лучшие результаты в тестах при высоких нагрузках.
• Географическое покрытие. Наличие дата-центров в России важно для соблюдения ФЗ-152 и обеспечения низкой задержки. Если у вас международный бизнес, ищите провайдеров с ЦОДами в других странах.

Опрос тысячи DevOps-инженеров, архитекторов и обычных пользователей показал: облака в 2025 году выбирают по трём критериям — цена, надежность и безопасность. Причём именно в таком порядке.

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

При выборе облака проверяйте не только стоимость подписки, но и совокупные расходы: миграция, обучение команды, безопасность и резервное копирование. Важны также задержки, соответствие ФЗ-152 и наличие дата-центров в России.

Метрики, KPI и дашборды – это основа деятельности любой компании, претендующей на отлаженность процессов. Особенно в разработке. Там все буквально помешаны на time-to-market и делают ради его достижения все, что только можно, лишь бы вывести продукт на рынок побыстрее. Разве что к бабке-шептунье не ходят. В связи с этим спрашивается: а почему, собственно, точно так же нельзя в облаке, где перерасходы – обычное дело и никто не стремится их устранять? Оказывается, можно.

Что такое Time-to-Optimize

Time-to-Optimize – это временной промежуток между выявлением перерасходов в облаке и их оптимизацией. Она необязательно должна быть полной. Частичная тоже подойдет: уменьшение счетов, высвобождение ресурсов под новые задачи или рост производительности при тех же расходах. Главное, чтобы эти результаты были реальными, а не сводились просто к планам.

Казалось бы, чего тут вообще считать?

Дело в том, что перерасход не фиксируется в тот момент, когда его обнаружили. Он не останавливается на месте, а продолжает нарастать как снежный ком. То есть чем выше ваш TTO, тем больше денег утекает в никуда.

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

Со своим железом еще сложнее. Там вообще надо учитывать амортизацию оборудования, зарплаты администраторов, затраты на электричество и обслуживание. И все это нужно как-то аккуратно разложить по проектам и командам.

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

Формула расчета Time-to-Optimize

Для расчета Time-to-Optimize есть специальная формула:

TTO = сбор данных + нормализация + аллокация + анализ + внедрение + фиксация результата

А вот что значат эти слагаемые:

• Сбор данных — получение сырых биллинговых отчетов от всех провайдеров.
• Нормализация — приведение данных к единому формату.
• Аллокация — распределение расходов по командам, проектам, cost-центрам (кто сколько потратил и на что).
• Анализ — принятие решений о том, что оптимизировать.
• Внедрение — реализация изменений: выключение VM, смена тарифов, резервирование ресурсов.
• Фиксация результата — подтверждение первых измеримых эффектов.

Опять-таки, на бумаге все выглядит просто. Складываем временные отрезки – получаем итоговое число. Вот только на практике возможны нюансы:

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

Другой важный фактор – это длительность каждого этапа, которая зависит от зрелости процессов. Если собирать данные вручную, это займет неделю. С API-интеграциями – считанные минуты. Согласования – наоборот: в стартапе они проходят за пару часов, а корпорации с двадцатью командами могут затянуться даже на неделю.

Поэтому полезно разделить TTO на уровни:

• Макро-TTO – показывает весь цикл от осознания проблемы до результата, помогает понять общую скорость реакции.
• Микро-TTO – фиксирует длительность отдельных этапов внутри цикла, показывая, как много времени вы тратите на каждый из них.

Так будет проще выявить проблемные места.

TTO как показатель зрелости

Time-to-Optimize – штука универсальная. Он показывает не только скорость оптимизации, но и общий уровень зрелости FinOps в компании. Про сами уровни мы уже рассказывали, а вот как они коррелируют со временем оптимизации:

• Crawl (начальный уровень) – когда все делается руками, а на проблемы реагируем постфактум. TTO измеряется 3-6 неделями.
• Walk (средний уровень) – когда уже есть некая системность, частичная автоматизация и FinOps-команда, пусть даже работающая по совместительству. TTO сокращается до 3-7 дней.
• Run (высший уровень) – когда автоматизировано вообще все, используются специализированные FinOps-платформы, а аллокация достигает 100%. TTO – от нескольких часов до пары дней.

Примеры расчета Time-to-Optimize

Теория теорией, но давайте посмотрим на разницу в результатах в зависимости от уровня зрелости FinOps у одной и той же компании, скажем, с 5 облаками и 10 командами разработки.

Ручной процесс:

• Сбор данных: 5 дней (походы по консолям, скачивание файлов)
• Нормализация: 3 дня (сведение в Excel)
• Распределение: 4 дня (выяснение владельцев, согласования)
• Анализ и решения: 5 дней (встречи, споры, утверждения)
• Внедрение: 2 дня (технические изменения)
• Результаты: 1 день (новый биллинг)

Итого: 20 дней

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

Автоматизированный процесс:

• Сбор данных: минуты (API все подтягивает сам)
• Нормализация: мгновенно (правила уже настроены)
• Распределение: автоматически (теги работают)
• Анализ и решения: 1 день (система выдает готовые рекомендации)
• Внедрение: 1-2 дня (часть изменений применяется сама)
• Результаты: в реальном времени (дашборды показывают изменения)

Итого: 2-3 дня

Разница в десять раз. При этом команды делают то, ради чего их наняли, а не возятся с таблицами.

Что замедляет процесс Time-to-Optimize

Основные факторы замедления TTO

Ну, вообще-то факторов, влияющих на TTO, довольно много. Но вот самые основные:

• Архитектурная сложность: мультиоблако – это в первую очередь многоформатность, с которой нужно уметь грамотно работать.
• Отсутствие автоматизации: когда вся аналитика делается руками в Excel, удивляться большому TTO не приходится.
• Бюрократия: если вы неделю тратите на то, чтобы согласовать отключение одной забытой виртуалки, вас никакие FinOps-платформы не спасут.
• Плохое тегирование ресурсов: от такой базовой вещи зависит очень многое. А с правильно настроенной системой тегов вся информация о владельцах, проектах и окружениях доступна мгновенно.

Польза быстрой оптимизации в FinOps

Зачем торопиться, спросите?

Во-первых, скорость оптимизации напрямую влияет на то, в какую сумму вам обойдется ваша облачная инфраструктура. Если команда тратит лишние 500 тысяч рублей в месяц, при TTO в три недели дополнительный перерасход составит еще 375 тысяч. При TTO в три дня — всего 50 тысяч.

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

В-третьих, если оптимизация происходит быстро, это позволяет высвобождать бюджет под новые инициативы здесь и сейчас, а не на будущий месяц. Отключили по-быстрому неиспользуемые виртуалки – и вот вам средства на разработку новой фичи для приложения. Не отключили? Окно возможностей закрылось, и конкуренты выпустили похожий продукт раньше.

Вывод: в FinOps медленно = плохо.

Что тормозит Time-to-Optimize

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

Кроме того, важно понимать контекст своих действий. Авральная оптимизация из-за двукратного увеличения месячного счета и плановая работа в рамках квартального ревью бюджетов – вообще не одно и то же. Они требуют разной скорости и подхода. Поэтому сравнивать их TTO напрямую некорректно.

Метрика требует отслеживания дат, этапов, событий. Это дополнительная нагрузка на команду, особенно если у вас параллельно идет несколько инициатив по оптимизации. Как понять, где одна закончилась, другая началась? Чем выше уровень зрелости, тем проще становится, потому что все автоматизировано. Но на начальных стадиях может реально напрягать.

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

Как использовать TTO на практике

Time-to-Optimize можно использовать несколькими способами:

1. Как основной KPI FinOps-команды. Забудьте про закрытые тикеты в Jira. Сократили TTO с 20 дней до 5? Значит, эффективность работы выросла в 4 раза. И это ясно всем – от CFO до уборщицы тети Маши.
2. Как обоснованиеч бюджетов. Руководство любит цифры, и, если показать ему десятикратную разницу между ручным подходом и автоматизацией. 20 дней против 2 – шутка ли. Вот вам и повод для использования FinOps-платформы. Причем не абстрактное, а с конкретными числами по вашей инфраструктуре.
3. Диагностика узких мест. Если разбить TTO на отдельные блоки, то можно сразу увидеть, где все тормозит. Может неожиданно выясниться, что техническая часть работает как часы, а вот согласования тянутся три недели. Тогда уже ясно, с кем надо разговаривать и какие процессы чинить.
4. Оценка зрелости процессов. Crawl – это недели, Walk – это дни, Run – это часы. Получается простой и понятный индикатор того, где вы сейчас и куда двигаться дальше.

В ближайшие годы TTO наверняка станет такой же привычной метрикой, как когда-то стал time-to-market в разработке. Так что компании, которые освоят быстрое реагирование на перерасходы, получат реальное преимущество перед конкурентами.

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

Быстрая оптимизация — штука безусловно полезная и прибыльная. Но это метрика должна работать на вас, а не вы на нее.

Если вы – тот самый IT-дир, который ни разу не выслушивал лекцию от консультанта о необходимости срочно мигрировать в облако, смело записывайтесь в красную книгу. Потому что чем бы вы ни занимались, сватать в облако вас будут методично и настойчиво. Оно, может, и неплохо. Но ведь есть и другой лагерь, который поносит облако на чем свет стоит, рассказывая ужастики про vendor lock-in, законодательные ограничения и проблемы с безопасностью. И тут вопрос только в том, кто окажется убедительнее. Но разве можно принимать решения без собственного представления о том, как обстоят дела на самом деле? То-то и оно.

Миф 1: Облако дешевле своей инфраструктуры

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

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

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

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

Миф 2: Облако подходит всем

Если послушать маркетологов, то создается полное впечатление, что облако универсально. Стартап? В облако. Банк? В облако. Маркетплейс? Угадайте с первого раза. Но на самом-то деле это так не работает.

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

То ли дело небольшая IT-компания или интернет-магазин. Вот они действительно могут выиграть от миграции. В облаке не нужно содержать системных администраторов, можно мгновенно масштабироваться под Черную пятницу и иметь непрерывный доступ к современным инструментам разработки и аналитики, который у себя бы вы точно никогда не развернули. Помните про “машинку”?

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

Миф 3: Миграция в облако автоматически модернизирует архитектуру

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

Если приложение тормозило на ваших серверах, то оно продолжит тормозить и в облаке, а на отвали написанные запросы к базе не станут быстрее от банальной смены дата-центра.

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

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

Миф 4: Облако небезопасно

Многие еще помнят историю со взломом iCloud, когда хакеры слили в сеть сотни фотографий знаменитостей. Тогда многим стало ясно, что облачные технологии – это история довольно сомнительная. Ведь если провайдер оказывается не способен сохранить конфиденциальность личных снимков, что и говорить о данных, составляющих корпоративную тайну. На удивление многие IT-диры до сих пор так и рассуждают, предпочитая все свое держать с собой.

Но давайте посмотрим на реальность. Команда информационной безопасности какого-нибудь Яндекса больше, чем весь IT-отдел среднего российского банка. VK тратит на защиту данных миллионы рублей ежемесячно. Мало того, у крупных провайдеров есть системы мониторинга угроз, которые работают круглые сутки, регулярные обновления безопасности, которые устанавливаются автоматически. И это не говоря уже о физической защите дата-центров по государственным стандартам.

Конечно, утечки из облака все равно случаются. Но, как показывает практика, большинство из них происходят не из-за хакерских атак, а из-за самих пользователей, которые ставят примитивные пароли, открывают S3-бакеты для всего интернета и банально забывают настроить права доступа.

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

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

Миф 5: Хранить корпоративные данные в облаке нельзя

152-ФЗ, требования ФСТЭК, работа с критической инфраструктурой – все это действительно создает массу ограничений на использование облаков для критической инфраструктуры. Но это не запрет, а просто требование быть более избирательным в выборе и не обращаться к кому попало.

А крупные отечественные провайдеры – точно не кому попало. Они давно получили необходимые сертификаты и аттестаты и функционируют полностью в российском правовом поле.

Например, Яндекс.Облако, VK Cloud и Selectel имеют право работать с персональными данными по первому уровню защищенности. Это значит, что там можно размещать даже самые чувствительные данные – биометрические, специальные категории персональных данных, информацию для госорганов.

МТС тоже не отстает. У них есть сразу несколько аттестованных сегментов: один с максимальным УЗ-1 для самых чувствительных данных, другие – с УЗ-2 и УЗ-3 для менее критичной информации. Так что компания может выбрать именно тот уровень защиты, который ей нужен, не переплачивая за избыточную безопасность.

А если вам нужна работа с критической информационной инфраструктурой и полная импортонезависимость, то и тут есть свои специалисты. Cloud.ru от Сбера аттестован для объектов КИИ третьей категории значимости, а Ростелеком запустил специализированное "Облако КИИ" для размещения объектов до второй категории значимости.

Вот и получается, что переход в сертифицированное облако – это едва ли не самый простой способ соблюсти 152-ФЗ без капитальных затрат на собственную инфраструктуру.

Миф 6: Vendor lock-in в облаке

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

Но ведь vendor lock-in – не конь в вакууме, и проявляется не сам по себе, а только при неграмотных действиях самой компании. И их можно избежать: большинство провайдеров поддерживают открытые стандарты, Kubernetes есть везде, PostgreSQL запустится на любой платформе, а Docker-образы не заблокированы и переносятся куда угодно. В общем, делай хорошо, а плохо не делай – и всего делов.

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

Миф 7: Российские провайдеры хуже западных

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

Причины тому было две:

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

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

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

• Terraform
• Ansible
• Kubernetes
• Docker

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

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

• Техподдержка работает в российском часовом поясе и говорит по-русски.
• Нет регуляторных рисков внезапного отключения сервиса.
• Можно договориться об индивидуальных условиях напрямую с российскими менеджерами.
• Проще получать скидки за счет резервирования и заключения долгосрочных контрактов.

Для многих компаний это оказывается важнее.

Миф 8: Цены на российские облачные услуги завышены

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

На практике, впрочем, все не так драматично. Виртуальная машина с 2 CPU и 4 ГБ памяти в Яндекс.Облаке сегодня стоит около 2500 рублей в месяц. То есть ровно столько же, во сколько оценивают аналогичный инстанс в AWS.

Бесспорно, рост цен был и утверждать обратное не имеет смысла. Но он составил примерно 15-20% за последние два года и был связан с объективными факторами: подорожанием импортного оборудования, ростом тарифов на электроэнергию, необходимостью инвестировать в развитие собственных технологий.

Так что, если снять шоры и взглянуть на рынок объективно, можно понять, что конкуренция между российскими провайдерами остается достаточно острой. Яндекс, VK, МТС, Ростелеком, Сбер и другие активно борются за корпоративных клиентов, предлагают скидки при долгосрочных контрактах, гибкие тарифные планы. Так что картелизации не наблюдается, и пугаться ее нет никаких оснований.

Миф 9: Облако – сложное

Kubernetes, Docker, микросервисы, Infrastructure as Code – все эти термины действительно могут напугать системного администратора, который привык к физическим серверам. А переучиваться и осваивать эту высшую математику так не хочется. И этих людей можно понять.

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

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

Никто не заставляет вас сразу прыгать в омут с контейнерами и оркестрацией. Боитесь – начните с обычных виртуальных машин и managed-сервисов, а там постепенно освоите и более продвинутые инструменты. Многие компании годами работают именно в таком режиме и чувствуют себя прекрасно.

Миф 10: Облачная инфраструктура ненадежна

Новости про глобальные сбои AWS регулярно попадают в заголовки, формируя представление о системной ненадежности облаков. Да, SLA 99,9% означает не идеальную стабильность, а честное признание того, что до 9 часов простоя в год действительно могут иметь место. Но это реалистичная оценка.

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

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

Российские провайдеры показывают доступность на уровне 99,95% и выше. Георепликация данных между несколькими дата-центрами снижает риски локальных проблем. Плюс возможность резервирования между разными провайдерами. Ну и где тут риски?

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

Что лучше: облако или свой ЦОД

Облако – это инструмент. Как любой инструмент, он подходит для одних задач и не подходит для других.

Главное – принимать решение относительно его использования или неиспользования не на основе мифов, а на основе анализа реальных потребностей. Хотите попробовать облако, но боитесь – просто запустите пилотный проект, измерьте результаты, поймите специфику работы. А уж потом решайте, стоит ли масштабировать на всю инфраструктуру.

Не хотите в облако – тоже нормально. Если у вас стабильная нагрузка, развитая IT-служба и все работает как часы, зачем что-то менять? Лишь бы ваше решение было осознанным, а не продиктованным страхами или чужим – зачастую необоснованным – мнением.

Что внутри AI Factory

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

В каталог открытых больших языковых моделей Foundation Models входит больше 20 популярных моделей, в том числе российская GigaChat и open source модели из других линеек.

Доступ к моделям реализован через Open AI API. Сервис ML Inference позволяет быстро развернуть и модели из каталога HuggingFace, и собственные модели.

Для работы и экспериментов с машинным обучением, запуска и тестирования ML-гипотез есть сервис Evolution Notebooks на базе JupyterLab.

Дообучение моделей под специальные задачи бизнеса происходит в сервисе ML Finetuning.

За использование внутренних данных пользователя, повышение точности ответа моделей, применение только доверенных источников информации отвечает сервис Managed RAG.

С ноября 2025 средняя цена на популярные открытые большие языковые модели составляет 35 рублей за входной и 70 рублей за выходной миллион токенов.

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

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

О компании

Cloud․ru — провайдер облачных сервисов и AI-технологий, который делает доступ к облакам и искусственному интеллекту простым и удобным. В Cloud.ru есть 100+ IaaS- и PaaS-сервисов, ML-платформа на базе суперкомпьютеров и публичное облако Cloud․ru Evolution на основе собственных разработок и open source.

В команде — более 1 500 специалистов в области IT, кибербезопасности и AI. Cloud.ru входит в число крупнейших IT-компаний России и в топ работодателей Хабр Карьеры.

Чтобы узнать больше, переходите на сайт cloud.ru или подписывайтесь на Cloud.ru Tech в Telegram.

Представим ситуацию: у вас три облака. Да, все российские (да и как же иначе?), но каждое работает по своим правилам. Одно считает трафик отдельной строкой в счете, второе как-то замешивает его в стоимость виртуалок, третье вообще берет фикс за месяц и не парится. Красота? Да нет, конечно! Потому что как все это складывать, решительно непонятно. Но вот был бы у вас FinOps, жить было бы куда легче. И дешевле.

Почему компании используют несколько облаков одновременно

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

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

У одной компании может быть и 3, и 4 площадки одновременно. Например, основа – это Яндекс Облако, VK Cloud – для экспериментов, Cloud.ru – для работы с госсектором. Конфигурации могут быть самые разные. Главное – суметь свести все расходы воедино и понять, на чем реально можно сэкономить, а на чем – нет.

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

Причем названия сервисов скорее всего тоже будут разные. То, что в Яндексе называется Object Storage, в VK Cloud может быть S3-совместимым хранилищем, а в Cloud.ru обозначаться как-то по-своему.

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

Проблемы миграции с AWS и Azure на российские облака

В 2022 году западные провайдеры ушли с российского рынка довольно резко. AWS, Azure, Google Cloud просто закрыли возможность создавать новые ресурсы, а потом начали постепенно отключать существующих клиентов. У компаний было всего несколько месяцев на то, чтобы перенести всю инфраструктуру куда-то еще.

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

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

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

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

Просто тарифы у местных провайдеров устроены чуть иначе, чем у зарубежных. В AWS можно было выгодно взять инстанс побольше с запасом по памяти, потому что разница в цене была небольшая. Но у наших та же логика могла привести к переплате в полтора раза. А поскольку многие переносили виртуалки один в один без оптимизации под нового провайдера, не пересчитывая конфигурации под реальную нагрузку, счета росли на 30-40%.

Как спроектировать инфраструктуру для мультиклауда

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

1. Не завязывайтесь на уникальные сервисы конкретного провайдера. Если компания активно использует фирменные managed-базы со специфичными настройками, сервисы ML, которые есть только у этого вендора, проприетарные API, переехать к другому без переписывания половины кода будет невозможно. Используйте стандартные решения там, где это возможно: PostgreSQL вместо фирменной базы, S3-протокол для хранения объектов, Kubernetes для контейнеров.
2. Описывайте инфраструктуру как код. Kubernetes + Terraform дают гибкость. Один раз описали инфраструктуру, развернули в Яндексе. Потом взяли тот же манифест, поменяли параметры провайдера – и без проблем развернули в VK Cloud. Правки будут, конечно: названия инстансов разные, зоны доступности называются по-другому. Но исправить это займет часы, но никак не месяцы.
3. Проверяйте отказоустойчивость на практике. Размазать нагрузку по трем облакам – это еще не мультиклауд. Задумывались ли вы, что будет, если основная площадка ляжет на часов эдак на 8? Как быстро переключится трафик? Кто это будет делать и по какой инструкции? Без подобных учений эти вопросы остаются без ответа до тех пор, пока не сломается что-то реально важное.

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

Хорошо, архитектуру продумали, провайдеров выбрали. Теперь вопрос: кто за все это отвечает?

Тут нет универсального ответа. Все зависит от размера компании и того, насколько у вас вообще налажены процессы.

• В маленьких компаниях обычно один DevOps на все. Он и мониторит расходы, и общается с провайдерами, и поддерживает инфраструктуру. Просто потому что больше некому. Такой подход называется централизованным и работает до тех пор, пока проектов немного и бюджет считается на коленке. Но как только начинается рост, вся схема ломается. Человек физически не успевает отследить расходы по десяткам сервисов в трех облаках.
• Крупные компании идут другим путем. Каждое подразделение получает свой бюджет и само решает, как его тратить. Маркетинг управляет своими аналитическими системами, разработка продукта своими, бэкенд-команда своими. Это федеративная модель. Тут главное, чтобы сверху были единые правила: как тегировать ресурсы, какие отчеты предоставлять, кто принимает решения о резервировании мощностей. Без этого получается хаос, где никто не знает, кто виноват в перерасходе.
• Золотая середина – это гибридная модель. Она предполагает, что есть небольшая центральная команда, которая договаривается с вендорами, выбирает инструменты учета, пишет политики использования облаков. А исполнение остается за подразделениями. То есть центр задает стандарты, команды их выполняют.

Как понять, что система работает нормально? Посмотрите, какой процент расходов вы можете объяснить. Если половина бюджета уходит непонятно куда, без привязки к проектам и командам, значит контроль не работает. В идеале вы должны быть способны объяснить буквально каждый рубль.

Cost per unit и другие метрики для контроля облачных затрат

Допустим, вы внедрили контроль расходов, назначили ответственных. Теперь надо понять: а работает ли это вообще? На какие цифры смотреть, чтобы увидеть реальную картину?

Начните с простого – посчитайте стоимость базовых действий в вашем сервисе:

• Одного письма
• Одного заказа
• Одного показа страницы пользователю

Важно считать траты не за месяц, а именно за одно конкретное действие. Только тогда можно будет начать сравнивать провайдеров между собой и понять, что в одном облаке письмо стоит 2 копейки, в другом 5.

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

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

Как снизить расходы на межоблачный трафик

Все думают, что деньги жрут виртуалки. В целом, да: GPU, мощные инстансы, терабайты дисков – все это стоит денег. Но на самом деле главной неожиданностью является трафик.

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

К чему это ведет: API лежит в одном облаке, статика раздается из второго, аналитика собирается в третьем. Каждый запрос пользователя теперь не просто обрабатывается, а гоняет данные туда-сюда между площадками. Миллион запросов в день по 50 килобайт каждый – и вот вам счет на сотни тысяч рублей лишь за трафик.

Чтобы остановить это, начните с рисования схемы потоков данных. Реально возьмите бумагу или откройте какой-нибудь draw.io и прикиньте, куда ходят ваши данные и зачем. В результате получится, что логи пишутся в одно облако, обрабатываются во втором, результаты складываются в третье. И половину этих переездов можно убрать, просто переставив сервисы поближе друг к другу.

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

Резервирование мощностей и спотовые инстансы: как экономить на облаках

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

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

Спотовые инстансы дают скидку до 70-80%, но могут отключиться в любой момент. Поэтому для продакшена они не подойдут. Но для CI/CD, обработки данных, рендеринга это то, что нужно. Хотя если архитектура спроектирована правильно, можно часть нагрузки держать на спотах с автоматическим переключением на обычные инстансы при отключении. В общем, тут смотрите сами. На худой конец, посоветуйтесь со спецами в сообществе Практики FinOps.

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

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

Как финансовый контроль помогает ловить проблемы с безопасностью

Чем больше облаков, тем больше шансов, что что-то где-то может сломаться или подвергнуться атаке. Вот только при чем тут FinOps? Речь же о безопасности, а не об экономии.

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

Технический мониторинг может не заметить продуманную атаку без явных признаков. А вот счет не обманешь. Он просто не может вырасти без причины. Появились расходы на GPU, которые команда не заказывала? Трафик между облаками удвоился без изменений в коде? Каждый такой случай требует разбора. Что-то да найдете.

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

Решения для учета расходов в облаке

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

За границей для этой цели используют FOCUS (FinOps Open Cost and Usage Specification). У нас про такое пока не слышали, поэтому решают проблему своими силами. Кто-то пишет скрипты на Python, которые собирают данные через API. Кто-то использует готовые ETL-инструменты вроде Airflow. Кто-то просто скачивает CSV и сводит в Excel.

Но какой бы путь вы ни выбрали, есть базовые вещи, без которых система не заработает:

• Провайдеры обновляют API без предупреждения. Сегодня поле с ценой называется cost, завтра price, послезавтра total_amount. Из-за этого ваши скрипты ломаются, отчеты начинают показывать нули, а вы узнаете об этом только когда руководство спрашивает, почему счета не сходятся. Автоматические проверки на изменения в структуре данных решают эту проблему.
• Без меток project, owner, environment в мешанине из сотен инстансов вы точно не разберетесь. Каждый ресурс должен знать, к какому проекту относится, кто владелец, какое окружение. Думаете, что запомните? Не обольщайтесь. Через месяц никто не вспомнит, зачем вообще была нужна та ВМ и можно ли ее выключить.

Теперь про конкретные инструменты. В России их пока не так много, но они все-таки есть:

• Клаудмастер от Inferit FinOps. Российская разработка, которая входит в реестр отечественного ПО. Система смотрит на реальную нагрузку и предлагает корректировки размеров, чтобы не переплачивать за простаивающие мощности.
• Kubecost + Prometheus решают специфическую проблему кубернетес-кластеров. Prometheus собирает метрики о том, сколько ресурсов потребляет каждый под, каждый контейнер. Kubecost берет эти метрики и накладывает на них цены провайдера. В результате видите не абстрактные CPU и память, а рубли.
• Самописные решения. Это может быть дашборд в Grafana, который собирает данные из API провайдеров раз в час, скрипт на Python с утренней сводкой в Telegram или что-то другое. Для первых шагов будет вполне достаточно.

Практический чек-лист готовности к мультиклауд-FinOps

Теория это хорошо, но нужно обязательно проверить, все ли у вас настроено правильно:

1. Начните с архитектуры. Если завтра понадобится перенести часть нагрузки в другое облако, сколько времени это займет? Неделю правок в конфигах или три месяца переписывания кода? Используете ли проприетарные сервисы провайдера там, где можно обойтись стандартными решениями? Когда последний раз проверяли, что будет при отказе одной из площадок?
2. Дальше про данные. Биллинг из всех облаков собирается автоматически или кто-то вручную скачивает CSV раз в месяц? Есть ли проверки на изменения в структуре данных от провайдеров? Все ли ресурсы помечены тегами с проектом, владельцем и окружением? Если на последний вопрос ответ нет, начните именно с этого.
3. Финансовая часть. Можете ли посчитать, сколько стоит одна транзакция в вашей системе? Один активный пользователь за месяц? Гигабайт данных в хранилище? Учитываются ли в прогнозах сезонные пики нагрузки? Закупки ресурсов планируются заранее на основе статистики или покупаете все по требованию когда припрет?
4. Автоматизация и безопасность. Настроены ли правила для автоматической уборки забытых ресурсов? Алерты на резкий рост расходов без видимых причин? Совместно ли команды FinOps и безопасности отслеживают аномалии в потреблении?

Если хотя бы на половину вопросов ответили утвердительно, уже неплохо. Если меньше, есть над чем работать. Мультиклауд без контроля расходов превращается в черную дыру для бюджета. Но с правильно настроенным FinOps получаете не только экономию, но и дополнительный инструмент для мониторинга безопасности и стабильности всей инфраструктуры. Так что дерзайте. Хуже точно не будет.

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

Почему все пошло не так

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

Попробуйте просчитать unit economics в таких условиях – и получится чушь. Да, вы знаете общие расходы на облако, но, как определить, какая их часть приходится именно на мобильное приложение, а не, скажем, на сайт, аналитику или тестовые среды?

Без четкого распределения затрат мы получаем просто гадание на кофейной гуще. Хуже того, продукт может только казаться прибыльным в отчетах, а на самом деле проедать половину IT-бюджета через скрытые инфраструктурные траты, которые вы даже не фиксируете. Что же делать? Муравья мучить не надо. Лучше займитесь детализацией.

Как выбраться из финансовой каши

Сразу предупреждаем: овладеть ситуацией за один день не получится. Это поэтапный процесс, каждый из которых может растянуться даже не на месяцы, а на годы. Но пусть вас это не пугает. Первые 3-4 этапа вы пройдете довольно быстро, а там сориентируетесь и будете действовать с полным пониманием дела.

Этап первый: тратим как получается

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

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

Этап второй: разбираемся с провайдерами

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

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

Этап третий: раскладываем по полочкам

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

Например, что виртуальные машины и контейнеры съедают львиную долю бюджета. Нередко это может быть даже 60-70%. Хранение данных, как правило, тянет еще 20-30%. Ну, а остатки доедают сетевой трафик и управляемые сервисы.

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

С управляемыми сервисами в России пока тоже не все гладко. Их просто меньше, чем хотелось бы, поэтому приходится больше настраивать самостоятельно. Зато собственное решение может стоить дешевле готового. И это плюс.

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

Этап четвертый: каждому ресурсу своего хозяина

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

Оно покажет, кто сколько тратит с разбивкой по командам, что хорошо. Но есть одна сложность – люди.

Заставить всех верно проставлять теги – задача не из легких. Программистам и так есть чем заняться, скажут вам.

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

Зато результат того стоит. Благодаря тегированию вы точно узнаете, что, скажем, мобильная команда потратила 150 тысяч на продакшен и 50 тысяч на тестирование. А если кто-то забыл выключить staging-среду на выходные, виновник будет вычислен моментально. А там – делайте с ним, что хотите. Только не убивайте.

Этап пятый: каждый отвечает за свой бюджет

Финальная стадия — создание отдельных cost-центров с реальной финансовой ответственностью. На этом этапе каждая команда получает свой лимит расходов и сама за него отвечает.

Тут есть два основных подхода:

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

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

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

Как это сделать технически

Правила хорошего тегирования

В теории все звучит гладко, но стоит дойти до дела – и начинаются проблемы. В частности, тегирование – это история про жесткую дисциплину. В этом деле критически важно не допускать разночтений. Если команда называется Backend, то и называть ее надо именно так, а не back-end или даже backend. В противном случае, система просто не вывезет.

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

• cost_center — кто за это платит
• project — к какому продукту или сервису относится
• environment — production, staging или development
• owner — конкретный ответственный человек

Kubernetes — отдельная история

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

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

Впрочем, даже если инструменты есть, с распределением все равно не все просто. Допустим, у нас есть кластер стоимостью 100 тысяч рублей в месяц. На нем работают три проекта: фронтенд с потреблением 40% ресурсов, бэкенд – с 35%, аналитика – с 25%. Казалось бы, просто берем и делим затраты в тех же пропорциях. Но тут есть подводные камни.

Но ведь кроме основных приложений есть ведь и общие сервисы. Кто должен платить за них? Большинство компаний идет на компромисс: треть стоимости кластера делят поровну между всеми проектами (это плата за общую инфраструктуру), а оставшиеся две трети распределяют пропорционально реальному потреблению процессора и памяти. Решение не идеальное, но хотя бы работает и получается более-менее честно.

Каждой команде свой аккаунт

Другой способ решить проблему с атрибуцией — выделить каждой команде отдельный облачный аккаунт. Российские провайдеры это поддерживают:

• В Яндекс.Облаке есть каталоги и организации;
• VK Cloud предлагает проекты;
• Cloud.ru тоже умеет разделять ресурсы по организациям.

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

Но как честно поделить стоимость общих сервисов? Например, той самой базы данных, которой пользуются три разные команды или балансировщика нагрузки, через который проходят запросы к пяти разным сервисам?

Есть несколько основных вариантов:

1. Первый — делить пропорционально использованию. Просто ставите мониторинг и считаете, от кого сколько запросов уходит к общей базе. А затем распределяете эти расходы в тех же пропорциях.
2. Второй — взять и поделить. Такой подход проще в реализации, но может показаться несправедливым.
3. Третий — воздавать каждому по заслугам его. Ну, или, проще говоря, брать больше с тех, кто приносит компании больше денег или обслуживает больше пользователей. Это вполне логично с точки зрения бизнеса, но значительно сложнее в подсчетах.

Отчеты для разных ролей

Когда данные собраны, а теги расставлены, встает вопрос: как правильно все это преподнести людям? Ведь генеральному директору и сисадмину нужны совершенно разные срезы данных. Поэтому берем и разделяем.

• Руководству компании обычно достаточно общей картины: растут расходы или падают, какие три проекта обходятся дороже всего, есть где-то резкие скачки в тратах или нет. Лишние детали будут не поняты и только помешают.
• Продакты ориентируются в основном на unit-экономику. Им важно, сколько стоит инфраструктура для обслуживания одного пользователя, обработки одного заказа или показа тысячи рекламных объявлений. Эти цифры помогают понять реальную рентабельность продуктов и принимать обоснованные решения об их развитии.
• Ну, а DevOps’ы требуют максимальной детализации вплоть до отдельных серверов. Им нужно знать, какие ресурсы недоиспользуются, где можно сэкономить, что оптимизировать в первую очередь.

При этом есть несколько ключевых показателей, которые будут полезны всем:

• Cost per team — месячные расходы каждого подразделения. Помогает понять, кто тратит больше и есть ли для этого объективные причины.
• Cost per product — стоимость инфраструктуры для каждого продукта или сервиса. Без этого корректно посчитать рентабельность просто невозможно.
• Процент распределенных затрат — какую долю общих расходов удалось привязать к конкретным владельцам. Это показатель качества вашей системы учета.

Пошаговый план внедрения

Главное правило внедрения – не пытаться охватить все сразу. Гарантированно свихнетесь. Поэтому идите по порядку:

• Начните с аудита. Посмотрите, куда ушли деньги за последние полгода.
• Составьте список всего, что у вас работает в облаке.
• Распишите правила тегирования.
• Настройте автоматическое создание ресурсов с правильными тегами.
• Назначьте ответственных.
• Объясните командам, зачем это все нужно (но приготовьтесь к сопротивлению).
• Договоритесь заранее, как делить общие ресурсы.
• Настройте автоматические отчеты.

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

И еще один важный момент: первые результаты увидите не сразу. Первые месяца три-четыре будет казаться, что занимаетесь ерундой. Это нормально. Все-таки система учета затрат — не та штука, которая работает с первого дня. Зато когда заработает, сразу станет понятно, стоило ли оно того. Так что мужайтесь.

Что получится в результате

Компании, которые довели это дело до конца, экономят на облачных расходах от 20 до 30% без каких-либо потерь. Если у вас уже есть какие-то базовые механизмы контроля, экономия будет поскромнее, но все равно вполне заметной.

Помимо прямой экономии денег, вы получите несколько приятных эффектов:

• Точность планирования бюджета вырастет в разы.
• У команд разработки появится реальная мотивация думать об эффективности своих решений.
• Станет возможным корректно считать unit-экономику всех продуктов.
• Появится детальный контроль над каждой статьей расходов.

Да, на внедрение всей этой системы придется потратить время и нервы. Но альтернатива-то еще хуже. А какой смысл продолжать работать практически вслепую, спуская IT-бюджет неизвестно на что? Рано или поздно такой подход неизбежно приведет к серьезным финансовым проблемам. И тогда разбираться с ними придется в режиме аврала, когда руководство стоит над душой и только требует, требует, требует.

Облачная экспансия

Против статистики не попрёшь. Сегодня более 90% компаний в мире уже используют облачные технологии в той или иной форме, а по итогам 2025 года почти 85% предприятий планируют сделать его основой своей инфраструктуры. С таким успехом уже к 2027-му году мировой рынок облачных услуг может вырасти до триллиона долларов.

В России тренд проявляется не менее ярко. После того как весной 2022-го западные гиганты AWS, Azure и Google Cloud покинули наш рынок, местная облачная индустрия получила такой толчок, что объём рынка подскочил на 50% за год. Сейчас он достигает 165 миллиардов рублей, демонстрируя рост почти на 25% год к году, и останавливаться явно не собирается.

Почему облака так популярны:

• Стартапам не нужно думать о покупке серверов на старте. Можно запустить MVP за копейки и тестировать гипотезы без капитальных вложений.
• Средний бизнес экономит на содержании ИТ-персонала и получает возможность мгновенно масштабироваться под нагрузку.
• Крупные корпорации благодаря облаку могут развернуть новый проект без согласования закупок оборудования или запустить проект в одном регионе, а потом за пару кликов расширить географию.

Местные провайдеры отреагировали на увеличение спроса на их услуги с большой благодарностью. Кто-то сделал ставку на готовые решения для ИИ, кто-то начал развивать инфраструктурные сервисы, кто-то – интегрировать собственные разработки. Результат такой активности стал заметен довольно быстро: контейнеризация перестала быть экзотикой, Kubernetes стал использоваться в 84% организаций, а DevOps-подходы проникли даже в самые традиционные отрасли.

Почему компании уходят из облака

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

Например, Wildberries отгрохал дата-центр в Электростали за сотни миллионов и сейчас строит ещё два объекта в Подмосковье. Мотивируют это просто: свои ЦОДы банально дешевле аренды, которая постоянно дорожает. В том же направлении движется и Газпром, который занимается строительством гигантского дата-центра на 5 тысяч стоек с инвестициями, исчисляемыми миллиардами рублей. Росэнергоатом и вовсе развивает целую сеть дата-центров «Атомдата» и даже приглашает коллег по цеху на экскурсии, делясь опытом эксплуатации собственных мощностей.

Что толкает их на такие траты? Российские компании чаще всего называют две причины. Вот они:

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

Однако по факту факторов куда больше. Просто говорить о них на публику почему-то не принято:

• Плата за трафик. К примеру, наши платформы оценивают каждый гигабайт исходящего трафика в 5-10 рублей в зависимости от тарифа и условий обслуживания. Таким образом маркетплейсы и стриминговые сервисы могут тратить миллионы только на сеть. А ведь есть ещё межзонный трафик, VPN-туннелирование, резервное копирование между регионами, что тоже сильно влияет на счета. На фоне этого своя инфраструктура с практически нулевой стоимостью обмена данными между машинами выглядит очень заманчиво. Тем более что облачные вендоры любят создавать зависимость: чем больше информации у них храните, тем болезненнее будет уход.
• Геополитические риски. После 2022-го любая зависимость от внешних поставщиков воспринимается как критическая уязвимость. На их фоне собственный ЦОД кажется более предсказуемым и управляемым.
• Регуляторное давление. ФЗ-152 требует хранения персданных россиян на территории РФ. Критически важные системы должны размещаться в аттестованных средах. Поэтому многим проще построить свой ЦОД, чем разбираться с сертификацией провайдеров.
• Нехватка мощностей. Несмотря на то, что облако — это история про удобное, быстрое и практически неограниченное масштабирование, по-настоящему крупные российские компании типа Wildberries столкнулись с ситуацией, когда рынок колокации просто не может предложить ресурсы под реально внушительный рост бизнеса.

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

Впрочем, назвать эту тенденцию чисто российским явлением нельзя. По данным Liquid Web, более 40% ИТ-компаний в мире стремятся диверсифицировать нагрузки и возвращаются к использованию своих собственных дата-центров. Вот так вот, сами того не подозревая, мы оказались в числе основоположников нового тренда.

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

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

• Безопасность. Облака стали удобной целью для атак злоумышленников. Чем больше клиентов у провайдера, тем привлекательнее он для хакеров. Взлом одной платформы автоматически открывает доступ к данным десятков компаний.
• Egress fee бьёт по карману везде одинаково. AWS берет 0,09 доллара за гигабайт исходящего трафика, а примерно те же 8-9 рублей по текущему курсу. Для контент-провайдеров и стримингов это миллионы долларов ежемесячно.
• Экономия. Компания 37signals, разработчик Basecamp, подсчитала, что за пять лет сэкономит более 7-10 миллионов долларов, если перейдёт на собственную инфраструктуру. По их словам, облачные провайдеры превратились в «налог на простоту», когда за удобство платишь астрономические суммы, которые стало слишком сложно оправдывать.
• Растущие требования к комплаенсу тоже толкают компании к собственной инфраструктуре. Европейский GDPR, американские финансовые регуляторы, медицинские стандарты вынуждают компании постепенно приходить к простому выводу: куда проще построить свой ЦОД под конкретные стандарты, чем подстраиваться под ограничения провайдера.

Чем облако лучше своей инфраструктуры

Однако у облачных провайдеров есть что на это ответить:

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

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

В-третьих, гарантии работоспособности облаков в 99,9-99,99% выглядят очень привлекательно. По факту цифры тоже не идеальные. В год это примерно от одного до 9 часов простоя. Но попробуйте добиться такой надежности самостоятельно. Вам потребуется продублировать все компоненты, разнести оборудование по разным локациям, нанять штат дежурных специалистов, работающих круглосуточно, и заморочиться с автоматизацией процессов восстановления. Реально ли это? Вполне. Выгодно ли? Большой вопрос. Потому что в денежном эквиваленте такой проект может обойтись значительно дороже облачного варианта.

В-четвёртых, безопасность — это не только недостаток, но и преимущество облаков. Российские платформы работают в рамках действующего законодательства и проходят необходимые проверки на соответствие требованиям ФЗ-152 и стандартам ФСТЭК. Кроме того, сегодня облака, как правило, лучше защищены от хакеров, чем когда-либо прежде. Поэтому после недавней серии атак на корпоративные сети даже убеждённые сторонники собственной инфраструктуры стали рассматривать облако как запасной вариант.

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

В-шестых, бэкапы и резервирование. Облако часто используется как запасной контур. При аварии или кибератаке среду можно развернуть в другом регионе за часы, а не за недели. В on-prem для того же пришлось бы строить второй ЦОД, дублировать оборудование и поддерживать его в состоянии постоянной готовности, что в разы дороже.

Что выгоднее: экономика ЦОД и облаков

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

Ваши ожидания — ваши проблемы, сказал бы классик. Но дело вовсе не в ожиданиях, а в отсутствии чётко выстроенных процессов при использовании облака. Именно из-за этого до 30% облачного бюджета организаций чаще всего тратится впустую.

Незакрытые тестовые инстансы, избыточное резервирование, неоптимальные конфигурации – все это приводит к тому, что в одной только России суммарный перерасход в облаке составляет 30-50 миллиардов рублей ежегодно. А хуже всего то, что точную сумму до сих пор так никто и не посчитал. Ведь всегда проще бросить новое начинание и сказать, что оно вам не подходит, чем покопаться в себе и найти корень проблемы.

FinOps как спасение от облачного хаоса

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

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

Есть несколько способов этого добиться:

• Повышение прозрачности затрат. Узнавать о расходах в конце месяца из счета провайдера плохо и неэффективно. Команды должны получать информацию о стоимости своих решений в реальном времени, чтобы вовремя их корректировать. Специальные дашборды покажут, сколько что стоит. Только через это технари начинают понимать, что инстанс, более мощная конфигурация, выбранная без нужды, и забытые базы данных — это потраченные деньги компании.
• Распределение ответственности. Каждая команда получает свой бюджет и отвечает за его соблюдение. Это кардинально меняет поведение: если раньше разработчики могли бездумно создавать ресурсы, то теперь они думают о каждом действии. Превысил лимит — объясняй руководству, зачем это было нужно. Не смог объясниться — изыщи способ сэкономить на чем-то другом.
• Автоматизация оптимизации. Если всё грамотно настроить, системы сами будут отключать неиспользуемые ресурсы в нерабочее время, выбирать оптимальные конфигурации серверов, а редко используемые данные переводить в более дешёвые хранилища.
• Культурные изменения. Чтобы каждый технарь осознавал цену своим действиям и мог на них влиять, должны появиться новые метрики эффективности, новые KPI, новые процессы планирования и ретроспектив. Даже мотивировать их надо будет иначе, чем раньше. Но всё это окупится, не сомневайтесь.

Конкретные результаты внедрения FinOps

Компании, которые серьёзно внедрили FinOps, показывают впечатляющие результаты. Снижение облачных расходов на 20-30% без потери функциональности – это стандартный показатель для отрасли. И ничего сверхъестественного для этого не нужно. Достаточно просто начать отслеживать использование ресурсов и оптимизировать их.

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

Гибридный подход становится нормой

Несмотря на то что FinOps изначально появился как способ навести порядок в облачных затратах, постепенно он превратился в универсальный подход к управлению любой ИТ-инфраструктурой. И это полностью соответствует текущему тренду на гибридизацию:

• 67% компаний используют публичные облака;
• 55% поддерживают собственные серверы;
• 45% разворачивают частные облака;
• 8% работают с одним провайдером.

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

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

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

Хотя можно и совмещать. Вот для примера несколько популярных схем:

1. Ядро on-prem, всё остальное в облаке. Критичные системы и базы данных можно держать на собственных серверах, где они будут в зоне вашего полного подчинения. А вот фронтенд, API, аналитику можно спокойно вынести в облако для быстрого масштабирования. Disaster recovery можно отдать на откуп третьему провайдеру. Такую схему предпочитают банки и ретейл с большими транзакционными нагрузками. Так они экономят до 30% на ядре и сохраняют гибкость для пользовательских интерфейсов.
2. Облако primary, on-prem для подстраховки. Эта схема предполагает, что основная работа идет в облаке, а собственные мощности используются для восстановления и долгосрочного хранения архивов, а синхронизация настраивается в обе стороны. Данный подход удовлетворяет потребности ИТ-компаний и стартапам, которые доросли до enterprise-уровня.
3. Multi-cloud для глобальных продуктов – это когда сервисы работают параллельно в 2-3 облаках, обеспечивая балансировку по географии и стоимости, а также единый мониторинг за всем этим хозяйством. Совмещение облаков может быть сложным в управлении — особенно для новичков, — зато гарантирует максимальную отказоустойчивость.
4. Тестирование в облаке, продакшн on-prem. Разработка и эксперименты в облаке дают гибкость, а рабочие системы крутятся на собственной инфраструктуре. Плюсы? Контроль затрат и производительности.

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

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

Практические выводы: облако или ЦОД

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

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

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

В России работа с несколькими провайдерами снижает риски, но требует больше ресурсов на управление. Учитывайте это.

Но главное условие — не принимать инфраструктурную стратегию как решение навсегда. Рынок меняется, регуляторка ужесточается, потребности бизнеса эволюционируют. То, что успешно работает сегодня, может перестать работать уже завтра. Поэтому будьте гибче. И да пребудет с вами FinOps.

Почему локальные решения теряют актуальность

В традиционной on-prem среде каждый шаг превращается в отдельный мини-проект: нужно утвердить бюджет, приобрести оборудование, настроить VPN, организовать резервирование. Даже простое действие — предоставление доступа новому разработчику — требует цепочки согласований через ИТ-отдел.

Кроме того, локальные решения часто избыточны с точки зрения ресурсов. Организация оплачивает полный набор серверов и лицензий, хотя фактическая загрузка может составлять всего 40-50%. Это создаёт неоправданные финансовые издержки.

Что дает переход в облако

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

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

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

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

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

Облачные решения устраняют эту проблему:

● Снижается «порог входа» для новых сотрудников — они подключаются к проекту за часы, а не дни;

● Ресурсы выделяются динамически, по фактическому потреблению, без оплаты простаивающего оборудования;

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

Вопрос безопасности: миф или реальная проблема?

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

Вопрос не в том, есть ли у платформы нужный функционал, а в том, как компания его применяет. Если внутри нет выстроенной модели доступа, логики разграничения ролей, процессов аудита — уязвимости будут и в облаке, и в on-prem. При правильном подходе к безопасности облако может быть даже надежнее локальной среды, особенно при работе с внешними подрядчиками, где важно контролировать периметр доступа.

Гибридные подходы и особые случаи

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

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

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

Вместо заключения

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

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

Что известно сейчас

• Модель «смотри рекламу — играй час». Внутренние тесты предусматривают около двух минут преролла перед стартом и ограничение одной сессии до 60 минут, суммарно до пяти бесплатных часов в месяц (параметры могут измениться ко времени релиза).
• Какие игры доступны. Можно будет стримить часть игр из вашей библиотеки, тайтлы из инициативы Free Play Days (бесплатные уикенды) и подборку Xbox Retro Classics.
• Где будет работать. ПК, консоли Xbox, портативные устройства и браузер — как и у платной версии облака.
• Публичная бета — затем полноценный запуск. Microsoft готовит открытое тестирование и планирует вывести сервис в прод в ближайшие месяцы.

Почему сейчас

Запуск бесплатной версии накладывается на свежие перестановки в линейке Game Pass и облака: Xbox Cloud Gaming вышел из беты, расширился на Premium и Essential, при этом Ultimate подорожал, но получил повышенное качество стриминга — вплоть до 1440p (разрешение экрана 2560×1440 пикселей, QHD или WQHD) на части игр/устройств и увеличенный битрейт.

Microsoft намекала на доступный/бесплатный доступ к облаку ещё раньше. Финансовый директор Microsoft Gaming Тим Стюарт говорил о варианте ad-supported почти два года назад, а в августовском выпуске официального подкаста Xbox топ-менеджеры повторили курс на «более доступное и глобальное» облако.

Microsoft тестирует гибрид стриминга и AVoD (advertising-video-on-demand) в играх. Если публичная бета подтвердит стабильность и вменяемые лимиты, у Xbox появится ещё один канал охвата — с шансом перерасти в «Spotify» для облачного гейминга.

Когда растущий трафик интернет-магазина приводит к замедлению скорости генерации страниц и IT-архитектура с единым сервером перестает справляться, а еще учащаются DDoS-атаки, то перенос IT-проекта в облачные сервисы становится неизбежным. Именно с такой ситуацией столкнулся мебельный ритейлер «169». Изначально компания использовала для работы виртуальный хостинг и небольшие VPS-серверы, однако в связи с возникшими сложностями начала миграцию своих IT-систем в облако.

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

Настройка облачной инфраструктуры для IT-архитектуры

Чтобы справиться с проблемами производительности, компании «169» пришлось изменить подход к построению IT-инфраструктуры и внедрить четыре ключевых принципа современной облачной архитектуры.

Принцип разделения ответственности стал основой новой системы. Вместо хаотичного размещения сервисов на единой платформе была реализована четкая специализация компонентов. Под базы данных выделили мощные серверы PostgreSQL с репликацией по схеме master-slave для отказоустойчивости и производительности. Поисковые функции перенесли на отдельный кластер Elasticsearch с русскоязычной морфологией, что значительно ускорило работу с каталогом товаров. Фоновые задачи и очереди обработки вынесли на специализированные серверы с Redis и RabbitMQ — это разгрузило основные веб-ноды и повысило стабильность системы.

Далее внедрили многоуровневую систему кэширования, которая уменьшила время отклика в шесть раз. На уровне приложения настроили Redis для кэширования шаблонов и результатов API-запросов, что снизило нагрузку на базы данных. Для статического контента подключили браузерное кэширование с оптимальными сроками жизни ресурсов. Геораспределенная CDN-сеть помогла с быстрой доставкой контента пользователям из разных регионов, уменьшив задержки до минимума.

Децентрализованное хранение данных устранило проблемы с производительностью и надежностью медиаконтента. Все файлы были перенесены в S3-совместимое объектное хранилище, что позволило отделить хранение от логики приложения. Для безопасного доступа к приватным ресурсам реализовали механизм presigned URL с ограниченным временем жизни. Автоматизация управления данными через lifecycle-правила упростила процессы архивирования и удаления устаревших файлов, снизив затраты на хранение.

Также важным элементом стала полная автоматизация процессов. Внедрили CI/CD на базе GitLab с автоматическим тестированием каждого коммита — это в разы ускорило вывод новых функций на прод. Система мониторинга на Prometheus и Grafana с продуманными алертами позволила оперативно реагировать на инциденты до их влияния на пользователей. Сейчас автоматическое масштабирование ресурсов по метрикам нагрузки позволяет вести бесперебойную работу даже в периоды пикового трафика, экономя ресурсы в спокойные периоды.

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

В таблице представлены технические характеристики основных нод, развернутых в инфраструктуре Рег.облака.

Технические результаты

Распределенная IT-архитектура с балансировкой нагрузки и резервированием критических компонентов помогла компании добиться выдающихся показателей отказоустойчивости. Среднее время простоя сервисов сократилось до менее 15 минут в год — это соответствует уровню доступности 99,98%. Существенно улучшилась и производительность: время отклика IT-системы уменьшилось в 6 раз — с 800 мс до 120 мс, а полная загрузка страниц стала занимать 200–250 мс. Эти улучшения не только повысили удовлетворенность пользователей, но и положительно сказались на SEO-показателях проектов.

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

Исходный план был реализован полностью, но в процессе мы усилили архитектуру несколькими важными корректировками: перешли на выделенные серверы для кластера БД из-за ограничений по приватным сетям, внедрили ELK-стек для централизованного логирования, развернули трехнодовый кластер Redis для кэширования, глубоко интегрировали CI/CD с Terraform и Ansible, подключили облачное S3-хранилище для медиаконтента и усилили защиту Anycast-DNS. Эти изменения позволили добиться максимальной отказоустойчивости и снизить нагрузку на бэкенд даже в пиковые периоды.

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

Главные анонсы Cloud.ru на конференции GoCloud Tech

Провайдер облачных и AI-технологий Cloud.ru остаётся лидером российского рынка по совокупной выручке IaaS+PaaS: по итогам 2024 года доля компании составила 28,9%. Отдельно в сегменте IaaS — 24,7%.

Компания развивает собственное публичное облако Cloud.ru Evolution, предоставляет инфраструктурные и платформенные сервисы, внедряет решения на базе AI/ML и выпускает инструменты для разработчиков, работает с клиентами от небольших команд до крупных предприятий.

3 сентября прошла вторая технологическая конференция для инженеров и разработчиков GoCloud Tech, которая собрала сотни участников, в том числе онлайн. На сессиях топ-менеджеры и инженеры платформы представили новые сценарии AI-помощника «Клаудии» (режимы SRE-агента и FinOps-оптимизации), объявили новые цены на открытые LLM в Cloud.ru Evolution AI Factory (вступают в силу 1 ноября 2025 года), а также сообщили о запуске грантовой программы «Код без границ» совместно со СберТех и сообществом Хабр. В числе спикеров были и приглашённые представители индустрии, в том числе 2ГИС.

На конференции работали четыре трека:

AI&ML — здесь спикеры обсуждали AI-агентов, разгружающих инженеров (SRE/DevOps), и прикладную работу с моделями (RAG, инференс) — как это ускоряет поддержку и улучшает клиентский сервис.

Cloud Infrastructure — на сессиях сделали упор на устойчивость и защищённые соединения: архитектура IaaS на Kubernetes, связность между проектами с Magic Link и облачный Evolution VPN для гибридных сценариев.

Data & Analytics — трек был посвящён запуску коммерческой Evolution Data Platform и современному взгляду на СУБД/HTAP и метрики производительности — «данные как топливо» для AI-кейсов

Dev Platform Services — демонстрировались практические решения для девов: Partner API, монтирование S3 в Container Apps, и приёмы с eBPF для улучшения cloud-native продуктов.

Рассказываем подробнее о главных тезисах и анонсах события.

«Клаудия»: от ассистента к агентным сценариям SRE и FinOps

AI-помощник «Клаудия» — это интерфейс в личном кабинете Cloud.ru Evolution, который не только советует, но и выполняет действия. Клаудию представили в конце июня, и с тех пор идёт публичное тестирование: участие приняли более 4 000 инженеров, отправлено ~36 000 сообщений, из них 67% — получили положительные оценки. Пока сервис открыт только для инженеров;корпоративные аккаунты подключат после доработки сценариев.

Из базовых задач AI-помощник уже умеет подобрать сервисы под задачу, развернуть ВМ, сгенерировать SSH-ключ, включить мониторинг и алерты, а в сложных местах — «провести за руку»: подсказать по Secret Management и Terraform, выступить «копилотом» в консоли. На демо показали сокращение онбординга инфраструктуры с 15–30 до ~2 минут; в ~96% случаев ответ приходит около 10 секунд (внутренние метрики).

Сейчас в публичном тесте — еще два режима «Клаудии»: SRE и FinOps.

• SRE. Подключается к метрикам и логам проекта, собирает дашборды, предлагает правила алертинга и план действий при инциденте. Ближайший шаг — возможность масштабироваться «по клику» из рекомендации с подтверждением инженера.
• FinOps. Ищет «зомби-ресурсы» (простаивающие ВМ, диски, IP) и предлагает безопасные варианты экономии, и никаких авто-удалений — любые изменения совершаются только после согласия пользователя.

Вместе с ручным тестированием команда использует собственного агента-тестировщика «Альберта» на базе фреймворка с открытым исходным кодом DeepEval. Он генерирует и ведёт диалоги с Клаудией в разных ролях (например, «студент делает лабораторную»), помогает проверять регрессии и качество ответов.

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

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

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

И важно понимать границы: всё, что рутина и повторяемые действия, — отлично автоматизируется. А там, где начинаются инновации, лучшие практики, критическое мышление, стратегические решения и сама постановка задачи, — роль человека остаётся ключевой. Это не замена инженера, это усиление: та же команда делает кратно больше, потому что освобождается время и ресурс.

Evolution VPN и немного «магии»: другие громкие анонсы

На конференции командой был анонсирован запуск собственного облачного VPN-сервиса — Evolution VPN. Он уже доступен пользователям в Private Preview, а до конца года выйдет в общий доступ. Задача сервиса — обеспечить защищённый удалённый доступ к ресурсам в VPC и корпоративной сети, а также упростить работу в гибридной и мультиоблачной архитектуре: подключать офис/ЦОД к облаку и связывать несколько облаков без сложной ручной настройки. Сервис ориентирован и на компании любого масштаба, и на индивидуальных специалистов — сетевых администраторов, DevOps и системных инженеров.

Что это даёт на практике: шифрование трафика на линии (конфиденциальность и целостность данных), единые правила доступа для распределённых команд и возможность собрать единую гибридную архитектуру — когда часть систем остаётся в офисе/ЦОД, а часть работает в облаке. При мультиоблаке VPN помогает свести разные площадки в централизованно управляемое пространство.

Параллельно Cloud.ru показал Magic Link — дополнение к Magic Router, которое позволяет настраивать прямые частные маршруты между ресурсами разных проектов (и даже разных клиентов) внутри Cloud.ru Evolution без выхода в интернет.

Что умеет Magic Router (и что добавляет Magic Link):

• маршруты между VPC внутри Cloud.ru Evolution;
• маршруты между VPC и on-prem инфраструктурой клиента;
• маршруты между VPC и ресурсами на платформах Cloud.ru Advanced и «Облако VMware»;
• новое (Magic Link): маршрутизация между ресурсами разных проектов и клиентов в Evolution без интернета;
• self-service-настройка в кабинете (без обращения в поддержку)

Услуга доступна в Private Preview. Выход в Public Preview заявлен до конца квартала. Настройка выполняется прямо в личном кабинете в режиме self-service, что удобно для холдингов и компаний с несколькими контурами и дочерними организациями.

Теперь о деньгах: новые цены на LLM в Evolution AI Factory

Объём российского рынка LLM-продуктов для бизнеса по итогам 2024 года составил — 35 млрд ₽. До 2028 года среднегодовой рост составит около 25%. Основная часть приходится на on-premise (~33 млрд ₽), а на облачные решения — примерно 2 млрд ₽. Средняя стоимость LLM-проекта без железа сейчас оценивается примерно в 15 млн ₽.

LLM или большая языковая модель — это нейросеть с большим числом параметров, обученная на больших массивах текстов. На практике это инструмент для прикладных задач: поддержка клиентов (чат-боты и голос), поиск и анализ документов (RAG), генерация деловых текстов и отчётов, ассистенты для разработчиков и аналитиков, автоматизация внутренних процессов через API. Поэтому стоимость токенов прямо влияет на цену экспериментов (PoC) и эксплуатацию в проде.

С 1 ноября 2025 в Evolution AI Factory вводится раздельная тарификация токенов для открытых моделей (≥120B параметров): 35 ₽ за 1 млн входных и 70 ₽ за 1 млн выходных токенов. Примеры в каталоге: GLM-4.5 — 55/220 ₽, Qwen3-235B — 17/50 ₽, Qwen3-Coder — 40/80 ₽ (ввод/вывод). Подключение — через OpenAI-совместимый API.

Наша цель — сделать цены на LLM в Cloud.ru максимально доступными в России и сопоставимыми с глобальными провайдерами. Так компании смогут брать модели в работу, тестировать их и быстро решать, внедрять ли их в продакшн.

EDP запущена в прод: данные, пайплайны и аналитика в одном контуре

Весной на конференции GoCloud команда представила ядро будущей Evolution Data Platform (EDP). Осенью платформа вышла на новый этап: Evolution Data Platform перешла в коммерческую эксплуатацию. Теперь большинство сервисов доступно для промышленного применения — от базового хранения и обработки данных до построения сложной аналитики и визуализации. Ключевое изменение — все data-сервисы разворачиваются в едином кластерном окружении на общем платформенном слое. Это снижает объём ручной интеграции, ускоряет сборку сквозных пайплайнов и, по оценке компании, даёт до 40% экономии инфраструктурных затрат за счёт автомасштабирования и автоматизации рутины.

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

• Единый управляемый контур для: Evolution Managed Metastore, Spark, Trino, BI, Airflow, ArenadataDB; плюс управляемые БД и Object Storage.
• Прямая интеграция с AI Factory — данные из EDP без лишних прослоек уходят в AI-сервисы.
• Масштабируемость и отказоустойчивость за счёт базы на Kubernetes.
• Оплата по потреблению (pay-as-you-go).

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

До конца 2025 года Cloud.ru планирует перевести в статус General Availability (GA) — то есть в общую коммерческую доступность для продакшена — сервисы Evolution Managed Metastore, Spark, Trino и ArenadataDB, тогда как Evolution Managed BI и Evolution Managed Airflow останутся в режиме Preview — предварительном режиме (по аналогии с другими анонсами Cloud.ru, где Preview может проходить стадии от Private к Public).

Тренды в AI: быстрый инференс и «маленькие» доменные модели

По просьбе редакции мы попросили Дмитрия Юдина назвать самые интересные и важные тренды в области AI — которые уже влияют на продуктовые команды.

Я вижу два практичных тренда.

Первый — оптимизация инференса: снижение разрядности (low-bit), цепочки обработки и, как результат, заметный прирост скорости при приемлемом качестве.

Второй — уход к Small Language Models: небольшим, доменным моделям под конкретные задачи. Они дешевле в эксплуатации и дают лучший результат в своей нише.

Логика простая: вместо одной “всеобщей” модели — несколько маленьких, каждая под свой кейс. Такой подход позволяет быстрее и экономичнее доводить решения до продакшена.

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

Сейчас большая часть наших решений — инструменты для разработчиков, но мы целенаправленно двигаемся к продуктам, понятным и бизнес-пользователю. Идея простая: зайти в платформу, собрать из готовых инструментов свой сценарийи сразу улучшить, например, поддержку. Это особенно важно для малого и среднего бизнеса, где нет глубокой AI/ML-экспертизы.

Tproger также выяснил, в каких сферах бизнеса внедрение AI даёт наибольшую отдачу.

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

• Продажи и маркетинг: в компаниях с большим объёмом клиентов AI помогает автоматизировать рутину (чат-боты, персонализированные предложения, скоринг лидов). Здесь важно, что AI ускоряет воронку и снижает нагрузку на сотрудников.

• Операции и цепочка поставок: в производстве и ритейле приоритет — оптимизация логистики, прогнозирование спроса и управление запасами. AI может снижать издержки за счёт более точного планирования и предотвращения сбоев.

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

• R&D и продукт: в фарме, IT и инженерии AI используется для ускорения исследований, симуляций и генерации новых решений.

То есть внедрение AI — это не универсальный рецепт, а скорее выбор наиболее «узкого места» или наибольшего источника ценности в конкретной индустрии.

И напоследок — про сообщество

На GoCloud Tech объявили грантовую программу «Код без границ» от Cloud.ru, СберТех и Хабр для open-source проектов: четыре номинации, денежные гранты, облачные ресурсы и менторская поддержка. Для участия репозиторий должен быть на GitVerse (есть импорт «в один клик»). Сбор заявок: 3 сентября — 31 октября 2025; отбор: 1–30 ноября; итоги: декабрь 2025. Победители получат не только финансирование и инфраструктуру, но и доступ к профессиональному комьюнити — шанс ускорить развитие и найти единомышленников.

Итог. В этом году Cloud.ru связал воедино три линии — данные (EDP), модели (AI Factory и новые цены на LLM) и практику агентов («Клаудия») — плюс дал «сетевые мосты» (Magic Link и Evolution VPN). Для команд это открывает возможности быстрее переходить от эксперимента к промышленной эксплуатации,

PlatformCraft PC‑media: облачная платформа для видео

PlatformCraft PC‑media — российская видеоплатформа для бизнеса, которая позволяет хранить, транслировать и монетизировать видеоконтент. Сервис поддерживает адаптацию видео под любые устройства, защищает контент от копирования, есть брендированный HTML5-плеер и сбор детальной статистики просмотров. Что предлагает платформа:

Гибкость и безопасность. Развернуть решение можно как в облаке (через инфраструктуру PlatformCraft), так и в виде On-Premise установки в своей сети. Это соответствует регуляторным требованиям, предъявляемым к сервисам госсектора, банковских услуг, телекома и других отраслей. Например, в рамках 152-ФЗ (или регламентов ФСТЭК/ФСБ) on-premise — единственный допустимый вариант. Важно, что видео не покидает контур организации: хранение, обработка и трансляция происходят исключительно внутри локальной инфраструктуры клиента.

Полный контроль над инфраструктурой. Клиент сам управляет серверами, хранилищем, сетевыми настройками и масштабированием. Это позволяет точно прогнозировать расходы, минимизировать зависимость от внешнего облака и обеспечивать нужную производительность в пиковые периоды. Даже при отключении интернета или проблемах с доступом к внешним провайдерам, on-premise продолжает работать в замкнутом режиме. Такой вариант идеально подходит для организаций с критически важными задачами, например, для трансляций внутри закрытых корпоративных сетей.

Также PlatformCraft можно настроить под специфические требования: собственные политики доступа, нестандартные интеграции, уникальные интерфейсы. В отличие от типового SaaS-решения, где пользователь ограничен предоставленным API, здесь возможны доработки ядра под заказ. On-premise можно сочетать с облачной инфраструктурой PlatformCraft: например, использовать локальный сервер для хранения оригиналов и облако для трансляции.

Полностью российская разработка. PlatformCraft входит в реестр российского ПО, а само решение развёрнуто в трёх дата-центрах на территории РФ. Используются 5000+ узлов CDN для мгновенной раздачи контента по всему миру. Разработка, не подвержена санкционным рискам и блокировкам. Изучить документацию можно здесь, также доступна видео-инструкция по работе с личным кабинетом.

Где можно применить PlatformCraft PC‑media:

• медиакомпании: OTT-сервисы, онлайн-кинотеатры, телеканалы;
• образовательные проекты, EdTech платформы;
• корпоративные видеопорталы;
• государственные компании;
• финтех, телеком и другие чувствительные отрасли, где требуется надёжное хранение и вещание видео. Например, с помощью PC‑media можно быстро развернуть собственный сервис наподобие YouTube со всем необходимым функционалом: от загрузки роликов до их воспроизведения на сайте или в приложении.

Для разработчиков и интеграторов PlatformCraft предоставляет официальную документацию, а также готовые примеры использования API. Кроме того, команда PlatformCraft подготовила видео-гайд по работе с обновлённым личным кабинетом (ролик можно найти на Yandex.Диске по ссылке, указанной в документации) — это помогает быстро освоиться в интерфейсе платформы.

Рассчитать стоимость медиа-хранилища, CDN, S3 хранилища и других услуг можно в удобном калькуляторе. Там же можно оставить заявку для более точного подсчёта.

Реальные кейсы: опыт клиентов PlatformCraft

Мы нашли несколько клиентских кейсов PC‑media из разных отраслей:

• Социальный онлайн-проект «Бессмертный полк». Это памятная акция федерального масштаба, в онлайн-шествии которой участвуют миллионы людей. В 2020 году мероприятие впервые прошло в цифровом формате: пользователи загружали карточки с фотографиями ветеранов и их именами, а на выходе формировался единый видеопоток. Всего было обработано более 2 миллионов карточек, а стрим шёл непрерывно почти 20 суток (более 19 дней без единого перерыва). Размер каждого сформированного видеофайла составлял до 20 ГБ, поэтому для загрузки использовался SFTP-протокол, а полученные файлы сегментировались в HLS-поток для трансляции. PlatformCraft обеспечила надёжное объектное хранилище (S3) для приёма этих файлов, сформировала из них бесшовный плейлист и опубликовала поток через CDN, выдержав огромную нагрузку по просмотрам. В реализации принимала участие сторонняя команда (Aventica), ответственная за приём и модерацию карточек, а PlatformCraft отвечала за непрерывность эфира и масштабирование под миллионы зрителей. В результате организаторы акции получили бесперебойный онлайн-марафон памяти, сэкономив до 40% затрат по сравнению с развёртыванием собственной инфраструктуры видеостриминга и её круглосуточным сопровождением.
• Крупная медиакомпания (телеканал), аудитория — сотни тысяч зрителей в России и СНГ. Столкнувшись с ростом онлайн-потребления (фильмы, телепередачи) и постоянной нагрузкой 24/7, компания обнаружила, что её собственных ресурсов не хватает: трансляции начали тормозить, серверов не хватало, расходы на поддержку росли. Ежемесячно инфраструктура обходилась примерно в 1,6 млн руб. (серверы хранения и раздачи, сетевое оборудование, каналы связи, штат инженеров и т.д.). PlatformCraft предложила перевести вещание в облако. Всего за 65 тыс. руб. в месяц клиент получил облачное хранение 20 ТБ видео в трёх ЦОД, раздачу ~80 ТБ трафика через CDN, брендированный HTML5-видеоплеер, транскодирование потоков в нужные качества, приём сигнала со спутника и защиту контента от скачивания — плюс техническую поддержку 24/7. Экономия составила колоссальные 2357%: вместо миллионов на собственные серверы компания стала платить десятки тысяч за облако. При этом скорость загрузки и масштабируемость выросли в разы — глобальная CDN-сеть PlatformCraft обеспечила мгновенную отдачу контента пользователям на любых устройствах. Зрители этого телеканала смогли смотреть прямой эфир и видеотеку без лагов, а медиакомпания избавилась от головной боли с инфраструктурой, фокусируясь на контенте.
• Viju — OTT-видеосервис (онлайн-кинотеатр). Проект рассчитан на десятки тысяч одновременных зрителей в СНГ и по всему миру, предоставляя просмотр видео по запросу (VoD) и прямые эфиры. Объём контента у Viju огромный: отдельные видеофайлы достигают 100 ГБ, запись трансляций должна храниться несколько месяцев, а ежедневный трафик раздачи — сотни терабайт. Вместо того чтобы инвестировать десятки миллионов рублей в собственную IT-инфраструктуру, сервера хранения и доставки, разработку ПО и найм штата специалистов, Viju выбрали PlatformCraft PC‑media. Облачная платформа предоставила им мультиреплицируемое хранилище для контента (с резервированием копий в нескольких ЦОД), удобную чанковую загрузку больших файлов с докачкой (важно при 100-гигабайтных объёмах), автоматическое транскодирование видео в необходимые форматы, раздачу через распределённую CDN, защиту потоков с помощью DRM и токенов, а также API для интеграции с собственным интерфейсом и сбора статистики. ROI: благодаря модели SaaS, Viju полностью отказался от капитальных затрат на железо и софт, сократив операционные расходы на хранение, распределение контента и разработку функционала на десятки миллионов рублей. Кроме того, запуск сервиса удалось осуществить значительно быстрее — без длительных закупок оборудования и найма команды, необходимых при создании «с нуля».

Масштабирование с PlatformCraft

PlatformCraft справляется с нагрузками любого масштаба — от разовых акций с миллионами участников до непрерывного вещания телеканалов и крупных онлайн-кинотеатров. В качестве критериев выбора этого решения клиенты указывают экономию расходов, отказоустойчивость (непрерывный эфир без простоев) и оперативную поддержку со стороны команды PC‑media.

«Часто недооценивают сложность масштабирования — особенно при росте трафика и количества одновременных зрителей. Мы закладываем отказоустойчивость и гибкую архитектуру с самого начала, чтобы избежать “узких мест”», — говорит ведущий инженер по инфраструктуре PC‑media. Масштабируемость и надёжность становятся критичными, когда аудитория измеряется тысячами и миллионами, поэтому опыт PlatformCraft в высоконагруженных системах позволяет предусмотреть проблемы заранее.

Альтернативные решения на российском рынке

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

Kinescope

Kinescope — профессиональная онлайн-видеоплатформа для бизнеса, появившаяся в 2020 году. По сути, Kinescope предоставляет сервис, очень близкий по идеологии к PlatformCraft: это готовое SaaS-решение, позволяющее загружать, хранить и транслировать видео через интернет. В функционал Kinescope входят: DRM-шифрование для защиты видео от скачивания; встроенная CDN-сеть для доставки контента; брендируемый HTML5-плеер с настройкой дизайна; поддержка Live-трансляций и вебинаров; аналитика просмотров и API/SDK для интеграции.

Разработчики Kinescope отмечают, что начать пользоваться их платформой можно за считанные минуты — интерфейс максимально упрощён для массового пользователя, а при необходимости есть инструменты командной работы (разграничение ролей доступа к контенту, совместная модерация и пр.). Kinescope гордится тем, что обслуживает крупных клиентов: так, через эту платформу хранят и показывают видео Нетология, Авито, Газпром, сети ритейла и многие другие. По сути, Kinescope позиционируется как «Vimeo для бизнеса по-русски» — то есть безопасный видеохостинг с возможностью встраивания плеера в любые сайты и приложения, нацеленный на корпоративный сектор.

Основные отличия Kinescope от PlatformCraft заключаются в модели предоставления и степени готовности решения. Kinescope существует только в облачном формате (SaaS) — собственного on-premise варианта для локальной установки у клиента они пока не предлагают. Кроме того, Kinescope долгое время делала упор на удобство именно VoD-контента (видеоуроки, маркетинговые ролики, архивы и т.п.), хотя сейчас у них тоже есть live-стриминг и даже поддержка рестриминга на внешние площадки.

С технологической точки зрения о внутренней «начинке» Kinescope известно не очень много — разработчики заявляют об использовании облачных хранилищ и CDN (расположенных по всему миру), однако не раскрывают деталей. В интервью и материалах компания подчёркивает простоту интерфейса и богатые возможности кастомизации плеера (логотип, цвета, аннотации, субтитры и даже встроенные маркетинговые элементы). У Kinescope есть ограниченный бесплатный тариф, а платные планы начинаются от 500 руб./мес, плюс оплата за потреблённый трафик и хранение. Таким образом, для небольших проектов Kinescope может оказаться более экономичным на старте, тогда как PlatformCraft со своим порогом ~5000 руб./мес. ориентируется, скорее, на клиентов покрупнее.

С другой стороны, у PlatformCraft в эту стоимость сразу включается определённый пакет ресурсов и премиальная поддержка, в то время как у Kinescope расширенная техподдержка оплачивается отдельно (базовые ответы бесплатно, а профессиональная помощь — в enterprise-тарифе).

Выбор между платформами часто зависит от конкретных потребностей и масштаба: PlatformCraft делает акцент на гибкость и индивидуальные доработки (вплоть до установки on-premise и кастомизации под заказчика), тогда как Kinescope привлекает простотой и доступностью своего готового сервиса здесь и сейчас, но его функционал более ограничен.

Yandex Cloud Video

Yandex Cloud Video — ещё одно решение, о котором стоит упомянуть. Этот сервис развивается компанией Яндекс как часть их облачной экосистемы Yandex.Cloud. Цель — предоставить универсальный инструмент для работы с видео: от автоматической обработки (транскодирование, анализ) до потокового вещания и хранения контента на серверах в России.

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

Согласно пресс-релизу за август 2025, Cloud Video запущен в режиме технического теста, временно бесплатного, только по заявке для ограниченного числа компаний. Среди ключевых функций сервиса — возможность управлять доступом к контенту, например, ограничивать доступ к видео для использования только внутри компании. Также предусмотрена функция анализа статистики просмотров, которую можно визуализировать с помощью Yandex DataLens.

Уже известно, что Yandex Cloud Video умеет выполнять основные операции с видео (хранение, стриминг с низкой задержкой, базовая CDN). Используется S3 хранилище, все данные хранятся на территории РФ. В наличии SDK-плеер собственной разработки с возможностью изменения оформления. Интеграция видео — без установки дополнительных плагинов. Совместим с iOS, Android и веб-браузерами, поддерживает основные форматы файлов: MP4, AVI, MKV, FLV и MOV.

Про DRM не сказано ни слова — видимо, пока не реализовано (в Yandex Cloud Video упомянута только защита от скачивания и разграничение доступа средствами токенов). Также Яндекс предлагает выгружать статистику просмотров в их BI-сервис DataLens, это значит, что нет удобных отчетов «из коробки», нужно пользоваться внешним инструментом.

Яндекс явно строит сервис как часть облака, с возможностью задействовать его AI-модели для видео (например, нейросети для субтитров и перевода встроены уже сейчас) и с интеграцией рекламы через экосистему (указано, что Cloud Video позволяет показывать рекламу через Яндекс Рекламную Сеть на аудиторию сайта клиента). Модель оплаты тоже, ожидаемо, по потреблению ресурсов (как у всех сервисов Yandex Cloud) — пока в бете сервис бесплатен, но коммерческая версия наверняка будет тарифицироваться за объем хранения, трафик CDN, минуты транскодирования и пр., подобно конкурентам.

Из плюсов — можно ожидать глубокую интеграцию с экосистемой (например, аналитика, AI-сервисы для видео и т.д.) и привычную модель оплаты «по потреблению» ресурсов. Впрочем, пока Yandex Cloud Video — это перспектива на будущее. На сегодняшний день компании, которым нужен готовый инструментарий для онлайн-видео, выбирают между уже зарекомендовавшими себя решениями (PlatformCraft или Kinescope).

Помимо Kinescope и Yandex Cloud Video, на рынке есть и другие игроки. Например, крупные CDN-провайдеры — CDNvideo (СДН-Видео) или NGENIX — предлагают собственные облачные платформы для хранения и стриминга медиа. Эти решения зачастую ориентированы на технически подкованных клиентов: по сути, они дают в аренду инфраструктуру (облачные серверы, S3-хранилище, CDN) и набор инструментов (транскодеры, плейаут-сервисы, плееры), из которых можно собрать нужное решение.

Так, платформа CDNvideo позволяет хранить контент с тройной гео-репликацией (данные автоматически дублируются на независимых узлах) и сразу же раздавать его через глобальную CDN-сеть. Стартовый порог у подобных провайдеров может быть ниже — например, базовый пакет облачной медиаплатформы CDNvideo начинается примерно от 2000 руб. в месяц. Однако и объём услуг минимальный — всё «лишнее» оплачивается отдельно. В итоге для долгосрочных проектов удобнее полноценные платформы, где все компоненты интегрированы изначально.

Важное отличие PlatformCraft от большинства альтернатив — компания разработала практически все компоненты самостоятельно, без использования сторонних open-source решений. Это подчёркивает CTO PlatformCraft: «Мы разрабатываем собственное ПО без зависимости от сторонних open source. Это позволяет гибко адаптировать платформу под конкретные задачи клиентов — от VoD до потокового вещания с записью в реальном времени». В то время как многие конкуренты строят свой стек на базе типовых решений (например, хранилища на MinIO или Ceph, стандартные видеосерверы), PC‑media — полностью собственная инфраструктура, оптимизированная под медиа-нагрузки и соответствующая требованиям российских регуляторов. С точки зрения клиента это означает более тонкую кастомизацию и возможность получить функции «под себя», а также уверенность в том, что весь сервис поддерживается единым вендором, а не набором разрозненных компонентов.

«Большинство решений на рынке используют типовые стеки вроде MinIO или Ceph. Мы пошли дальше и создали полностью собственную инфраструктуру, оптимизированную под медиа-нагрузку и защищённую с учётом требований российских регуляторов», — подчёркивает CTO компании. Таким образом, PlatformCraft делает ставку на технологическую независимость и безопасность, что особенно важно для государственных и крупных корпоративных клиентов.

Интеграции, API и экосистема возможностей PlatformCraft

Современные видеоплатформы ценятся не только готовыми интерфейсами, но и возможностями интеграции в существующие системы. PlatformCraft PC‑media предоставляет гибкие интерфейсы доступа к своему медиахранилищу и сервисам. Доступны сразу несколько вариантов API:

• REST API — универсальный интерфейс для управления хранилищем, загрузки файлов, получения ссылок, метаданных и др. С помощью REST API можно автоматизировать практически любую операцию. Пример: интеграция с CMS сайта — когда видео автоматически выгружается на платформу после публикации статьи, и сразу получаются защищённые embed-ссылки на плеер для вставки в материал.
• S3 API — совместимый с Amazon S3 протокол объектного хранения. Это удобно, если у компании уже есть настроенные процессы резервного копирования или работы с файлами через S3: можно «переключить» их на PC‑media без переписывания кода. Фактически, PlatformCraft выступает аналогом AWS S3, но расположен в РФ и интегрирован с видео-сервисами.
• SDK для загрузки (Upload SDK) — JavaScript-библиотека для чанковой загрузки больших файлов (до 100 ГБ) с возобновлением при обрыве связи. Благодаря ей можно встроить на свой сайт или в приложение удобный загрузчик видео, который по кускам передаст файл на сервер, что предотвращает потери данных при нестабильной сети. Пример: онлайн-кинотеатр Viju внедрил такой SDK в свою студию контента, чтобы продюсеры могли загружать гигантские мастер-файлы фильмов напрямую в облако PlatformCraft без проблем с зависанием браузера.
• Streaming API — интерфейсы управления трансляциями и плейлистами. Через API можно запускать и останавливать live-эфиры, получать списки активных трансляций, вставлять заранее записанные сегменты в поток (функция плейаута), управлять таймкодами и записями эфира. Пример: телеканал использует Streaming API, чтобы по расписанию автоматически запускать подготовленный стрим (например, утренний эфир, собранный из заранее загруженных видеороликов) — платформа сама сформирует HLS-поток в нужное время.
• Token/DRM API — инструменты для организации защищённого доступа к контенту. Можно выпускать временные токены на просмотр видео, ограниченные по времени, IP-адресу, домену или другим параметрам. Также PlatformCraft поддерживает интеграцию с DRM системами шифрования. Пример: онлайн-школа выдаёт студенту ссылку на видео, действующую 24 часа с привязкой к его аккаунту — по истечении времени токен протухает, и прямой доступ к файлу более невозможен.
• Statistics API — сбор и экспорт подробной статистики: сколько трафика расходуется, какая география зрителей, какие ролики и как долго смотрят, и т.д. С помощью этого API компании могут интегрировать данные из PC‑media в свои BI-системы или строить собственные отчёты. Пример: медиахолдинг выгружает ежемесячную статистику просмотра рекламных видео с платформы и объединяет её с внутренними данными, чтобы показать рекламодателям полную картину по охвату.

Дополнительные функции PlatformCraft

PlatformCraft старается закрыть максимальный спектр потребностей внутри своей экосистемы, в которую входят:

• собственная CDN-сеть, объединяющая мощности нескольких крупных операторов, с балансировкой нагрузки между ними;
• встроенная система аналитики по просмотрам, и поддержка основных DRM для шифрования потока.

То есть клиенту не нужно отдельно заключать договор с CDN-провайдером или покупать лицензии DRM — всё включено «из одной коробки». Пожалуй, единственное, чего нет на платформе напрямую — это рекламные инструменты монетизации (например, система показа видео-объявлений).

Но PlatformCraft при необходимости поможет с интеграцией сторонних рекламных решений: существуют специальные интерфейсы для подключения AdServer или вставки рекламных ссылок в плеер. Как отмечает команда: «мы можем только рекомендовать рекламных интеграторов… Всё остальное у нас есть». То есть, если задача — просто транслировать видео по подписке или за разовую плату, PC‑media обеспечивает полный цикл — от оплаты доступа до генерации защищённой ссылки. А если нужен именно рекламный модуль с таргетингом и подсчётом показов рекламы — тут подключается внешний сервис, который встраивается в платформу через доступные интеграционные точки.

Сценарии использования: что можно построить на базе этих платформ

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

• Собственный онлайн-кинотеатр (VoD-платформа). Используя облачную медиаплатформу, любая медиакомпания или студия может развернуть свой стриминговый сервис — с каталогом фильмов/серий, системой подписки или платного доступа, защитой контента от нелегального копирования и подробной аналитикой по просмотрам. Платформа обеспечит хранение видеотеки, адаптацию потоков под устройства (Adaptive Bitrate), работу плеера на Smart TV, и интеграцию с платёжными шлюзами для монетизации. Все «кирпичики» — от CDN до DRM — уже встроены.
• Телеканал в облаке. Традиционный телевизионный эфир теперь можно вести без собственного аппаратно-студийного комплекса. Облачный плейаут в PlatformCraft или аналогичных сервисах позволяет загрузить контент, сформировать расписание вещания (сетку) и вещать онлайн 24/7 через CDN. Достаточно интернет-сигнала — и зрители будут видеть эфир на сайте или приложении канала. Это открывает возможности для региональных и тематических каналов вещать на всю страну без огромных инвестиций. В кейсах мы видели, что даже крупный телеканал перевёл часть процессов в облако ради экономии и скорости.
• EdTech-платформа для онлайн-обучения. Онлайн-школы и образовательные проекты могут хранить видео-уроки, вебинары, записи занятий в защищённом облачном хранилище, встраивать плееры уроков на свои порталы и собирать статистику успеваемости (кто и сколько посмотрел). Важно, что платформа позволяет защитить контент от скачивания — студенты будут иметь доступ только через авторизованный плеер, что предотвращает утечки платных материалов. Плюс, можно масштабировать систему под всплески нагрузки, например, когда начинается новый поток обучения и тысячи учеников одновременно смотрят введение.
• Корпоративный видеопортал/видеохостинг. Крупные компании накапливают большие архивы видео: от записей совещаний и обучающих роликов для сотрудников до презентаций для партнеров. Облачное решение позволяет создать внутренний «YouTube»: с разграничением доступа по ролям (например, отделу HR видны одни видео, отделу продаж — другие), удобным дележом ссылок с внешними партнёрами (временные ссылки на определённые материалы) и экономичным хранением огромного массива данных. В отличие от публичных сервисов, корпоративная видеоплатформа обеспечивает нужный уровень конфиденциальности и контроля доступа.
• Медиапорталы и новостные издания. Практически любое новостное СМИ сейчас сопровождает материалы видеосюжетами. Специализированная платформа позволяет публиковать видео-репортажи и стримы событий с минимальной задержкой: журналист загрузил отснятый материал — и через несколько минут готова версия в разных качествах, встроенная в статью. Через CDN-кеширование контент мгновенно доставляется читателям по всей географии, а высокая нагрузка (например, во время чрезвычайной новости) не «падает» на сервер сайта напрямую. Это повышает доступность ресурса и качество контента для аудитории.

Российские облачные платформы для видеостриминга уже сейчас способны заменить собой зарубежные аналоги, предлагая полный цикл работы с видео «под ключ». PlatformCraft PC‑media выделяется как мощное комплексное решение с упором на кастомизацию под задачи клиента и проверенной надёжностью на крупных кейсах. Kinescope привлекает простотой и быстротой старта, что важно для малого бизнеса и отдельных создателей контента. Yandex Cloud Video — перспективный игрок, за развитием которого стоит следить, особенно если вам нужна интеграция с широким спектром облачных сервисов.

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

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

В конце я расскажу о своём травматическом опыте пользования облачным сервисом. Надеюсь, это поможет кому-то избежать ошибок.

Поехали!

Где можно развернуть телеграм-бота?

Многое зависит от вашего опыта и бюджета, поэтому сначала разберёмся, где лучше всего развернуть сервис:

Локально

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

Плюсы:

• бесплатно;
• минимум настроек;
• быстрая проверка изменений.

Минусы:

• В случае, если у вас выбьет пробки при одновременном включении пылесоса и чайника, пользователи потеряют доступ к вашему сервису 🙂

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

На сервере

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

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

Плюсы:

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

Минусы:

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

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

В облаке

Сервис разворачивается в облаке по тем же причинам, что и на удалённом сервере.

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

Также облако предоставляет современную инфраструктуру для вашего сервиса: CDN, DNS, мониторинг, балансировка, очереди задач и т.д.

Плюсы:

• облако может взять на себя обслуживание серверной части (IaaS);
• облако может полностью закрыть потребности в инфраструктуре (PaaS);
• вы платите только за то, что используете;
• есть бесплатные лимиты.

Минусы:

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

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

Итого

Несмотря на высокий порог входа и отсутствие необходимости в масштабировании, нам вполне подойдет облако, и вот почему:

• Для работы бота достаточно двух базовых сервисов: Cloud Functions и API Gateway
• Фреймворк serverless полностью возьмет на себя создание функции, маршрутизацию бекенда и деплой кода в облако

Cloud Functions (облачные функции) — сервис для запуска кода в облаке. Функции запускаются при помощи HTTP-запроса или при срабатывании событий, например, записи в базу данных.

API Gateway (API-шлюз) — сервис для создания и управления доступом к API, который выступает единой точкой входа, основная задача которой это маршрутизация запросов между сервисами.

Какое выбрать облако, чтобы развернуть бота?

Из наиболее популярных облаков (AWS, Google Cloud, Яндекс, VK Cloud) я решил использовать Яндекс.Облако, и вот почему:

• проработанная документация и комьюнити на русском языке;
• удобная админ-панель, видно, что разработчики делают для разработчиков;
• бесплатные лимиты;
• нет рисков блокировки.

Что будет делать развёрнутый бот?

В качестве примера мы создадим бота, который будет принимать название крипто-тикера и возвращать его текущую цену.

Подготовительные этапы

Перед началом разработки нам нужно выполнить несколько подготовительных шагов:

• Создать аккаунт в Яндекс.Облаке
• Установить Yandex Cloud CLI
• Авторизоваться в облаке через Yandex Cloud CLI
• Создать телеграм-бота через @botfather и получить его токен

Важно: После успешного создания аккаунта вам нужно зайти в админ-панель облака и создать платёжный аккаунт. Шаг с привязкой карты можно пропустить. Далее Яндекс.Облако предоставит вам бесплатно 1 000 000 вызовов функций в месяц.

Когда вы завершите все подготовительные этапы, можно приступать к развёртыванию проекта.

Разворачиваем стартовый проект

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

• Сборщик JavaScript (vite)
• Зависимости для бота (telegraf, node-fetch)
• Команды (build, deploy)

Как только репозиторий будет клонирован, зайдите в проект и поставьте зависимости.

Вначале глобально установим фреймворк serverless:

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

Далее поставим зависимости проекта:

Деплоим проект в облако

Теперь мы готовы выполнить тестовый деплой, для этого нужно запустить команду:

Команда деплоя запустит фреймворк serverless, который прочитает кинфиг в корне проекта:

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

Как создается и управляется функция без фреймворка можно посмотреть в документации.

После успешного деплоя зайдите в админку облака и откройте раздел Функции. Там вы найдете облачную функцию, созданную согласно указанным параметрам — serverless-dev-crypto-bot

Так как функция будет вызываться вне облака (из телеграма), функцию нужно обязательно сделать публичной:

Для проверки доступности перейдите по ссылке. Если ссылка доступна, функция вернёт вам ответ:

Связываем облачную функцию и телеграм

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

В хуке нужно указать токен бота и ссылку для вызова облачной функции:

При успешной привязке бота к функции, хук вернет вам ответ:

Теперь можно приступать к бизнес-логике нашего бота.

Создаём облачную функцию

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

В нашем случае в запросе будут приходить сообщения от телеграм-пользователей. Для их получения и последующей обработки создадим хэндлер:

Это бойлерплейт-код, вносить в него изменения больше не потребуется.

Пишем бизнес логику

Далее напишем функцию для получения полного списка криптовалют и их цен с API Binance:

Затем создадим команды, которые пользователи будут отправлять в наш бот:

/start — команда для запуска бота

/tickers — получить список доступных тикеров

/price {ticker} — получить цену криптовалютной пары по тикеру

Теперь задеплоим новую версию нашей функции в облако:

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

Тестируем бота в продакшене

Открываем бота в телеграме и отправляем ему наши текстовые команды:

/start

/tickers

/price <ticker>

Поздравляю 🎉

Вы успешно создали и задеплоили бота в Яндекс.Облако при помощи фреймворка serverless.

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

Травматический опыт автора

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

Об этом следует помнить.

Когда-то давно я решил сделать парсер прогнозов по акциям. Нашёл отличное открытое API — данные обновлялись каждые 10 минут, история за несколько лет. Просто идеально!

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

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

Два-три месяца всё работало идеально. Данные собирались, я радовался, трафик на приложение рос. Я расслабился и перестал заходить в админ-панель Firebase.

Затем, в один прекрасный день, мне пришло уведомление от Firebase — он попытался снять с меня 26 842 рубля за Cloud Functions.

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

Какие выводы я сделал из этой ситуации?

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

Заключение

Развернуть телеграм-бота в облаке можно быстро, легко и без лишних вложений.

Бесплатные лимиты позволят ему беззаботно существовать, пока ботом не начнут активно пользоваться настоящие пользователи.

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

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

Облака дают гибкость и масштабируемость, но ответственность за контроль расходов лежит только на вас!

Какие сервисы вам было бы интересно реализовать на serverless-технологиях? Поделитесь идеями в комментариях! 👇

Спасибо ✨