Облачные сервисы *

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

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

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

Привет, Хабр! На связи команда маркетинга продукта Agent Platform. Как и многие продуктовые команды, мы пристально следим за тем, что говорят о нас пользователи.

Эта статья — о том, как мы решили задачу, которая знакома, наверное, каждому продуктовому маркетологу или DevRel-у: не пропустить негатив о продукте в разных источниках, где его упомянули.

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

Да кому вообще нужен облачный гейминг?

Недавно я задался этим вопросом во время дружеской посиделки...

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

В этой статье разберемся, как запустить Wan2.2 на своем облачном сервере, сколько ей нужно памяти и какие конфиги прописать, чтобы все запустилось с первого раза. Подробности под катом!

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

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

Привет, Хабр! На связи Егор Сапун, руководитель направления сертификации инфраструктуры Рег.облака. 

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

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

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

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

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

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

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

Привет, Хабр! Мы тут в Selectel начали весну с расширения возможностей Managed Kubernetes, запустили отказоустойчивое облако и Object Lock в S3, презентовали новый продукт для высоконагруженных аналитических систем на базе Arenadata и реализовали много других полезных обновлений. Подробности под катом.

Привет, Хабр. Меня зовут Дима, я делаю WebAsk - конструктор опросов и тестов. Четыре года назад я писал тут про тотализатор на коленке, спагетти-код из 5к строк и борьбу с мобильным скроллом.

Но сегодня не про это. Сегодня - как мы дали нейронкам прямой доступ к нашему сервису через MCP, какие грабли собрали по дороге и что из этого получилось

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

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

Ранее я уже рассказывал про то, как мы выбирали SDS (Software Defined Storage), почему остановились на Ceph, а также о наших процессах в R&D. В этой статье , поделюсь, что мы поймали за год в продакшене, какие решения в дизайне кластеров оказались ошибочными, как это изменило нашу референсную архитектуру и к чему мы пришли в итоге.

Я посадил AI-агента на свой VPS и перестал открывать SSH. На сервере крутится дюжина Docker-контейнеров — клиентские проекты, SaaS, мониторинг, базы. Раньше любая мелочь требовала SSH: глянуть логи, рестартнуть контейнер, проверить место на диске.

Теперь я пишу в Telegram «память за 90%, разберись» — и через минуту получаю ответ: что случилось, что починил, сколько памяти сейчас.

В статье — реальные сценарии: SQL-запросы к PostgreSQL из Telegram, автодиагностика упавших сайтов, правка конфигов, мониторинг с авторестартом и управление задачами в YouTrack. Всё через кастомные shell-скрипты и AI-агент OpenClaw.

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

Я как всегда с аналитикой отчетов из мира IT – в этот раз в мои руки попал большой отчет MWS о перспективах IT-рынка. Как и ожидалось цифры растут от года к году:
в 2021 году рынок оценивался в 2,06 трлн рублей, в 2025-м – уже в 3,86 трлн, а в 2026 году, по прогнозу, должен дойти до красивых 4,44 трлн. Тенденция выглядит как бурный технологический рост, с преодолением ковидного и прочих кризисов. Однако ситуация (как всегда) немного сложнее – сейчас в целом меняется внутренняя природа рынка.

Возьмём рынок кэптивных IT-компаний (внутренних технологических структур, которые крупный бизнес создаёт под свои нужды, а не для открытого рынка) – его можно считать параллельной экономикой: в 2025 году сегмент оценивается в 1,964 трлн рублей против 628 млрд рублей в 2021.

Долгое время крупные корпорации для рынка были прежде всего заказчиками: они покупали софт, железо, интеграции, консалтинг, а кэптивный рынок жил тем, что продавал им технологии. Сейчас граница начала немного размываться: на 2025 год уже 21% выручки кэптивов стала чисто коммерческой. Иными словами, внутренние IT-центры крупнейших компаний начинают выходить наружу, брать внешний рынок и постепенно превращаться в самостоятельных игроков. И это только одна тенденция

Сегодня я хочу поговорить не про рост IT-рынка (цифры в отчете видны невооруженным взглядом)  а поставить вопрос из кого вообще состоит этот рынок, поскольку мы видим новый слой – внутренние технологические фабрики банков, ритейлеров, нефтегазовых компаний, телекомов и логистических гигантов. И если этот сдвиг продолжится, Россия получит рынок другой природы, где крупнейшие заказчики сами станут производителями новых технологий.

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

3-я статья из цикла туториалов о том, как можно кастомизировать свой бизнес-портал в Битрикс24.

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

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

Привет, Хабр! На связи команда виртуализации Astra Cloud. 

Мажорное обновление Astra Cloud Platform будет уже скоро (спойлер: в мае). Мы готовимся к этому основательно, но уже сейчас нам есть, чем поделиться. В частности, в составе платформы серьезно апгрейдился ключевой компонент виртуализации — ПК СВ «Брест».

Если вы администрируете системы виртуализации — этот материал для вас. Будет много про удобство, про мастера, про бэкенд и про то, как мы учитывали пожелания администраторов, когда меняли интерфейс. Готовы?)

Меня зовут Григорий Орлов, я руководитель команды разработки сетевых сервисов гибридных облаков в Yandex Cloud. В статье расскажу про детали работы наших сервисов на уровне Config Plane — это уровень, на котором пользователь может задавать целевое состояние системы. А именно речь пойдёт про CIC‑API — сервисе управления железом, которое стоит на наших точках присутствия и участвует в работе Cloud Interconnect, необходимого для создания приватных выделенных сетевых соединений.

«Где мои логи — в /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 с популярными инфраструктурными службами. 

← Часть первая

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

Цель заключалась в увеличении на 50%, до 48 VM на узел, с перспективой увеличения до 64 в будущем. То, что должно было стать задачей по повышению произвольных ограничений ПО, привело к росту вылетов и инцидентов на 50%. Проблемы масштабировались ровно пропорционально плотности.

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

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

Так как я был вернувшимся сотрудником, то пропустил обучение для новичков и получил приглашение Global Security на полдень для получения своего бейджа, но мой будущий менеджер спросил, смогу ли я прийти раньше, потому что тем утром у команды должно было состояться ежемесячное совещание по планированию.