Не шучу, правда довели. Одни уходят, другие замедляют. И у меня начала мелькать шальная мысль: а что, если взять и поднять свой корпоративный чат?

Но я это делаю вообще в первый раз, поэтому сразу появилась гора вопросов: а с чего начать, как это спроектировать, сколько нужно серверов, нужен ли VPN, как не оставить дыру в безопасности и не собрать систему, которую потом я сам же запарюсь поддерживать?

Я Марк Ковалев, технический специалист по ИБ. И сегодня я отвечу на все эти вопросы себе и вам, а также расскажу, как поднял корпоративный мессенджер в облаке с нуля. Сильно не ругайтесь, я знаю, что решение может быть не самым оптимальным — поэтому жду советы в комментах, чтобы его докрутить и сделать круче.

Привет! На связи Наталья Нефедова — менеджер продукта и head of сообщества техписателей в Cloud.ru. 

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

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

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

В этой статье я расскажу, как начал разрабатывать персонального ИИ-ассистента задолго до бума OpenClaw, с какими фундаментальными проблемами столкнулся и почему в итоге решил написать свой фреймворк. Вы узнаете, какие принципы работы ИИ-агента, как мне кажется, наиболее важны в современных агентских системах, как он обеспечивает безопасность и почему Python все-таки лучший выбор для подобных проектов. Если вы тоже пробовали подружиться с LLM-агентами, но сталкивались с перерасходом токенов, утечкой данных или проблемами их запуска, интеграции и модификации — возможно, этот проект окажется полезным.

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

Я Саша, работаю техническим лидером в Cloud.ru уже три года, большую часть — на удаленке. Поэтому очень пекусь о своем домашнем офисе и рабочем столе. И когда натыкаюсь на интересные штуки в интернете, у друзей или коллег, то сохраняю их себе в заметки. Решил собрать самые полезные, на мой взгляд, варианты и поделиться в статье. Добавил реальный опыт использования, цены и ссылки. Enjoy.

Ваша ML-модель работает в ноутбуке, а в продакшене — нет. Бывало такое? Именно здесь начинается настоящая инженерная задача: взять эксперимент из Jupyter-ноутбука и превратить его в воспроизводимый, наблюдаемый и масштабируемый пайплайн — от сырых данных до стабильного инференса под реальной нагрузкой. Kubernetes давно стал де-факто стандартом для этой работы: более 70% компаний используют его в продакшене — это не дань хайпу, это прагматичный выбор тех, кто уже наступал на грабли.

В этой статье разберем, почему K8s выигрывает у альтернатив именно для ML-нагрузок, а также обсудим какие мифы и анти-паттерны тормозят команды на пути к продакшену. Пройдемся по полному стеку: от подготовки кластера и фиксации данных через DVC до canary-деплоя модели и автоскейлинга GPU-подов. В конце вас ждет взгляд на то, куда движется индустрия: serverless-ML, multi-LLM-ops и edge-развертывания.

Если вы DevOps- или MLOps-инженер, которому приходится запускать обучение и инференс в одном кластере, или R&D-инженер, чьи модели «магически ломаются» при переходе в прод — читать обязательно.

Мир AI-разработки стремительно движется от парадигмы «один модельный вызов — один ответ» к системам, в которых множество специализированных агентов решают сложные задачи совместно. Представьте себе оркестр, где каждый музыкант — это отдельный AI-агент со своей специализацией: один анализирует данные, другой генерирует код, третий проверяет результаты. Такие мультиагентные системы позволяют декомпозировать и задачу ускорять выполнение за счёт параллельной работы. Крупнейшие игроки — Google, Microsoft, IBM — уже делают ставку на эту парадигму как на фундамент приложений следующего поколения.

Однако путь от прототипа к работающему продукту усеян типичными провалами. На Reddit (MachineLearning) или Хабр разработчики часть жалуются: «Агенты теряют контекст при передаче задач», «Они зациклились в бесконечных дебатах, сожгли весь бюджет на токены, а результата нуль». Анализ таких кейсов показывает: дело не в «глупости» LLM или неудачных промптах. Корень зла почти всегда лежит в отсутствии грамотной оркестрации.

В этой статье я подробно разберу тему оркестрации AI-агентов с использованием протокола A2A, а также его эффективное расширение за счет AGP, чтобы показать, как эти инструменты упрощают сложные мультиагентные системы.

Принято считать, что работа аналитика — это сухие цифры, SQL-запросы и работа с графиками. Безусловно, hard skills наш фундамент, но на деле львиная доля времени аналитика уходит на другое. Это множественная коммуникация с заказчиками, упаковка пожеланий в строгие требования и последующий (а часто и параллельный) перевод этих смыслов на язык, понятный разработке. Чтобы эта цепочка не распалась, одних hard skills мало, здесь в целом нужен определенный склад ума. 

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

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

Привет, хочу поговорить об AI-агентах. Но не об их преимуществах: все и так уже знают, как они ускоряют разработку и освобождают команду от рутины. Здесь я хочу обсудить риски и новые варианты сбоев, которые появляются вместе с внедрением агентов. В реальности даже один AI-агент способен уронить проект быстрее, чем человеческая ошибка.

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

Сначала я был уверен, что мой coding‑агент просто тупит. Он игнорировал свежие требования, изредка терял файлы, а иногда даже генерировал что-то совсем уж не в тему. Потом я открыл свои старые сессии — и стало неловко, потому что во всем виноват только один из нас — я. Я увидел, как сам ломаю контекст: смешиваю разные задачи, таскаю старое ТЗ и не вычищаю ненужные хвосты, когда уже пора.

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

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

Поводом к этой статье стал гайд Sankalp Shubham про Claude Code 2.0 и мои размышления о контекст‑инжиниринге. Здесь я совмещаю мини‑перевод ключевых идей с собственной практикой, чтобы показать, как приемы из гайда переложить на работу с любыми coding‑агентами (да и на работу вообще).

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

Я Юлия Липатникова, BISO в Cloud.ru. Прошла путь от рядового специалиста до позиции, где отвечаю за связь между безопасностью и бизнесом. В этой статье я хочу поговорить откровенно: каково это — строить карьеру в кибербезе, когда ты женщина. Про гендерные предрассудки, про синдром самозванца, который на самом деле не гендерный, но бьет по девушкам почему-то сильнее. И, главное, — про то, как со всем этим работать и расти дальше.

Что, если я скажу, что для обучения AI-агентов вам вообще не нужны датасеты? Не надо их собирать, валидировать, размечать. Достаточно развернуть двух агентов на компактной модели Qwen2.5-3B или 7B, запустить их где-нибудь у себя или в облаке, дать им базу знаний и наблюдать за циклом «AI учит сам себя», попивая кофеек :)

В середине января 2026 года на Hugging Face опубликовали исследование по фреймворку Dr. Zero (DeepResearch-Zero) для самообучения агентов (ссылка на GitHub там тоже имеется). Фишка: в этом подходе агенты самообучаются с нуля без участия человека и показывают результаты, сопоставимые с полностью контролируемыми поисковыми агентами. Для вашего удобства я написал обзор исследования и дополнил его пояснениями. Приглашаю почитать обо всем этом под катом.

Привет, дорогой читатель! Меня зовут Анна. Сейчас по иронии или волею судьбы я работаю в договорном направлении и теперь-то понимаю, почему важно согласовать договор не только с самим собой, а с целым рядом специалистов, чтобы максимально защитить свои права и снизить риски. Но буквально два года назад я не придавала большого значения даже внимательному чтению договоров, и это оказался самый дорогой опыт в моей жизни. Надеюсь, дороже уже не будет.

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

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

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

Привет! Меня зовут Борис Мацаков, я Data Science инженер в Cloud.ru. Хочу поговорить о сравнительно новом направлении кибербезопасности — защите AI-систем и агентов.

Каждая команда понимает безопасность AI-моделей по-своему, а за ее основу часто берут подходы классического DevSecOps. Но проблема в том, что классический DevSecOps защищает периметр, зависимости, инфраструктуру и доступы, а атаки на модели происходят совсем в других слоях: в данных, контексте и самой логике работы модели.

Именно поэтому одних инфраструктурных мер недостаточно и для AI-агентов нужно закладывать отдельный контур безопасности поверх базовых методов DevSecOps. В еще молодой области AI-security появляются фреймворки, типологии атак и практические рекомендации, но единого стандарта и «общего ГОСТа» пока нет. Зато есть рамки, на которые уже можно опереться: OWASP Top 10 для LLM-приложений и отдельный Top 10 для agentic-приложений, SAIF-карта рисков, MITRE ATLAS как база техник атак на AI. Этого достаточно, чтобы выстроить практичную защиту и не изобретать ее с нуля. Давайте разбираться, почему DevSecOps здесь не хватает и какие контуры защиты нужны AI-системам на практике.

Привет, Хабр. Меня зовут Денис, и я люблю 3D-печать. Как и в любой компании с дружным коллективом, у нас в Cloud.ru есть много сообществ по интересам, одним из которых является кружок очумелых печатников. Со временем чат, где мы обсуждаем приемы моделирования, аспекты печати, принтеры, спорим про пластик и делимся моделями, так разросся, что кажется, пора показать немного его содержимого кому-то за пределами компании. Не пропадать же такому добру!

OpenClaw (ex. Moltbook и Clawdbot) мощно взорвал начало года. Все бросились устанавливать себе агента, и я понимаю, почему получился такой хайп. Ведь это первый в мире опен сорсный персональный AI-ассистент, которого можно подключить к мессенджеру, почте, календарю и практически чему угодно еще и он будет управлять моей личной жизнью. Ему можно поручить покупку билетов в кино, бронь столика в любимом кафе или внести важную встречу в календарь.

Другая сторона хайпа — вопросы к безопасности агента, здесь шумихи не меньше. То исследователи Gen Threat Labsнашли 18 000 открытых инстансов OpenClaw, к которым можно подключиться и управлять уже не своей, а чужой личной жизнью. То Касперский пишет, что каталог «навыков» агента стал рассадником вредоносного кода. Или вспомнить историю о том, что OpenClaw сливал данные своих пользователей через Moltbook (соцсеть для нейронок).

И что теперь, совсем нельзя пользоваться этим агентом? Я считаю, что пользоваться можно, но осторожно и лучше в облаке. Расскажу, как это сделать безопасно.

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

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

Привет, это Саша Константинов из Cloud.ru. Недавно в статье я рассказал, как после ухода Notion развернул базу знаний в облаке на Wiki-движке Outline, потому что хотел хранить данные и управлять ими самостоятельно и без ограничений, чего не может дать SaaS. И что самое главное, я хотел дорабатывать решение под свои требования.

В этой части истории сосредоточусь на том, как я еще упростил себе жизнь и добавил в базу знаний AI-помощника. Он помогает мне, когда нужно быстро просмотреть тезисы нескольких статей на общую тему или найти ответ на конкретный вопрос в документах по работе. Для доступа к базе я сделал Telegram-бота с подключением через MCP-сервер. Расскажу, как все устроено, поделюсь процессом настройки и интеграции компонентов. 

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

Как только мы получили B200, графический процессор, который по заявлениям производителя открывает новые грани производительности, гибкости и масштабируемости, то сразу побежали его тестировать. Сегодня я и мои коллеги из Evolution Bare Metal возьмем лупу SGLang и пристально взглянем на новую карту. Заходите под кат оценить, какие цифры нам покажет B200 «в бою», и узнать, чем отличается эта модель от предыдущих ускорителей, таких как A100, H100 и H200.

Привет, друзья! Меня зовут Роман Татаркин, я руководитель проектов в Cloud.ru. До этого я четыре года работал solution manager в направлениях информационной безопасности и сетевой архитектуры. В этой роли я стоял в самой гуще: мне нужно было понять реальные потребности заказчиков, обосновать требования по безопасности, перевести их на язык технических деталей и сформулировать техническое задание на реализацию.

За эти годы я видел одну и ту же ситуацию сотни раз. Поэтому мне, как и каждому IT-специалисту, знакомо чувство легкого (или не очень) раздражения, когда приходит очередное требование от службы безопасности установить DLP, переписать политики доступа, внедрить EDR...

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