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

“Где мои логи — в /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.

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

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

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

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

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

Привет, Хабр! На связи Илья Мартысь из Рег.облака. Сегодня расскажу, как мы переезжали в новый московский дата-центр, почему именно DataHouse «Магистральный-1» и при чем здесь серверы с NVIDIA H200.

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

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

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

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

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

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

В последнее время из общего ИИ-пузыря выделилось несколько хайповых тем:

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

С агентами всё понятно, а вот частные облака и P2P-суперинтеллект можно рассмотреть внимательнее.

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

Продолжаю цикл статей о своей команде и об облаке, которое развиваем.

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

Связка React+MobX хорошо себя зарекомендовала при работе с формами, в то время как за реактивность модели данных в Angular обычно отвечает библиотека RxJS. Но что делать, если вы хотите воспользоваться преимуществами Angular в React или Node.js? В этой статье речь пойдет о новой библиотеке от Cloud X, которую мы разработали для того, чтобы проложить “мостик” из мира Angular, где всё богато, но дорого в мир React, где все дешево, но скудно. В этой статье я описываю применение ядра @cloudx/react-ui-kit-forms, которое отвечает за структуру модели данных, реактивность модели данных и контроль состава данных (валидацию), позволяя “скрестить” плюсы React и Angular на одном проекте. 

У меня есть платформа для работы с метафорическими ассоциативными картами. Это инструмент психологов, коучей: колода картинок, вопросы, разговор. Звучит нишево, но суть задачи универсальна – авторский визуальный контент в вебе, который надо защитить от массового скачивания и пиратства. При этом контент загружают сами пользователи.

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

Когда речь идет о веб-разработке, а именно — о разработке форм, можно встретить множество мнений о том, «на чем» лучше делать проект. Очень часто React и Angular Framework рассматриваются как альтернативы друг другу. При этом выбор фреймворка — критически важный этап, который определяет дальнейшую разработку и особенности развития технологического стека компании.  

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

Привет, Хабр!
Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Несколько лет назад, пока облако росло, интеграционный слой между сервисами и брендами естественным образом усложнялся. Каждый новый сценарий требовал отдельного решения — и со временем стало понятно, что нужен общий подход.

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

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

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

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

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

Привет! Меня зовут Дима Веселов, уже три года я развиваю облачные технологии в команде Evolution App Services как техлид. Мой путь начинался с классической backend-разработки на Python, но со временем я все глубже погружался в то, как работает инфраструктура, сетевые протоколы, Kubernetes. Сегодня я хочу рассказать, как eBPF буквально в два присеста позволяет делать то, что раньше требовало невероятных усилий.

Кому будет полезен этот материал? В первую очередь разработчикам PaaS-платформ, DevOps-инженерам и архитекторам, которым тесно в рамках классического HTTP-only serverless. Расскажу, как обеспечить масштабирование с нуля для любых TCP-приложений без переписывания их кода.

Привет, Хабр!

Некоторое время назад я заметил, что #архитектура создаваемых решений сама собой структурируетcя в конвейер-пайплайн, например что-то вроде. Термин, кстати, идёт от БЭСМ-6.

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

Сейчас я переживаю бурный месяц в клауде. И с клаудами связан один интересный вопрос. Ресурсы в веб-консоли управления собраны по типам: базы, контейнеры, функции, джобы/флоу, бакеты/их фолдеры, и т. п. И возникает проблема навигации среди них. Целый день щёлкаешь по табочкам, ищешь объекты по спискам… (Кстати, надо будет перечитать что-нибудь вроде этого).

В сентябре2025 на просторах Хабра была опубликована статья «Облачные сервисы на Tcl/Tk». Спустя полчаса после опубликования появился комментарий от CloudTk-JeffSmith  , который приятно удивил меня:

Workflow Automation be like

Сегодня пост для тех, кто не наигрался в пошаговые стратегии: о Yandex Cloud Serverless Integration Workflows. Нетрудно догадаться, что это представитель обширнейшего поля Workflow Automation Tools, eg OSS: Apache Airflow/Hop, n8n to name a few. Но YC Wokflows не Open Source, конечно же. Окей, ближайший аналог, скажем, AWS Step Functions.

Одна из его характерных особенностей — использование JQ как одного из краеугольных камней. Прямо скажем, не Yandex's vibe 🚲 ⛔. Не могу сказать, что было легко с JQ, нахлынули какие-то воспоминания об XSLT (не кликайте, не надо!). В целом, конечно, работает, но у любой абстракции существует критическая точка взаимодействия с реальным миром: по отдельности $global, Foreach и сложные шаги, например, работают замечательно, но их комбинация пока является крайним случаем, где всё не совсем очевидно.

Рассмотрим пример простого вызова языковой модели:

Зачем это обывателю?

Кейсов на самом деле не мало, как минимум это бесплатно и дает возможность запускать AI без облака, чтобы ничего не отправлялось в интернет (приватность, скорость), 

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

Еще можно использовать как офлайн переводчик или объяснялку без интернета, помощника по учебе и изучения чего либо.