Разработка публичных облаков *

У вас есть модель, API к ней и идея продукта с агентом. Кажется, осталось написать цикл: отправить запрос, получить tool call, выполнить его и отправить результат обратно. Можно приступать к интерфейсу?

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

Привет, Хабр! Меня зовут Игорь Цупко. Этот текст вырос из моего доклада о внутреннем устройстве агентных систем. Я буду сознательно упрощать детали: реализации у Codex, Claude Code, OpenCode и других различаются, но основные инженерные задачи удивительно похожи. Мой главный совет звучит резко: не начинайте с разработки собственного ядра агента. Ближе к концу объясню, что делать вместо этого и когда исключение всё-таки оправдано.

/

Мы уже научились писать код с помощью AI. Но гораздо интереснее другое - как именно мы встроили AI разработку в свою работу. Я попробовал вспомнить все свои наблюдения и составил небольшую небольшую классификацию - от Воина до Некроманта. Надеюсь этот опрос вас немного порадует.

Как устроен Cozystack и managed Kubernetes на собственном железе

Во время поездки в ОАЭ я случайно попал в дубайское IT-комьюнити в Telegram. Там мы внезапно скоординировались и собрали незапланированный митап. 3 октября встретились в небольшой переговорке в Дубае — получилось душевно, и мы успели обсудить много интересных тем: от Talos и хранилища до сетей и устройства managed Kubernetes.

На митапе я рассказывал о Cozystack — открытой платформе для предоставления managed-сервисов на собственном железе. Начали с обзорной презентации, но довольно быстро перешли к вопросам: почему выбрали именно такой storage, зачем нам одновременно Kube-OVN и Cilium, как устроен Kubernetes внутри Kubernetes и где проходит граница между облачной платформой и обычной виртуализацией.

Ниже — отредактированная техническая расшифровка доклада и обсуждения. Я разберу, как связаны Talos, Flux, LINSTOR, Kube-OVN, Cilium, KubeVirt, Kamaji и Cluster API; как пользовательский ресурс превращается в работающий сервис; и почему для managed Kubernetes важно отдельно обслуживать control plane, вычислительные узлы и хранилище.

15 сентября Армения на десять дней осталась без российского газа — и пережила это на иранском бартере. Именно на этой энергосистеме работают обе ИИ-фабрики из первой части: фундамент — российская труба 1988 года, иранский обмен 3 кВт·ч за кубометр и советский реактор, который продлевает Росатом. Арифметика внутри: заявленные планы фабрик съедают почти треть генерации целой страны. Плюс структура киловатта по Армстату, три вектора фактами без выводов и решатель для CTO — на что смотреть до аренды армянских мощностей.

В августе в Раздане открылась AI-фабрика Firebird: 6144 ускорителя NVIDIA B200 на 15 МВт, стройка заняла чуть больше полугода. Вторая, Eleveight, работает с июня — 512 B300 в селе Гагарин у Севана. Канал доставки чипов — легальный, американский: меморандум с Трампом, экспортные лицензии, инвестиции CoreWeave. Но главный вопрос — не «как построили», а «для кого»: на своём сайте Firebird обещает открыть 90% мощностей американским компаниям региона. Внутри — разбор обеих фабрик, история канала от VivaTech до визита Вэнса и расчёт, на кого в итоге работают армянские вычисления. Энергетический фундамент и его пределы — во второй статье.

Сколько вычислительной мощности реально у России, Казахстана и Беларуси — и что из этого доступно CTO прямо сейчас. Прайсы: аренда H100 от 342 ₽/час, серая карта от 2,65 млн ₽; порог, когда выгоднее купить, чем платить за API. Господдержка: 243-ФЗ уже в силе, пакет 71,7 млрд ₽ обсуждается, платный ЦКП — от 208 ₽/час. Казахстан строит ИИ-хаб с NVIDIA; у Беларуси — профицит атомной энергетики и тариф 0,69 ₽/кВт·ч. Шесть выводов с цифрами и первоисточниками.

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

Travel-индустрия не прощает простоев — каждая минута простоя может стоить бизнесу клиента. Как сделать так, чтобы большая инфраструктура работала 24/7 с минимальными простоями? В Туту мы пришли к мультиклауду не за один шаг. 

Привет, Хабр! Меня зовут Андрей Борзов, я в Туту работаю с 2012 года — отвечаю за то, что… сайт работает. Мои команды занимаются железом, сетью, делают облака, занимаются отказоустойчивыми кластерами ВМ в облаках, а также готовят системы мониторинга.

В этом материале по мотивам выступления на конференции K2 Cloud Conf 2026 хочу рассказать об отказоустойчивости в мультиклауде — о том, как мы строим инфраструктуру Туту, зачем используем несколько облаков и собственные площадки и что происходит, когда что-то начинает ломаться.

Облачные PaaS-сервисы позволяют использовать платформенные компоненты для построения инфраструктуры и избежать при этом лишних затрат, предоставляя сервисы в том объеме и той конфигурации, что необходимы клиенту. Одна из категорий клиентов PaaS-сервисов — разработчики ПО, и в этой статье предлагаю поговорить о том, чем использование платформенных сервисов ценно именно для разработчиков, обсудить принципы разработки Cloud-native приложений (методику 12 факторов), а также я расскажу о том, что мы в Cloud X делаем для повышения эффективности процессов создания ПО. 

Если вы хоть раз эксплуатировали Kafka, то знаете, сколько нервных клеток способен съесть её кластер. Поднять Kafka для PoC несложно, а вот дальше начинается планирование ёмкости, диски, replication factor, перераспределение партиций и восстановление после отказа брокера. 

В MWS Cloud Platform мы решили, что так дальше жить нельзя, и запустили Serverless Queue — бессерверный Kafka-совместимый брокер. Читайте статью, чтобы узнать, как с его помощью быстро и просто можно запустить сценарии обработки сообщений по Kafka-протоколу.

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде Kubernetes Security, MWS Cloud Platform. В этой статье я расскажу об одной попытке оптимизации: как мы залезли под капот CEL и Protobuf, чтобы научить интерпретатор читать данные из бинарного формата на лету без полной десериализации, и почему в итоге от этого кода пришлось отказаться.

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

Далее эти данные проходят через различные валидации и проверки. Для описания и выполнения таких политик мы используем CEL — наподобие Kyverno или нативных k8s Validating (и Mutating) Admission Policies. Вот тут-то Protobuf и CEL встретились, и эта встреча оказалась не такой гладкой, как мы рассчитывали, — об этом подробнее ниже.

Привет! Меня зовут Ренат Ахмеров, я один из руководителей направления по работе с виртуальными сетями и сетевыми функциями в MWS Cloud Platform. В этой статье я рассказываю про сетевые возможности нашей облачной платформы, приправляя рассказ своей личной историей взаимоотношений с компьютерными сетями. 

Чтобы наглядно объяснить, как работают сети в нашем облаке, мы рассмотрим по шагам построение некой e-commerce системы: от примитивного решения в одной «коробочке» до полноценной Enterprise Grade-архитектуры.

Всем привет! Я Андрей Халиуллин — руководитель направления IAM & Security Services в MWS Cloud Platform, и мы продолжаем делать облако. В этот раз хочется поговорить о стабильности, отказоустойчивости и прочих SLO. В этой статье расскажу, как мы обеспечиваем свою отказоустойчивость, как мы её тестировали (спойлер: мы отключили целую зону доступности) и что нового для себя узнали. Для наглядности решил объяснить наш подход на примере швейцарского сыра.

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

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

Сегодня Kubernetes стал де-факто стандартом для развёртывания SaaS-приложений и сервисов. Практически каждый разработчик работает с ним ежедневно, но большая часть этой работы связана с установкой уже готовых компонентов и манифестов. Если базового функционала начинает не хватать, возникает потребность в расширении. И вот тут начинается путешествие в уникальный мир k8s-операторов.

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

Меня зовут Антон Железнов, я разработчик в команде Managed Kubernetes облака MWS Cloud Platform. И в этой статье я хочу рассказать о тестировании операторов не на абстрактных примерах, а на устройстве нашего решения. Итак, поехали! 

Всем привет! Меня зовут Кирилл, я много лет занимался системами биллинга для Облаков и инфраструктур, например, именно моя команда построила большую часть механик тарификации и FinOps для Yandex Cloud — от сложных statefull скидок и резервов, функции экспорта данных в Object Storage, заканчивая детализацией по лейблам и продвинутой аналитики в DataLens. Все это на масштабах более 10 миллиардов событий тарификации в день.

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

Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина в новой для себя области. Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.

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

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

В статье расскажу, почему.

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

Меня зовут Алексей Баранов, я — руководитель направления Data Storage Systems в MWS Cloud Platform, и в этой статье я расскажу, как строим блочное хранилище в нашем облаке, с какими вызовами встречаемся и как их решаем.

В облачных сетях принято разделять два уровня: физический Underlay и виртуальный Overlay. Если Underlay — это фундамент здания (кабели, коммутаторы, базовая IP-связность), то Overlay — инженерные коммуникации: невидимые глазу, но без которых жизнь в доме остановится. От того, насколько эффективно и надёжно спроектирован Overlay, напрямую зависят скорость пользовательских приложений и стабильность всей платформы.

Привет! Меня зовут Валерий Симаков, я разработчик команды Network DPL в MWS Cloud Platform. Сегодня мы подробно поговорим о сетевой составляющей нашего облака, а именно об устройстве Data Plane (DPL) в Overlay-слое — том самом слое, который и отвечает за передачу пользовательского трафика. Мы разберём, как из разрозненных компонентов рождается единый, слаженный механизм передачи данных. Благодарю коллег из команды Network DPL за помощь в подготовке статьи.