💡 Linux против FreeBSD

Когда сервис обрабатывает 15 000 запросов в секунду, а p99 всё равно ведёт себя странно, код тут ни при чём. Проблема может быть в ОС. Разберём, чем Linux и FreeBSD отличаются на уровне ядра и где каждый из них реально быстрее.

• Шедулеры

Linux с версии 6.6 использует EEVDF вместо старого CFS. Он учитывает дедлайны задач и снижает джиттер для чувствительных к задержке сервисов.

FreeBSD использует ULE. Хорош для интерактивных задач и NUMA-балансировки, держит процессы ближе к их CPU-кешу.

• I/O: io_uring против kqueue

Это главное различие для серверных нагрузок. io_uring, появившийся в Linux 5.1, использует общие кольцевые буферы между userspace и ядром. Меньше системных вызовов, меньше смены контекста, батчевая отправка запросов.

FreeBSD использует kqueue. Технически хорошее решение, которое в своё время повлияло на дизайн io_uring. Но батчами отправлять запросы не умеет.

• Кого куда назначить

Linux выигрывает на I/O-тяжёлых API при высокой конкурентности. io_uring здесь не просто деталь, а архитектурное преимущество. Go, Rust и большинство современных рантаймов используют его автоматически на Linux.

FreeBSD лучше там, где много системных вызовов, важна предсказуемость аллокатора и нужен сетевой стек с минимальными задержками. Netflix держит FreeBSD на CDN-эджах именно из-за этого.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🗣 Материалы и обновления недели

Надеемся все пережили пятницу 13е.

— Прочитать диск без дисковода

— Найм по знакомству

— curl 8.19.0

— Ботнет KadNap

— kitty 0.46.0

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#дайджест_недели

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

📝 Линтер для SQL

SQL в командах часто выглядит как зоопарк. Один пишет select, другой SELECT, третий вообще не ставит пробелы вокруг операторов. На код-ревью половина комментариев о стиле, а не о логике. SQLFluff решает именно эту проблему.

SQLFluff — открытый линтер и форматтер для SQL. Он находит проблемы в коде и сообщает о них автоматически, чтобы код-ревью касалось функциональности, а не оформления. Умеет не только находить ошибки, но и исправлять большинство из них сам.

Инструмент создавался с прицелом на ELT-задачи, поддерживает Jinja-шаблоны и dbt. Работает без подключения к базе данных — парсит SQL и ловит синтаксические проблемы ещё до того, как код дойдёт до БД.

Установка через pip:

pip install sqlfluff

Чтобы исправить файл автоматически:

sqlfluff fix test.sql --dialect ansi

Все правила гибко настраиваются через файл .sqlfluff в корне проекта. Можно отключить конкретные правила, задать свой стиль отступов, указать диалект по умолчанию. Файл .sqlfluffignore работает как .gitignore.

SQLFluff хорошо вписывается в CI/CD — на GitHub есть готовые шаблоны Actions для типовых сценариев.

➡️ Сайт проекта

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🔄 Debian 13.4 — четвёртое обновление Trixie

Проект Debian выпустил четвёртое обновление дистрибутива Debian 13 с кодовым именем Trixie.

Среди заметных исправлений: glibc получил патчи для трёх уязвимостей, включая повреждение кучи и утечку содержимого стека. В openssh закрыты две уязвимости с возможностью выполнения кода.

PostgreSQL 17 обновлён до нового релиза от разработчиков с исправлением переполнения буфера. MariaDB и Samba также получили свежие версии от разработчиков.

➡️ Release notes

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека 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

#арсенал_инженера

🤨 Скоро за сохранение придётся платить. Или нет

Яндекс подал в Роспатент заявку на регистрацию товарного знака на фразу «Сохранить как». Да, ту самую, которую вы нажимаете с 1983 года, когда хотите не испортить оригинал.

Пользователи уже предлагают превентивно запатентовать «Отменить» и «Вставить».

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека 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

#пульс_индустрии

👨‍💻 Синдром пятничного оффлайна

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

➡️ Новая статья — это карьерный словарь на 14 терминов

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека 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

#локализация

🤭 Топ-вакансий для девопсов за неделю

DevOps Middle — 200 000 - 350 000₽, гибрид в Москве

DevOps-инженер — от 400 000 ₽, удалёнка или офис в Москве

DevOps/SRE инженер — от 270 000 ₽, гибрид в Москве

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

🐸Библиотека 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'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

#арсенал_инженера

🔄 GNOME 50 Tokyo

Вышел свежий GNOME с кодовым именем «Tokyo». Это юбилейный выпуск с заметными изменениями.

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

Также заложена основа для веб-фильтрации на уровне системного сервиса. Фронтенд пока не готов, но бэкенд уже есть.

VRR и дробное масштабирование теперь включены по умолчанию. Курсор при активном VRR работает на полной частоте монитора независимо от FPS приложения.

Для пользователей NVIDIA исправлены проблемы со статтерами и временем кадра. Добавлена поддержка второй версии протокола управления цветом Wayland и HDR при захвате экрана.

Удалённый рабочий стол ускорили через аппаратное ускорение на базе Vulkan и VA-API. Появилась поддержка HiDPI, перенаправление камеры и аутентификация через Kerberos.

Из точечных улучшений: в Files переработан пакетное переименование и ускорена загрузка миниатюр, в Calendar появился список участников событий и экспорт в ICS, в средстве просмотра документов переписан инструмент аннотаций.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

⚙️ Безопасный дебаг прода в 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

#арсенал_инженера

🏗 DevOps-вопрос с собеса

Вам нужно выкатить одно и то же приложение на dev → staging → prod.

Как вы это делаете?

Подумайте: как передать конфиг, если образ нельзя менять? Как откатиться, если что-то пошло не так? Как доказать, что в проде крутится именно то, что прошло тесты?

➡️ Ответ

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#задача_со_звёздочкой