DevOps *

Каждый разработчик сталкивался с проблемой хранения артефактов: Docker-образы, npm-пакеты, Maven-артефакты, Python wheels. Вариантов обычно два — использовать публичные реестры (Docker Hub, npmjs.org, PyPI) или поднимать Nexus / Artifactory / Harbor. Публичные реестры ненадёжны из-за rate limit и блокировок. А Nexus и Artifactory — это тяжёлая Java-платформа: JVM, отдельная СУБД (OrientDB/PostgreSQL), 2–4 ГБ RAM уже в простое и десятки минут на старт.

NORA — open-source реестр артефактов на Rust, созданный как прямая альтернатива этим гигантам. Вместо Java-стека — один бинарник < 27 МБ. Вместо 2–4 ГБ RAM — < 50 МБ в простое, т.е. на порядок меньше. Вместо десятков минут на старт — 3 секунды. Внешних зависимостей нет вообще: ни Java 11+, ни отдельной СУБД — метаданные хранятся на файловой системе, а артефакты сразу можно отправлять в S3, чего бесплатные версии Nexus и Artifactory не умеют. При этом поддерживается 15 форматов: Docker, Maven, npm, PyPI, Cargo, Go, Raw, RubyGems, Terraform, Ansible Galaxy, NuGet, Pub (Dart/Flutter), Conan (C/C++), RPM (yum/dnf), Debian/APT. Плюс Helm-чарты через OCI, карантин свежих пакетов (Min Release Age), блокировка уязвимых версий (CVE Blocking) и лицензия MIT.

В этой статье мы развернём NORA в Kubernetes на Yandex Managed Kubernetes, а затем попробуем все основные сценарии использования.

Полгода назад я поддерживал TypeScript SDK для одной панели администрирования. Обычная библиотека: сгенерированный из OpenAPI клиент, авторизация, ретраи, вебхуки. И в какой‑то момент я поймал себя на том, что рутинные вопросы к панели — «у кого истекает доступ на этой неделе», «почему нода отвалилась», «сколько трафика съел вот этот аккаунт» — я решаю одинаково: открываю редактор, пишу пятнадцать строк скрипта на своём же SDK, запускаю, читаю, удаляю.

Мысль напрашивалась: SDK уже типизирован, схемы уже есть, значит модель может вызывать его сама. Так появился marzban-mcp.

Дальше выяснилось, что «обернуть SDK в MCP» — это примерно 10% работы. Остальные 90% — ответ на вопрос, который в обычной библиотеке вообще не стоит: что можно доверить модели делать с боевой инфраструктурой, а что нельзя, и как эту границу выразить в коде.

DoorDash построили внутреннюю платформу для облачных AI-агентов под названием Flux. Масштаб уже впечатляющий: за один месяц 2026 года через неё прогнали 130 000 инженерных задач, включая свыше 25 000 автоматических код-ревью в неделю и более 10 000 запусков playbook'ов из более чем 300 уникальных сценариев — всё это работает без участия человека, параллельно и круглосуточно.

Почему ушли от локальных агентов на ноутбуках

Команда описывает три конкретных ограничения агентных воркфлоу, запущенных прямо на машинах инженеров:

OpenTelemetry постепенно становится универсальным пылесосом для телеметрии. Осталось только научить его аккуратно засасывать всё то наследие, которое приложения десятилетиями складывали в файлы. В этом переводе статьи разбирается как использовать filelog receiver на практике — от простого чтения JSON‑логов до продакшен‑сценариев с настройкой производительности. Ещё больше полезных материалов я публикую у себя в авторском телеграм‑канале Мониторим ИТ. Всегда рад новым подписчикам.

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

Получатель filelog в OpenTelemetry Collector позволяет интегрировать эти логи в современный конвейер наблюдаемости. Он непрерывно отслеживает файлы, анализирует их содержимое и преобразует необработанный текст в структурированные записи логов OpenTelemetry.

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

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

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

Начнём!

У каждого, кто работает с Kubernetes, рано или поздно возникает потребность «посмотреть на кластер глазами»: кто с кем связан, почему под в CrashLoopBackOff, что изменилось за ночь, какие сертификаты истекают. Вариантов обычно два — Kubernetes Dashboard (слишком бедный) или Lens / Headlamp (десктопное приложение или тяжёлый стек с зависимостями). А kubectl-специалисты откапывают причины инцидентов в простынях YAML, где сигнал тонет в managedFields и status.conditions.

Radar — open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD, карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl.

В этой статье мы развернём Radar в Yandex Managed Kubernetes через Helm — с ingress-nginx и доменом из публичного IP — и разберём все основные экраны. Разворачиваемый инстанс — общий для команды разработчиков, поэтому конфигурация строго read-only: все write-права выключены, ИИ-агенты подключаются к read-only MCP.

Разбираемся с мониторингом и observability, metrics, logs и traces, time series, labels, scrape, TSDB, PromQL и alerting rules.

Разберём, как Prometheus получает метрики через /metrics, чем target отличается от endpoint и job, зачем нужны exporters, а также почему запуск Node Exporter в Docker требует доступа к ресурсам Linux-хоста.

UFW показывает DENY, а контейнер отвечает снаружи за 130 миллисекунд. Разбираю на стенде, почему файрвол тут ни при чём, почему популярный совет с правилом в DOCKER-USER не работает, и что об этом написано в документации Docker.

С 13 по 21 августа Anthropic выпустила восемь версий Claude Code, с 2.1.232 по 2.1.239. Разбираю по порядку, что реально приехало: fork-субагенты с наследованием контекста и фоновые спавны, переписка между сессиями через @имя и SendMessage, автопродолжение работы после сброса лимита, Auto mode как режим по умолчанию с правилами на обычном английском, research preview команды /design, переменная ANTHROPIC_DEFAULT_MODEL, стиль вывода Concise, поддержка GitLab MR и починенная память в длинных сессиях. Часть вещей я прогнал на своей машине с 2.1.239 под Linux — включая ловушку с $defaults, которая сносит единственный дефолтный hard-запрет, и расхождение changelog с реальным поведением при возврате todo-инструментов.

Для тех, кто держит или собирается держать LLM внутри контура: тимлидов, DevOps, архитекторов. Здесь конфиги, цифры и грабли, а не введение в трансформеры.

Что вы унесёте: историю пяти последовательных конфигураций с тем, что каждая дала и чего стоила; рабочий набор флагов vLLM под одну карту Blackwell; три неочевидных бага и обходы; разбор реального счёта с отношением вход/выход 452:1.

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

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

Я не программист, не девопс и не системный администратор. По диплому — недоучившийся инженер-энергетик, программировать учился сам по учебникам, команды никогда не было. При этом у меня выросли два сервера, полсотни виртуалок и десяток микросервисов. В ночь на четвёртое июня всё это едва не закончилось: кто-то зашёл на резервный сервер и снёс двадцать две виртуальные машины вместе с дисками примерно за десять минут. Разбираю по шагам, где именно я оставил дверь открытой.

Всё началось с желания организовать и автоматизировать работу с Terraform, впоследствии с Terragrunt, выстроить управляемый процесс, централизовать, настроить понятный RBAC, в общем, сделать так, «чтобы было красиво». Было сделано несколько подходов, и были рассмотрены разные варианты. Отправной точкой стало структурирование кода, его декомпозиция и рефакторинг, и постепенно дошло до автоматизации самого процесса применения (или просто plan/apply). К этому моменту основная часть кода сконцентрировалась в монорепозитории в self-hosted GitLab, общая и повторяемая логика отделилась во внутренние приватные модули, а сам код вырос в объёмах: более 4 000 .tf файлов, не учитывая внешних и внутренних модулей, более 900 проектов (каталогов), более 30 000 ресурсов, более 30 уникальных провайдеров Terraform. Конечно, все эти условия в той или иной степени повлияли на конечный выбор.

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

Привет, Хабр! Меня зовут Денис Корбаков, я технический директор «Смарт-Софт». Мы разрабатываем NGFW и регулярно разбираем, какие сетевые события можно использовать для независимого контроля автоматизированных систем. Последний год эта задача резко усложнилась. В инфраструктуре массово появился новый операционный тип машинного субъекта: автономный агент, который сам выбирает инструменты, меняет контекст и делегирует полномочия.

Zero Trust никогда не ограничивался только людьми. NIST SP 800-207 прямо включает в модель non-person entities: сервисы, приложения, автоматизированное ПО, и обсуждает их ещё с версии 2020 года. Субъект как класс не новый, новыми являются масштаб, автономность и модель поведения. Большинство корпоративных реализаций IAM на практике заточены либо под человека с интерактивной сессией, либо под стабильный сервисный аккаунт, который работает годами с предсказуемым поведением. ИИ-агент находится между этими моделями: не человек, способный самостоятельно оценить допустимый объём своих полномочий, и не полностью статичный сервис с неизменным поведением. Как отмечает исследование Cloud Security Alliance, проведённое при поддержке Aembit, существующие подходы к IAM испытывают нагрузку, на которую изначально не проектировались.

Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в draw.io и PNG. Почему диаграмма без модели быстро устаревает и как собрать архитектурный control plane из знакомых деталей: API server, графа, CMDB, diff/review и operator pattern? А может нам нужно решение с ResourceDefinition, типизированными связями, Temporal workflows и change sets.

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

DevOps-инженер Сергей Тимиряев решил эту проблему сам, без вендоров и бюджетов: за полгода в одиночку собрал ИИ-агента, который проходит весь этот путь за секунды и присылает готовую гипотезу причины прямо в Telegram. Промпт у него всего 14 строк, а две недели непрерывной работы стенда обошлись в 20%.

Как это устроено внутри, что случилось на демо с живым кластером и почему агенту намеренно не дали прав хоть что-то сломать в проде, рассказываем в конспекте с первого занятия «Вечерней школы. ИИ для инженеров» от Слёрма.

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

Хабр, привет! 30 июля во второй раз прошла инженерная конфа Kuber Community Day. 400 специалистов встретились в Москве, чтобы послушать о вызовах в Kubernetes, обменяться опытом, завести новые знакомства. Мероприятие объединило 26 спикеров в разных форматах: доклады, круглые столы, мастер-класс, научпоп и стендап. Еще конференция запомнилась экспериментальным форматом Arch Dating, в рамках которого с опытными менторами можно было обсудить технические и карьерные вопросы.

Под катом мы собрали подборку всех выступлений с Kuber Community Day'26. Скоро вернемся с новыми анонсами, первыми о них узнают участники K8s-сообщества.

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

kconmon‑ng ставит агента на каждую ноду и гоняет TCP, UDP, ICMP, DNS и HTTP‑пробы между всеми парами каждые 5 секунд, а при сбое сам снимает MTR‑трейс, пока проблема ещё жива.

К версии 2.0.0 у проекта выросла веб‑консоль: матрица N×N, расследование с ранжированием причин без ML, машина времени для разбора ночных инцидентов и алертинг, который сводит правила в настоящий PrometheusRule. Под капотом всё тот же Prometheus.

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

Эту проблему решает запуск приватной LLM в облачном Managed Kubernetes. Приватная модель гарантирует конфиденциальность и не отправляет данные во внешние сети, облако переводит капитальные затраты в гибкие операционные, а Kubernetes берет на себя отказоустойчивость и автоматическое масштабирование дорогих GPU-ресурсов. Материал будет полезен DevOps-, MLOps-инженерам и архитекторам, перед которыми стоит задача развернуть изолированную и надежную RAG-систему.

В этой статье рассмотрим, как можно задеплоить LLM в Managed Kubernetes на примере простой RAG-системы. Будем использовать LLM-роутер AIBrix, n8n и vLLM. Дополнительно понадобятся Envoy Gateway (как зависимость для AIBrix), cert-manager (выпустим сертификаты для домена n8n), Qdrant (хранилище для RAG системы) и PostgreSQL в качестве базы данных для n8n.

Команда VK Cloud перевела материал о посте Lin Sun в блоге CNCF: остаётся ли Pod правильной единицей развёртывания, идентичности и жизненного цикла для ИИ-агентов на Kubernetes. Материал будет полезен платформенным инженерам, DevOps- и SRE-инженерам и всем, кто разворачивает ИИ-агентов в кластере.