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

🚨 Пожар в дата-центре «Яндекса» затронул часть инфраструктуры

По сообщению компании, 8 октября в результате атаки беспилотника произошёл пожар в дата-центре «Яндекса» в Сасово (Рязанская область).

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

⏺Пожар затронул часть инфраструктуры ЦОДа.

⏺Работа дата-центра полностью остановлена.

⏺Часть сервисов «Яндекса» и клиентских проектов может быть недоступна.

⏺Специалисты устраняют последствия происшествия. Пострадавших нет.

С утра пользователи также сообщают о сбоях в работе сервисов «Яндекса» и других компаний.

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

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

Пятница, конец рабочей недели и новый 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

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

🗣GhostAction: вредоносные GitHub Actions похищали секреты из 345 репозиториев.

8 октября злоумышленники использовали скомпрометированные аккаунты сопровождающих проектов, чтобы внедрить вредоносные рабочие процессы. Они собирали не только секреты CI/CD, но и облачные ключи и другие учётные данные из истории Git — в том числе давно удалённые.

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

Подробнее — в разборе StepSecurity.

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

Уязвимость CVE-2026-97229 получила максимальную оценку CVSS 10.0. При определённых условиях специально сформированное регулярное выражение в конфигурации CI/CD могло позволить удалённому злоумышленнику выполнить произвольный код на сервере GitLab.

Исправления доступны в версиях 19.4.2, 19.3.5 и 19.2.8.

Больше деталей читайте в объявлении GitLab.

🗣Let's Encrypt сократит срок действия сертификатов до 64 дней.

С 10 февраля 2027 года новые сертификаты будут действовать 64 дня вместо 90. Тестовая среда переходит на новый срок уже 14 октября 2026 года.

Это делает надёжное автоматическое продление ещё важнее: если процесс обновления сломается, запас времени до истечения сертификата станет меньше.

Подробности в объявлении Let's Encrypt.

🗣Yandex Cloud продолжает восстановление после атак на дата-центры.

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

Следить за новостями можно в статусе Yandex Cloud.

#новостной_дайджест #devopsfm #безопасность #yandexcloud

👩‍💻 Релиз 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

Как меняется работа SRE и DevOps в эпоху AI? 🔆

Команда DevCrowd* запустила новое исследование инженеров, которые отвечают за надёжность: SRE, DevOps, платформенных инженеров и всех, кто держит прод в строю.

В этом году главный сюжет — роль AI в инженерной работе: какие задачи уже можно автоматизировать, доверяют ли ему работу в проде и приводит ли сгенерированный код к новым инцидентам. Отдельно изучают soft skills и навыки, которые AI пока не заменит.

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

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

⌨️ Если работаете с инфраструктурой и надёжностью сервисов — можете пройти опрос и поделиться своим опытом.

Опрос займёт 10–12 минут. Отчёт со всеми разрезами опубликуют в начале декабря.

➖➖➖➖➖➖➖➖➖➖➖

*DevCrowd — независимые исследования IT-профессий: больше 15 000 участников, публичные отчеты по мобильной разработке, SRE, дата-специалистам, продактам и другим направлениям.

#партнёрский_пост

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

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

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

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

⏺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