Что на самом деле ограничивает max_locks_per_transaction в PostgreSQL

Параметр задаёт долю общей таблицы блокировок на процесс, а не предел транзакции. По умолчанию: 64 в PostgreSQL 18 и 128 в PostgreSQL 19; изменение требует перезапуска.

Ошибка out of shared memory означает нехватку записей блокировок. Перед переходом на PostgreSQL 19 удвойте явно заданное значение: сначала обновите и перезапустите реплики, затем основной сервер, иначе применение журнала на реплике остановится.

Занятость: select count(*) from pg_locks where not fastpath. Расчёты — в статье All Your GUCs in a Row: max_locks_per_transaction.

Как выстроить управление инцидентами по модели Google и PagerDuty

При крупном сбое мало искать первопричину: нужно одновременно снижать влияние, координировать команды и сообщать о ходе работ. В Google процесс основан на Incident Command System, системе с заранее определёнными ролями и линией подчинения.

Incident Commander координирует реагирование, Operations Lead устраняет последствия и восстанавливает сервис, Communications Lead обновляет участников и заинтересованные стороны. Команды при этих ролях могут расширяться или сокращаться по мере необходимости.

До следующего сбоя назначьте роли, согласуйте порядок связи, ведите журнал отладки и принятых мер, объявляйте инцидент на ранней стадии и отрепетируйте процесс. Четыре разбора и стартовый чеклист собраны в главе Incident Response на сайте Google SRE.

Как перенести метрики на OpenTelemetry без массовой переделки сервисов

Atlassian сохранила прежний контракт: приложения продолжили отправлять StatsD-метрики по UDP, а платформенная команда заменила сбор, приём, агрегацию и пересылку данных на собственные сборки OpenTelemetry Collector. Сборщик одновременно принимал StatsD и OTLP, поэтому команды могли менять инструментирование постепенно.

Замена двух сайдкаров одним снизила среднюю загрузку CPU на 3,9% у самых дорогих сервисов Micros. Маршрутизация по идентификатору временного ряда распределила крупные сервисы между шардами, а новая агрегация сократила потребление CPU этого уровня примерно вдвое.

Практический порядок: начинайте с dev- и staging-сред, непрерывно профилируйте под рабочей нагрузкой и раскатывайте по схеме 1% → 10% → 50% → 100%. Архитектура и выводы собраны в разборе миграции в блоге Cloud Native Computing Foundation.

Как проверить качество телеметрии сервисов в Grafana Cloud

Метрики могут поступать исправно, но без логов, трассировок, корректного service.name и меток Kubernetes расследование упрётся в тупик.

Instrumentation quality в Knowledge Graph проверяет телеметрию сервисов: логи, трассировки, метрики, имена, метки Kubernetes и кардинальность метрик.

Откройте Entity catalog → Instrumentation quality, отфильтруйте проваленные проверки и исправьте сервисы с низкой оценкой. Затем запустите Re-run checks. Grafana Labs показывает, как читать отчёт и устранять разрывы телеметрии.

Как подключить 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 без физических серверов.

Как RFC 9234 защищает от утечек BGP-маршрутов

Настройте BGP Role на каждой eBGP-сессии по отношению с соседом: customer, provider или peer; для точек обмена есть RS и RS-client. Если обе стороны объявят несовместимые роли, сессия не установится.

Атрибут Only to Customer (OTC) отмечает маршрут, который дальше можно передавать только клиентам. Совместимый маршрутизатор не объявит его провайдеру или пиру, а маршрут с OTC от клиента отклонит как утечку.

В разборе Cloudflare Blog объяснены механизм и ограничения внедрения. При частичном внедрении не включайте строгий режим: он отклоняет соседей без BGP Role. Если с одним соседом совмещены разные отношения, разнесите их по отдельным eBGP-сессиям и назначьте каждой свою роль.

Как построить надёжную платформу для распределённого обучения

В Kubernetes-задачах Atlassian неисправный RDMA-плагин оставался в CrashLoopBackOff на всех подходящих production-узлах 271 день. Задачи без явного запроса RDMA продолжали работать через сокеты без ошибок, поэтому деградацию обнаружили случайно. В тесте переход на RDMA сократил медианное время шага с 12,36 до 6,07 секунды.

Платформа объединила RDMA-сеть, Lustre через CSI и ReadWriteMany PVC, привязку задач к нужным пулам узлов и gang scheduling: распределённая задача получает всех исполнителей сразу либо ждёт. Узлы с непройденной проверкой готовности не допускаются к планированию.

Практический вывод из разбора Atlassian для Cloud Native Computing Foundation: проверяйте не только статус задачи. Запускайте синтетическую нагрузку и фиксируйте транспорт, путь к хранилищу и полное время обучения.

Как связать синтетические проверки с ошибками реальных пользователей в Grafana Cloud

Синтетическая проверка показывает сбой сценария, но не его масштаб. В Grafana Cloud её можно сопоставить с Frontend Observability: ошибками JavaScript, загрузкой страниц и записями сессий.

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

Подключите Faro SDK, сопоставьте метрики проверок и логи Loki с данными Faro, затем выведите статус, долю ошибок и число сессий на один дашборд. Настройка разобрана в статье Grafana Labs.

Как масштабировать GPU-нагрузки в Kubernetes до всплеска трафика

Реактивный HPA может опоздать: в описанном инциденте порог сработал в 06:05, а первые GPU-ноды были готовы лишь в 06:45. К тому времени всплеск закончился, а пользователи увидели 15–20% ошибок.

Авторы разобрали предиктивный контроллер для Kubernetes. Каждые 60 секунд он анализирует час метрик Prometheus, прогнозирует нагрузку на 10 минут вперёд и добавляет не более 20 подов в минуту. Отдельный детектор ускоряет масштабирование, если фактический спрос превысил прогноз.

В теневом режиме 85% прогнозов уложились в отклонение ±10%, а детектор поймал 9 из 10 всплесков. Для проверки подхода соберите неделю метрик, неделю запускайте прогноз без масштабирования, затем задайте предел реплик и выключатель контроллера. HPA v2 можно оставить как реактивную страховку.

Как собирать телеметрию запусков HCP Terraform и Terraform Enterprise в Grafana Cloud

Агент Terraform отдаёт трассировки и метрики по OTLP, а логи пишет в стандартные потоки контейнера. Grafana Alloy принимает эти данные, читает логи через Docker Engine API и отправляет их в Grafana Cloud. Дельта-метрики нужно преобразовать в накопительные.

Рабочую область HCP Terraform переключите в режим Agent и привяжите пул: иначе запусков у локального агента не будет. Конфигурация Alloy и Docker Compose есть в разборе Grafana Labs.

Как удалённая Spectre-атака обошла защиту Cloudflare Workers

Cloudflare воспроизвела удалённую атаку на Workers: до 12 бит в секунду с точностью 99%. Атакующий использовал спекулятивное выполнение процессора и измерял задержки через WebSocket.

Проблема затрагивала изоляцию арендаторов внутри одного процесса. Cloudflare усилила Dynamic Process Isolation, добавила песочницу V8 и изоляцию внутри процесса. Атака уже закрыта, признаков эксплуатации нет.

Для собственных мультиарендных сред проверьте, отделяет ли защита подозрительный код на уровне процесса. Схема атаки и контрмеры разобраны в техническом материале Cloudflare.

Защитите PostgreSQL 18 от забытых слотов репликации

В PostgreSQL 18 появился idle_replication_slot_timeout. Он инвалидирует неактивный слот после заданного срока, чтобы тот не удерживал WAL до заполнения диска. По умолчанию стоит 0: защита выключена.

Начните с 3d и оставьте запас дольше планового простоя потребителя. Проверка выполняется при checkpoint, поэтому слот может прожить ещё до checkpoint_timeout. Перезапуск сервера сбрасывает отсчёт.

Параметр не удаляет слот: логическую подписку придётся синхронизировать заново, а физической реплике понадобится архив WAL или пересборка. Используйте его вместе с max_slot_wal_keep_size и настройте алерт на возраст inactive_since. В разборе параметра объяснены исключения и цена инвалидации.

Как понять, почему внутренняя платформа не стала самообслуживанием

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

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

Как сохранить редкие трейсы при ограниченном бюджете Grafana Cloud

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

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

Если Adaptive Traces уже настроен, вероятностную политику можно заменить volumetric policy одним нажатием. Новым пользователям её добавляет мастер настройки. Механика и ограничения подробно разобраны в статье Grafana Labs.

Как вынести CI-логику из YAML в обычный скрипт

Автор CI In a Box сделал box, тонкую обёртку над SSH. Управляющий узел исполняет пользовательский скрипт, а box пересылает команды машинам с нужными ОС и процессорами. В примере box create поднимает Windows-, macOS- и Linux-раннеры, а box run клонирует репозиторий и запускает тесты.

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

Если строите такой слой сами, отдельно решите передачу аргументов и очистку процессов. SSH отправляет удалённой стороне одну строку для командной оболочки и просто соединяет аргументы пробелами, что создаёт риск инъекции. После команды также не должны оставаться запущенные процессы.

Как посчитать холодный старт Go-сервиса в AWS Lambda

Тёплая функция может показывать p99 в 12 мс, но при всплеске Lambda создаёт окружение для каждого конкурентного вызова: 200 холодных стартов добавят задержку 200 запросам.

В примере параллельный запуск подключений к MongoDB и Redis через errgroup сокращает инициализацию с 230 до 120 мс.

Измерьте Init Duration в CloudWatch отдельно от обработчика, затем рассчитайте provisioned concurrency с запасом на пик. Масштабирование запускайте минимум за пять минут: окружения разворачиваются две-три минуты. Расчёты стоимости и схема выбора помогут сопоставить задержку с ценой прогретых экземпляров.

Как подготовить аварийный доступ к 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.

Как сократить ожидание в GitLab CI с помощью дочерних пайплайнов и needs

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

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

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

Как добавлять настройки прокси в поды EKS Fargate через Kyverno

В Fargate нельзя настроить ОС узла, а контейнеры не наследуют его переменные окружения. Поэтому трафик приложений может обходить корпоративный прокси.

Политика Kyverno добавляет HTTP_PROXY, HTTPS_PROXY и NO_PROXY в обычные и init-контейнеры подов из пространств имён с меткой proxy-injection: enabled.

Перед внедрением составьте NO_PROXY для Kubernetes, VPC и AWS-сервисов, затем проверьте маршруты из тестового пода. Существующие поды придётся перезапустить.

Как объединить трассы приложения и Istio через B3

После включения Istio в Jaeger появляются два дерева одного запроса: спаны приложения и Envoy не связаны. В стенде из статьи встроенный OTel-трассировщик Envoy создаёт новый корневой спан, не читая входящий traceparent.

Исправление состоит из двух действий. Переключите Envoy на трассировщик Zipkin и направьте его в Zipkin-приёмник Collector на порту 9411. В приложениях добавьте b3multi в OTEL_PROPAGATORS рядом с tracecontext,baggage.

После этих настроек Collector сведёт данные приложения и прокси в одну трассу. Конфигурация связки показывает оба изменения. Версии компонентов не указаны, поэтому проверьте поведение на своём стенде.