DevOps *

Хабр, привет! 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-инженерам и всем, кто разворачивает ИИ-агентов в кластере.

LLM‑фича может месяцами показывать хорошие метрики и при этом регулярно ошибаться на реальных запросах.

В статье разберём 7 типичных провалов в оценке качества LLM‑систем: где ломаются эвалы, почему врут дашборды и как выстроить контроль, которому можно доверять в продакшене.

Всё началось с обычного письма от хостинга: VPS слишком долго держит CPU выше 70%. Я открыл Gitea посмотреть, что происходит, а там уже был чужой репозиторий.

По логам восстановил атаку почти по секундам: регистрация, repository, diffpatch, Git hook, RCE. От первого запроса до proof прошло около 11 секунд.

А дальше обнаружился loader крипто-майнера. Покажу, как это произошло и что пришлось переделать на сервере.

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

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

Рано или поздно в инфраструктуре появляется задача автоматического обновления TLS-сертификатов. В простом случае она решается установкой certbot: один домен, один сервер, cron-задание и дальше можно не вспоминать об этом годами.

Сложности начинаются, когда инфраструктура вырастает…

Цифру «+1100%» я увидел в чужом пересказе, и это ровно тот жанр новости, после которого приходят спрашивать, что будет со сметой. Часть нашей нагрузки на DeepSeek пакетная, ее можно двигать по времени суток, так что вопрос был прикладной: насколько сильно двигать и куда.

Я открыл прайс, взял профиль своей нагрузки, перемножил. Получилось 2,3. Перепроверил на других профилях, получилось от 2,3 до 2,9. Роста в 11 раз не вышло нигде.

Дальше выяснилось, что 12,1 существует, живет ровно в одной клетке прайса из шести и весит в счете меньше 10%. А по дороге я наткнулся на вещь поинтереснее: пиковые окна DeepSeek объявил в UTC, и в московском времени они ложатся так, что из рабочего дня дорогим оказывается ровно промежуток с 10:00 до 13:00, после чего до 04:00 следующих суток все идет по дешевому тарифу.

Ниже разбор прайса, реверс-инжиниринг пиковых окон, таблица «найдите свой часовой пояс», калькулятор на 40 строк и фрагмент crontab, который сдвигает батч за 13:05.

Я делаю сервис, который разворачивает проекты юзеров на их серверах.

Разбираю на своём примере три вещи, которые нужны любому, кто просит доступ к секретам пользователя. Что просить, как хранить и что делать, когда сузить права нельзя в принципе.

Дальше практика с кодом. Почему в ключе стоит метка, почему сам ключ встречается в команде ровно один раз, и три места, где я налажал.

Кому полезно: тем, чей сервис просит доступ к секретам своих пользователей (серверы, репозитории, токены), да и в общем всем кто как-то связан с этой темой.

Пошагово собираем собственный AI-контур на VPS c зарубежным IP: подключаем ChatGPT и Claude через OmniRoute, объединяем модели в LiteLLM и настраиваем Codex, Qwen Code и VS Code для работы без VPN.

Привет! Мы в шаге от выпуска новой версии нашей игры. Число изменений в сервисах и инфраструктуре выросло кратно, все хотят уложиться в дедлайны. Каналы с алертами напоминают Красное море, а в канале поддержки всем не терпится узнать, почему упал билд, — и, конечно, немедленно его починить.

С диагностикой нам уже помогает агент из первой и второй частей — но это только полдела. Дальше начинается самое муторное: инженер должен понять, где именно нужно внести изменения, оценить, сможет ли он сделать их сам или тут нужен разработчик, найти нужный репозиторий среди десятков похожих, внести правку, прогнать её через PR и ревью. В релизный кранч эти «ещё пятнадцать минут» на каждое обращение складываются в часы, а переключение контекста добивает остатки концентрации. Знакомо? У нас это выглядело так: агент за две минуты выдаёт диагноз «в workflow не передаётся input окружения», а потом инженер ещё полчаса ищет, в каком из реюзабельных workflow это чинить.

Именно поэтому мы решили пойти дальше и дать возможность просто сказать:

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

Для платформенных команд и команд ИБ теневой ИИ на самом деле не проблема «разработчики пользуются чат-ботом». Это проблема доступа. Неконтролируемый ИИ может добраться до исходного кода, секретов, данных клиентов, облачных окружений и процессов развёртывания. Как только ИИ-системе разрешают вызывать инструменты и совершать действия, она перестаёт быть просто ПО для продуктивности. Она становится новой машинной идентичностью — с правами доступа, радиусом поражения (blast radius) и местом в вашей модели угроз.

Команда VK Cloud перевела статью, где авторы моделируют угрозы для типичного cloud-native пути поставки — от ноутбука разработчика до рабочей нагрузки, запущенной в Pod Kubernetes. Каждому этапу они сопоставляют меры контроля, которые можно внедрить уже сегодня с помощью проектов CNCF и решений с открытым исходным кодом.

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

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

Полный self-hosted стек observability (Go-приложение + PostgreSQL + ClickHouse) живёт на VPS с 2 ядрами и 2 ГБ RAM. Но сначала стоковый ClickHouse занял 12 ГБ диска при 543 КБ полезных данных, держал 900 МБ памяти и мержил 11 миллионов строк каждые 30 секунд. Разбор с реальными замерами: куда всё ушло, какая гипотеза не подтвердилась, какая ошибка уронила прод и какие настройки в итоге вернули две трети памяти.

Coding agent может написать технически правильный код и всё равно сделать неправильное изменение. Причина не обязательно в модели или промпте. Репозиторий может содержать несколько правдоподобных источников, неявный ownership, устаревшие артефакты или доказательство, которое относится не к той ревизии. Для человека часть этих противоречий компенсируется контекстом команды. У агента этого контекста может не быть.

Разбираю, почему репозиторий становится частью среды исполнения, где заканчиваются возможности AGENTS.md и файлов инструкций и как из этой проблемы появился open-source framework AIRepo.

Привет, Хабр. Я Матвей Лихота, старший Go-разработчик и DevSecOps. Как это часто бывает с внутренними инструментами, идея этой утилиты появилась уже после того, как у нас упал прод. Во время хотфикса сотрудник забыл обновить в одном из двух сервисов версию библиотеки с контрактами и в результате в зависимостях осталась предыдущая версия. Перед слиянием код собирался и тесты проходили, но после деплоя сервис упал с ошибкой 500: новое поле в структуре запроса не появилось на сервере. Пришлось откатить изменения и даунтайм был ощутимый.

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

Тогда я решил, что теперь проверять актуальность зависимостей будет CI. Так и появился Dependency Validator.

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

Другой клиент отправил в открытый Ollama-compatible API 27 тысяч реальных задач. Самый большой промпт содержал 919 тысяч символов. Модели за API при этом не было.

Я три месяца наблюдал за двумя среднеинтерактивными ханипотами — традиционным SCADA/Bitrix-стендом и поддельным AI gateway. В статье разбираю 2,5 млн событий Cowrie, стотысячный MySQL password spray, 183 сохранённых payload, массовую эксплуатацию AI API и MCP-разведку.

Высокий уровень observability в наше время — такое же необходимое условие для любого проекта, как и высокая доступность или производительность. Мы стараемся собрать и сохранить максимум метрик, чтобы понимать, в каком состоянии находится наша система и куда это состояние дрейфует. Собираем максимум логов, чтобы понимать, что происходило. Но даже когда логов и метрик настолько много, что для них собираются свои логи и метрики, иногда этого бывает недостаточно. Иногда нужно понимать не ЧТО и КОГДА, а ПОЧЕМУ.

В мире Kubernetes такой источник есть — events: именно они отвечают, почему под перезапустился, почему не смог подняться, почему не встал на ноду. Парадоксально, но эти чрезвычайно важные сведения довольно неудобно извлекать, а по умолчанию через час они уже исчезают. С этим обычно мирятся — ровно до утра, когда нужно объяснить, почему ночью упали сборки. Дальше история одного такого утра: начинается она с двух неудачных пайплайнов, заканчивается часовым окном нестабильности, задевшим 46 namespace'ов, и ни одной улики к моменту расследования в кластере уже не остаётся.

Привет всем заглянувшим!

В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.

В чем «фишка» этого подхода?

Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.