DevOps для ДевоПсов

Часть систем CERN готовят к переходу с CentOS Linux на Debian

Если у вас парк CentOS Linux, опыт CERN полезен как ориентир для оценки собственной миграции. CERN готовит переход только части систем: речь не идёт о переносе всей вычислительной среды организации.

Сотрудники CERN представили переход в докладе «Controlling CERN's Accelerators with Debian» 30 августа 2026 года. В целом ускорительный комплекс получает данные с датчиков и сохраняет петабайты для анализа, но конкретные версии пакетов, команды и срок завершения в переданном фрагменте не названы.

Перед собственным пилотом отделите выбранные системы от остального парка и зафиксируйте их зависимости от CentOS Linux. В разборе LWN есть видео доклада и слайды сотрудников CERN: используйте их для изучения кейса, а не как готовую инструкцию.

Karmada признали зрелым проектом CNCF

Cloud Native Computing Foundation (CNCF) присвоила Karmada статус graduated, признав проект зрелым. Karmada распределяет приложения между кластерами Kubernetes, облаками и регионами без их изменения. Проект централизованно размещает их, переключает при отказе и масштабирует между кластерами.

В Karmada v1.19 улучшили планирование составных задач распределённого обучения ИИ. Планирование по приоритетам перешло в бету и включено по умолчанию, чтобы критичные нагрузки планировались первыми.

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

Миллиард манифестов показал цену свежих контейнеров

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

За шесть месяцев до публикации Chainguard увеличила число манифестов сборки с 500 млн до более чем 1 млрд. Каждый такой манифест фиксирует новый артефакт: версию образа, пересборку после патча или вариант для другой архитектуры.

Проверьте правила своей цепочки поставки: патч базовой библиотеки, изменение зависимости и обновление исходного проекта должны запускать пересборку. В материале The Hacker News описано, как Chainguard OS и Chainguard Factory поддерживают непрерывный выпуск вместо полугодового релизного цикла.

Доступ к Kubernetes можно отзывать вместе с учётной записью

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

С OIDC доступ привязывается к учётной записи и группам. kubelogin запускает вход через браузер, получает ID-токен с именем и группами и добавляет его к запросам kubectl. kube-apiserver проверяет токен, а RBAC определяет разрешённые действия.

Для kubectl настройте публичный OIDC-клиент с PKCE, без клиентского секрета. Тогда доступ отзывается удалением пользователя из группы, а сертификаты распространять не нужно. В разборе Cloud Native Computing Foundation перечислены три компонента схемы и нужные параметры kube-apiserver.

Сломанный API в Nitro можно поймать раньше пользователей

Деплой Nitro-приложения может оставить фронтенд доступным, но сломать /api/*. Мониторинг одной главной страницы этого не покажет.

Добавьте маршрут /server/routes/health.get.ts:

export default defineEventHandler(() => ({
  status: 'ok',
  timestamp: new Date().toISOString(),
  service: 'nitro-app'
}))

Подключите маршрут к Vigilmon вместе с главной страницей и критичными API. Он подтверждает только ответ Nitro. Для контроля базы или внешнего сервиса проверяйте соединение в обработчике и возвращайте degraded при сбое. В руководстве также перечислены риски для сертификата, фоновых маршрутов и холодного запуска Cloudflare Workers.

Четыре проверки перед релизом можно провести из GitHub

Когда решение по pull request зависит от продуктовой аналитики, состояния зависимостей, управления выкладкой и готовности к выпуску, один и тот же контекст приходится переносить между сервисами. GitHub предлагает обращаться к их агентам там, где уже идёт работа над изменением.

В примере агент Amplitude проверяет связь шага регистрации с дальнейшим удержанием ещё до написания кода. После открытия чернового pull request агент Endor Labs получает вопрос о зависимостях, затронутых изменением. В сценарий также входят LaunchDarkly и PagerDuty.

Для пробы возьмите один черновой pull request и запросите проверку зависимостей до результата CI-сканирования. В разборе GitHub показаны вопросы для этапов от проверки гипотезы до решения о выкладке.

Алерт по задержкам пришёл, а дашборды деплоймента зелёные: чего не хватает вашей телеметрии

Latency вырос, rollout выглядит здоровым, поды живы, CPU в норме. Причина ниже: запрос пользователя проходит ingress, сервисы, очереди, storage и фоновых воркеров, и деградация приходит с любого участка или из шумного retry-цикла.

Мониторинг отвечает только на вопросы, заданные заранее: CPU выше порога, память растёт, ошибки участились. Инцидент, которого вы не предвидели, он не опишет.

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

Что делать: возьмите последний инцидент и проверьте, пройдёте ли по нему от ingress до воркера одним trace id. Нет — чинить надо инструментирование, а не добавлять ещё дашборд.

Ваш сервис в ECS может переключаться дольше расчёта, но хаос-тест покажет реальное окно

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

В разборе InfoQ DNS TTL в 60 секунд дал 93 секунды переключения из-за промежуточного кеширования. Настроенная политика повторных запросов увеличила нагрузку на базу данных в 2,4 раза. Значения в конфигурации здесь надо сверять с замерами при отказе.

Начните хаос-тесты с сервисов вне пути транзакций. До проверки основных сервисов задайте штатное состояние, автоматический откат и согласование. Отдельно смоделируйте замену задач и отказ зоны доступности: замерьте время переключения и нагрузку на базу, затем проверьте стратегию размещения.

Две строки лога в секунду превращаются в 50 операций записи на диск

Виртуалка шуршит диском на ровном месте — проверьте journald. В тикете systemd #40262 стенд простой: Debian 13, systemd 257.9, ядро 6.12.57+deb13-amd64, журнал лежит на XFS. haproxy пишет две строки в секунду, а виртуалка выдаёт около 50 IOPS.

Автор объясняет это форматом журнала: файлы кратно больше того, что в них записано, и на грязной перезагрузке он их не раз ловил битыми. Точно такой же отчёт (#15292) закрыли с формулировкой, что iotop врёт; здесь IOPS сняты снаружи, с гипервизора, уже после того как ядро склеило записи.

Что делать: снимать IOPS со стороны гипервизора, а не из гостя. Если журнал правда упирается в диск, переведите его в память (Storage=volatile в journald.conf) и отправляйте логи наружу, в syslog или удалённый сборщик. Плата за это — журнал на самой машине не переживёт перезагрузку.

Проверить, что ваши ретраи и circuit breaker срабатывают, можно прямо в интеграционном тесте

Ретраи, таймауты и фолбэки настроены, но сработают ли они, вы узнаёте на инциденте. Чтобы сломать HTTP специально, обычно поднимают сетевой прокси, а тащить его в тесты дорого.

Flaky HTTP ломает вызовы на уровне приложения: это обёртка над java.net.http.HttpClient из Java 11. failureRate(1.0) и errorStatus(503) заставляют каждый подходящий вызов вернуть пустой 503, не доходя до сети. Нужна медленность без ошибки: failureRate(0.0) и LatencyStrategy.fixed(500). Цели задаёт регулярка по полному URI, остальной трафик не меняется.

Работает синхронно и асинхронно, отмена пробрасывается в отложенный вызов, зависимостей кроме Java 11 нет. Координата com.tapadyuti:flaky-http:1.0.0, подключать в тестовый scope.

Реальную сеть библиотека не трогает: разрывы TCP и потерю пакетов проверяйте прокси.

Образ в вашем проде теперь можно проверить одной командой: из какого коммита и каким пайплайном он собран

В Packer v1.16.0 появился post-processor provenance. На каждую сборку он выпускает и подписывает attestation, то есть машиночитаемую справку о происхождении образа: коммит, репозиторий и ref, пайплайн, время сборки. Формат стандартный (in-toto с предикатом SLSA Provenance v1), поэтому такую подпись понимают и сторонние сканеры цепочки поставки.

У локальных артефактов подпись привязана к SHA-256 файла, у облачных — к builder ID и artifact ID, плюс URI реестра HCP Packer, если билдер его отдаёт.

Что делать: обновиться до 1.16.0, дописать post-processor в build-блок и поставить проверку packer verify-attestation в пайплайн деплоя перед раскаткой.

Инвалидация кеша по URL ломается на первом же обновлении товара, спасают теги

Короткий TTL кладёт базу наплывом запросов, длинный отдаёт устаревшие цены. Событийная очистка снимает выбор, но PURGE /api/products/linen-shirt заставляет помнить все адреса, которые задело одно обновление: карточку товара, листинг категории, страницу бренда. Забыли один — там висит старая цена.

Вместо адресов бэкенд проставляет в ответ теги: заголовок Surrogate-Key у Fastly, Cache-Tag у Cloudflare, значения вида product:1029, collection:summer. Прокси держит обратный индекс «тег → ответы в кеше» и по запросу на product:1029 выбрасывает их во всех точках присутствия.

Что сделать: дёргать очистку из вебхука после коммита в БД, а не до; добавить ретраи с идемпотентным ключом, иначе потерянная доставка держит устаревший ответ до конца TTL; сам TTL оставить длинным как страховку. Схема — в статье на dev.to.

Fallback на упавший сервис продаёт товар, которого нет на складе, но отличить такие места от безопасных помогает одно правило

Каталог, склад, заказы, расчёты с продавцом: любой из них может лечь, и вопрос не в том, как это предотвратить, а в том, какие запросы отдавать с деградацией, а какие обрывать. Разбор на dev.to предлагает критерий: обратима ли ошибка, если сервис угадал неверно.

Лёг каталог: отдавайте кэшированный снимок или пустую выдачу. Цена устарела на пару секунд, товар выглядит недоступным, и это чинится само, как только каталог вернётся.

Лёг склад или сервис выплат: fallback запрещён. Отгрузку и ушедший продавцу платёж не откатить UPDATE'ом, а сверка склада задним числом означает, что последнюю единицу продали пяти покупателям сразу. 503 с предложением повторить дешевле.

Что делать: пройти по своим fallback'ам и убрать те, что стоят перед необратимой операцией.

Лиз Фонг-Джонс: телеметрия это сырьё, наблюдаемость это свойство системы

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

Отсюда её формулировка: наблюдаемость это живое качество софта, вроде тестируемости или доступности, и закончить работу над ней нельзя.

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

Апгрейд control plane за одиннадцать минут и без единого человека в цикле

Как это выглядело раньше: ночь, SSH на каждую ноду, апгрейд руками и постоянный присмотр за здоровьем etcd в надежде, что кворум переживёт очередную перезагрузку.

Оливье Кальци, Golden Kubestronaut, описывает пайплайн, который он построил, чтобы этой ночи больше не было, и, главное, как он проверил, что тот действительно работает.

Ценность материала в проверке, а не в схеме: одиннадцать минут от старта до готового обновлённого кластера, ноль людей. Прочитать стоит до того, как планировать следующий апгрейд вручную.

CISA добавила семь эксплуатируемых уязвимостей: SonicWall на 10,0 и Artifactory на 9,8

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

CVE-2026-83548 в SonicWall SMA 1000 с оценкой 10,0 даёт неаутентифицированному атакующему доступ к чувствительным функциям через подделку запроса на стороне сервера. CVE-2026-9586 в Sangoma Switchvox, 9,3, позволяет одним запросом выполнить произвольный SQL против PostgreSQL и дойти до выполнения кода.

Первым делом стоит закрыть CVE-2026-82329 в JFrog Artifactory на 9,8: при конфигурации по умолчанию неаутентифицированный атакующий с сетевым доступом получает права администратора. Если Artifactory смотрит внутрь периметра, это ваш случай.

tfpolicy переносит правила управления в HCL, тот же язык, что и сама инфраструктура

HashiCorp выпустила tfpolicy в публичную бету на HCP Terraform. Платформенные команды пишут правила на HCL вместо отдельного инструмента с отдельным синтаксисом.

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

Смысл в том, чтобы убрать из стека второй язык политик и приблизить управление к рабочему процессу, который у команды уже есть. Если у вас сейчас OPA рядом с Terraform, это повод сравнить.

Запустить kubectl expose умеют все, объяснить, что при этом произошло, меньше десяти процентов

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

Гайд идёт снизу вверх: как назначаются IP подов и почему они работают между нодами, как kube-proxy реализует ClusterIP через правила iptables, как Ingress маршрутизирует внешний трафик через один балансировщик и как сетевые политики дают микросегментацию под требования SOC2 CC6.1.

Финал про Cilium и то, как eBPF заменяет всё перечисленное на более быстрый и наблюдаемый вариант. Открыть стоит перед тем, как в следующий раз спрашивать, почему под не достучался до сервиса.

SpaceWeb стукнуло 25, и вместе с Типичным программистом компания решила не только вспомнить прошлое, но и заглянуть вперёд.

В анкете школьные вопросы про спорт, друга и обои на рабочий стол соседствуют с историей аськи, скайпа и биткоина — всем, чем жил рунет с 2001 года. Здесь же история рунета за 25 лет и самой компании.

CoHDI даёт Kubernetes подключать и отключать PCIe-устройства на живой ноде

Проект приняли в песочницу CNCF. Запустили его в марте 2025 года совместно Red Hat, FSAS, Fujitsu, IBM Research и NTT, занимается он компонуемым железом в дезагрегированной инфраструктуре.

Практически это динамическое подключение и отключение устройств PCIe на уровне хоста через Dynamic Resource Allocation прямо на нодах Kubernetes. Железо перестаёт быть намертво привязанным к машине.

Где это даёт выигрыш: в инференсе больших моделей с разделением фаз, где prefill упирается в вычисления, а decode в память, и в агентных сценариях, где потребности меняются от шага к шагу. Заявка на заметную экономию энергии отсюда же.