Admin Guides | Сисадмин

ethtool -k: что сетевая карта делает вместо CPU Приложение отправляет обычные данные, но часть работы с пакетами Linux может передавать непосредственно NIC. Посмотреть включённые offload-механизмы:

ethtool -k eth0

Например:

tcp-segmentation-offload: on
generic-receive-offload: on
receive-checksum-offload: on

При TSO kernel может передать NIC большой TCP-пакет, а сама карта разобьёт его на отдельные Ethernet frames. GRO работает в обратную сторону: kernel может объединять несколько полученных сегментов, уменьшая количество операций обработки. Это снижает нагрузку CPU, но иногда создаёт путаницу при диагностике через tcpdump. Например, в захвате можно увидеть большой сегмент, хотя на физическом интерфейсе реально ушло несколько меньших пакетов Проверить конкретный параметр:

ethtool -k eth0 | grep -E 'gro|gso|tso|checksum'

⚡️Поэтому при странном поведении сети полезно знать не только настройки IP и маршрутизации, но и какие операции Linux уже делегировал сетевой карте

⚡️⚡️Инциденты, метрики и спасенный прод на DevOops 2026 Даже самая отказоустойчивая инфраструктура иногда преподносит сюрпризы, а один неудачный коммит может устроить всей команде долгий вечер. На DevOops 2026 будут разбирать, что делать с такими ситуациями в реальной инфраструктуре: от проблем с Kubernetes и GitOps до инцидентов, метрик и observability. Программный комитет выбрал восемь докладов, которые рекомендует посмотреть в первую очередь. Здесь — Kafka в Kubernetes, архитектура корпоративного GPT, GitOps без лишнего blast radius, security-политики, надежность, DORA и observability. Все подробности — в карточках и на сайте. 🔥С промокодом admguides персональные билеты дешевле Купить билет

Microsoft ужесточит требования к подписанию драйверов для Windows 11 и Server 2025. С марта 2027 года все драйверы, проходящие аттестацию WHCP, должны будут сопровождаться двумя документами: — SBOM - перечень компонентов ПО — VEX - информация о наличии и применимости уязвимостей Без них драйвер не получит подпись. Требования затронут Windows 11 25H2/26H1, Windows Server 2025 и более новые версии. Изменения связаны с вступлением в силу Закона ЕС о киберустойчивости, который также требует от производителей вести актуальный SBOM и выстроить процессы управления уязвимостями.

Microsoft ужесточит требования к подписанию драйверов для Windows 11 и Server 2025. С марта 2027 года все драйверы, проходящие аттестацию WHCP, должны будут сопровождаться двумя документами: — SBOM - перечень компонентов ПО — VEX - информация о наличии и применимости уязвимостей

Без них драйвер не получит подпись.

Требования затронут Windows 11 25H2/26H1, Windows Server 2025 и более новые версии. Изменения связаны с вступлением в силу Закона ЕС о киберустойчивости, который также требует от производителей вести актуальный SBOM и выстроить процессы управления уязвимостями.

udevadm monitor: что происходит с устройством между kernel и /dev Когда подключается диск, сетевой адаптер или USB-устройство, файл в /dev не появляется сам по себе. Сначала kernel обнаруживает устройство и генерирует событие, затем udev обрабатывает его и создаёт нужные device nodes и symlink. Посмотреть эти события в реальном времени:

udevadm monitor

Подключаем USB-накопитель и можем увидеть события от kernel и udev

KERNEL[...] add /devices/.../usb1/1-2
UDEV  [...] add /devices/.../usb1/1-2

Это позволяет увидеть разницу между двумя этапами. KERNEL - устройство обнаружено ядром UDEV - событие обработал userspace udev Отфильтровать только устройства

udevadm monitor --kernel --udev --subsystem-match=block

Теперь интересуют только block devices При подключении диска можно увидеть цепочку событий для самого устройства и его разделов

add → nvme0n1
add → nvme0n1p1
add → nvme0n1p2

Узнать, почему устройство получило именно такое имя После обнаружения:

udevadm info --query=all --name=/dev/sda

Можно посмотреть свойства, по которым udev идентифицирует устройство Например:

ID_SERIAL=...
ID_WWN=...
ID_FS_UUID=...
ID_PATH=...

Именно на основе таких атрибутов создаются стабильные ссылки вроде:

/dev/disk/by-id/
/dev/disk/by-path/
/dev/disk/by-uuid/

Полезный кейс Допустим, после перезагрузки диск иногда становится /dev/sdb, а иногда /dev/sdc Ориентироваться на имя sdX в такой ситуации ненадёжно Можно посмотреть стабильный идентификатор:

udevadm info --query=property --name=/dev/sdb

А затем использовать /dev/disk/by-id/... Так можно понять не только что система обнаружила, но и почему конкретное устройство получило конкретные свойства и имена

nsenter: заглянуть внутрь namespace работающего контейнера Контейнер не обязан иметь shell внутри себя. Если приложение работает, но docker exec недоступен или сам контейнерный userspace сломан, namespace можно открыть непосредственно с хоста Сначала находим PID основного процесса контейнера

docker inspect -f '{{.State.Pid}}' <container>

Допустим, получили 4217 Проверяем его namespaces:

ls -l /proc/4217/ns/

Например:

net  -> net:[4026532456]
mnt  -> mnt:[4026532457]
pid  -> pid:[4026532458]

Заходим сразу во все основные namespace

nsenter -t 4217 -m -u -i -n -p -C

Теперь shell работает в namespace процесса контейнера Проверка:

hostname
ip addr
mount
ps aux

При этом команды выполняются с host kernel, но видят изолированное окружение контейнера Можно войти только в нужный namespace Например, посмотреть сетевую конфигурацию контейнера с хоста:

nsenter -t 4217 -n ip addr

Или его mount namespace:

nsenter -t 4217 -m mount

Это удобно, когда проблема именно в одном namespace и нет смысла запускать полноценный shell Почему nsenter особенно полезен при авариях docker exec фактически зависит от container runtime и возможности запустить новый процесс внутри контейнера nsenter работает иначе: он использует namespace уже существующего процесса через /proc/<PID>/ns Поэтому если внутри контейнера сломан shell, отсутствуют утилиты или runtime не может выполнить exec, диагностику всё ещё можно проводить с хоста ⚡️Важный нюанс: namespace изолирует пространство имён, но не создаёт отдельное ядро. Процессы контейнера и хоста используют одно Linux kernel, просто смотрят на разные namespace

lsblk -o +UUID,PARTUUID: когда UUID и PARTUUID ведут к разным объектам У диска и его раздела могут быть сразу несколько идентификаторов, и они не взаимозаменяемы Посмотрим их вместе:

lsblk -o NAME,SIZE,FSTYPE,UUID,PARTUUID,MOUNTPOINTS

Например:

nvme0n1
├─nvme0n1p1 vfat  7A3C-91F2  4f8a...  /boot/efi
└─nvme0n1p2 ext4  91c2...    8e21...  /

UUID относится к файловой системе PARTUUID относится к самому разделу в partition table Это принципиальная разница. Если выполнить:

blkid /dev/nvme0n1p2

можно получить:

UUID="91c2..."
PARTUUID="8e21..."

UUID меняется вместе с filesystem Например, для ext4 можно создать новую файловую систему:

mkfs.ext4 /dev/nvme0n1p2

Раздел останется тем же, но filesystem UUID будет новым. Поэтому /etc/fstab, где используется:

UUID=91c2... / ext4 defaults 0 1

после пересоздания filesystem перестанет находить старую файловую систему PARTUUID принадлежит разделу Если файловую систему внутри раздела пересоздать, PARTUUID обычно останется прежним. Но если удалить раздел и создать его заново, partition entry уже может получить другой идентификатор Посмотреть таблицу непосредственно можно:

lsblk -o NAME,PARTUUID

или:

blkid -p /dev/nvme0n1p2

Где это становится особенно важным В Linux можно встретить: root=UUID=... в параметрах kernel command line А в некоторых конфигурациях используется:

root=PARTUUID=...

В первом случае kernel/initramfs ищет filesystem с определённым UUID Во втором - конкретный partition entry Поэтому после клонирования диска можно получить очень неприятную ситуацию: структура разделов и их PARTUUID скопированы, а UUID файловых систем тоже совпали В результате система или initramfs может обнаружить не тот экземпляр filesystem ⚡️Практическое правило: UUID отвечает на вопрос «какую файловую систему найти», а PARTUUID - «какой раздел найти» При диагностике загрузки, клонирования дисков и проблем с /etc/fstab важно сначала определить, какой именно идентификатор используется и к какому уровню устройства он относится

💬 Вопрос на собеседовании для сисадмина Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое split-brain в кластере и почему он опасен? ✅Ответ: Split-brain - это состояние кластера, при котором его узлы теряют связь между собой, но несколько частей кластера продолжают считать себя активными и пытаются одновременно управлять одними и теми же ресурсами. Как это происходит: • Кластер из нескольких узлов теряет сетевую связь между ними. • Каждый узел видит, что остальные недоступны, и может решить, что именно он должен продолжать обслуживать ресурс. • Два узла начинают одновременно работать с общим хранилищем, виртуальной машиной или IP-адресом. • В результате возникают конфликты, повреждение данных или двойная запись.

opensnoop: кто постоянно открывает файлы Бывает приложение начинает тормозить из-за огромного количества файловых операций, хотя CPU и диск выглядят нормально Например, процесс может тысячи раз в секунду проверять один и тот же отсутствующий файл, конфигурацию или каталог opensnoop позволяет увидеть эти обращения непосредственно на уровне syscall open, openat и openat2 ⏺Смотрим, кто открывает файлы

opensnoop

В выводе будут PID, процесс, результат операции и путь

PID     COMM        FD  ERR  PATH
4217    app         12   0   /etc/app/config.json
4217    app         -1   2   /etc/app/cache.db
4217    app         -1   2   /tmp/app.lock

FD=-1 означает, что открыть файл не удалось, а ERR=2 соответствует ENOENT - файла не существует ⏺Почему ошибки открытия особенно интересны Допустим, приложение постоянно делает:

openat("/etc/app/cache.db") → ENOENT
openat("/etc/app/cache.db") → ENOENT
openat("/etc/app/cache.db") → ENOENT

Файл отсутствует, поэтому I/O данных практически нет, но приложение продолжает выполнять системные вызовы и проходить путь поиска BCC прямо отмечает такой сценарий как возможную причину проблем с производительностью. Можно оставить только неудачные открытия:

opensnoop -x

Или ограничиться конкретным процессом:

opensnoop -p 4217

⏺А если обращений слишком много Для приложения, которое делает тысячи операций в секунду, вывод каждой строки сам становится неудобным. Можно вместо этого агрегировать события через bpftrace

bpftrace -e '
tracepoint:syscalls:sys_enter_openat
{
    @[comm, str(args.filename)] = count();
}'

После остановки получим не тысячи одинаковых строк, а статистику

@[app, "/etc/app/config.json"]: 18432
@[app, "/tmp/app.lock"]: 9217
@[app, "/proc/self/status"]: 4081

bpftrace использует kernel tracepoint для openat() и позволяет собирать статистику непосредственно в ядре, а не просто печатать каждое событие ⏺Что искать в результате Особенно подозрительны огромные количества обращений к одному и тому же несуществующему файлу, постоянное чтение конфигурации вместо её кэширования, бесконечный поиск библиотек или конфигов по нескольким каталогам и приложения, которые постоянно открывают /proc и /sys Важно и то, что opensnoop показывает именно попытки открытия, а не только успешные операции - поэтому через него можно увидеть ошибки, которые обычный мониторинг диска вообще не заметит ⚡️Это хороший пример ситуации, когда проблема выглядит как «приложение просто тормозит», хотя причина находится намного ниже - в тысячах повторяющихся системных вызовов openat() и неудачных поисках файлов

Только 2% запросов к git.kernel.org приходят от людей Инфраструктура kernel.org обрабатывает около 6 млн запросов в день, но лишь 2% из них считаются запросами реальных пользователей. Остальные создают боты и скрапперы. Они перебирают старые коммиты и ветки, отправляя миллиарды запросов вместо обычного git clone. При этом используют миллионы случайных IP из домашних и мобильных сетей, поэтому блокировка по IP почти не работает.

Даже Anubis, который заставляет клиентов выполнять вычислительную задачу, боты научились обходить.

В результате на пяти серверах 14–16 из 90 CPU-ядер постоянно уходят на обслуживание скрапперов. Команде приходится ограничивать анонимный доступ и отключать ресурсоёмкие функции. Простого решения пока нет: ИИ-компаниям нужны данные, а боты продолжают адаптироваться.

lsof +L1: почему удалённый файл продолжает занимать место Бывает, что файл уже удалили, а df продолжает показывать занятое место Причина в том, что процесс всё ещё держит файл открытым Находим такие файлы lsof +L1 Например: java 4217 app 12w REG 8,1 21474836480 /var/log/app.log (deleted) Файл больше не виден в каталоге, но его inode и блоки всё ещё принадлежат процессу java Почему rm не освобождает место При удалении файл сначала теряет имя в файловой системе Но данные остаются доступны через уже открытый файловый дескриптор Условно: /var/log/app.log ↓ rm inode ─────→ процесс Пока процесс не закроет FD, ядро не сможет освободить занятые блоки Можно увидеть сам дескриптор ls -l /proc/4217/fd/12 Получим: /var/log/app.log (deleted) А иногда нужно срочно освободить место, но перезапускать процесс нельзя Тогда содержимое открытого файла можно обнулить через /proc : > /proc/4217/fd/12 Размер файла станет нулевым, при этом процесс продолжит использовать тот же FD ⚡️ Поэтому ситуация df показывает занято, а du не находит часто объясняется именно deleted-open файлами du уже не видит файл в каталоге, а ядро продолжает учитывать его блоки до закрытия последнего дескриптора

systemctl cat: как найти реальную конфигурацию сервиса, когда файл выглядит нормально Иногда открываешь unit-файл и не находишь параметр, который явно влияет на работу сервиса. Причина в том, что systemd собирает конфигурацию не только из основного файла. ⏺Смотрим итоговую конфигурацию

systemctl cat nginx.service

Команда покажет основной unit и применённые drop-in конфигурации. Например:

/etc/systemd/system/nginx.service
/etc/systemd/system/nginx.service.d/override.conf

И в override.conf может находиться:

[Service]
LimitNOFILE=65535
Environment="APP_ENV=prod"

Хотя в самом nginx.service этих параметров вообще нет. ⏺Находим все локальные изменения

systemd-delta

Она показывает unit-файлы, которые отличаются от поставленных системой, включая override. Для конкретного сервиса:

systemd-delta nginx.service

⏺Проверяем, что systemd реально применил

systemctl show nginx.service \
  -p LimitNOFILE \
  -p Environment \
  -p FragmentPath \
  -p DropInPaths

Здесь уже отображается эффективное состояние запущенного unit, а не просто содержимое файла ⏺Почему это важно На production сервере сервис может вести себя иначе после локального override Например, основной unit говорит:

User=nginx

а drop-in меняет: [Service] User=app И если смотреть только основной файл, причина изменения останется незаметной. ⚡️При странном поведении systemd-сервиса полезно разделять две вещи: что написано в unit-файле и какую конфигурацию PID 1 реально применил. systemctl cat, systemd-delta и systemctl show позволяют увидеть эту разницу

MinIO больше не развивается Патчи безопасности не выпускают, Обновления и железо не тестируют. Если у вас петабайты данных в S3-хранилище — это уже не гипотетический риск, а вопрос времени. 3 сентября на вебинаре разберем, как перенести данные из устаревшего хранилища (на примере MinIO) в другое S3-совместимое — без остановки сервиса. Что будет: — что переносится при миграции: объекты, версии, ACL, bucket-policy, lifecycle, теги, ссылки — и что остается вне переноса (незавершённые multipart-загрузки) — как устроено техническое переключение: минимальное окно на смену endpoint, параллельная работа приложений на обоих хранилищах без ограничений на операции — что происходит при сбоях и разрывах синхронизации — почему перенос продолжается с точки останова, а не начинается заново — как считается стоимость перехода в зависимости от объема данных и масштаба инфраструктуры — техническое демо: от подключения источника до полного переключения трафика Полезно DevOps- и SRE-инженерам, ИТ-директорам и компаниям, для которых остановка сервиса недопустима даже на время миграции. 📅 3 сентября, 16:00 мск Регистрация

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое file descriptor leak и как его обнаружить в Linux? ✅Ответ: File descriptor leak - это ситуация, когда процесс открывает файлы, сокеты, pipes или другие ресурсы, но не закрывает их после использования. Со временем количество открытых дескрипторов растёт, пока процесс или вся система не упрётся в лимит. Как это проявляется: • новые файлы или соединения перестают открываться с ошибкой Too many open files • процесс продолжает работать, но постепенно потребляет всё больше FD • особенно часто проблема возникает в долгоживущих сервисах и сетевых приложениях Диагностика:

ls /proc/$PID/fd | wc -l
lsof -p $PID
cat /proc/$PID/limits | grep "open files"

Хочешь прокачать знания в DevOps? Но не знаешь где взять информацию и четкий план? 👍Рекомендуем бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет вам сориентироваться в мире DevOps и стать крутым спецом. В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования. ✅Он будет полезен при подготовке к собеседованиям. 📅А еще у автора есть крутые практические курсы на собственной платформе и программа наставничества. Узнать больше #реклама 16+ platform.lifeisfile.com О рекламодателе

Transient units: сервисы, которых вообще нет в /etc/systemd/system Не каждый systemd unit существует как файл на диске. Transient unit создаётся прямо во время работы системы и может появиться без собственного файла в /etc/systemd/system Например:

systemd-run --unit=backup-now /usr/local/bin/backup.sh

После этого появляется unit:

systemctl status backup-now.service

Но поиск файла ничего не даст:

find /etc/systemd/system -name '*backup-now*'

Потому что конфигурация существует только в памяти systemd. ⏺Как найти такие unit

systemctl list-units --type=service --all

Для конкретного unit: systemctl show backup-now.service Можно увидеть реальные параметры запуска:

systemctl show backup-now.service \
  -p Transient \
  -p ExecStart \
  -p User \
  -p MainPID

Если: Transient=yes значит unit был создан runtime ⏺Откуда они появляются Transient units создают не только вручную через systemd-run Их могут использовать скрипты, оркестраторы, CI/CD и другие сервисы, которым нужно запустить процесс под управлением systemd без создания постоянного unit-файла. Например, с временными ограничениями ресурсов:

systemd-run \
  --unit=test-job \
  -p MemoryMax=2G \
  -p CPUQuota=50% \
  /usr/local/bin/task.sh

В таком случае systemd создаёт service и cgroup на время выполнения задачи. ⏺Почему это важно при диагностике Можно увидеть запущенный процесс в: systemctl status но не найти его unit в /etc/systemd/system И начать искать «потерянный» конфигурационный файл Проверить происхождение unit можно напрямую:

systemctl show <UNIT> -p Transient -p FragmentPath

У transient unit Transient=yes, а FragmentPath обычно не указывает на обычный unit-файл ⚡️Поэтому наличие systemd-сервиса ещё не означает, что его конфигурация лежит на диске - часть unit может существовать только в runtime state PID 1