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

Секрет для systemd-сервиса можно передать файлом Пароль в Environment= становится значением переменной и по умолчанию наследуется дочерними процессами. У systemd есть другой механизм: LoadCredential= загружает данные, а сервис получает файл в каталоге $CREDENTIALS_DIRECTORY. В unit-файле путь к этому каталогу доступен через %d. Приложение должно уметь читать секрет из файла. Доступ ограничивается пользователем сервиса, а mount namespacing, например через PrivateMounts=, скрывает каталог от других сервисов. Это не защита от root или уже скомпрометированного процесса, которому секрет выдан. Обычный LoadCredential= не шифрует исходный файл на диске. Для заранее зашифрованных данных есть LoadCredentialEncrypted= с расшифровкой при активации сервиса. Шифрование может опираться на TPM2, ключ хоста или их сочетание. Открытый пароль в SetCredential= оставлять нельзя: unit-файлы доступны для чтения. Перед внедрением сверьте поддержку параметров в установленной версии systemd. После смены секрета отдельно проверьте, какие данные читает живой процесс, не выводя значение в лог. Credentials не обеспечивают автоматическую ротацию внешнего ключа.

ALB продолжает слать трафик, когда все targets стали unhealthy Статус unhealthy у всех бэкендов не гарантирует прекращения запросов. У AWS Application Load Balancer есть режим fail-open: если в target group остались только нездоровые зарегистрированные targets во всех включённых зонах доступности, запросы направляются ко всем этим targets по алгоритму балансировки. Поэтому health check нельзя использовать как защиту, которая обязательно перекроет доступ к приложению. И провал всех проверок сам по себе не гарантирует клиенту ответ 503. Это поведение именно ALB, его нельзя автоматически переносить на NLB или пустую target group. При разборе смотрите причины Target.Timeout, Target.ResponseCodeMismatch и Target.FailedHealthChecks. У health check собственные протокол, порт, путь и пороги последовательных успехов и неудач. Проверка может не проходить, пока часть клиентских запросов всё ещё обрабатывается. AWS описывает fail-open в правилах health checks. Проверить своё допущение можно на отдельной тестовой группе: одновременно провалить проверки всех targets и сопоставить причины статусов с фактическими ответами клиенту.

Нулевое время I/O в PostgreSQL ещё не доказывает быстрый диск В PostgreSQL 18 счётчики операций в pg_stat_io растут, а read_time и write_time остаются нулевыми. Сначала проверьте измерение времени: для таблиц и индексов нужен track_io_timing, для WAL — track_wal_io_timing. При выключенном измерении эти времена равны нулю. Представление содержит накопленные данные всего кластера с разбивкой по backend_type, object и context. Неприменимые операции дают NULL, а бессмысленные сочетания вообще не представлены строками. Это отличается от нулевого замера. Для диагностики сравните два снимка за нужный интервал в разных транзакциях и проверьте stats_reset. Длинная транзакция при стандартных настройках удерживает прочитанную статистику в кеше. Если timing включили позже последнего сброса, нельзя делить накопленное время на все операции с момента сброса. У самого измерения есть накладные расходы. Даже ненулевые времена не отделяют чтение из page cache ОС от обращения к устройству. Поэтому pg_stat_io сопоставляют с метриками ОС за тот же интервал, прежде чем делать вывод о диске.

Смена DNS ещё не означает смену upstream в NGINX DNS уже возвращает новый адрес бэкенда, но запросы прокси продолжают приходить на старый. Проверка через dig показывает ответ DNS, а не адрес, который фактически использует NGINX. Для динамического обновления есть параметр resolve у server в группе upstream. Группе нужна общая память через zone, а в http или соответствующем upstream — настроенный resolver. В открытой версии NGINX этот механизм доступен начиная с 1.27.3. До неё он требовал коммерческой подписки. По умолчанию ответы кешируются на срок TTL, параметр valid позволяет его переопределить. Для resolver используйте DNS-сервер в доверенной защищённой сети. Обновление адреса не означает мгновенного разрыва уже установленных соединений. Проверять результат лучше контролируемой сменой DNS на стенде: после срока кеширования посмотреть по логам бэкендов или сетевым данным, куда идут новые запросы. Условия работы resolve описаны в документации upstream-модуля.

Ротация Docker-логов не применяется к старым контейнерам В daemon.json добавили ограничения, Docker перезапустили, а лог работающего контейнера продолжает расти. Изменение драйвера по умолчанию и его опций действует только на вновь создаваемые контейнеры. Существующие сохраняют настройки, с которыми были созданы. У стандартного json-file ротации по умолчанию нет. Если оставляете этот драйвер, в log-opts можно задать max-size со значением "10m" и max-file со значением "3". Даже числовые значения опций в этом JSON должны быть строками. Проверьте HostConfig.LogConfig конкретного контейнера через docker inspect: настройка демона сама по себе не доказывает, что ограничение работает. Для применения новых опций контейнер нужно пересоздать через обычную процедуру развёртывания с сохранением данных и доступности. Затем проверить настройки и рост файлов на тестовом логировании. Для обычных сценариев вне Kubernetes Docker рекомендует драйвер local, у которого ротация уже включена. Перед заменой проверьте совместимость сборщика логов с его форматом.

PSI показывает, сколько времени Linux теряет в ожидании ресурсов Задержки сервиса растут, а процент загрузки CPU не объясняет причину. В Linux можно посмотреть /proc/pressure/cpu, memory и io: PSI измеряет время, когда задачи не могут продолжить работу из-за нехватки ресурса. Строка some — доля времени, когда ждёт хотя бы часть задач. full — когда одновременно ждут все не простаивающие задачи. avg10, avg60 и avg300 показывают проценты за окна 10, 60 и 300 секунд, total — накопленное время в микросекундах. Системный CPU full не определён и с ядра 5.13 возвращает ноль для совместимости. Сопоставьте давление на память и I/O с задержками сервиса. При CONFIG_CGROUPS=y и смонтированной cgroup v2 те же показатели доступны в memory.pressure и io.pressure конкретной группы: так проще отделить её проблему от состояния всего узла. Универсального безопасного порога здесь нет. PSI помогает найти периоды ожидания, а причину и эффект изменений проверяют по метрикам нагрузки и пользовательской задержке.

Grafana IRM сохраняет хронологию инцидента вместе с сообщениями команды После восстановления сервиса приходится вспоминать, когда начались ошибки, кто предложил откат и почему одну из гипотез отбросили. Часть ответов остаётся в переписке. В Grafana Cloud IRM сообщения из Slack можно добавлять в хронологию инцидента реакцией с эмодзи робота. Вместе с текстом сохраняются автор и время. Так полезное наблюдение попадает в запись сразу, пока команда ещё разбирается с проблемой. К записи привязаны оповещения, панели и данные расследования. Grafana Assistant использует этот контекст для гипотез. Участники могут смотреть источники, опровергать предположения и возвращать их на проверку. Такая история помогает подготовить разбор после инцидента: восстановить последовательность решений и найти пробелы в процессе. Связи со Slack и другими сервисами нужно настроить заранее. Вывод помощника остаётся гипотезой, которую команда проверяет по данным. Подробнее ДевоПсы

CompositePodGroup задаёт общие правила для вложенных групп подов Распределённой задаче могут одновременно требоваться четыре рабочих пода и один управляющий. Если разместить только часть, ресурсы будут заняты, а полезная работа не начнётся. В Kubernetes 1.37 появился CompositePodGroup. Он объединяет дочерние группы в иерархию: каждая задаёт собственное минимальное количество подов, а родитель определяет, сколько групп должно быть готово к размещению. Планировщик рассматривает дерево целиком. Пока ограничения родителя не выполняются, частичного размещения этой иерархии не происходит. На разных уровнях можно задать и ограничения топологии. Например, всю задачу разместить в одной зоне доступности, а поды каждой рабочей группы — в пределах одной стойки. Новый CompositePodGroup использует API scheduling.k8s.io/v1alpha3. Его стоит отдельно проверять на тестовой нагрузке: переход базовых Workload и PodGroup в beta не делает все связанные возможности стабильными. Подробнее ДевоПсы

Перед закрытием HCP Vagrant нужно перенести образы и каталог их версий HashiCorp закрывает HCP Vagrant поэтапно. Создание новых образов и реестров прекращено с 1 октября. Поддержка и обслуживание заканчиваются 2 ноября, работа сервиса — 31 декабря 2026 года. Проверьте, откуда команда скачивает образы: ссылки в Vagrantfile, задачи CI/CD, скрипты и инструкции для новых сотрудников. Отдельно учтите собственные публичные и закрытые образы и тех, кто от них зависит. Для переноса нужны файлы .box и метаданные каталога. В них хранятся версии, провайдеры виртуализации, архитектуры, адреса загрузки и контрольные суммы. Копирования одного последнего образа может оказаться недостаточно. После переноса проверьте загрузку нужных версий с чистой машины и из CI. Локальный кеш способен скрыть неработающую ссылку. Закрытие касается облачного сервиса. Vagrant CLI и исходный код остаются доступны, образы можно размещать на собственном хостинге. Подробнее ДевоПсы

Kubernetes тестирует вытеснение подов ради увеличения ресурсов работающего приложения Работающий под запросил больше памяти, но на узле её нет. Увеличение ресурсов остаётся в состоянии Deferred, хотя сам запрос допустим. Появление свободного узла в кластере не добавляет памяти на текущем. В Kubernetes 1.37 появилась альфа механизма, который позволяет планировщику освобождать место для такого увеличения. Он может вытеснить менее приоритетные поды с нужного узла, чтобы запрос более важного приложения выполнился. Возможность включается через InPlacePodVerticalScalingSchedulerPreemption. Это экспериментальная функция, её нужно проверять отдельно от уже стабильного изменения ресурсов работающего пода. Приоритеты здесь влияют на доступность соседних сервисов. До включения проверьте, кого допустимо вытеснять, и что произойдёт с этой нагрузкой после остановки. Механизм помогает преодолеть нехватку свободной ёмкости на узле. Запрос, превышающий возможности самой машины, он выполнить не сможет. Подробнее ДевоПсы

OpenTelemetry позволяет постепенно переходить на новые метрики процессов Обновление коллектора может оставить пустые панели, даже если сбор данных продолжает работать. Достаточно изменения имени метрики, её типа или атрибута, на который опирался запрос. В Collector Contrib 0.160.0 сборщик процессов в hostmetrics получил предварительную версию новых соглашений о метриках. Переход управляется отдельными переключателями для включения новых и отключения старых определений. Есть деталь для проверки совместимости: когда имя совпадает, две независимые метрики не всегда отправляются параллельно. При переименовании атрибута могут передаваться оба атрибута в одной метрике. При смене типа приоритет получает новый тип. Поэтому сначала проверьте запросы, правила оповещений и ожидаемые атрибуты на тестовом коллекторе. Простого сравнения списка имён недостаточно. Это кандидат в стабильную версию метрик процессов. Объявлять весь приёмник hostmetrics стабильным пока рано. Подробнее ДевоПсы

GitHub автоматизировал отзыв неподтверждённых доступов к репозиториям Внешний подрядчик закончил работу, а доступ к репозиторию остался. Если проверка зависит от памяти владельца, такие разрешения легко переживают сам проект. В GitHub для одной из внутренних организаций сделали Evergreen. Раз в квартал приложение открывает задачу со списком внешних участников. Ответственный отмечает тех, кому доступ ещё нужен, и закрывает её. Неподтверждённые разрешения отзываются. Если ответа нет, после установленного срока отзывается весь доступ из списка. На проверку предусмотрены две недели. Случайный ручной запуск не должен сокращать этот период. Состояние проверок хранится в JSON-файлах в Git. По истории изменений видно, кто принял решение и что произошло. Отдельный процесс предупреждает о заброшенных репозиториях и затем архивирует их. Авторы показывают внутреннюю реализацию на GitHub App, Actions и задачах. Этот процесс можно взять за основу для собственной проверки доступов. Подробнее ДевоПсы

Grafana ограничивает рост числа рядов при автоматической оптимизации метрик Автоматическая агрегация метрик экономит ресурсы, пока кто-нибудь не запросит подробные данные обратно. Восстановление детализации увеличивает число активных временных рядов. В Adaptive Metrics появился режим cost-first. Сначала применяются рекомендации, уменьшающие число рядов. Затем система рассматривает увеличивающие рекомендации, начиная с самых небольших, и останавливается перед превышением исходного количества. Допустим, есть три изменения: −10, +5 и +10 рядов. Первые два пройдут, последнее останется на рассмотрение. Итог цикла — на пять рядов меньше. Режим coverage-first применяет все рекомендации, включая восстановление детализации для востребованных данных. Для критичных метрик это может быть предпочтительнее. Режимы можно выбирать отдельно по сегментам: например, командам или окружениям. При этом ограничение прогнозируемого числа рядов в цикле не задаёт жёсткий потолок всему счёту Grafana Cloud. Подробнее ДевоПсы

GitLab Secrets Manager выдаёт секреты только нужным задачам CI/CD Ключ для выкладки в production не нужен задаче, которая проверяет форматирование кода. Если обе получают его через общую переменную, компрометация любой из них расширяет область утечки. В GitLab Secrets Manager задача явно запрашивает секрет через secrets: в .gitlab-ci.yml. Доступ можно ограничить веткой, её защищённостью и целевым окружением. Например, разрешить чтение только из защищённой ветки для production/*. Значение хранится в OpenBao. Задача получает его по короткоживущему токену, а в окружение передаётся путь к временному файлу. В аудите чтения сохраняются идентификаторы задачи и конвейера. Это не отменяет ротацию: если задача успела прочитать и передать ключ злоумышленнику, ключ нужно заменить. Динамические учётные данные пока заявлены как следующая возможность. Secrets Manager доступен в GitLab 19.5 на Premium и Ultimate для GitLab.com и собственной установки. Поддержка Dedicated появится позже. Подробнее ДевоПсы

Kubernetes 1.37 снижает расход памяти при чтении больших списков из etcd При запуске API-сервер заполняет кеш, считывая состояние ресурсов из etcd. Пагинация ограничивает число объектов в ответе, но размер объектов бывает разным. Страница с крупными Pod всё ещё может потребовать много памяти. RangeStream передаёт данные порциями с учётом их размера. etcd не собирает весь ответ заранее, а API-сервер декодирует и освобождает очередную порцию по мере чтения. Это снижает пики потребления памяти с обеих сторон. Нужны Kubernetes 1.37 и etcd 3.7 или новее. Переключатель EtcdRangeStream в 1.37 включён по умолчанию. Со старой версией etcd сохранится прежний способ чтения. Проверить, используется ли потоковое чтение, можно по счётчику:

etcd_request_duration_seconds_count{operation="listStream"}

Ненулевое значение подтверждает, что такие запросы выполнялись. Полезная проверка после обновления большого кластера. Подробнее ДевоПсы

Как собрать уязвимости нескольких групп GitLab в одном месте Для общего отчёта по безопасности команда выгружает данные из разных групп верхнего уровня и сводит их в таблице. К моменту встречи часть результатов уже устаревает. В GitLab 19.4 появилась панель безопасности уровня организации: общий показатель риска, графики и детализация по проектам. Данные сторонних сканеров также можно включить через поддерживаемые SARIF-отчёты. Функция доступна в бета-версии на GitLab.com Ultimate. Нужна организация с несколькими группами верхнего уровня, роль владельца (Owner), включённые расширенный поиск и расширенное управление уязвимостями. Источник данных — результаты сканирования проектов. Поэтому перед оценкой сводного риска проверьте, что в основной ветке действительно завершались нужные проверки. Общая панель помогает увидеть приоритеты, но отсутствие находок у проекта без сканирования не означает отсутствие проблем. Подробнее ДевоПсы

Как разделить синтетические проверки между командами Сотни HTTP-, DNS- и браузерных проверок лежат в одном списке. Непонятно, кто отвечает за конкретный сервис и какие проверки можно отключить на время обслуживания тестового окружения. В Grafana Cloud Synthetic Monitoring появились папки. Проверки можно группировать по командам, сервисам и окружениям, использовать права папок вместе с ролями Synthetic Monitoring и применять действия сразу к группе. Есть нюанс для автоматизации: проверки, созданные через API или Terraform без указания папки, попадают в стандартную Synthetic Monitoring. Удаление папки также не удаляет проверки — они переезжают в стандартную и продолжают работать. Если цель очистки — прекратить ненужные запросы и расходы, результат нужно проверить отдельно. Начать можно с одного сервиса: перенести его проверки, назначить права владельцам и сверить поведение массового включения и отключения. Подробнее ДевоПсы

Как видеть изменение прав ИИ-агента при проверке изменений У агента есть доступ к каталогу, API-токен и несколько разрешённых доменов. Через месяц трудно восстановить, какие права ему выдали и зачем. Docker Sandbox Kit Specification v3 описывает окружение и запросы доступа в обычном OCI-образе. В декларации входят сеть, учётные данные, тома и другие возможности. Хеш образа фиксирует содержимое вместе с этими настройками. Теперь новый домен или дополнительный секрет можно увидеть в сравнении версий при обновлении Kit. Сетевые правила также позволяют ограничивать методы и пути API, а поддерживающая спецификацию среда выполнения может подставлять настоящий секрет через прокси. Сам Kit прав не выдаёт: декларации должен применять совместимая среда выполнения. Если запустить образ без такого механизма, аннотация останется метаданными. При внедрении проверяйте фактический запрет доступа, а не только наличие правил в YAML. Подробнее ДевоПсы

Как сделать план OpenTofu понятнее до применения изменений Значение известно только после создания ресурса, поэтому в плане появляется known after apply. Иногда из-за этого нельзя вычислить count или for_each, а автоматическая проверка политики не видит достаточно данных. В OpenTofu 1.13 появились convert и семейство assume…. Они позволяют автору модуля передать дополнительные сведения: ожидаемый тип результата, отсутствие значения null или известный префикс строки. Будущий ID от этого не становится известным. Зато OpenTofu может раньше вычислить некоторые условия и проверить ограничения, для которых достаточно этих свойств. При обновлении проверьте и несовместимые изменения: поддержка WinRM для выполнения команд при подготовке ресурсов удалена, а base64gzip выдаёт немного другой результат. Встроенный статический анализ и Symbol Libraries пока экспериментальные — включать их как обязательный этап общего CI стоит после отдельного пилота. Подробнее ДевоПсы

Как управлять коллекторами OpenTelemetry без перехода на Alloy Коллекторы уже настроены через OTel YAML, но общие изменения приходится раскатывать по множеству окружений. Grafana Cloud Fleet Management теперь поддерживает управление совместимыми коллекторами OpenTelemetry через OpAMP. Можно централизованно задавать конвейеры обработки телеметрии, выбирать коллекторы для их применения и оформлять конфигурацию через Terraform. Существующий язык конфигурации OTel сохраняется. При этом локальная и удалённая конфигурации объединяются. Одинаковые имена компонентов могут привести к переопределению настроек. Fleet Management добавляет имена конвейеров к идентификаторам удалённых компонентов и обновляет ссылки, а одинаковые определения объединяет. Перед подключением всей инфраструктуры проверьте итоговую конфигурацию одного коллектора и его собственную телеметрию. Поддержка OpAMP стала общедоступной, но конкретный дистрибутив и его способ развёртывания всё равно нужно сверить с требованиями. Подробнее ДевоПсы