DevOps FM

Как подготовить инфраструктуру к отказу облачного региона 👀 Даже отказоустойчивая инфраструктура внутри одного дата-центра не гарантирует доступность сервисов при потере всей площадки. Недавние инциденты с Яндексом — повод вспомнить, как устроено георезервирование и что важно учитывать при его проектировании. Георезервирование — это размещение критичных компонентов инфраструктуры в разных регионах. Но одной репликации между ними недостаточно, важно продумать и другие аспекты: ⏺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 #георезервирование #отказоустойчивость

Как меняется работа SRE и DevOps в эпоху AI? 🔆 Команда DevCrowd* запустила новое исследование инженеров, которые отвечают за надёжность: SRE, DevOps, платформенных инженеров и всех, кто держит прод в строю. В этом году главный сюжет — роль AI в инженерной работе: какие задачи уже можно автоматизировать, доверяют ли ему работу в проде и приводит ли сгенерированный код к новым инцидентам. Отдельно изучают soft skills и навыки, которые AI пока не заменит. Не обошли и человеческую цену надежности: сколько стоят дежурства по времени, деньгам и здоровью и на ком в команде реально концентрируется нагрузка. Часть вопросов повторяет прошлогодние, поэтому результаты позволят увидеть динамику изменений за год. ⌨️ Если работаете с инфраструктурой и надёжностью сервисов — можете пройти опрос и поделиться своим опытом. Опрос займёт 10–12 минут. Отчёт со всеми разрезами опубликуют в начале декабря. ➖➖➖➖➖➖➖➖➖➖➖ *DevCrowd — независимые исследования IT-профессий: больше 15 000 участников, публичные отчеты по мобильной разработке, SRE, дата-специалистам, продактам и другим направлениям. #партнёрский_пост

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

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

На фоне последних событий вокруг дата-центров многие столкнулись с трудностями в работе. В такие моменты важны не только технические решения, но и командная работа, координация действий и взаимная поддержка. 🎧 Полезный материал на пятницу: Google SRE Prodcast — Incident Management with Adrienne Walcer. В выпуске специалисты Google делятся подходами к управлению инцидентами и рассказывают, как командам действовать слаженно в нестандартных ситуациях. Можно послушать на английском или прочитать расшифровку. Желаем всем, кого коснулась эта ситуация, скорейшего восстановления и возвращения к привычному рабочему ритму. 🙏🏼 Пусть выходные пройдут спокойно, а следующая неделя принесёт больше стабильности!

Новостной дайджест от 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

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

⏺Yandex Cloud перешёл в аварийный режим после повреждения дата-центра во Владимире 11 октября «Яндекс» сообщил о повреждении инфраструктуры дата-центра во Владимире в результате атаки БПЛА. Работа площадки полностью остановлена. Что известно: ⏺Зоны доступности ru-central1-a и ru-central1-b недоступны. ⏺Часть сервисов работает с ограничениями или недоступна. ⏺Компания рекомендует использовать альтернативные планы аварийного восстановления. Ранее, 8 и 9 октября, «Яндекс» сообщал о повреждении дата-центров в Сасове и Калуге. Подробнее можно посмотреть в официальном статусе Yandex Cloud #новости #devops #yandexvloud #сбои

👁Канарейка застряла в релизе: поможем с деплоем! Пятница, конец рабочей недели и новый 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

Время пройтись по интересным IT-событиям этой осени!🚀 22 октября в Москве пройдёт Kuber Conf от АОТ — конференция для сообщества Kubernetes. В программе технические доклады и обсуждения о том, как сегодня развивается Kubernetes и инфраструктура вокруг него. Поговорят о платформенной инженерии, запуске ИИ-нагрузок, безопасности, сетевых технологиях и эффективном использовании ресурсов. Отдельно стоит обратить внимание на круглые столы: «Kubernetes победил, и это проблема?» и «Из-за ИИ нас всех уволят, что будем делать?». Можно будет не только послушать экспертов, но и поучаствовать в обсуждении. Будет интересно сравнить разные взгляды. Среди спикеров — представители Yandex Cloud, VK Cloud, «Фланта», MWS Cloud Platform, Positive Technologies, Mindbox и других компаний. 📅 22 октября 📍 Москва, Connect, 5-й Донской проезд, 17 И небольшой бонус для наших читателей: по промокоду devops_fm_aot можно получить скидку 1000₽ на участие. Подробности и регистрация — на сайте конференции. #мероприятия #конференции #партнёрский_пост

🚨 Пожар в дата-центре «Яндекса» затронул часть инфраструктуры По сообщению компании, 8 октября в результате атаки беспилотника произошёл пожар в дата-центре «Яндекса» в Сасово (Рязанская область). Что известно: ⏺Пожар затронул часть инфраструктуры ЦОДа. ⏺Работа дата-центра полностью остановлена. ⏺Часть сервисов «Яндекса» и клиентских проектов может быть недоступна. ⏺Специалисты устраняют последствия происшествия. Пострадавших нет. С утра пользователи также сообщают о сбоях в работе сервисов «Яндекса» и других компаний. #новости #сбои

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

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

🎙 Что послушать на выходных: Kubernetes становится слишком сложным? Пятница — отличный повод немного отвлечься от рабочих задач и послушать что-нибудь интересное. В этот раз предлагаем включить свежий выпуск «Kubernetes: слишком сложно?» от DevOps Дефлопе. В выпуске обсуждают, как Kubernetes прошёл путь от первых развертываний до eBPF, сложных сетевых решений и внутренних платформ. А ещё — зачем скрывать инфраструктурную сложность от разработчиков и сможет ли искусственный интеллект взять на себя часть работы с Kubernetes. В гостях Александр Качмашев, техлид внутреннего облака в «Точке», и Александр Поломодов, эксперт по архитектуре и ИИ в разработке. Получился разговор не только про Kubernetes, но и про то, куда движется инфраструктура и каким будет DevOps в будущем. 🎧 Выпуск «Kubernetes: слишком сложно?» послушать можно здесь. Желаем приятного прослушивания и выходных без инцидентов! А тем, кто дежурит 🛡 — спокойных смен 🙌🏼 #пятничная_подборка #подкаст #devops #kubernetes #platformengineering #ai

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

Почему 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

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

Новостной дайджест от 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