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

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

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

Привет, Хабр! Меня зовут Даниил Оларь, я разработчик в команде продукта MWS Tables — платформы для лёгкой автоматизации и совместной работы на базе таблиц. 

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

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

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

В материале расскажу, как устроена каждая таблица и как настроена связь между ними. 

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

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

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

Привет, Хабр! Меня зовут Александр Бардаш, и я CTO интеграционной платформы MWS Octapi. В одной из предыдущих статей я рассказывал, как мы выбирали движок для low-code и почему остановились на Temporal, отказавшись от Apache Camel. С тех пор регулярно получаю один и тот же вопрос — от продактов, аналитиков, а иногда и от коллег-архитекторов: «Подождите, ну сейчас же есть Karavan, Kaoto, нормальные визуальные редакторы. Аналитик там накидает кубики, настроит логику, разве это не cделает Camel доступнее?» Короткий ответ — нет, не cделает. А вот почему, предлагаю разобрать в материале.

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

Когда серверы bare-metal, гипервизоры, облачные решения и десятки Kubernetes-кластеров живут вместе, навести порядок в ИТ-инфраструктуре становится задачей со звёздочкой. К тому же к гибридной инфраструктуре добавляется организационный слой: десятки автономных команд — backend, UI, data engineering, ML, platform — и у каждой свой бэкграунд, уровень зрелости и разный подход к описанию инфраструктуры через код (IaC).

Кто-то всегда пишет на HCL, кто-то предпочитает Python и JS, а кто-то привык работать с docker compose up –d. Задача инженера платформы в такой обстановке не в том, чтобы навязать «серебряную пулю», а в том, чтобы найти инструмент, который обеспечит контроль над состоянием инфраструктуры, позволит стандартизировать базовые паттерны, предсказуемо реагировать на изменения, которые внесли вручную, а еще не будет ломать уже существующие процессы.

Привет, Хабр! Меня зовут Вячеслав Швецов, я архитектор в команде MWS B2B Store. Это первый материал из цикла о построении инженерной платформы в гетерогенной среде. Мы будем разбирать инструменты, антипаттерны и ограничения при эксплуатации. В этом выпуске сравним подходы Terraform и Pulumi, а также рассмотрим управление состоянием, детекцию дрейфа инфраструктуры и практику управления инфраструктурой как кодом.

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

Меня зовут Алексей Баранов, я — руководитель направления 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.

Привет, Хабр! Меня зовут Сергей Клюев, я техлид команды, которая занимается внедрением ИИ на платформе MWS Octapi.

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

По мере расширения возможностей ИИ-ассистента нам понадобилось множество интеграций. В MWS Octapi уже более 700 интеграций (OpenAPI, SOAP, AsyncAPI, GraphQL и другие). Мы решили переиспользовать их, внедрив на платформу протокол MCP. Добавление поддержки MCP позволило превратить привычные API в «руки» для ИИ и быстро интегрировать ИИ-агентов в ИТ-ландшафт.

Про возможности протокола MCP и особенности его внедрения в Enterprise среде — далее под катом. Эта статья — текстовая версия вебинара. Видеоверсия доступна по ссылке.

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

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

Разберу:

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

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

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

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

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

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

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

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

Знаете, бывают технологии, которые изучаешь — и сразу понятно, куда шли и чем закончили, но OpenStack — это не просто технология, это целая эпоха. Причём такая, где на одной временной шкале у тебя NASA, Rackspace, Mirantis и Red Hat и десятки других крупных компаний, каждая из которых решила, что надо объединиться чтобы сделать свой, «домашний» AWS.

Кстати, да, меня зовут Эдгар Сипки, я девелопер-адвокат в MWS Cloud Platform, и сегодня мы поговорим об OpenStack.

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

Привет, Хабр! Меня зовут Сергей, я занимаюсь исследованиями в MWS и руковожу небольшой, но классной командой инженеров-исследователей. Пока одни с помощью ИИ-агентов ищут способы разгрузить рутину, мы в MWS смотрим дальше и видим больше. А что, если дать ИИ-агенту не только «руки», чтобы бродить по сети и нажимать кнопки в интерфейсе, но и «тело»?  

OpenClaw может физически взаимодействовать с реальным миром даже с помощью устройств «без мозгов». В этом материале разберём, как максимально просто развернуть такую систему самостоятельно. За помощь в подготовке спасибо Артёму @Artem_Lykov из центра R&D TechGov, который отвечает за направление Physical AI в MWS, и стажёру Дмитрию Ярчуку.

За время работы в облаке я убедился в одной простой вещи: сколько бы сервисов ни предлагало облако — Kubernetes, Serverless, базы данных, Big Data или AI-сервисы, — всё это работает только потому, что под ними есть прочный фундамент: виртуальные машины, диски и сети. Этот фундамент и называется IaaS. Он важен и для клиентов, и для самого облачного провайдера: все сервисы строятся поверх него, а уровень этой базы определяет надёжность и скорость создания сервисов.

Всем привет! Меня зовут Родион Цалкин, TPO в MWS Cloud Platform. Сегодня поговорим о IaaS-слое. 

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

Как мы проектировали физическую фабрику и overlay-сеть на SRv6 — отдельная статья про архитектуру сети.

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

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

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

За окном 2026 год, а компании по-прежнему взламывают через незакрытые уязвимости. При этом управление уязвимостями часто сводится к нерегулярному скану и надежде, что «пронесёт».

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

Привет, Хабр! Я  Виктор Бобыльков, директор по кибербезопасности МТС Web Services Cloud, где помогаю строить нашу собственную платформу и делать Security-процесс прозрачным и удобным.

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

Мы пройдём по пяти уровням зрелости — от базового сканирования до автоматизации, whitebox-подхода и специфики KPI. Размер компании не имеет значения — подойдёт как для небольшой команды, так и для бигтеха. Заодно вы сможете свериться, где находитесь сейчас и какие шаги впереди.

Привет, Хабр! Я много лет работаю в системной интеграции и занимаюсь внедрением различных проектов в области ИТ и ИБ. Меня попросили написать технический обзор MWS Container Platform, так что ловите то, что получилось. В этом материале подробно поговорим о стеке наблюдаемости (observability) и рассмотрим несколько практических кейсов по обнаружению проблем средствами стека. 

Добрый день! Меня зовут Роман Помазанов, я руковожу командой Global Network Fabric в MWS Cloud Platform. Сегодня я хочу рассказать о  фундаменте, который обычно остаётся в тени, когда говорят об облачных платформах. Речь пойдёт не о виртуальных машинах, контейнерах или системах хранения, а о том, что заставляет всю эту сложную машинерию работать как единое целое, — о сети.

Если представить облако как живой организм, то сеть — это его кровеносная система. Это та самая инфраструктура, которая связывает вычислительные ресурсы, системы хранения, сервисы безопасности и подключает всё это к внешнему миру — к интернету. Без её бесперебойной и предсказуемой работы ни один сервис, ни одна виртуальная машина просто не смогут функционировать. Хотя я, конечно, лукавлю — функционировать-то сможет, но только диск будет в read-only режиме, он же сетевой :) 

В этой статье я подробно расскажу об Underlay-сети — том самом физическом фундаменте нового облака MWS. Мы разберём, почему мы приняли стратегическое решение спроектировать её с чистого листа, отказавшись от следования традиционным, зачастую излишне сложным вендорским подходам. Поговорим о принципах, которые легли в основу архитектуры: простоте, отказоустойчивости и масштабируемости. И наконец, заглянем «под капот»: посмотрим на leaf-spine фабрику, на протоколы BGP и IPv6, которые стали её нервной системой, и на то, как мы управляем этой сложной распределённой системой с помощью автоматизации и мониторинга.

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