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

⏺ 10 августа Docker выпустил обновление Docker VMM, переведя технологию в статус Public Beta.

Docker VMM — новый уровень виртуализации для Docker Desktop, который сделает работу контейнеров на Mac и Windows быстрее и стабильнее. Среди заявленных улучшений — более быстрый запуск контейнеров, ускоренный файловый I/O и более эффективное управление памятью. Сейчас технология доступна в Docker Desktop 4.86, а финальный релиз по имеющейся информации запланирован на конец октября.

Подробнее о том, что изменилось и как попробовать новый VMM — в блоге Docker.

⏺ После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.2.

Новая версия ядра традиционно приносит изменения в подсистемах, драйверах и производительности. Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.

⏺ Debian обсуждают использование AI при разработке.

Debian объявили о начале общего голосования разработчиков по вопросу использования больших языковых моделей и AI-инструментов при разработке дистрибутива.

Прием голосов будет осуществляться до 28 августа. Как проходит голосование и какие позиции обсуждаются — читайте в OpenNET.

⏺ GitHub пережил масштабный сбой.

17 августа проблемы затронули сразу несколько ключевых сервисов платформы: Web и API показывали около 20% ошибок, а количество неудачных запросов к архивам и Raw-контенту доходило до 50%. Были затронуты Actions, Pull Requests, Issues, Webhooks, Copilot и другие сервисы.

GitHub постепенно восстановил сервисы. В качестве причины сбоев эксперты предположили сетевые инциденты в Amazon Web Services. Подробнее о масштабах сбоя — в статье.

#новостная_подборка #devops #github #docker #linux #debian

Пятничное чтиво от DevOps FM

📚AI-агенты постепенно заходят в DevOps: получают доступ к коду, инфраструктуре, CI/CD и production. Сегодня читаем о том, как безопасно управлять системами, которые умеют действовать самостоятельно.

⏺12 августа Docker представил Agent Baseline — набор практических рекомендаций для безопасного внедрения AI-агентов. В центре внимания — least privilege, наблюдаемость, аудит и возможность остановить агента, а не просто надеяться, что модель будет вести себя правильно. Подробнее читайте в статье.

⏺CNCF смотрит на проблему с другой стороны: если AI становится частью production, то где проходит граница между ML-командой, DevOps и Platform Engineering? И кто в итоге отвечает за надёжность всей этой системы? Подробнее читайте здесь.

⏺В разборе кейса Hugging Face хорошо показывает, почему вопрос контроля уже не теоретический. В ходе инцидента исследователи восстановили около 17 600 действий агента, объединённых примерно в 6 280 цепочек.

⏺GitLab, в свою очередь, показывает, как можно встроить AI-агентов в существующую инфраструктуру с учётом требований безопасности. В новой статье компания рассказывает об AI Gateway для GitLab Dedicated, который позволяет контролировать используемые модели и сохранять AI-обработку внутри выбранного региона. Подробнее читайте в статье.

👀Получается интересный сдвиг: раньше DevOps автоматизировал процессы, а теперь ему предстоит ещё и управлять AI-агентами.

И теперь главный вопрос — какие права мы готовы дать AI и насколько быстро сможем его остановить, если что-то пойдет не так? Пишите свое мнение в комментариях.

Желаем приятного чтения и хороших выходных!

#пятничноечтиво #devops #ai

DevOps через Git: насколько реально управлять всей инфраструктурой и deployment из Git?

Что, если от создания VPC до выката приложения в Kubernetes вообще не заходить в AWS руками? Именно такой сценарий GitLab разбирает в статье — и он хорошо показывает, куда движется современный DevOps.

Если сильно упростить, схема примерно такая:
Git → GitLab CI/CD → OpenTofu → AWS/EKS → Argo CD → приложение

OpenTofu создаёт и изменяет инфраструктуру, GitLab CI/CD управляет процессом и сборкой, а Argo CD следит за состоянием Kubernetes и синхронизирует его с Git.

Вместо привычного сценария:

> Зайди в AWS, поправь вот это.
> Потом сделай kubectl apply.
> А почему staging теперь отличается от production?

Получаем:

> Изменение инфраструктуры — commit.
> Изменение приложения — commit.
> Дальше автоматика сама приводит окружение к нужному состоянию.

И вот это уже интереснее, чем просто очередная связка инструментов.
IaC + CI/CD + GitOps постепенно превращаются в единую декларативную цепочку, где Git становится источником истины не только для кода, но и для окружения.

Плюсы очевидны:
⏺меньше ручных действий;
⏺изменения проходят review;
⏺инфраструктура воспроизводима;
⏺rollback часто превращается в git revert;
⏺окружение можно восстановить из кода.

Но ведь чем больше production мы передаём автоматизации, тем важнее становится надёжность самого control plane.

Отсюда возникают следующие вопросы:
⏺Что делать, если GitLab недоступен?
⏺Как внести emergency change?
⏺Кто имеет break-glass доступ?
⏺Можно ли восстановить инфраструктуру, если недоступны инструменты, которые ей управляют?

И, пожалуй, это один из интересных вопросов современного DevOps — что важнее: полностью исключить ручные изменения или сохранить возможность быстро обойти автоматизацию в аварийной ситуации? Делитесь своим мнением в комментариях💬

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

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

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

⏺Kubeflow получил статус CNCF Graduated.

Kubeflow получил высший статус зрелости в CNCF. Проект объединяет инструменты для построения AI/ML-платформ на Kubernetes — от подготовки данных и обучения моделей до inference.

Для DevOps это ещё один сигнал: Kubernetes всё активнее становится инфраструктурой для AI — от обучения моделей до inference и serving. Детали читайте в статье.

⏺AWS продолжает развивать Argo CD в EKS.

В понедельник мы разбирали сценарий, где Git становится control plane для инфраструктуры и deployment. Теперь AWS расширяет возможности настройки управляемой Argo CD Capability в EKS — в частности, добавляет поддержку кастомных health checks и параметров сравнения ресурсов.

Похоже, AWS постепенно углубляет интеграцию GitOps с EKS, беря на себя всё больше операционных задач по управлению Argo CD. Подробнее — в блоге AWS.

⏺IncidentRelay 2.0 — новый релиз self-hosted incident management.

Open-source проект для управления дежурствами, маршрутизации алертов и incident response получил новый major-релиз.

IncidentRelay ориентирован на SRE и DevOps-команды, которым нужна self-hosted альтернатива облачным платформам управления инцидентами.
Подробности о ключевых обновлениях и список основных изменений — читайте в OpenNET.

⏺GitHub опубликовал разбор масштабного сбоя 17 августа.

Напомним, тогда GitHub был недоступен или работал с ошибками почти 8 часов. Теперь компания раскрыла детали: проблема с autoscaling Istio sidecar-подов привела к перегрузке сети и каскаду отказов.

Ситуацию дополнительно усугубили агрессивные retry: нагрузка на отдельные сервисы выросла многократно.

Получился отличный пример того, как ошибка в автоматическом масштабировании + retry storm могут превратить локальную проблему в большой outage.
Подробнее — в разборе GitHub.

#devops #инциденты #gitlab #kubeflow

Подборка интерактивных тренажеров для DevOps

⌨️ В эту пятницу собрали тренажеры, где можно на практике разбирать нетривиальные сценарии Kubernetes, networking и troubleshooting.

⏺ Deadnodes — тренировка в формате production-инцидента: получаем сломанное окружение, ищем root cause и восстанавливаем систему. Есть сценарии по Linux, Kubernetes, networking и базам данных.

⏺ iximiuz Labs — набор hands-on лабораториий с Linux, контейнерами и Kubernetes. Можно самостоятельно разбирать networking, container internals и troubleshooting-сценарии разной сложности.

⏺ Anycast и BGP — меняем маршруты и отключаем PoP, чтобы посмотреть, что происходит с трафиком и TCP-соединениями. Можно разобрать проблемы с long-lived connections и capacity при отказе части инфраструктуры.

⏺ Kubernetes Scheduler Simulator — практика работы с Filter/Score, resource requests, taints и tolerations. Можно посмотреть, почему Pod оказывается Pending, и сравнить стратегии размещения.

Сохраняйте подборку, чтобы попробовать эти сценарии на практике и проверить свои навыки troubleshooting.

Хорошей практики и приятных выходных! Делитесь своими любимыми тренажерами в комментариях.

#девопс #тренажеры

А что, если AI посмотрит ваш Kubernetes?

AI-помощники для Kubernetes — уже далеко не новость.

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

Red Hat в своем блоге показывает 5 сценариев для OpenShift Lightspeed — AI-помощника, который помогает работать с OpenShift и Kubernetes.

Собрали самое интересное 👇

1. Спросить вместо поиска по документации

Например:

How do I configure a custom ingress controller?

What are the prerequisite network requirements for setting up an OpenShift cluster?

Lightspeed использует официальную документацию Red Hat и учитывает версии OpenShift и Lightspeed в вашем окружении.

2. Сгенерировать YAML

Можно попросить AI подготовить конфигурацию:

Generate a YAML file for a deployment running a basic NGINX server with 3 replicas.

Или:

Create a NetworkPolicy that limits traffic to pods in the production namespace.

Получаем черновик манифеста, который дальше, конечно, нужно проверить перед применением.

3. Разобраться с проблемой

Здесь уже можно использовать AI не только для генерации конфигурации, но и для troubleshooting.

Например:

Why is my application pod stuck in ImagePullBackOff?

I am getting a CrashLoopBackOff error on my frontend pod. What is happening there?

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

4. Разобраться с виртуализацией

Для OpenShift Virtualization можно задавать вопросы вроде:

Is there a storage vMotion equivalent?

How do I import a VMware virtual machine into OpenShift Virtualization?

Удобный вариант, чтобы разобраться с Kubernetes-based virtualization и сопоставить её с уже знакомыми подходами.

5. А теперь самое интересное — live-кластер

При включённом Cluster Interaction Lightspeed может получать актуальный контекст активного кластера через OpenShift API.

Например:

Show me all degraded pods running in the payment-processing namespace.

Are there any active security alerts or failed deployments on my cluster right now?

То есть вопрос можно сформулировать не только как: «Как сделать X в OpenShift? Но и как: «Что сейчас происходит с моим кластером?»

Сам сценарий AI-assisted troubleshooting для Kubernetes уже существует. Интерес Lightspeed — в его интеграции с OpenShift и доступе к контексту работающего кластера.

При этом Cluster Interaction сейчас имеет статус Technology Preview, поэтому воспринимать его как готовую замену привычным инструментам мониторинга и диагностики точно не стоит.


👀 А когда такая возможность выйдет из Technology Preview — дали бы вы AI read-only доступ к production-кластеру? Делитесь своим мнением в комментариях 💬

#DevOps #Kubernetes #OpenShift #AI

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

⏺ Вышел релиз Kubernetes 1.37.

В новой версии добавили 67 изменений: 16 функций перешли в Stable, 23 — в Beta, ещё 27 получили статус Alpha.

Среди основных изменений — переход Metrics API в Stable, обновления сетевых компонентов, поддержка Pod Certificates и Cluster Trust Bundles, а также изменения в kube-proxy и cgroup. Релиз также включает обновления и улучшения для безопасности, управления ресурсами и работы кластера.

Подробнее об изменениях Kubernetes рассказали в своем блоге.


⏺Боты создают 98% трафика на git.kernel.org и заставляют ограничивать сервис.

git.kernel.org получает около 6 млн запросов в день, и около 98% из них — боты, которые массово запрашивают страницы отдельных коммитов, создавая постоянную нагрузку на серверы.

На пяти серверах 14–16 из 90 CPU-ядер постоянно заняты обработкой этих запросов, в результате администраторы начали отключать ресурсоёмкие операции, ограничивать анонимный доступ и сокращать количество доступных для обхода ссылок.

Детали читайте в статье.


⏺Amazon завершила покупку DuckLabs, разработчика DuckDB.

Сделка была закрыта 31 августа. Команда DuckDB присоединяется к AWS, при этом проект продолжит развиваться под руководством своих основателей. AWS планирует использовать технологии DuckDB для развития своего аналитического стека.

Подробнее на OpenNET.


⏺Для Debian 11 завершилась официальная LTS-поддержка.

31 августа закончился период LTS для Debian 11 Bullseye. Для части пакетов и архитектур доступна Extended LTS от Freexian — она продлевает поддержку до 2031 года.

Подробнее на OpenNET.


⏺Debian завершил голосование по правилам использования AI.

Ранее мы писали о голосовании Debian по правилам использования генеративного AI. Теперь голосование завершено: проект выбрал вариант Responsible Generative AI Use.

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

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

🔔 Друзья, 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