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

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

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

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

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

В 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 в пайплайн деплоя перед раскаткой.

Проверить, что ваши ретраи и 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 и потерю пакетов проверяйте прокси.

Две строки лога в секунду превращаются в 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 или удалённый сборщик. Плата за это — журнал на самой машине не переживёт перезагрузку.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сломанный 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZeroTier можно запустить без нативных библиотек, а на ESP32 оставить только P2P

Для сервисов на .NET появилась ZtSharp: реализация ZeroTier на C# со своим стеком TCP/IP поверх виртуального Ethernet. Она не требует нативных бинарников и отдельных P/Invoke-обёрток для каждой ОС.

Для ESP32 автор оставил только VL1, слой с идентификацией узлов, шифрованием, поиском пиров и обходом NAT. ZtLiteESP передаёт сообщения напрямую между узлами без виртуального Ethernet и IP-связности. Ещё один проект, ZtGenStorage, создаёт идентификаторы ZeroTier при подготовке устройства, а не на самом микроконтроллере.

Перед пилотом определите границу: если устройству нужна обычная IP-связность, потребуется VL2; если достаточно прямых сообщений между узлами, можно оценить VL1-only клиент. В статье показано, как обязанности разделены между двумя слоями и тремя проектами.

eBPF убирает код трассировки из Go-сервисов, но зависит от среды выполнения

Ручная инструментализация OpenTelemetry расползается по вызовам SDK, передаче контекста и служебным метаданным. Под нагрузкой она может расходовать процессорное время, а пропущенная ветка оставит дыру в трассе. eBPF-пробы цепляются к функциям Go и точкам входа HTTP и gRPC, не меняя целевой бинарник.

Цена переноса логики наружу: горутина переезжает между потоками ОС, Go 1.17 перенёс аргументы со стека в регистры, а инлайнинг может убрать функцию для пробы. Трассеру нужна привязка по ID горутины и логика под соглашение о передаче аргументов каждой минорной версии Go либо отладочные данные DWARF.

Перед продом проверьте точную версию Go, а также откуда трассер читает аргументы: из регистров или данных DWARF. В разборе на DEV Community остались механика проб, границы подхода и компромиссы для эксплуатации.