DevOps *

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

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 и решений с открытым исходным кодом.