DevOps для ДевоПсов

Ваш пайплайн знает версию образа, но не знает, какая модель выдала странный ответ

Обычный CI/CD построен на понятной цепочке: изменился код, тесты проверили, собрался артефакт, приложение поехало по средам. С ИИ-приложениями модель ломается: поведение в проде меняется, даже когда код не менялся ни строчкой.

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

Правило простое: если что-то способно изменить поведение в проде, оно должно быть версионировано и прослеживаемо. Иначе разбор инцидента превращается в гадание. Разбор перечисляет, что именно версионировать.

Buildpacks собирает OCI-образ прямо из исходников и стал Graduated в CNCF

Проект получил статус Graduated. Buildpacks сам определяет язык, ставит зависимости и раскладывает слои, поэтому Dockerfile на каждый сервис не нужен: поддержаны Java, Python, Go, Node.js и Ruby, на выходе образы, готовые к Kubernetes и совместимые с Helm и Harbor.

Аргумент, ради которого стоит смотреть, из практики: в крупных финансовых внедрениях на 500 с лишним приложений время закрытия уязвимости упало с недель до часов за счёт централизованного патча самого buildpack. Правите в одном месте, разъезжается по всем сервисам.

В контрибьюторах Bloomberg и Heroku от Salesforce, в дорожной карте OCI Artifacts, работа с SBOM и совместимость с WebAssembly.

Kubernetes 1.37 выкидывает kube-dns, IPVS и cgroup v1: проверьте три вещи до апгрейда

Релиз назвали Garhwal, в нём 67 изменений: 16 фич доведены до стабильных, 23 в бете, 27 новых альфа и одно удаление. Команда явно расставляет приоритеты в сторону готовности к продакшену, а не новизны.

Проверить до обновления надо три вещи: не остался ли kube-dns вместо CoreDNS, не работает ли kube-proxy в режиме IPVS и не сидят ли ноды на cgroup v1. Всё три уезжают, и молча это не пройдёт.

Для контекста: по январскому опросу CNCF Kubernetes крутят в проде около 82% тех, кто вообще пользуется контейнерами, против 66% в 2023 году, а 66% организаций, которые хостят генеративные модели, гоняют через него инференс. Разбор релиза.

DRA дошёл до GA, но HAMi он не отменяет

Раньше словарь для GPU в Kubernetes состоял из одной строчки nvidia.com/gpu: 1: целая карта, берите или отказывайтесь. HAMi, которого TOC принял в инкубацию CNCF 15 июля 2026 года, целиком построен вокруг обхода этого ограничения: мутирующий вебхук, расширитель планировщика, аннотации и принуждение лимитов внутри контейнера.

Теперь словарь изменился. Dynamic Resource Allocation дошёл до GA в Kubernetes 1.34 и включён по умолчанию с 1.35, а вместе с consumable capacity под может нативно попросить у планировщика долю памяти устройства, без всяких аннотаций.

Отсюда и вопрос, который задают в чатах HAMi. Короткий ответ: нет, не отменяет. Кодирование дробных запросов DRA действительно забирает себе, а вот принуждать лимиты внутри контейнера на уровне вызовов CUDA он не проектировался. Что оставить HAMi, а что отдать DRA, разобрано в материале.

Проверка подписи образа на уровне рантайма, а не admission-вебхука

Kyverno, OPA Gatekeeper и Sigstore Policy Controller работают на слое API Kubernetes: перехватывают создание пода, проверяют подписи и аттестации, пропускают или отклоняют.

Проблема в том, на чём это держится. Вебхуки зависят от явной конфигурации и от сети: криво заданный селектор неймспейсов молча пропускает проверку, отказ вебхука ставит перед выбором между блокировкой кластера и тихим байпасом, а статические поды и прямой доступ к API kubelet обходят admission целиком.

Supply Chain NRI Plugin спускает проверку на слой ниже, в сам рантайм контейнеров, через который проходит любой контейнер независимо от способа запуска. Работает и с CRI-O, и с containerd, выпускается отдельным циклом. Порядок подключения описан в статье CNCF.

Поставил CDN-кеш перед статикой, и сайт стал медленнее

Не тонко медленнее: независимый краулер до изменения отмечал 38 медленных страниц, после — 75. Автор откатил всё в тот же день.

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

Прогоните эту формулу, прежде чем ставить CDN перед малопосещаемым разделом. Разбор с цифрами до и после.

Хроника вторжения: как ИИ-агент четверо суток ходил по инфраструктуре

Hugging Face выложила технический разбор июльского инцидента 2026 года: два вектора первичного доступа, как агент закрепился и двигался вбок, и примеры команд, которые реально выполнялись. Живые учётные данные и внутренние имена хостов вымараны, техники описаны как наблюдались.

Отдельная деталь: расследование вели с помощью GLM 5.2, модели с открытыми весами. В посте есть интерактивный проигрыш кампании длиной 4,5 суток по шагам: цепочка через границы доверия, активность по фазам и записанные команды.

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

Дежурный инженер не должен работать движком корреляции

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

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

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

Когда Helm-чарта уже мало: пишем свой Kubernetes Operator

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

Первый вопрос, на который стоит ответить до кода: чем оператор отличается от контроллера и CRD и почему в вашем случае не хватит чарта, CronJob или скрипта. Руководство начинается ровно с него, а не с генерации проекта.

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

Образ с Go-сервисом влезает в 15 МБ, если не собирать его на scratch

Go компилируется в один статически слинкованный бинарник без рантайма и системных зависимостей, поэтому образ это ваш бинарник плюс пара килобайт метаданных. Там, где Node с трудом влезает в 150 МБ, Go садится ниже 15 МБ без всяких усилий.

Ключевые флаги: CGO_ENABLED=0 даёт по-настоящему статический бинарник с чистой Go-реализацией сети и DNS, -ldflags="-s -w" убирает отладочные символы и режет примерно 30% размера, а копирование go.mod и go.sum до исходников оставляет слой зависимостей в кеше между сборками.

Вывод про базовый образ неочевидный. FROM scratch работает ровно до того момента, когда понадобятся HTTPS и часовые пояса: там нет ни CA-сертификатов, ни tzdata. Distroless static везёт и то и другое плюс пользователя nonroot примерно в 2 МБ. Разбор с Dockerfile.

Четыре паттерна Docker Compose, каждый ценой вечера отладки

Полдюжины сервисов на одном VPS: база, шлюз API, пара воркеров, Redis. Compose тут очевидный выбор, вот только первые конфиги обычно собираются методом тыка.

Показателен первый паттерн, про хелсчеки. Слишком агрессивный вариант с interval: 5s и start_period: 5s перезапускает контейнер раньше, чем тот успевает подняться, и вместо диагностики вы получаете бесконечный цикл рестартов.

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

Кластер лёг целиком, а его копия в соседнем регионе трафик не подхватила

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

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

Разбор собирает все три режима на трёх кластерах GKE, с полносвязной топологией связей и хаос-тестом, который выносит кластер целиком. Скрипты лежат в отдельном репозитории.

Сходили на Deckhouse Conf 2026: собрали выжимку с конференции и ссылки на записи докладов

Сколько ресурсов на самом деле съедает безопасность кластера? Мощности под бизнес-логику при переезде в Kubernetes закладывают все, а вот про «налог» на защиту вспоминают не всегда. На Deckhouse Conf этот налог посчитали: компетенции инженеров, дополнительные вычислительные ресурсы и время на разбор ошибок.

Ещё из зала: как «АльфаСтрахование» убрала архитектурное ревью из бутылочного горлышка, зашив стандарты прямо в CI/CD. Теперь пайплайн сам разворачивает валидную среду и бьёт по рукам, если сервис не проходит по требованиям, а сеньоры не проверяют бойлерплейт вручную.

Для тех, у кого нет времени смотреть все доклады, краткий пересказ: https://tproger.ru/articles/deckhouse-conf-2026-zachem-inzheneram-samopisnyj-sdn-i-virtualki

Docker Sandboxes изолируют агента от вашей машины, но не от вашего репозитория

Смысл песочницы в том, чтобы разрешить агенту работать без подтверждений, но не на вашей машине, а в отдельной виртуалке. До хоста он оттуда не дотянется: у песочницы своё ядро, свой демон Docker, наружу она ходит только через прокси, и всё кроме HTTP и HTTPS закрыто.

Одна дверь открыта намеренно, иначе в инструменте не было бы смысла: папка проекта примонтирована в песочницу на запись. Агент правит ровно те файлы, которые открыты у вас в редакторе.

Среди них есть такие, что выполняются сами, без вашей команды. Docker перечисляет их прямо: git-хуки, Makefile, скрипты из package.json, конфиги CI и IDE. Сработает это уже на вашей машине и с вашими правами, мимо всякой изоляции. Хуки вдобавок лежат в .git/ и в git diff не показываются, так что при беглом просмотре правок вы их не увидите.

Что с этим делать. Запускать агента как sbx run <агент> --clone: тогда репозиторий монтируется только на чтение, а агент работает с приватной копией внутри виртуалки. И заглянуть в sbx policy ls — там список доменов, куда песочнице разрешено ходить. По умолчанию он широкий, вплоть до масок вроде *.googleapis.com, а это все направления, по которым из песочницы что-то уходит наружу.

#devops

Масштабируйте поды Kubernetes по глубине SQS через KEDA

Для воркеров с очередями CPU и память лгут: под может ничего не есть, а сообщений в SQS — тысячи. KEDA на EKS следит за глубиной очереди и двигает HPA вместо того, чтобы ждать, пока лаг убьёт downstream.

Ставится через Helm: helm install keda kedacore/keda --namespace keda --create-namespace. Для доступа к AWS используйте EKS Pod Identity или IRSA, затем создайте ScaledObject с триггером aws-sqs-queue. Параметры queueLength, activationQueueLength и cooldowns решают, сколько реплик запускать и когда останавливать.

При пустой очереди KEDA сокращает реплики и экономит ресурсы. Подробности по настройке — для тех, кто уже в проде.

Один sos вместо сбора логов руками

При инциденте не собирайте логи по кускам через SSH: запустите sos, ранее известную как sosreport. Один проход даёт архив с конфигурацией, логами и диагностическими данными, то есть срез состояния системы на момент сбоя.

Утилита входит в пакет sos в большинстве дистрибутивов Linux. Это открытый Python-проект, который развивается с 2009 года: изначально создали в Red Hat, позже к разработке подключились Canonical, IBM, Dell/EMC, Oracle и Linux Foundation.

На выходе — снимок для разбора инцидента, сохранённая доказательная база и единый артефакт для вендорской поддержки. Подробности о плагинах и возможностях.

GNU Binutils 2.47: что поменяется в сборочных CI

Обновите GNU Binutils до 2.47 в сборочных образах, если там линкуются нативные бинарники под Linux. Новые флаги дают контроль над размером и скоростью сборки — без переписывания пайплайнов.

Ассемблер получил --reloc-section-sym. objdump и readelf теперь поддерживают --debug-dir, а линкер BFD получил -O 0 для ускоренной линковки ценой размера. Ещё добавлены --start-lib/--end-lib и поддержка архивов без индекса символов.

Если билдите под RISC-V, в 2.47 добавлены расширения zalasr, zvabd и zvqwdota/zvfwdota. Для легаси риск: 32-битный s390 теперь считается устаревшим, а s390x остаётся.

SRE-агенты переходят от рекомендаций к автономным действиям

В классическом SRE инженер получает алерт, открывает консоль, гоняет диагностику и правит по ранбуку. Агент ИИ может съесть тот же алерт, коррелировать его с недавним деплоем и выполнить рутинное исправление самостоятельно.

Это меняет роль SRE: из «делающего вручную» в «менеджера команды агентов», которые накапливают операционную память и снижают зависимость от одного эксперта. Но работает только при одном условии — выбираете один целевой сценарий, а не натягиваете «ИИ-слой» на всё подряд.

Ещё несколько направлений, где агенты разгружают команду.

EKS теперь можно откатить до предыдущей версии Kubernetes

Amazon EKS добавил откат управляющего слоя (control plane) кластера на предыдущую версию Kubernetes в течение 7 дней после апгрейда. etcd, ворклоады и PVC сохраняются. Для кластеров в Auto Mode откатят сначала ноды, потом control plane.

Раньше обновление Kubernetes называли односторонней дверью: команды откладывали апгрейды из-за неуверенности в откате, и кластеры застревали без патчей. Теперь откат идёт пошагово — одна минорная версия за раз — после проверки cluster insights.

Если планируете апгрейд EKS, закладывайте это окно в процедуру отката. Детали на InfoQ.

ИИ-агенты уже работают в вашей инфре. Одной инвентаризации мало

Они сидят в SaaS-платформах, dev-окружениях, облачных workflow, системах поддержки и внутренних приложениях. Часть согласована, часть нет. И агенты не пассивны: рассуждают, вызывают API, лезут в данные и действуют без человека в цикле.

Реестр агентов без привязки к контролю превращается в статичный список активов. Он показывает, что агент существует, но не отвечает на вопросы: адекватен ли его доступ, кто владелец, когда права пора отозвать. А создаются и расшариваются агенты быстрее любых других активов.

Что делать: завести на каждого агента identity, владельца и политику наименьших привилегий, плюс проверку намерения (intent) перед действием. Понимание intent агента, пишет The Hacker News, единственный рабочий путь к реальному enforcement.