🔔 Друзья, 9 сентября — День тестировщика, и в этот день в Москве пройдет ежегодная конференция, посвященная обеспечению качества и надежности ИТ-систем.

Тема — производительность, отказоустойчивость и все практики, которые позволяют системам выдерживать высокие нагрузки.

Будет особенно интересно инженерам по нагрузочному тестированию, QA-лидам, DevOps и SRE-специалистам.

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

📍 Москва, 9 сентября
⌨️ Очно и онлайн

Подробности и регистрация на сайте.
И в канале конференции.

🎙️ На волне DevOps FM!

Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное.

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

🗣 DevOps в 2026: Platform Engineering, AI-агенты и будущее джунов от DevOps Kitchen Talks. Что происходит, когда у вас уже 600 сервисов и 3600 пайплайнов? Обсуждают internal platform, её архитектуру и self-service-возможности для разработчиков, а также границы ответственности platform team. Отдельный фокус — AI-агенты и multi-agent workflows: что происходит, когда автоматизация начинает работать уже не только с инфраструктурой, но и непосредственно с engineering-процессами.

🗣 Kubernetes 2035: кто будет управлять инфраструктурой? от «В SREду на кухне» / AvitoTech. GitOps, Crossplane, автоматизация Kubernetes и развитие абстракций над инфраструктурой. Интересный вопрос выпуска — сколько деталей инфраструктуры разработчику действительно нужно видеть и какие операции со временем можно передать платформе и автоматизации.

🗣 Инфраструктура & MLOps от [I'ML]. Здесь уже про инфраструктуру для ML и AI-систем. Обсуждают ML Platform, Data Platform, вывод моделей в production и особенности эксплуатации AI workloads. Хороший выпуск, чтобы посмотреть, какие привычные DevOps-подходы приходится адаптировать для AI.

Желаем приятного прослушивания и дежурств без алертов!🛡

#пятничная_подборка #подкаст #DevOps #PlatformEngineering #AIEngineering

Platform Engineering 2.0: как меняется роль внутренней платформы

Kubernetes, Terraform, GitOps, CI/CD, Backstage — классический стек Platform Engineering уже хорошо знаком.

Но что происходит с этой моделью, когда появляются AI-нагрузки и новые способы взаимодействия с инфраструктурой?

В материале CNCF автор предлагает рассматривать это как следующий этап — Platform Engineering 2.0.

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


Что добавляется:

⏺AI становится ещё одним типом нагрузки

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

То есть AI — это не отдельный слой где-то рядом с платформой. Для platform team это ещё один класс нагрузки со своими требованиями к ресурсам, безопасности и управлению.

⏺Пользователей становится больше

Помимо разработчиков и platform engineers, с платформой работают ML-инженеры, специалисты по данным, команды безопасности и соответствия требованиям, FinOps — и постепенно AI-агенты.

Отсюда практический вопрос: можно ли пользоваться платформой программно?

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

⏺FinOps перемещается ближе к созданию ресурсов

Стоимость становится частью решения ещё до развёртывания.

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

⏺Безопасность уходит глубже в платформу

Меньше ручных проверок после развёртывания — больше политик и контроля непосредственно на уровне платформы и среды выполнения.

Для AI добавляются свои риски: неконтролируемое использование AI, prompt injection, отравление моделей, утечки данных при обработке запросов.

⏺Платформа становится модульной

Отдельные возможности должны быть доступны через API и собираться в разные сценарии: интерфейс, CLI, CI/CD, автоматизация или агент.

По сути, архитектура начинает выглядеть так:

Developer / ML Engineer / Agent
↓
Platform APIs
↓
Identity / Policy / Cost
↓
Kubernetes / Cloud / GPU / AI

И здесь важно: Kubernetes, Terraform, GitOps, Backstage никуда не исчезают. Меняется слой над ними — платформа начинает решать задачи, которые раньше находились за пределами классического самообслуживания разработчиков.


В итоге из концепции Platform Engineering 2.0 можно сделать вполне практичную вещь — ревизию собственной платформы.

Спросить себя:

→ Можем ли мы быстро выдать специализированный ресурс?

→ Можем ли мы сделать это через API?

→ Знаем ли стоимость до развёртывания?

→ Можем ли мы применять политики на уровне платформы?

→ Может ли автоматизация или агент работать с платформой без человека?

Если где-то ответ «нет» — вот там и находится следующая задача для platform team⌨️

#DevOps #Platformengineering

🔔В эфире DevOps FM – срединедельный дайджест новостей!

🔊 NVIDIA договорилась о покупке Hugging Face за $12,93 млрд.

NVIDIA объявила о соглашении по покупке Hugging Face — платформы с open-source и open-weight AI-моделями. После сделки Hugging Face должна сохранить открытый и мультиоблачный подход.

Для NVIDIA это возможность усилить позиции не только в GPU, но и в инфраструктуре для разработки и запуска AI-моделей. Закрытие сделки ожидается в первой половине 2027 года.

Детали сделки можно прочитать в блоге NVIDIA.

🔊 В vm2 нашли критическую уязвимость с обходом sandbox и RCE.

GitLab Threat Research обнаружила уязвимость с максимальным CVSS 10.0 в популярной Node.js-библиотеке vm2. Она позволяет обойти изоляцию и получить полный доступ к хост-системе.

Проблема затрагивает версии 3.11.6 и ниже при включённом require.external. Исправление доступно в 3.11.7.

Подробности читайте в исследовании GitLab.

🔊 Google Cloud пережил четырёхчасовой сетевой сбой.

1 сентября в зоне us-central1-b произошёл серьёзный сбой, затронувший Compute Engine, GKE, Cloud Run, Cloud SQL и другие сервисы.

Причиной стала ошибка во время планового обслуживания: последовательно были отключены все оптоволоконные пути к части инфраструктуры, из-за чего часть VM в зоне потеряла сетевую связность. Сбой продолжался 4 часа 11 минут.

Подробности инцидента — в отчёте Google Cloud.

🔊 Karmada получил статус CNCF Graduated.

Karmada стал первым проектом CNCF для управления несколькими Kubernetes-кластерами, достигшим статуса Graduated.

Платформа позволяет управлять приложениями сразу в нескольких кластерах, облаках и регионах, а в последних версиях развивает механизмы планирования для распределённых AI-нагрузок.

Подробнее — на сайте CNCF.

#новостной_дайджест #devopsfm #karmada #security #cloud

Как LegalOn адаптирует Platform Engineering под AI-агентов ⌨️

Продолжаем тему Platform Engineering — сегодня разбираем кейс LegalOn Technologies от Signadot. LegalOn Technologies от Signadot.

У LegalOn около 200 инженеров, GKE, Argo CD и собственная платформа Akupara. С появлением AI-агентов узким местом всё чаще становится уже не создание кода, а его проверка и доставка.

Архитектуру они разделили на три части:

⏺Контекст

Каталог продуктов в YAML используется как источник данных для Terraform и агентов. На основе Terraform HCL и Kubernetes-конфигураций они строят граф знаний, доступный через MCP.

По данным LegalOn, это снизило потребление токенов примерно на 25%.

⏺Соединение с реальным окружением

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

Так появляется быстрый цикл, без необходимости каждый раз проходить полный путь через CI/CD: зменение → проверка → результат → исправление

⏺Изолированная среда

Для PR LegalOn использует Signadot: изменённые сервисы запускаются в отдельном окружении, которое можно использовать для тестов и проверки взаимодействия компонентов.

Но здесь меняется сама роль платформы.

Если раньше Platform Engineering строился вокруг разработчика: разработчик → платформа → инфраструктура

то теперь появляется второй потребитель: разработчик / агент → платформа → инфраструктура

Агенту нужны не только API и инструменты, но и контекст, быстрый цикл проверки и чёткие границы действий.

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

#DevOps #PlatformEngineering #LegalOn

Как дать командам доступ к метрикам Kubernetes и не открыть весь Prometheus?

Всем DevOps!🖖 В прошлом посте мы разбирали, как LegalOn перестраивает платформу для AI-агентов: даёт им нужный контекст и доступ к окружению, но оставляет чёткие границы действий.

В свежем материале CNCF инженеры Adobe разбирают похожую задачу для наблюдаемости: как дать командам самостоятельный доступ к метрикам, не открывая весь общий Prometheus.

В многопользовательском Kubernetes командам нужны собственные запросы и оповещения, но общий Prometheus нельзя открыть всем: его API не изолирует запросы по пространствам имён, а множество произвольных запросов создаёт на него нагрузку.

В Adobe решили проблему через промежуточный слой:
команда → проверка прав → ограничение области данных → Prometheus

Этот слой ограничивает запросы данными своего пространства имён. А нужные метрики при необходимости можно дополнительно отправлять в отдельный Prometheus команды — для графиков и оповещений.

Получается тот же принцип, что и в кейсе LegalOn: самообслуживание без прямого доступа ко всей инфраструктуре.

В кейсе Adobe это помогло найти GPU, который 11 дней был выделен, включен, но не использовался.

Как у вас устроен доступ команд к метрикам: общий Prometheus с изоляцией или отдельный для каждой команды? Делитесь опытом в комментариях💬

В эфире DevOps FM – срединедельный дайджест новостей!

⏺В Forgejo обнаружили критическую уязвимость с RCE и CVSS 9.9.

CVE-2026-89094 позволяет выполнить произвольный код при обработке специально подготовленного шаблонного репозитория. Проблема затрагивает версии Forgejo до 16.0.4.

Если Forgejo используется во внутренней Git-инфраструктуре, стоит проверить версию и обновиться.

Подробнее в статье OpenNET.

⏺Вышел Cilium 1.20 с новыми возможностями для сетей Kubernetes.

Обновили Gateway API до версии 1.6, добавили ExternalAuth, TCPRoute и UDPRoute, а также поддержку IPv6 в AWS ENI IPAM.

Появилась возможность перейти от общего пула IP-адресов к нескольким пулам без пересоздания кластера и смены IP-адресов.

Больше об изменениях читайте в блоге CNCF.

⏺Исследователи показали способ подмены идентичности рабочей нагрузки в SPIFFE/SPIRE.

Получив root на узле, атакующий может подменить данные cgroup, которые агент SPIRE использует для определения рабочей нагрузки, и получить криптографический идентификатор другой нагрузки.

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

Подробнее — в исследовании Unit 42.

⏺AWS не смог восстановить часть инфраструктуры после масштабного повреждения.

Масштаб повреждений оказался больше расчётного сценария отказа, поэтому часть ресурсов в Бахрейне и ОАЭ восстановить не удалось.

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

Детали читайте в Reuters.

#новостной_дайджест #devopsfm #kubernetes #security #cilium #aws

👩‍💻 Что нового в Kubernetes 1.37?

Бодрый DevOps! В эту пятницу разбираем свежие материалы команды Kubernetes о v1.37 Garhwal. Выбрали несколько изменений, о которых стоит почитать перед обновлением кластера.

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

Разбор масштабирования до нуля.

⏺Больше контроля над памятью.
Memory QoS перешёл в Beta. Kubernetes получает более точный контроль за потреблением памяти контейнерами.

Как работает новый механизм.

⏺Kubernetes без root.
Компоненты ноды теперь можно запускать от непривилегированного пользователя. Ещё один шаг к уменьшению привилегий в кластере.

Разбор rootless-режима.

⏺GPU и другие специализированные ресурсы.
DRA получил новые возможности для более гибкого распределения ресурсов — особенно актуально для кластеров с GPU.

Подробнее о DRA.

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

А если хочется погрузиться глубже — держите полный обзор изменений Kubernetes 1.37.

Желаем всем хороших выходных и спокойных дежурств!🛡

#девопс #kubernetes #пятничное_чтиво

Новостной дайджест от DevOps FM!

Делимся свежими новостями и важными изменениями в мире DevOps и инфраструктуры за прошедшую неделю.⌨️

⏺В KVM нашли уязвимость, позволяющую гостевой системе получить доступ к памяти хоста.

CVE-2026-89775 затрагивает ARM64-системы с включённой вложенной виртуализацией. При определённых условиях гостевая система может читать и записывать память ядра хоста.

Проблема появилась в Linux 6.16 и исправлена в версиях 6.18.51 и 7.2.5. Для дистрибутивов стоит проверить доступность исправлений.

Подробнее — в материале OpenNET.

⏺GitHub усилил защиту GitHub Actions.

GitHub сделал доступным новый механизм контроля запуска workflow. Теперь можно задавать правила, определяющие, кто и какие события может использовать для запуска workflow на уровне организации и репозитория.

Отдельные ограничения появились для pull_request_target: при неправильной настройке он может привести к выполнению недоверенного кода с доступом к секретам репозитория.

Читайте подробности в блоге GitHub.

⏺GitHub переводит ubuntu-latest на Ubuntu 26.04.

С 19 октября по 19 ноября GitHub начнёт поэтапно переводить ubuntu-latest с Ubuntu 24.04 на 26.04.

Для CI это означает изменение окружения без изменений в самих workflow: обновятся версии системных пакетов и предустановленных инструментов.

Если используется ubuntu-latest, GitHub рекомендует заранее проверить сборки на Ubuntu 26.04 или зафиксировать ubuntu-24.04.

Детали узнавайте в статье на GitHub.

⏺В Kubernetes 1.37 добавили отслеживание неиспользуемых PVC.

PersistentVolumeClaimUnusedSinceTime перешла в статус Beta и включена по умолчанию.

Теперь Kubernetes может помечать PVC как Unused, если его не использует ни один работающий Pod, и фиксировать время перехода в это состояние.

Это позволит находить давно неиспользуемые PVC и использовать эту информацию для последующей очистки.

Подробности — в блоге Kubernetes.

#новостной_дайджест #devopsfm #kubernetes #github #linux

Redis Streams vs Kafka

📝 Что выбрать для системы обработки событий: Redis Streams или Kafka?

Сегодня заглянем в Reddit-тред, где инженеры поделились своим опытом использования этих инструментов в реальных продакшен-системах.

suhaanthvv

Для системы уведомлений я выбрал Redis Streams + Consumer Groups вместо Kafka/SQS. Нам нужны retry, replay, восстановление после падения consumer'а и DLQ. Пока Redis закрывает эти задачи, но главный вопрос — в какой момент его возможностей становится недостаточно и стоит переходить на Kafka?

dragon_idli

Мы используем Kafka примерно для
30 млн событий, при этом кластер рассчитан на 70 млн. Redis у нас работает отдельно для ultra-low-latency сценариев. Например, игровые события внутри комнат — там важна минимальная задержка.

gvensan

Я бы использовал Redis, пока не появляются multi-site, независимые команды и необходимость в длинном replay. Вот тогда Kafka начинает выглядеть более оправданно.

7z3b

Мы сначала использовали Redis, но потом ушли на NATS JetStream. Stream'ы росли, потребление памяти увеличивалось, и Redis становился слишком дорогим. Kafka тоже не выбрали — managed-вариант был дорогим, а самостоятельно поддерживать Kafka не хотелось.

💬 Отдельно в обсуждении подняли вопрос replay:

srikanth_builds

Если сообщение повторно доставляется спустя время, ситуация могла измениться: например, пользователь уже не имеет доступа к данным. Поэтому authorization нужно проверять в момент доставки, а не только при постановке события в очередь.

Полный тред можно почитать здесь.

А какой production-кейс заставил бы вас отказаться от Redis Streams в пользу Kafka? Делитесь опытом в комментариях💬

#devops #reddit #redis #kafka