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

👋 Ansible Automation Platform 2.4 уходит на покой Red Hat объявила дату окончания поддержки для Ansible Automation Platform 2.4 — 30 июня 2026 года. Платформа вышла в июне 2023 года и стала первым релизом с Event-Driven Ansible в составе. Теперь пришло время переходить на актуальную версию. Рекомендуемая версия для обновления Ansible Automation Platform 2.6. Важный момент: прямое обновление с 2.4 на версии 2.7 и выше будет недоступно. Поэтому переход на 2.6 сейчас это правильная подготовка инфраструктуры к будущим релизам. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

Почитали тут свежий отчёт по рынку ИИ-ускорителей в РФ: оказывается, 54% компаний тормозят внедрение ИИ исключительно из-за конских цен на инфраструктуру. Ну, то есть написать пет-проект с вызовом API это задача на вечер, а вот запустить агента в продакшн так, чтобы он не сжёг бюджет отдела за неделю — суровая инженерия. По сути, сейчас мало уметь собирать RAG. Нужно считать токены, настраивать time-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов. Также в программе: — оценка качества, трейсинг и защита от деградации пайплайнов; — мультиагентные паттерны и интеграция по протоколу MCP; — локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу). Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям. Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ 62 990 ₽ за базовый тариф и 99 000 ₽ 124 990 ₽ за продвинутый трек), но стоит поторопиться — на потоке осталось всего 5 мест. 👉 Зафиксировать цену и начать собирать агентов, за которых не стыдно в проде

🏗 DevOps-вопрос с собеса Вам нужно выкатить одно и то же приложение на dev → staging → prod. Как вы это делаете? Подумайте: как передать конфиг, если образ нельзя менять? Как откатиться, если что-то пошло не так? Как доказать, что в проде крутится именно то, что прошло тесты? ➡️ Ответ 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

Давненько не было нормальных разборов по базам данных без воды По сути, когда речь заходит о масштабировании хранилищ, всё сводится к скучному пересказу официальной документации. Коллеги из AvitoTech решили пойти другим путём и 27 марта проводят митап, где покажут свои реальные шишки и технические решения. Можно прийти ногами к ним в офис, а можно просто открыть вкладку с трансляцией на втором мониторе. Что в программе: — как устроена защита чувствительных данных в DBaaS (Никита Жига выкатит внутренний чек-лист и покажет архитектуру); — в чём реальная разница между FoundationDB и Cassandra 5, если смотреть на практику и продакшн, а не на красивые статьи; — альтернативный путь масштабирования S3 (спойлер: пошли вразрез с привычными паттернами бигтеха, и это сработало). Честно говоря, доклад про S3 звучит интригующе — всегда полезно посмотреть, как пересобирают архитектуру, когда коробочные решения уже не тянут нагрузку. Регистрация на офлайн и онлайн тут 👈

⚙️ Безопасный дебаг прода в Kubernetes Типичная картина во время инцидента — инженер получает широкий доступ: cluster-admin, общий jump-бокс или долгоживущий SSH-ключ. У этого подхода два системных последствия: аудит теряет смысл, потому что непонятно, кто и что делал, а временные исключения тихо становятся постоянной нормой. Три принципа 1. Минимальные права через RBAC Вместо cluster-admin выдавать роль с конкретным набором действий, которые нужны дежурному. Привязывается к группе, а не к конкретному пользователю:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oncall-debug
  namespace: payments
rules:
  - apiGroups: [""]
    resources: ["pods", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["pods/exec", "pods/portforward"]
    verbs: ["create"]
  - apiGroups: [""]
    resources: ["pods/ephemeralcontainers"]
    verbs: ["update"]

RBAC умеет ограничивать, может ли пользователь запустить pods/exec, но не может ограничить, какие команды он выполнит внутри сессии. Это задача для отдельного слоя поверх RBAC. 2. Краткосрочные учётные данные, привязанные к личности Статичные kubeconfig с долгоживущими токенами — классический вектор компрометации. Цель: каждая сессия дебаггинга должна иметь учётные данные, которые истекают через 15-30 минут и однозначно идентифицируют конкретного человека. Два способа реализации. Вариант А — короткоживущие OIDC-токены. Большинство managed-кластеров это уже поддерживает. Достаточно настроить kubeconfig так, чтобы токен обновлялся автоматически, а не копировался вручную в конфиг:

users:
- name: oncall
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      command: cred-helper
      args: ["--cluster=prod", "--ttl=30m"]

Вариант Б — короткоживущие X.509-сертификаты. Если API-сервер доверяет клиентскому CA, можно выдавать временные сертификаты через CertificateSigningRequest API. Приватный ключ остаётся на машине инженера, в идеале в аппаратном токене.

openssl genpkey -algorithm Ed25519 -out oncall.key

openssl req -new -key oncall.key -out oncall.csr \
  -subj "/CN=user/O=oncall-payments"

После подписания CSR используем вместе с приватным ключом в kubectl. Через 30 минут сертификат протухает автоматически. 3. Just-in-time access gateway Это точка входа, которую разворачивают в кластере по запросу — на время сессии. Работает по SSH-протоколу. Инженер запрашивает доступ, получает короткоживущий OpenSSH user certificate, подключается. Gateway аутентифицирует пользователя, применяет политики и от его имени делает вызовы Kubernetes API. Сессия пишется в лог. После завершения гейт удаляется. RBAC для такого сценария выглядит так:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: jit-debug
  namespace: payments
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jit-debug
  namespace: payments
subjects:
  - kind: Group
    name: jit:oncall:payments
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: jit-debug
  apiGroup: rbac.authorization.k8s.io

Имя группы jit:oncall:payments берётся из короткоживущего сертификата или OIDC-токена — так в логах всегда видно, кто именно и к чему имел доступ. Три принципа работают как слои: RBAC определяет, что разрешено; краткосрочные учётные данные убирают риск утечки; JIT gateway даёт полный аудит каждой сессии. Каждый из них можно внедрить отдельно, не переписывая всё сразу. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

Почитали тут свежий отчёт по рынку ИИ-ускорителей в РФ: оказывается, 54% компаний тормозят внедрение ИИ исключительно из-за конских цен на инфраструктуру. Ну, то есть написать пет-проект с вызовом API это задача на вечер, а вот запустить агента в продакшн так, чтобы он не сжёг бюджет отдела за неделю — суровая инженерия. По сути, сейчас мало уметь собирать RAG. Нужно считать токены, настраивать time-travel дебаг в LangGraph и уметь роутить запросы на лету. Всё это мы учли в обновлённом курсе по разработке AI-агентов, где акцент сделан именно на AgentOps и жёсткий контроль ресурсов. Также в программе: — оценка качества, трейсинг и защита от деградации пайплайнов; — мультиагентные паттерны и интеграция по протоколу MCP; — локальный деплой Open Source под 152-ФЗ (когда данные нельзя выносить наружу). Кажется, это единственный адекватный roadmap по переходу от блокнотов к enterprise-решениям. Прямо сейчас можно урвать курс с увесистой скидкой (49 000 ₽ 62 990 ₽ за базовый тариф и 99 000 ₽ 124 990 ₽ за продвинутый трек), но стоит поторопиться — на потоке осталось всего 5 мест. 👉 Зафиксировать цену и начать собирать агентов, за которых не стыдно в проде

🔹🔹🔹🔹26 марта в 12:00 (мск) пройдет бесплатный вебинар «Сервисы шифрования в MWS Cloud Platform: возможности и сценарии использования». Разработчики сервисов расскажут: ⚫️как сервисы шифрования помогают обеспечивать безопасность данных в облаке; ⚫️какие сценарии использования сервисов доступны пользователям MWS Cloud Platform; ⚫️как использовать сервисы на практике — демонстрация от спикеров; ⚫️какие обновления сервисов стоит ожидать в ближайшее время. Вебинар будет полезен ИБ-специалистам и инженерам, работающим в облачных средах. Регистрируйтесь, подключайтесь к прямому эфиру и задавайте вопросы в чате. ⏰ 26 марта в 12:00 ➡️ Зарегистрироваться

🔄 GNOME 50 Tokyo Вышел свежий GNOME с кодовым именем «Tokyo». Это юбилейный выпуск с заметными изменениями. Родительский контроль наконец-то получил возможность устанавливать лимиты экранного времени для детских учётных записей, настраивать расписание сна и автоматически блокировать экран по достижении лимита. Также заложена основа для веб-фильтрации на уровне системного сервиса. Фронтенд пока не готов, но бэкенд уже есть. VRR и дробное масштабирование теперь включены по умолчанию. Курсор при активном VRR работает на полной частоте монитора независимо от FPS приложения. Для пользователей NVIDIA исправлены проблемы со статтерами и временем кадра. Добавлена поддержка второй версии протокола управления цветом Wayland и HDR при захвате экрана. Удалённый рабочий стол ускорили через аппаратное ускорение на базе Vulkan и VA-API. Появилась поддержка HiDPI, перенаправление камеры и аутентификация через Kerberos. Из точечных улучшений: в Files переработан пакетное переименование и ускорена загрузка миниатюр, в Calendar появился список участников событий и экспорт в ICS, в средстве просмотра документов переписан инструмент аннотаций. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🧑‍💻 Процесс, который держит Linux живым В Linux есть процесс, который никто не трогает. Не потому что он как-то защищён или спрятан. А потому что если он остановится, система упадёт целиком. Это PID 1. И чтобы понять, как Linux работает изнутри, стоит разобраться именно с ним. Что такое PID 1 и откуда он берётся Когда Linux загружается, ядро первым делом инициализирует железо и память. После этого оно запускает один-единственный процесс в пользовательском пространстве. Этот процесс получает идентификатор 1 и становится родителем для всего остального, что будет работать на машине. На большинстве современных дистрибутивов этим процессом является systemd. Проверить это можно прямо в терминале:

ps -p 1

Вывод покажет systemd с PID 1. Всё просто. Почему это важно Каждый процесс в Linux имеет родителя. Терминал запускает bash, bash запускает скрипт, скрипт запускает что-то ещё. Если подняться выше по этой цепочке, в конце всегда окажется PID 1. Упрощённый вид дерева процессов:

systemd (PID 1)
 ├── sshd
 ├── nginx
 ├── docker
 ├── cron
 └── bash
      └── команды пользователя

Есть и ещё один момент. Если какой-то процесс завершается, а его дочерние процессы остаются запущенными, они становятся сиротами. Linux автоматически передаёт их под контроль PID 1. systemd разбирается с ними сам. Что именно делает systemd systemd занимается не только стартом при загрузке. Это менеджер всей системы. Он читает юнит-файлы с конфигурацией и запускает сервисы: SSH, сеть, логирование, планировщики задач, Docker, веб-серверы. При сбое сервиса systemd может перезапустить его автоматически, остановить зависимые компоненты и записать всё в журнал. В отличие от старых SysV-систем, где сервисы стартовали строго по очереди, systemd запускает их параллельно. Именно поэтому современные Linux-системы загружаются заметно быстрее. Посмотреть всё дерево процессов и убедиться, что оно начинается с PID 1, можно командой:

pstree -p

PID 1 это не просто технический факт из учебника. Это точка, с которой начинается вся работа системы. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пятничный_деплой

🔄 systemd 260: что изменилось и что сломается Вышел systemd 260. Это юбилейный релиз, и он принёс несколько серьёзных изменений, о которых стоит знать заранее. Поддержка скриптов System V окончательно убрана. Это не сюрприз, об этом предупреждали ещё в прошлом релизе. Вместе с ней ушли systemd-sysv-generator, systemd-rc-local-generator, rc-local.service и хук systemd-sysv-install. Если у вас где-то ещё живут старые init-скрипты, самое время их переписать на нативные unit-файлы. Что появилось varlinkctl list-registry теперь показывает все публичные интерфейсы из /run/varlink/registry/. Появился новый systemd-report с экспериментальной системой репортинга через /run/systemd/report/. systemd-networkd получил секцию [MobileNetwork] для интеграции с ModemManager. systemd-vmspawn теперь умеет регистрировать виртуальные машины в пользовательском инстансе systemd-machined, а не только в системном. systemd-ask-password теперь можно запускать от обычного пользователя через политику PolKit. Добавили поддержку SCHED_EXT в CPUSchedulingPolicy юнита. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🤭 Топ-вакансий для девопсов за неделю DevOps Middle — 200 000 - 350 000₽, гибрид в Москве DevOps-инженер — от 400 000 ₽, удалёнка или офис в Москве DevOps/SRE инженер — от 270 000 ₽, гибрид в Москве ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

🔄 Вышел Bcachefs 1.37.0 Релиз Bcachefs 1.37.0 включает два компонента: ядерный модуль bcachefs-kernel-dkms и утилиты bcachefs-tools для создания, монтирования, проверки и управления файловой системой. DKMS-версия работает начиная с Linux 6.16. Главное в этом релизе — стабилизация erasure coding. Это аналог RAID 5/6 внутри самой файловой системы: данные распределяются по N дискам с возможностью восстановления при потере одного из них. Из других заметных изменений: добавлены три новые команды для работы с подразделами. • subvolume list показывает список подтомов с иерархией • subvolume list-snapshots выводит снапшоты для конкретного подраздела • subvolume reflink-option-propagate распространяет настройки reflink на вложенные файлы и каталоги. Пакеты уже доступны для Arch Linux, Debian, Ubuntu, Fedora, openSUSE и NixOS. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #локализация

👨‍💻 Синдром пятничного оффлайна Проверить мессенджеры перед выключением ноутбука, потому что «вдруг что-то случилось» — знакомо? У этого явления уже есть название. Как и у десятка других ситуаций, которые случаются с айтишниками каждый день. ➡️ Новая статья — это карьерный словарь на 14 терминов 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a

⚡️ В k8s переписали ядро, удалили 20% кода и никто не заметил Каждый образ с registry.k8s.io попал туда через kpromo. Без него ни один выпуск Kubernetes не выходит. Ядро переписали с нуля, удалили 16 000+ строк, ускорили. Пользователи не заметили ничего. Что делает kpromo Копирует образы в производственную среду, подписывает через cosign, реплицирует подписи на 20+ зеркал, генерирует аттестации происхождения по SLSA. Почему понадобился рефакторинг За 7 лет — 42 участника, 3 500 коммитов, 60+ выпусков. К 2025 производственные задания падали с ошибками лимита запросов и работали больше 30 минут. Монолитная логика мешала. Как переписывали 9 фаз, каждая — отдельный запрос на слияние. Фаза 1 — ограничение частоты с адаптивным откатом. Фаза 2 — реестр и авторизация за интерфейсами. Фаза 3 — движок конвейера: продвижение как последовательность шагов. Фазы 4–5 — проверка происхождения SLSA, выпуск v4.2.0 на обкатку. Фазы 6–9 — разделение подписи и репликации, удаление старого кода. Новый конвейер Setup → Plan → Provenance → Validate → Promote → Sign → Attest Шаги последовательны — каждый получает полный бюджет лимита запросов. Производительность Параллельное чтение 1 350 реестров: фаза Plan с ~20 мин до ~2 мин. 57% образов без подписей — пропускают, обращений к API вдвое меньше. Проверка основного реестра перед зеркалами: с ~17 часов до ~15 минут. Итоги — 40+ запросов на слияние, выпуски v4.2.0, v4.3.0, v4.4.0 — кодовая база уменьшилась на 20%, закрыто 19 задач — аттестации происхождения, сканирование уязвимостей, логика повторных попыток Команда kpromo cip принимает те же флаги и читает те же манифесты. Никто ничего не обновлял. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

Кажется, мы окончательно перешли от игрушек к суровому AgentOps Приглашаем на наш обновлённый курс по разработке ИИ-агентов. Никакой воды про «будущее нейросетей», только инженерный подход. Что внутри: — пошагово строим готовые системы на LangGraph, CrewAI и MCP; — настраиваем кэширование и роутинг, чтобы бот не сожрал токены; — разбираемся со стейтом, учимся дебажить через time-travel и прикручиваем human-in-the-loop; — выводим RAG в прод так, чтобы безопасники не завернули архитектуру из-за 152-ФЗ. В пекло скучные лекции про общую инфраструктуру — сразу фокусируемся на агентных фреймворках и написании кода. Занятия ведут бывалые лиды из Газпромбанка и Альфы, набившие шишки на реальных задачах.

Кстати, на днях мы пилили агента в прямом эфире, если пропустили — есть запись вебинара.

Сегодня последний день, когда можно забрать курс по старым ценам. Базовый тариф сейчас стоит 49 000 ₽ (вместо 62 990 ₽), продвинутый трек — 99 000 ₽ (вместо 124 990 ₽). Если не хочется отдавать всю сумму сразу, есть рассрочка. Торопитесь — на потоке осталось всего 5 мест! → Зафиксировать цену и перейти к сборке своих агентов

У «Библиотеки программиста» появился резервный канал в мессенджере MAX Он нужен исключительно для связи с теми, кто не может следить за обновлениями здесь из-за трудностей с доступом. Поэтому, если вы видите это сообщение, распространите его среди жильцов вашего ЖЭКа. Контент в MAX будет дублировать телеграмный — основной нашей площадкой был и остаётся Telegram. Надеемся, это временная мера. → Подписаться на «Библиотеку программиста» в MAX

🤨 Скоро за сохранение придётся платить. Или нет Яндекс подал в Роспатент заявку на регистрацию товарного знака на фразу «Сохранить как». Да, ту самую, которую вы нажимаете с 1983 года, когда хотите не испортить оригинал. Пользователи уже предлагают превентивно запатентовать «Отменить» и «Вставить». 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🔒 Рантайм безопасность в Kubernetes Контейнер в проде неожиданно начинает читать /etc/passwd, или кто-то запускает bash внутри пода, или процесс вдруг открывает сетевое соединение, которого раньше не было. Логи это зафиксируют, но через час, когда кто-то до них доберётся. К тому моменту уже поздно. Falco — опенсорсный инструмент для runtime-безопасности. Он работает на уровне ядра Linux через eBPF, перехватывает системные вызовы и сравнивает их с набором правил. Если правило срабатывает, Falco отправляет алерт куда вы настроили: в stdout, Slack, Kafka, syslog или любую из 50+ интеграций. Правила пишутся на простом YAML-like синтаксисе. Вот пример встроенного правила, которое срабатывает, если кто-то запускает оболочку внутри контейнера:

- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    A shell was spawned in a container
    (user=%user.name container=%container.name
    image=%container.image.repository shell=%proc.name)
  priority: WARNING

Когда условие выполняется, Falco пишет что-то вроде:

WARNING A shell was spawned in a container
(user=root container=my-app image=nginx:latest shell=bash)

Что мониторит из коробки Дефолтные правила покрывают типичные атаки и нарушения. Среди них: запись в системные директории вроде /etc или /usr, запуск привилегированных процессов внутри контейнеров, нестандартные сетевые соединения, изменения конфигурации Kubernetes, попытки читать чувствительные файлы. Кроме системных вызовов Falco умеет работать с Kubernetes Audit Logs, AWS CloudTrail, GitHub Events и Okta через плагины. То есть вы можете мониторить не только то, что происходит внутри контейнера, но и то, кто и что делает в облаке. ➡️ Документация и quickstart 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🔄 Debian 13.4 — четвёртое обновление Trixie Проект Debian выпустил четвёртое обновление дистрибутива Debian 13 с кодовым именем Trixie. Среди заметных исправлений: glibc получил патчи для трёх уязвимостей, включая повреждение кучи и утечку содержимого стека. В openssh закрыты две уязвимости с возможностью выполнения кода. PostgreSQL 17 обновлён до нового релиза от разработчиков с исправлением переполнения буфера. MariaDB и Samba также получили свежие версии от разработчиков. ➡️ Release notes 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии