Библиотека девопса | DevOps, SRE, Sysadmin

🍭 Топ-вакансий для девопсов за неделю SRE/DevOPS инженер до 500 000 ₽ Senior DevOps-инженер от 4700 до 5700 $ DevOps-инженер до 400 000 ₽ AppSec инженер на удалёнку Бустер — Офис у вас дома. ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

🕷 Забытые ресурсы едят деньги и место Kubernetes не удаляет ресурсы автоматически. Создали тестовый Deployment, Service, LoadBalancer — забыли удалить. Через месяц в кластере 50 неиспользуемых объектов. Что происходит Service с типом LoadBalancer создаёт внешний балансировщик в облаке. Вы платите за него каждый день. PersistentVolumeClaim держит диск, даже если под давно удалён. ConfigMap и Secret захламляют namespace. Как исправить Добавьте лейблы всем ресурсам:

metadata:
  labels:
    owner: team-backend
    purpose: experiment
    expires: 2025-11-15

Теперь можно найти всё, что создала команда: kubectl get all -l owner=team-backend. Или всё, что просрочено. Настройте сборку мусора. Kubernetes удалит зависимые объекты, если удалить владельца. Используйте Kyverno для автоматического удаления ресурсов. Делайте аудит раз в неделю: kubectl get all --all-namespaces. Ищите незнакомые имена, странные namespace. Удаляйте то, что не нужно. 🐸 Библиотека devops'a #арсенал_инженера

Open Source в действии: Runtime Radar — первый в России инструмент для защиты контейнерных сред на базе eBPF и Tetragon. 📆 11 ноября, 14:00 (МСК), онлайн, бесплатно Контейнеры ускорили DevOps, но открыли новые векторы атак. Узнай, как Runtime Radar помогает выявлять угрозы в реальном времени, расследовать инциденты и защищать Kubernetes без сложной настройки. Что вас ждёт: ✅ демонстрация Runtime Radar в действии; ✅ интеграция в SOC и мониторинг кластеров; ✅ инсайды от команды PT о развитии проекта. Open Source — код и документация доступны на GitHub. Присоединяйтесь и сделайте свою контейнерную инфраструктуру прозрачной и защищенной. 👉🏻 Регистрация на вебинар

⚙️ Окружение работает локально, но падает в CI Знакомая ситуация: код запускается на ноутбуке, а в CI он сразу же ломается. Причина почти всегда в окружении — где-то не хватает переменной, токен истёк, или указан неправильный регион. Перед тем как запустить джоб, убедитесь, что все критичные переменные на месте и имеют смысл:

# Проверяем, что все нужные переменные заданы
required=(DB_URL OAUTH_CLIENT_ID OAUTH_SECRET REGION)
for v in "${required[@]}"; do
  [ -n "${!v}" ] || { echo "::error::$v missing"; exit 78; }
done

Добавьте это в начало вашего скрипта CI. Код проходит по списку переменных и падает, если какая-то не установлена. 🐸 Библиотека devops'a #арсенал_инженера

⚡️ Devuan 6 Excalibur Devuan выпустил шестую версию своего дистрибутива. Это операционная система для тех, кто предпочитает OpenRC или runit вместо systemd. Новая версия основана на Debian 13 Trixie и получит поддержку до конца жизненного цикла Debian — в течение нескольких лет. Главное изменение — теперь обязателен merged-/usr, то есть директория /usr сливается с корневой директорией. Если обновляетесь со старых версий, нужно сначала установить пакет usrmerge в Daedalus, а потом уже переходить на Excalibur. ➡️ Анонс обновления 🐸 Библиотека devops'a #пульс_индустрии

😊 Dev и prod — разные миры, но у вас одинаковые манифесты Команды копируют манифесты из dev в prod, чтобы было проще. Но в деве 2 реплики и 128Mi памяти хватает. В продц нужно 20 реплик и 2Gi памяти. Что происходит В dev запустили 10 реплик для теста — кластер упал. В prod оставили 2 реплики — сервис не держит нагрузку. Или забыли поменять ConfigMap с URL базы — prod подключился к dev-базе. Как исправить Используйте kustomize. Создайте base с общими настройками, а окружения описывайте в overlays:

base/
  deployment.yaml
  service.yaml
overlays/
  dev/
    kustomization.yaml
  prod/
    kustomization.yaml

В overlay переопределяете replicas, resources, ConfigMap, Secrets. В dev можете вообще не использовать Secrets — подойдёт mock-конфиг. В prod — настоящий Secret из Sealed Secrets или внешнего Vault. 🐸 Библиотека devops'a #арсенал_инженера

🔭 Долгоживущие флаги Разработчик создаёт флаг для плавного выката новой фичи. Две недели максимум — думает он. Три месяца спустя флаг всё ещё живёт в кодовой базе. Теперь там две логики работы: старая и новая. Если что-то сломается, непонятно, что именно. Никто не удаляет флаг, потому что вдруг кто-то им пользуется. Как это решить Добавляем в каждый флаг срок жизни — дату, после которой он должен исчезнуть. Не данные флага, а сам код его обработки. И конвейер CI останавливает сборку, если срок прошёл.

new_feature_flag:
  owner: web-platform
  created: 2025-09-08
  expires: 2025-11-01

После даты expires случается одно из двух: • CI выдаёт предупреждение на третий день просрочки • CI ломает сборку, если просрочка больше недели Разработчик не может игнорировать проблему, потому что его коммиты просто не пройдут. Проводите flag burn-down — 15-минутный митинг, где смотрите, какие флаги уже 100% включены в прод. 🐸 Библиотека devops'a #арсенал_инженера

Вышла версия Grafana Mimir 3.0 — база данных временных рядов для метрик. Главное изменение — разделение путей чтения и записи. Раньше один компонент отвечал за обе операции, поэтому тяжёлые запросы замедляли поступление новых данных. Теперь между ними встал Kafka как буфер, и каждый путь масштабируется независимо. Вторая важная фишка — новый Query Engine для Mimir. Вместо загрузки всех данных в память, он обрабатывает выборку потоком и берёт только необходимые точки на каждом шаге. ➡️ Блог разработчиков 🐸 Библиотека devops'a #пульс_индустрии

👨‍💻 kubectl logs — это не логирование kubectl logs показывает логи только из работающих или недавно упавших контейнеров. Логи лежат на диске ноды. Контейнер удалился, нода перезагрузилась, логи ротировались — всё пропало. Что происходит Под упал ночью. Утром вы приходите разбираться — логов нет. Или под был в namespace с агрессивной политикой очистки. Или кто-то удалил Deployment. В production это значит, что вы не узнаете, почему сервис лёг в 3 часа ночи. Как исправить Поднимите централизованное логирование. Fluentd или Fluent Bit собирают логи со всех подов и отправляют в хранилище — Elasticsearch, Loki, S3. Пример sidecar с Fluent Bit:

containers:
- name: app
  image: your-app:1.0
- name: fluent-bit
  image: fluent/fluent-bit:latest
  volumeMounts:
  - name: varlog
    mountPath: /var/log

Если нужна корреляция логов с метриками — добавьте OpenTelemetry. Если нужны трейсы — Jaeger. Но начните с простого: соберите логи в одном месте. 🐸 Библиотека devops'a #арсенал_инженера

🤩 Апгрейднули cp Когда Вы копируете большую папку командой cp -r, Вы не видите, что происходит. Процесс может занять часы, а Вы сидите в неведении — копируется ли вообще? Сколько осталось? Если что-то пойдёт не так, часто нужно начинать заново. rsync — это утилита для копирования и синхронизации файлов. Главное преимущество: показывает прогресс, сохраняет все атрибуты файлов и умеет возобновлять прерванные копирования. Базовая команда:

rsync -av --progress /path/to/src/ /path/to/dest/

-a — архивный режим. Cохраняет права, временные метки, символические ссылки. -v — подробный вывод --progress — показывает прогресс для каждого файла Если Вы копируете по сети на удалённый сервер, добавьте флаг -z для сжатия:

rsync -avz --progress /local/path/ user@server:/remote/path/

Если копирование прервалось, просто запустите ту же команду ещё раз — rsync пропустит уже скопированные файлы и продолжит с того же места. 🐸 Библиотека devops'a #root@prompt

🍷 Wine: 32 бита на 64-битной системе Вышла версия Wine 10.18. Основной фокус — доработка WoW64 режима, который позволяет запускать 32-битные Windows-приложения на 64-битной Linux-системе, имитируя нативный Windows WoW64 подсистему. OpenGL теперь использует Vulkan для отображения в памяти в WoW64 режиме, добавлена поддержка SCSI pass-through, реализована API синхронизационных барьеров (нужна для некоторых игр, например The Obsessive Shadow), поддержка WinRT исключений. Плюс 30 багфиксов для приложений и игр. ➡️ Анонс 🐸 Библиотека devops'a #пульс_индустрии

👨‍💻 Без probes Kubernetes не знает, что ваше приложение умерло Kubernetes считает контейнер живым, пока процесс не завершился. Приложение может зависнуть, тупить, инициализироваться 5 минут — Kubernetes всё равно отправит трафик. Что происходит Liveness probe проверяет, жив ли контейнер. Если нет — перезапускает. Readiness probe проверяет, готов ли контейнер принимать трафик. Если нет — убирает из Service. Без readiness probe пользователи попадут на ещё не прогретое приложение. Получат таймауты, 500-е, странные ошибки. Вы будете часами искать баг, которого нет. Как исправить:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Добавьте в приложение два эндпоинта. /healthz отвечает 200, если приложение работает. /ready отвечает 200, если приложение загрузилось и готово обрабатывать запросы. 🐸 Библиотека devops'a #арсенал_инженера

🔒 Consul 1.22 и MCP-сервер для управления через AI HashiCorp анонсировал релиз Consul 1.22 и новый MCP-сервер, который меняет способ взаимодействия с платформой service mesh. Теперь можно управлять сервисами, health checks и конфигурацией через обычный разговор с AI-ассистентом. Сам Consul 1.22 получил поддержку IPv6 (требование для федеральных агентств США), улучшенную SSO-аутентификацию через private key JWT вместо client_secret, и расширенную телеметрию для IPv6-трафика. ➡️ Блог разработчиков 🐸 Библиотека devops'a #пульс_индустрии

🐸 Библиотека devops'a #пятничный_деплой

📰 Шесть непростых дней Вспоминаем что было за прошедшую рабочую неделю. — Критический баг в Ubuntu 25.10 — NGINX Unit больше не разрабатывается — Bottles 51.25 — Fedora Linux 43 — 14 вопросов, после которых вам не перезвонят #дайджест_недели

😮 Шестидневка позади Выдохнули — самая насыщенная неделя завершена. Теперь время для перезагрузки: встречи с друзьями, хобби, любимые сериалы — всё, что поможет восстановить силы. 💬 Как вы справились с этой неделей? Что первым делом сделаете в выходные? Рассказывайте в комментариях 👇 🐸 Библиотека devops'a #холиварня

📎 Боремся с infra-flake Когда вы запускаете автоматические тесты или задачи, иногда возникают ошибки, связанные с инфраструктурой — с сетью, временными сбоями серверов или сбоями среды выполнения. Они проявляются как короткие перебои или ошибки 5xx. В таких случаях есть эффективный подход: сделать автоматическую повторную попытку один раз. Почему это работает? Обычно проблема — не в вашем коде, а в инфраструктуре. Если перезапуск помогает и задача проходит успешно, значит ошибка — временная и связана с сетью или сервером, а не с самим программным продуктом. Пример:

jobs:
  tests:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      max-parallel: 4
    steps:
      - uses: actions/checkout@v4
      - name: Run tests with one retry on infra errors
        run: |
          set -e
          for i in 1 2; do
            npm test && break || {
              if grep -qE "ENETUNREACH|ECONNRESET|502 Bad Gateway" test.log; then
                echo "Retrying due to infra indicators..."
                sleep 10
              else
                exit 1
              fi
            }
          done

Такой подход помогает разграничить плохие ошибки, вызванные внешней инфраструктурой, от серьезных багов в коде. 🐸 Библиотека devops'a #root@prompt

☕️ Gitea 1.25.0 Gitea — это бесплатная платформа для хостинга и управления Git-репозиториями. Что нового: • Добавлен предварительный просмотр 3D-файлов и CAD-файлов. • Поддерживаются email-уведомления о результатах CI/CD. • Улучшена SSH-подпись коммитов и интеграция с OpenID Connect. • Админ-панель оптимизирована: архивы исключены из бэкапов, улучшена настройка эмодзи. • Удалены устаревшие источники аутентификации. ➡️ Release notes 🐸 Библиотека devops'a #пульс_индустрии

📎 Забыли про requests и limits — получили OOMKilled Kubernetes не требует указывать requests и limits для CPU и памяти. Поды запускаются и без них. Но когда кластер растёт, начинаются проблемы. Scheduler не знает, сколько ресурсов нужно поду. Он пихает на одну ноду 20 подов, которые съедают всю память. Результат — OOM killer убивает случайные поды. Или наоборот: один под жрёт все ресурсы, остальные задыхаются. Как исправить:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "200m"

Начните с минимальных значений. Запустите под, посмотрите kubectl top pods. Увидите реальное потребление — скорректируете цифры. Если нагрузка скачет, добавьте HorizontalPodAutoscaler. 🐸 Библиотека devops'a #арсенал_инженера