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

Как объединить трассы приложения и Istio через B3 После включения Istio в Jaeger появляются два дерева одного запроса: спаны приложения и Envoy не связаны. В стенде из статьи встроенный OTel-трассировщик Envoy создаёт новый корневой спан, не читая входящий traceparent. Исправление состоит из двух действий. Переключите Envoy на трассировщик Zipkin и направьте его в Zipkin-приёмник Collector на порту 9411. В приложениях добавьте b3multi в OTEL_PROPAGATORS рядом с tracecontext,baggage. После этих настроек Collector сведёт данные приложения и прокси в одну трассу. Конфигурация связки показывает оба изменения. Версии компонентов не указаны, поэтому проверьте поведение на своём стенде.

Как добавлять настройки прокси в поды EKS Fargate через Kyverno В Fargate нельзя настроить ОС узла, а контейнеры не наследуют его переменные окружения. Поэтому трафик приложений может обходить корпоративный прокси. Политика Kyverno добавляет HTTP_PROXY, HTTPS_PROXY и NO_PROXY в обычные и init-контейнеры подов из пространств имён с меткой proxy-injection: enabled. Перед внедрением составьте NO_PROXY для Kubernetes, VPC и AWS-сервисов, затем проверьте маршруты из тестового пода. Существующие поды придётся перезапустить.

Как сократить ожидание в GitLab CI с помощью дочерних пайплайнов и needs В монорепозитории полный прогон заставляет задания ждать несвязанные сборки и тесты. Вынесите конфигурации сервисов в дочерний пайплайн, а в родительском запуске добавьте strategy: depend: он дождётся дочерних заданий и вернёт общий результат. Несколько файлов в одном trigger: include GitLab объединяет в одну конфигурацию. Поэтому задания из этих файлов видят друг друга и могут через needs запускаться сразу после своих зависимостей, не ожидая завершения всей стадии. Отдельные trigger-задания создадут изолированные пайплайны, где такие связи не работают. В конфигурации из статьи выбор по изменённым файлам не настроен. Если нужен выборочный запуск сервисов, добавьте собственные правила изменений; пример используйте для организации дочернего пайплайна и зависимостей.

Как подготовить аварийный доступ к Amazon EKS без федерации При отказе провайдера идентификации администратор не получает учётные данные и не может войти в кластер, чтобы устранить причину. Резервный путь стоит создать заранее: отдельная роль в рабочем аккаунте доверяет аккаунту эксплуатации, требует свежую MFA и вызывается через sts:AssumeRole. Авторизация проходит через EKS access entries в AWS API, поэтому редактировать aws-auth через уже недоступный Kubernetes API не нужно. Сначала проверьте режим аутентификации: подходят API и API_AND_CONFIG_MAP, а переход из CONFIG_MAP необратим. Схема аварийного доступа включает шаблоны инфраструктуры как кода и две проверки: отказ без MFA и успешный вход с ней. Отдельно обеспечьте сетевой путь к приватному API кластера. Вызов роли попадёт в CloudTrail, а операции Kubernetes API можно отслеживать в CloudWatch.

Как посчитать холодный старт Go-сервиса в AWS Lambda Тёплая функция может показывать p99 в 12 мс, но при всплеске Lambda создаёт окружение для каждого конкурентного вызова: 200 холодных стартов добавят задержку 200 запросам. В примере параллельный запуск подключений к MongoDB и Redis через errgroup сокращает инициализацию с 230 до 120 мс. Измерьте Init Duration в CloudWatch отдельно от обработчика, затем рассчитайте provisioned concurrency с запасом на пик. Масштабирование запускайте минимум за пять минут: окружения разворачиваются две-три минуты. Расчёты стоимости и схема выбора помогут сопоставить задержку с ценой прогретых экземпляров.

Как вынести CI-логику из YAML в обычный скрипт Автор CI In a Box сделал box, тонкую обёртку над SSH. Управляющий узел исполняет пользовательский скрипт, а box пересылает команды машинам с нужными ОС и процессорами. В примере box create поднимает Windows-, macOS- и Linux-раннеры, а box run клонирует репозиторий и запускает тесты. Логику сборки можно держать в bash, языке проекта или системе сборки. На стороне CI остаются запуск скрипта и парк разнородных раннеров. Сложность никуда не исчезает: ОС обновляются, а лицензии и железо ограничивают выдачу машин с поминутной оплатой. Если строите такой слой сами, отдельно решите передачу аргументов и очистку процессов. SSH отправляет удалённой стороне одну строку для командной оболочки и просто соединяет аргументы пробелами, что создаёт риск инъекции. После команды также не должны оставаться запущенные процессы.

Как сохранить редкие трейсы при ограниченном бюджете Grafana Cloud Равномерная выборка по traceID сохраняет исходный перекос: самый нагруженный сервис забирает почти весь лимит, а редкие запросы других сервисов теряются. Volumetric policy в Adaptive Traces автоматически группирует трейсы по атрибутам, например service.name, status.code и k8s.cluster.name. Для каждой группы она отслеживает частоту и пересчитывает долю сохраняемых трейсов при изменении трафика. В тестах Grafana Labs такая выборка дала примерно на 25% больше уникальной информации при том же объёме хранения. Если Adaptive Traces уже настроен, вероятностную политику можно заменить volumetric policy одним нажатием. Новым пользователям её добавляет мастер настройки. Механика и ограничения подробно разобраны в статье Grafana Labs.

Как понять, почему внутренняя платформа не стала самообслуживанием Портал, CLI и golden path не снимают нагрузку с DevOps, если нестандартные конфигурации всё ещё идут через ручные заявки. Команда тогда обрабатывает исключения вместо улучшения платформы. Модель зрелости CNCF различает ручные процессы, стандартные инструменты, самообслуживание и сервисы в рабочих процессах. Проверьте повторяющиеся запросы, очередь исключений и время на ручные конфигурации. Частую операцию с одинаковыми шагами перенесите в самообслуживание: критерии уровней собраны в разборе CNCF.

Защитите PostgreSQL 18 от забытых слотов репликации В PostgreSQL 18 появился idle_replication_slot_timeout. Он инвалидирует неактивный слот после заданного срока, чтобы тот не удерживал WAL до заполнения диска. По умолчанию стоит 0: защита выключена. Начните с 3d и оставьте запас дольше планового простоя потребителя. Проверка выполняется при checkpoint, поэтому слот может прожить ещё до checkpoint_timeout. Перезапуск сервера сбрасывает отсчёт. Параметр не удаляет слот: логическую подписку придётся синхронизировать заново, а физической реплике понадобится архив WAL или пересборка. Используйте его вместе с max_slot_wal_keep_size и настройте алерт на возраст inactive_since. В разборе параметра объяснены исключения и цена инвалидации.

Как удалённая Spectre-атака обошла защиту Cloudflare Workers Cloudflare воспроизвела удалённую атаку на Workers: до 12 бит в секунду с точностью 99%. Атакующий использовал спекулятивное выполнение процессора и измерял задержки через WebSocket. Проблема затрагивала изоляцию арендаторов внутри одного процесса. Cloudflare усилила Dynamic Process Isolation, добавила песочницу V8 и изоляцию внутри процесса. Атака уже закрыта, признаков эксплуатации нет. Для собственных мультиарендных сред проверьте, отделяет ли защита подозрительный код на уровне процесса. Схема атаки и контрмеры разобраны в техническом материале Cloudflare.

Как собирать телеметрию запусков HCP Terraform и Terraform Enterprise в Grafana Cloud Агент Terraform отдаёт трассировки и метрики по OTLP, а логи пишет в стандартные потоки контейнера. Grafana Alloy принимает эти данные, читает логи через Docker Engine API и отправляет их в Grafana Cloud. Дельта-метрики нужно преобразовать в накопительные. Рабочую область HCP Terraform переключите в режим Agent и привяжите пул: иначе запусков у локального агента не будет. Конфигурация Alloy и Docker Compose есть в разборе Grafana Labs.

Как масштабировать GPU-нагрузки в Kubernetes до всплеска трафика Реактивный HPA может опоздать: в описанном инциденте порог сработал в 06:05, а первые GPU-ноды были готовы лишь в 06:45. К тому времени всплеск закончился, а пользователи увидели 15–20% ошибок. Авторы разобрали предиктивный контроллер для Kubernetes. Каждые 60 секунд он анализирует час метрик Prometheus, прогнозирует нагрузку на 10 минут вперёд и добавляет не более 20 подов в минуту. Отдельный детектор ускоряет масштабирование, если фактический спрос превысил прогноз. В теневом режиме 85% прогнозов уложились в отклонение ±10%, а детектор поймал 9 из 10 всплесков. Для проверки подхода соберите неделю метрик, неделю запускайте прогноз без масштабирования, затем задайте предел реплик и выключатель контроллера. HPA v2 можно оставить как реактивную страховку.

Как связать синтетические проверки с ошибками реальных пользователей в Grafana Cloud Синтетическая проверка показывает сбой сценария, но не его масштаб. В Grafana Cloud её можно сопоставить с Frontend Observability: ошибками JavaScript, загрузкой страниц и записями сессий. После сбоя откройте сессии для того же URL и времени: увидите число затронутых пользователей, браузер или регион и сравните их ошибку с проверкой. Страницы с частыми ошибками добавляйте в синтетические сценарии, а пороги задержки берите из реальных сессий. Подключите Faro SDK, сопоставьте метрики проверок и логи Loki с данными Faro, затем выведите статус, долю ошибок и число сессий на один дашборд. Настройка разобрана в статье Grafana Labs.

Как построить надёжную платформу для распределённого обучения В Kubernetes-задачах Atlassian неисправный RDMA-плагин оставался в CrashLoopBackOff на всех подходящих production-узлах 271 день. Задачи без явного запроса RDMA продолжали работать через сокеты без ошибок, поэтому деградацию обнаружили случайно. В тесте переход на RDMA сократил медианное время шага с 12,36 до 6,07 секунды. Платформа объединила RDMA-сеть, Lustre через CSI и ReadWriteMany PVC, привязку задач к нужным пулам узлов и gang scheduling: распределённая задача получает всех исполнителей сразу либо ждёт. Узлы с непройденной проверкой готовности не допускаются к планированию. Практический вывод из разбора Atlassian для Cloud Native Computing Foundation: проверяйте не только статус задачи. Запускайте синтетическую нагрузку и фиксируйте транспорт, путь к хранилищу и полное время обучения.

Как RFC 9234 защищает от утечек BGP-маршрутов Настройте BGP Role на каждой eBGP-сессии по отношению с соседом: customer, provider или peer; для точек обмена есть RS и RS-client. Если обе стороны объявят несовместимые роли, сессия не установится. Атрибут Only to Customer (OTC) отмечает маршрут, который дальше можно передавать только клиентам. Совместимый маршрутизатор не объявит его провайдеру или пиру, а маршрут с OTC от клиента отклонит как утечку. В разборе Cloudflare Blog объяснены механизм и ограничения внедрения. При частичном внедрении не включайте строгий режим: он отклоняет соседей без BGP Role. Если с одним соседом совмещены разные отношения, разнесите их по отдельным eBGP-сессиям и назначьте каждой свою роль.

Как подключить VM KubeVirt к Metal3 через KubeVirtBMC KubeVirtBMC даёт виртуальной машине интерфейс BMC, поэтому Metal3 и BareMetalHost управляют ею как физическим сервером. Ironic отправляет Redfish-запросы в KubeVirtBMC, а тот через API Kubernetes включает VM и подключает загрузочный образ. Для стенда понадобятся KubeVirt, Ironic, Bare Metal Operator и выключенная VM с диском, сетью и ISO. Cloud Native Computing Foundation даёт команды и манифесты для проверки Metal3 без физических серверов.

Как проверить качество телеметрии сервисов в Grafana Cloud Метрики могут поступать исправно, но без логов, трассировок, корректного service.name и меток Kubernetes расследование упрётся в тупик. Instrumentation quality в Knowledge Graph проверяет телеметрию сервисов: логи, трассировки, метрики, имена, метки Kubernetes и кардинальность метрик. Откройте Entity catalog → Instrumentation quality, отфильтруйте проваленные проверки и исправьте сервисы с низкой оценкой. Затем запустите Re-run checks. Grafana Labs показывает, как читать отчёт и устранять разрывы телеметрии.

Как перенести метрики на OpenTelemetry без массовой переделки сервисов Atlassian сохранила прежний контракт: приложения продолжили отправлять StatsD-метрики по UDP, а платформенная команда заменила сбор, приём, агрегацию и пересылку данных на собственные сборки OpenTelemetry Collector. Сборщик одновременно принимал StatsD и OTLP, поэтому команды могли менять инструментирование постепенно. Замена двух сайдкаров одним снизила среднюю загрузку CPU на 3,9% у самых дорогих сервисов Micros. Маршрутизация по идентификатору временного ряда распределила крупные сервисы между шардами, а новая агрегация сократила потребление CPU этого уровня примерно вдвое. Практический порядок: начинайте с dev- и staging-сред, непрерывно профилируйте под рабочей нагрузкой и раскатывайте по схеме 1% → 10% → 50% → 100%. Архитектура и выводы собраны в разборе миграции в блоге Cloud Native Computing Foundation.

✨ Как настроить PostgreSQL для продакшен-нагрузок

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

29 сентября эксперт Cloud․ru проведет вебинар о том, как обеспечить высокую доступность PostgreSQL в облаке. В программе:

▶️как устроен отказоустойчивый кластер в Evolution Managed PostgreSQL ▶️где проходит граница между высокой доступностью и аварийным восстановлением ▶️какую роль играет Multi-AZ-архитектура ▶️для каких задач используются реплики PostgreSQL ▶️как работают ручное и автоматическое переключение ▶️что важно учитывать при эксплуатации PostgreSQL в продакшене

Будет интересно всем, кто работает с PostgreSQL и отвечает за доступность баз данных и надежность инфраструктуры. Зарегистрироваться

Как выстроить управление инцидентами по модели Google и PagerDuty При крупном сбое мало искать первопричину: нужно одновременно снижать влияние, координировать команды и сообщать о ходе работ. В Google процесс основан на Incident Command System, системе с заранее определёнными ролями и линией подчинения. Incident Commander координирует реагирование, Operations Lead устраняет последствия и восстанавливает сервис, Communications Lead обновляет участников и заинтересованные стороны. Команды при этих ролях могут расширяться или сокращаться по мере необходимости. До следующего сбоя назначьте роли, согласуйте порядок связи, ведите журнал отладки и принятых мер, объявляйте инцидент на ранней стадии и отрепетируйте процесс. Четыре разбора и стартовый чеклист собраны в главе Incident Response на сайте Google SRE.