В эфире 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 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

А что, если 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!

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

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

🗣 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

Как 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

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

Почему Kubernetes API server может съесть память на обычном LIST 👀

Получить список объектов через Kubernetes API кажется безобидной операцией. Но в большом кластере один такой запрос может вернуть тысячи объектов и заметно увеличить пиковое потребление памяти.

Где возникает проблема?

API server разбивает большие ответы на страницы, но размер страницы ограничен количеством объектов, а не объёмом данных. Поэтому несколько крупных объектов вполне могут превратить одну страницу в большой объём памяти.

При чтении из etcd такая страница сначала собирается целиком, а затем передаётся API server для обработки:

etcd → API server → декодирование → клиент

В результате один и тот же объём данных на короткое время находится в памяти сразу с двух сторон. Если несколько больших запросов выполняются одновременно, API server может упереться в лимит памяти.

Что меняет RangeStream?

В Kubernetes 1.37 etcd RangeStream получил статус Beta. Вместо целой страницы данные передаются небольшими частями: API server обрабатывает их по мере поступления и освобождает память перед следующей частью.

Большой запрос всё равно остаётся большой операцией, но теперь его размер меньше влияет на пиковое потребление памяти.

Что это даёт на практике?

Особенно полезно помнить об этом при расследовании ситуаций, когда API server внезапно начинает потреблять много памяти. Если память растёт рывками, а явного изменения нагрузки нет, причиной может быть не количество запросов, а размер возвращаемых данных.

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

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

Использование RangeStream можно проверить по метрике:

etcd_request_duration_seconds_count{operation="listStream"}

🌐 Подробно о проблеме и механике RangeStream — в разборе Kubernetes.

#kubernetes #devops #et

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

⏺В Amazon EKS показали, как Pod могут потерять равномерное распределение по зонам доступности.

После потери части узлов 1000 Pod перестали равномерно распределяться между тремя зонами. Даже после восстановления ёмкости перекос сохранялся более 16 часов.

topologySpreadConstraints не перераспределяют уже запущенные Pod. Для исправления AWS предлагает Kubernetes Descheduler.

Подробнее — в блоге AWS.

⏺Исследователи нашли побочный канал через inotify.

Анализ событий файловой системы позволяет отслеживать действия других пользователей без доступа к содержимому файлов. Исследователи показали возможность отслеживать SSH-сессии и восстанавливать ввод с клавиатуры.

Для атаки достаточно доступа к событиям файловой системы.

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

⏺В LXD и Incus обнаружили критические уязвимости с получением root.

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

Уязвимости исправлены — стоит проверить версии LXD и Incus.

Детали в статье OpenNET.

⏺Google выпустил инструмент для миграции Kubernetes из EKS в GKE с помощью ИИ.

GKE Agentic Migration анализирует Terraform и Kubernetes-манифесты, переводит настройки AWS в конфигурацию GKE и формирует Pull Request.

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

Подробнее — в блоге Google Cloud.

⏺Ubuntu ускоряет выпуск исправлений ядра.

Canonical переходит на двухнедельный цикл доставки обновлений ядра Linux. Подготовка нового обновления будет запускаться каждую неделю.

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

Читайте больше в статье OpenNET.

#новостной_дайджест #devopsfm #linux #aws #gke #devops

Как retry может усугубить инцидент

Uber недавно опубликовал разбор реального инцидента, в котором обычный механизм retry мог усугубить деградацию системы.

Это хороший повод посмотреть на retry не только как на защиту от временных ошибок, но и как на источник дополнительной нагрузки. Особенно в распределённых системах, где один запрос может повторяться сразу на нескольких уровнях.

Представим цепочку:

A → B → C → D

D начинает отвечать ошибками.
C делает retry.
B получает ошибку от C и тоже делает retry.
A повторяет запрос к B.

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

Особенно опасно, когда retry есть сразу на нескольких уровнях:

клиент → SDK → сервис → service mesh → зависимый сервис

Если каждый из трёх уровней повторяет неудачный вызов один раз, число обращений в худшем случае может вырасти:

1 → 2 → 4 → 8

В случае Uber проблемный сервис находился более чем на пяти уровнях глубины в цепочке зависимостей. Обычная стратегия retry могла увеличить нагрузку на него ещё на 46–135%.

Uber ограничил усиление нагрузки через error ownership: каждый сервис определяет, является ли ошибка его собственной или пришла от зависимости.

Если ошибка возникла ниже по цепочке, сервис не должен автоматически запускать свой retry поверх уже выполняющихся повторных попыток. Иначе один и тот же сбой начинает повторно обрабатываться сразу несколькими уровнями.

По данным Uber, такой подход позволил предотвратить до 9,5 млн лишних retry-запросов.

Что проверить у себя?

⏺Где именно реализован retry: в приложении, SDK, прокси или service mesh?

⏺Может ли один запрос пройти через несколько механизмов повторных запросов?

⏺Сколько запросов к зависимому сервису приходится на один исходный запрос?

⏺Видно ли отдельно количество исходных запросов и повторных попыток?

Полезный показатель можно посчитать напрямую:

коэффициент усиления = запросы к зависимому сервису / исходные запросы

Например, 10 000 исходных запросов → 17 000 запросов к зависимому сервису означает, что часть нагрузки появилась из-за повторных попыток.

Если во время сбоя одновременно растут ошибки, retry и QPS зависимого сервиса, система может сама усиливать собственную деградацию.

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

👀 Разбор кейса Uber можно прочитать здесь.

#devops #retry

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

⏺GitHub Actions пережил серьёзный сбой из-за проблем с сетевой связностью.

5 октября GitHub Actions и Hosted Runners несколько часов работали с перебоями. В пике 47% рабочих процессов завершались ошибкой, а 71,9% заданий не запускались в течение пяти минут.

Причиной стал сетевой сбой между инфраструктурой GitHub и облачными сервисами баз данных и хранения. Self-hosted runners не пострадали.

Узнать подробности можно в статусе GitHub.

⏺Azure столкнулся со сбоем сетевой инфраструктуры сразу в нескольких регионах.

С 30 сентября по 1 октября проблемы затронули ExpressRoute Gateway, VPN Gateway, Azure Firewall, Application Gateway/WAF и Azure VMware Solution. Часть клиентов столкнулась с деградацией или потерей сетевой связности.

Microsoft связывает сбой с изменением в сервисе управления шлюзами, которое вызвало повышенную нагрузку одновременно с плановым обслуживанием ОС.

Читайте детали в жунале Microsoft.

⏺Kubernetes-инфраструктура Dell оказалась уязвима сразу по нескольким направлениям.

В Container Storage Modules обнаружили две уязвимости с CVSS 10.0. Без аутентификации они позволяют получить административный доступ к подключённым системам хранения.

Отдельная уязвимость в CSM Operator позволяет получить root на узлах Kubernetes. Dell рекомендует обновить CSM до версии 1.18.0 или новее.

Подробнее — в бюллетене Dell.

⏺В GitLab AI Gateway нашли способ превратить конфигурацию AI-агента в RCE.

CVE-2026-90970 позволяет пользователю с доступом к Duo Agent Platform выйти за пределы изоляции шаблонов и выполнить команды на AI Gateway.

Уязвимость исправлена в версиях 19.2.4, 19.3.2 и 19.4.1.

Узнать больше можно в GitLab Docs.

⏺Istio готовится к очередному отключению старых источников артефактов.

13 октября Istio временно отключит старые источники артефактов в Google Cloud. Это очередной тест перед окончательным выводом этой инфраструктуры из эксплуатации в декабре.

Если в CI/CD используются gcr.io/istio-release, registry.istio.io или старый источник Helm-чартов, их стоит заменить заранее.

Подробнее — в блоге Istio.

#новостной_дайджест #devops #kubernetes #github #azure #gitlab #istio

👁Канарейка застряла в релизе: поможем с деплоем!

Пятница, конец рабочей недели и новый DevOps-квест. The Silent Canary — интерактивный челлендж от Dynatrace Community, посвящённый Kubernetes и постепенному развёртыванию приложений.

Что предстоит сделать:

⏺Разобраться, почему canary-релиз застрял и не проходит проверки состояния приложения.

⏺Настроить проверки на PromQL, чтобы Argo Rollouts мог оценивать состояние новой версии.

⏺Исправить конфигурацию и провести релиз через этапы 33% → 66% → 100%.

В прохождении пригодятся Kubernetes, YAML, Argo CD, Argo Rollouts и Prometheus. Запустить окружение можно в GitHub Codespaces — без локальной настройки.

Попробовать челлендж можно здесь.

У челленджа есть дедлайн — 13 октября. За успешное прохождение можно получить бейдж и сертификат.

Делитесь в комментариях, получилось ли довести релиз до конца! Желаем всем хорошей практики и приятных выходных🚀

#devops #тренажеры #gamedev

⏺Yandex Cloud перешёл в аварийный режим после повреждения дата-центра во Владимире

11 октября «Яндекс» сообщил о повреждении инфраструктуры дата-центра во Владимире в результате атаки БПЛА. Работа площадки полностью остановлена.

Что известно:

⏺Зоны доступности ru-central1-a и ru-central1-b недоступны.

⏺Часть сервисов работает с ограничениями или недоступна.

⏺Компания считает оставшуюся конфигурацию ресурсов неустойчивой и рекомендует задействовать альтернативные планы аварийного восстановления.

Ранее, 8 и 9 октября, «Яндекс» сообщал о повреждении дата-центров в Сасове и Калуге.

Подробнее можно посмотреть в официальном статусе Yandex Cloud

#новости #devops #yandexcloud #сбои

AI Platform Engineering: как найти узкое место и не переплачивать за GPU

Представим ситуацию: AI-сервис тормозит под нагрузкой. Растёт время ответа, пользователи жалуются. Команда добавляет GPU-реплики, но задержка не снижается, а расходы растут.

Проблема может быть не в GPU. Узким местом способны оказаться CPU, подготовка данных, очереди запросов или видеопамять.

Эту тему раскрывают два материала CNCF: почему AI-инфраструктуре нужны согласованно работающие CPU и GPU и что нужно Kubernetes-платформе для работы с AI-нагрузками.

Что проверить до масштабирования?

⏺GPU загружен слабо, задержка растёт? Проверьте загрузку CPU, ограничения процессорного времени контейнеров, подготовку и передачу данных, ожидание в очередях. Сопоставьте эти показатели с задержками на разных этапах обработки запроса.

⏺GPU загружен сильно, очередь растёт? Сравните пропускную способность и задержку p95/p99 при разной нагрузке и размерах пакета запросов. Проверьте, не ограничивают ли производительность вычисления или видеопамять.

⏺Новые реплики не помогают? Проверьте, получают ли они доступ к GPU, хватает ли ресурсов узлов Kubernetes и действительно ли растёт общая пропускная способность, а не только число реплик.

⏺Задержка нестабильна? Сопоставьте длину очередей, загрузку CPU и GPU, потребление памяти и время обработки на разных этапах. Определите, при какой нагрузке начинает расти задержка.

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

❔А вы сталкивались с ситуацией, когда масштабирование не помогло? Что оказалось узким местом?

#devops #kubernetes #platformengineering

👩‍💻 Релиз Linux Kernel 7.2.11

15 октября вышло обновление стабильной ветки ядра Linux 7.2.11. Оно включает исправления сетевого стека, файловых систем, управления памятью и драйверов оборудования.

Среди наиболее интересных изменений:

⏺️Сеть. Исправления затрагивают IPv4/IPv6, TCP, UDP и WireGuard. В Open vSwitch устранена ошибка, которая могла приводить к зависанию ядра при длительной обработке сетевых потоков.

⏺️Файловые системы и точки монтирования. Исправлена обработка операций монтирования и размонтирования, в том числе в пространствах имён.

⏺️Шифрование и целостность данных. В dm-integrity исправлена ошибка переполнения буфера при определённых размерах метаданных. В dm-crypt добавлена проверка некорректных комбинаций параметров шифрования.

⏺️Управление памятью. В io_uring исправлен учёт страниц памяти для областей, занимающих несколько страниц.

⏺️Драйверы. Обновления затрагивают сетевые адаптеры NVIDIA/Mellanox, Intel и Broadcom, а также драйверы Wi-Fi, Bluetooth и систем хранения.

👨‍💻 Подробнее об изменениях — в полном обзоре релиза.

#devops #linux #релиз

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

⏺PwnEscape: уязвимость Linux позволяла выйти из виртуальной машины на хост.

Ошибка в сетевом стеке Linux позволяла гостевой системе получить доступ к памяти хоста и выполнить код с правами ядра. Уязвимость особенно важна для облачных платформ и изолированных сред запуска кода.

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

⏺eMudhra: скомпрометированы ключи TLS-сертификатов.

Из-за недостатков генерации ключей злоумышленники могли выпускать поддельные HTTPS-сертификаты. Google и Mozilla заблокировали затронутые сертификаты.

Детали в статье на OpenNET.

⏺Argo CD: критическая уязвимость позволяла обходить ограничения доступа.

Уязвимость CVE-2026-77459 затрагивала управление ресурсами Kubernetes и могла позволить создавать объекты за пределами разрешённых проекту границ.

Исправления доступны в версиях 3.3.15, 3.4.10 и 3.5.4. Командам, использующим Argo CD, стоит проверить версию и обновиться.

Подробнее — на GitHub.

⏺GitHub тестирует защиту от вредоносных зависимостей.

Package Firewall помогает блокировать опасные npm-пакеты, которые могут похищать учётные данные разработчиков и систем сборки. Пока функция доступна в тестовом режиме клиентам GitHub Enterprise Cloud.

Узнать больше можно в объявлении GitHub.

#новостной_дайджест #devops #security

Как подготовить инфраструктуру к отказу облачного региона 👀

Даже отказоустойчивая инфраструктура внутри одного дата-центра не гарантирует доступность сервисов при потере всей площадки.

Недавние инциденты с Яндексом — повод вспомнить, как устроено георезервирование и что важно учитывать при его проектировании.

Георезервирование — это размещение критичных компонентов инфраструктуры в разных регионах. Но одной репликации между ними недостаточно, важно продумать и другие аспекты:

⏺1. Active-Passive или Active-Active?

В Active-Passive резервная площадка принимает нагрузку при аварии. Важно предусмотреть достаточные мощности и механизм переключения.

В Active-Active обе площадки обслуживают трафик одновременно, что усложняет маршрутизацию, синхронизацию данных и защиту от split-brain.

⏺2. Репликация и согласованность данных

Для PostgreSQL и очередей сообщений критичны режим репликации и поведение системы при потере связи между регионами.

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

Поэтому важно определить RPO — допустимую потерю данных — и RTO — допустимое время восстановления.

⏺3. Общие точки отказа (SPOF)

Даже две независимые площадки могут зависеть от общих компонентов: DNS, IAM, CI/CD, container registry или систем управления инфраструктурой.

Если эти зависимости недоступны при аварии, восстановить сервисы может не получиться.

⏺4. Ресурсы и эксплуатация резервной площадки

В Active-Passive необходимо учитывать время масштабирования резервной инфраструктуры и доступность свободных мощностей. В Active-Active — расходы на межрегиональный трафик, задержки и согласованность данных.

Terraform и GitOps упрощают воспроизводимое развёртывание, но не заменяют подготовленные процедуры восстановления и переключения.

⏺5. Тестирование Disaster Recovery

DR-тесты помогают проверить реальные RPO/RTO, целостность данных и переключение трафика. Важно также отрабатывать failback — безопасный возврат на основную площадку.

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

Георезервирование — это способность пережить потерю целой площадки в рамках заданных требований к восстановлению.

Если вам нужна помощь с георезервированием, в НИКСИС можем помочь с проектированием и настройкой инфраструктуры.

#devops #георезервирование #отказоустойчивость

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

🗣 HCP Terraform: сбои при подключении к системам контроля версий.

HashiCorp связала перебои с версией агента 1.33.2. Для агентов, установленных на собственной инфраструктуре, рекомендовали вернуться к версии 1.33.1.

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

🗣 LiteLLM: вредоносное обновление поставило под угрозу секреты CI/CD.

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

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

🗣️ GitLab: критическая уязвимость позволяла удалённо выполнять код.

Уязвимость CVE-2026-110264 получила максимальную оценку опасности — 10 из 10. Командам, которые самостоятельно обслуживают GitLab, следует проверить установленную версию и как можно скорее установить исправление.

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

🗣️ Terraform: исправлены ошибки при проверке схем провайдеров.

В версии 1.16.7 устранён сбой, возникавший при проверке схем с устаревшими параметрами. Также обновлён Go — это исправляет проблему с доверием к сертификатам скомпрометированных промежуточных центров eMudhra.

Подробнее — в списке выпусков Terraform.

#новостной_дайджест #devops #security