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

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 за помощь в подготовке статьи.

Привет, меня зовут Борис Хасанов, я сетевой архитектор в MWS Cloud Platform. 

Решил поделиться с вами обзором новой технологии MRC* для создания сетей для AI/ML-кластеров, так называемых backend networks. Технология интересная и перспективная — там есть магия SRv6 :)

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

* MRC — Multipath Reliable Connection, расширение RoCE-архитектуры, предложенное коллегами из OpenAI, Microsoft, Nvidia, AMD, Broadcom. Недавно вышло несколько англоязычных публикаций с его анонсом. Вот одна из них на сайте OpenAI.

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

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

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

У Брюса Уэйна есть деньги, влияние и ресурсы.

У Бэтмена — скорость, гибкость и гаджеты на все случаи жизни.

Но по отдельности один без другого не может: без Брюса неоткуда взять технологии, а без Бэтмена они не имеют смысла. Только вместе они закрывают проблемы, с которыми поодиночке не справились бы. Гибридная инфраструктура работает (примерно) так же...

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

Привет! Я Владимир Атасунц, руководитель направления Security Services в MWS Cloud Platform. В этой статье расскажу о сервисе аудитных логов — базовом инструменте облака для контроля действий с ресурсами и анализа изменений в инфраструктуре.

Разберу:

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

как он выглядит с точки зрения продуктовой модели;

какие требования легли в основу системного дизайна;

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

Пойдём последовательно — от бизнес-сценариев к технической реализации.

Привет, Хабр! На связи Алексей Тюняев, директор по облачным продуктам Рег.облака.

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

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

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

Сегодня сфокусируемся на инструментах диагностики и устранения проблем производительности в Ceph‑кластерах.

Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака.  Представим знакомую многим ситуацию. У компании есть сервер. Он работает уже несколько лет. На нем крутятся базы данных, backend-сервисы, cron-скрипты, система мониторинга. Всё настроено, всё работает, и трогать это никто особенно не хочет.

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