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

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

Меня зовут Алексей Баранов, я — руководитель направления 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-скрипты, система мониторинга. Всё настроено, всё работает, и трогать это никто особенно не хочет.

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

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

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

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

Разбираем, почему так происходит и как разрабатывать с ИИ эффективно.

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

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

Привет, Хабр! На связи команда Рег.облака. 16 апреля мы провели свой Демо день — продуктовую конференцию для тех, кто строит IT-инфраструктуру и хочет делать это без лишних расходов. Два параллельных трека, панельная дискуссия про ИИ с «ВкусВиллом», банком «Синара», Raft и РБК, а вечером — нетворкинг с живой музыкой в Центре событий РБК. Для тех, кто пропустил, рассказываем, что обсуждали и к чему пришли.

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub.

В первой части статьи про KNGFW мы разобрали, как собрать контур управления, связать компоненты и получить рабочую основу. Но на этом этапе NGFW всё ещё остаётся «правильно собранным железом». Оно готово к работе, но само по себе ещё ничего не защищает.

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

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

Я год экспериментировал с on-premise Copilot — прямо над нашими разработчиками, — чтобы проверить: а правда ли эта штука разгоняет разработку на десятки процентов? Делюсь реальными метриками скорости и точности, разбираю, как оно работает на примере нашей инсталляции, и показываю результаты. По пути расскажу про все подводные камни: где ИИ стал турбоускорителем, а где подставил подножку и превратился в скрытую ловушку.

Базовый сценарий: вы пушите образ в Container Registry, и ничего не происходит. Чтобы обновить Serverless Container, нужно идти в консоль и накликивать обновление контейнера. Странно, что такой автоматизации нет «из коробки», но её легко собрать на коленке.

Я прошел этот путь и упаковал всё в готовый репозиторий:

Cloud Function на Go, которая ловит события Registry.

Terraform-конфиг, который разворачивает всю обвязку.

Разбор формата событий YMQ (самая неочевидная часть).

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

Привет! Меня зовут Кирилл, я инженер команды киберзащиты облачного провайдера Nubes. В зоне моей ответственности решения сетевой защиты. В рамках запуска облака КИИ «ТУЧА» мне досталась задача развернуть и настроить NGFW для защищённого контура. В этой статье хочу поделиться практическим опытом первого внедрения Kaspersky NGFW без лишнего маркетинга, а с акцентом на те моменты, которые действительно важны при первом знакомстве с продуктом.

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

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

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

Ещё недавно, разработав Телеграм‑бота, его можно было разместить на любой VPS, и он работал. Но с недавнего времени появились региональные ограничения. Чтобы бот мог подключиться к API Telegram, его нужно разместить на VPS вне России.

В статье я предложу краткий список как российских, так и зарубежных провайдеров VPS (и не только) для телеграм‑ботов, где можно разместить бота для стабильной работы.

Сегодня обсудим развёртывание агентов, созданных в Yandex Cloud AI Studio Agent Atelier. Atelier — это такой очевидный UI для настройки PromptTemplate для Responses API.