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

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

Многие знают нас как разработчиков Cozystack. Но помимо него в Ænix мы разрабатываем платформу для запуска публичного облака под ключ: с биллингом, проектами, self-service, поддержкой разных бэкендов, включая тот же Cozystack, и интеграциями с внешними системами.

Эта платформа целиком построена на Kubernetes, причём в самом буквальном смысле. Её бэкенд реализован на Kubernetes API Aggregation Layer и controller-runtime, собственные ресурсы хранятся в etcd-кластерах под управлением нашего etcd-operator, а единственная реляционная база данных — Postgres для Keycloak — работает под управлением CNPG-оператора (CloudNativePG). Своего хранилища состояния, своего механизма выбора лидера и своей репликации у платформы нет: всё это она получает от Kubernetes.

Архитектура Kubernetes позволила нам достичь элегантной схемы, где нам не требуется даже реплицируемое хранилище. Никакого DRBD, Ceph или синхронизации дисков между площадками: каждый член etcd и каждая реплика Postgres живут на своём локальном томе, а данные между площадками переносят сами etcd и Postgres своими механизмами репликации. Им в любом случае приходится договариваться о том, какая копия главная, и делать то же самое ещё раз уровнем ниже было бы лишним. К тому же блочная репликация между городами добавляла бы задержку к каждой записи и ещё один слой, который пришлось бы отдельно учить переживать разрыв связи.

Такой дизайн мы выбрали не случайно. Kubernetes с самого начала проектировался с расчётом на отказоустойчивость: декларативное состояние хранится в etcd с кворумом, контроллеры приводят систему к нему после любого сбоя, всё, что должно работать в одном экземпляре, использует leader election, а пробы убирают трафик с больных подов. Если построить весь бэкенд на этих механизмах, отказоустойчивость платформы в теории достаётся почти бесплатно.

Забегая вперёд скажу, что на практике Kubernetes оказался готов к этому куда меньше, чем принято считать, и многое нам пришлось достраивать самим.

Привет! Меня зовут Александр Пивкин, я ведущий SRE-инженер в MWS Cloud Platform. Сегодня я проведу вас по короткому пути через дебри подкапотного устройства бинарных файлов и покажу, какую пользу можно извлечь из этого знания применительно, например, к SDS Ceph. Сразу отмечу, что пишу я эту статью параллельно с написанием собственно трейсера. То есть даже можно сказать, что вы наблюдаете процесс исследования и создания готового решения в прямом эфире. 

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

Всем привет, меня зовут Вадим Лазук, я разработчик в команде VPC облака MWS Cloud. Пару месяцев назад мы запустили в Preview сервис Network Load Balancer, а в этой статье решили рассказать о нём подробнее. Сегодня рассмотрим, как устроен балансировщик в нашем облаке, на какой архитектуре он базируется и какие технологии использует под капотом.

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

Я столкнулся с этим, когда занимался проектами, которые собирают сведения об инфраструктуре и управляют ею через API. Сначала хотел сделать небольшой инструмент для собственных тестов, чтобы реже зависеть от лабораторного Proxmox. В результате появились четыре проекта: симуляторы API Proxmox VE, OpenStack, VMware и oVirt.

У вас есть модель, 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 миллиардов событий тарификации в день.

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