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

Как выбрать distroless-образ для статического и динамического бинарника FROM scratch даёт пустую файловую систему. Каталоги, CA-сертификаты, данные пользователей, часовые пояса и общие библиотеки приходится добавлять вручную. Distroless уже содержит необходимый системный минимум. Для статически собранного приложения подходит gcr.io/distroless/static: около 2 МБ, без libc и менеджера пакетов. Бинарнику с зависимостью от glibc нужен base-nossl размером около 15 МБ, а при зависимости от libssl — base размером 20,7 МБ. В замере статьи Trivy нашёл в static 0 уязвимостей, а в base восемь: семь низкой и одну средней опасности. Перед сменой образа проверьте зависимости бинарника через ldd и выберите минимальный вариант с нужными библиотеками. Иерархию образов и Dockerfile для Go с CGO автор показывает в разборе iximiuz Labs.

Как завершать Pod в Kubernetes без оборванных запросов При rolling update, масштабировании или вытеснении Pod могут удалить, пока он отвечает на запрос. Для Service маршрут до экземпляра задаёт endpoint: IP-адрес Pod вместе с targetPort. В список попадают Pod, прошедшие readiness probe; при создании и удалении Pod список обновляется. Перед изменением Deployment проверьте путь остановки: 1. новый Pod принимает трафик только после readiness probe; 2. для завершаемого Pod настроен preStop; 3. у долгих задач и постоянных соединений есть отдельный сценарий завершения; 4. длительность остановки согласована с масштабированием кластера. В разборе Learnk8s показан путь Pod через kubelet, Service и endpoints, затем сценарии корректного завершения. Используйте его как чеклист для теста rolling update без оборванных соединений.

Как превратить SLO в алерты, которые не будят зря У порога ошибок есть перекос. Для SLO 99,9% за 30 дней правило Prometheus «ошибки ≥ 0,1% за 10 минут» заметит полную недоступность за 0,6 секунды, но может срабатывать до 144 раз в сутки, хотя сервис всё ещё выполнит SLO. Увеличить окно до 36 часов? Точность вырастет, зато после полной недоступности сигнал продолжит гореть 36 часов. Добавить for: 1h? Пятиминутные всплески каждые десять минут вообще не вызовут алерт, хотя съедят 35% месячного бюджета ошибок. В главе Alerting on SLOs авторы сравнивают шесть схем по точности, полноте обнаружения, времени срабатывания и сброса. Практический ориентир: откажитесь от одного фиксированного порога и длительности for; стройте правила по скорости расходования бюджета ошибок относительно SLO. Так тяжёлый инцидент даст сигнал быстрее, а незначимое событие не превратится в вызов дежурного.

А вы уже забрали свой подарок ко Дню программиста? Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/GPUR

Как проверить аварийное восстановление приложений в Kubernetes Обстоятельный разбор Cloud Native Computing Foundation отделяет резервную копию от готовности восстановиться. В трёх опытах с PostgreSQL результат сверяли с четырьмя контрольными строками, а не со статусом ресурсов. Velero показал 47 989 888 байт, хотя Completed не подтверждает запуск приложения. GitOps вернул манифесты и создал пустой том. Два исправных снимка томов с интервалом пять секунд оставили после восстановления 25 платежей без заказов. Для согласованных снимков в Kubernetes 1.36 есть VolumeGroupSnapshot, но его должен поддерживать драйвер. В статье Cloud Native Computing Foundation даны лаборатория, команды и ограничения API. Тем, кто отвечает за приложения с хранимыми данными, стоит восстановить их в чистый кластер, проверить данные и пользовательский путь, затем измерить весь процесс до переключения трафика.

eBPF убирает код трассировки из Go-сервисов, но зависит от среды выполнения Ручная инструментализация OpenTelemetry расползается по вызовам SDK, передаче контекста и служебным метаданным. Под нагрузкой она может расходовать процессорное время, а пропущенная ветка оставит дыру в трассе. eBPF-пробы цепляются к функциям Go и точкам входа HTTP и gRPC, не меняя целевой бинарник. Цена переноса логики наружу: горутина переезжает между потоками ОС, Go 1.17 перенёс аргументы со стека в регистры, а инлайнинг может убрать функцию для пробы. Трассеру нужна привязка по ID горутины и логика под соглашение о передаче аргументов каждой минорной версии Go либо отладочные данные DWARF. Перед продом проверьте точную версию Go, а также откуда трассер читает аргументы: из регистров или данных DWARF. В разборе на DEV Community остались механика проб, границы подхода и компромиссы для эксплуатации.

ZeroTier можно запустить без нативных библиотек, а на ESP32 оставить только P2P Для сервисов на .NET появилась ZtSharp: реализация ZeroTier на C# со своим стеком TCP/IP поверх виртуального Ethernet. Она не требует нативных бинарников и отдельных P/Invoke-обёрток для каждой ОС. Для ESP32 автор оставил только VL1, слой с идентификацией узлов, шифрованием, поиском пиров и обходом NAT. ZtLiteESP передаёт сообщения напрямую между узлами без виртуального Ethernet и IP-связности. Ещё один проект, ZtGenStorage, создаёт идентификаторы ZeroTier при подготовке устройства, а не на самом микроконтроллере. Перед пилотом определите границу: если устройству нужна обычная IP-связность, потребуется VL2; если достаточно прямых сообщений между узлами, можно оценить VL1-only клиент. В статье показано, как обязанности разделены между двумя слоями и тремя проектами.

Часть систем 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'ам и убрать те, что стоят перед необратимой операцией.