Admin Guides | Сисадмин

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём:

🔹 как определить RPO и RTO для критичных сервисов;
🔹 как защитить бэкапы от шифровальщика;
🔹 как учесть зависимости систем и ресурсы для восстановления;
🔹 как каналы связи влияют на скорость бэкапа и восстановления;
🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS;
🔹 как подготовить план аварийного восстановления и протестировать его.

🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его

🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления:
— Матрица систем и зависимостей
— Таблица определения и согласования RPO / RTO
— Технический runbook аварийного восстановления
— Отчёт о тестовом восстановлении ИТ-сервиса
— Карта готовности одного критичного сервиса к восстановлению
— Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов»

👉 Приходите, будет полезно. Регистрация тут

dm-delay: как Linux специально замедляет диск

Device Mapper умеет не только объединять и шифровать устройства. У него есть target dm-delay, который специально добавляет задержку к I/O.
Это удобно для тестов: можно проверить, как система, файловая система или приложение ведут себя с медленным storage, не меняя реальный диск.

⏺Создаём задержку

Например, добавим 100 мс к чтению и 200 мс к записи:

echo "0 $(blockdev --getsz /dev/nvme0n1) delay /dev/nvme0n1 0 100 /dev/nvme0n1 0 200" \
| dmsetup create slowdisk

Проверяем:

dmsetup table slowdisk
lsblk

Теперь /dev/mapper/slowdisk обращается к тому же storage, но I/O проходит через dm-delay.

⏺Где возникает задержка

Схематично путь выглядит так:

application
↓
filesystem
↓
block layer
↓
dm-delay
↓
NVMe / SSD

dm-delay получает bio, удерживает его заданное время и только потом отправляет дальше.
Важно: физический диск при этом ничего не «замедляет». Дополнительная latency появляется именно в Device Mapper.

⏺Зачем это нужно

Например, можно воспроизвести ситуацию:

обычный SSD
↓
latency ~ сотни μs

dm-delay
↓
latency ~ сотни ms

И посмотреть, что произойдёт с timeout’ами, очередями I/O, fsync, RAID или приложением.

После теста mapping удаляется:

dmsetup remove slowdisk

На Stepik вышла программа «DevOps с нуля: от Linux до Kubernetes»

Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes

Вы последовательно пройдёте путь от работы в Linux и управления кодом через Git до контейнеризации приложений, настройки CI/CD-пайплайнов и развёртывания в Kubernetes.

Что вы изучите:

• работу с Linux и командной строкой
• Git и контроль версий в реальных проектах
• создание Docker-образов и запуск контейнеров
• автоматизацию сборки, тестирования и деплоя в GitLab CI/CD
• развёртывание и управление приложениями в Kubernetes
• сети, хранилища, конфигурации и секреты
• диагностику инфраструктуры и автоматизацию рутинных задач
... и многое другое

Все знания закрепляются на практике с помощью заданий с автопроверкой.

Материал подаётся последовательно и понятным языком: с примерами, схемами и демонстрациями. Во время обучения можно задавать вопросы по урокам и заданиям, получать обратную связь и помощь при возникновении сложностей.

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

Скидка 20% на 48 часов: по промокоду ADMING20 стоимость всей программы составит 10 392 ₽.

Открыть программу на Stepik

failfs: файловая система, где всё запрещено

В Linux появилась необычная внутренняя файловая система - failfs. Она специально устроена так, чтобы операции через неё завершались ошибкой EOPNOTSUPP.

Это не файловая система для хранения данных. Её задача - дать kernel контролируемое окружение, в котором filesystem operations гарантированно не работают.

1️⃣Что делает failfs

У неё практически нет нормального path lookup:


/
└── любой lookup → EOPNOTSUPP

Причём ошибка возникает ещё до разбора компонента пути. Даже . не проходит обычный lookup.

Открыть root через O_PATH тоже нельзя.

2️⃣Зачем это kernel

Один из вариантов - изоляция kernel threads.
Исторически kernel threads и PID 1 разделяли filesystem state.

Это создавало довольно странную зависимость: например, операции вроде pivot_root() могли менять filesystem state, который видели kernel threads.

nullfs уже используется как пустое изолированное окружение для таких задач. failfs идёт ещё дальше: любой filesystem access из такого окружения гарантированно заканчивается ошибкой.

3️⃣Почему это лучше обычного NULL

nullfs говорит:

«здесь ничего нет»
↓
ENOENT
failfs говорит:
«filesystem operation здесь вообще не поддерживается»
↓
EOPNOTSUPP

Это важная разница. Kernel получает не просто пустой каталог, а специальную среду, которая позволяет явно проверить или ограничить код, пытающийся обращаться к VFS.

⚡️failfs выглядит бесполезной файловой системой ровно до момента, когда kernel нужно гарантировать: этот код не должен случайно получить доступ к обычному filesystem namespace. Тогда отсутствие файлов превращается уже не в отсутствие данных, а в механизм изоляции.

💬 Вопрос на собеседовании для сисадмина

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

❓Вопрос: Как работает systemd socket activation и зачем сервису может не требоваться постоянно запущенный процесс?

✅Ответ: systemd может сначала открыть сетевой сокет сам, а приложение запускать только тогда, когда на этот сокет приходит соединение.

Например, вместо постоянно работающего сервиса:

client → port 8080 → application

может использоваться схема:

client → port 8080 → systemd → application

В .socket-юните описывается порт:

[Socket]
ListenStream=8080

А .service запускается при первом подключении. При этом уже открытый файловый дескриптор сокета передаётся запущенному процессу.

Process Builder: зачем Linux хочет уйти от fork()+exec()

Классическая схема запуска процесса в Unix выглядит просто: fork() создаёт копию текущего процесса, затем execve() заменяет её другой программой.

Но для больших приложений это не всегда удобно. Перед exec() приходится настраивать файловые дескрипторы, credentials, namespaces, ограничения и другие параметры уже созданного процесса.

А сам fork() при этом создаёт его как копию родителя. В 2026 году в Linux обсуждается отдельный process-builder API, который должен позволить собирать новый процесс без такого копирования.

1️⃣Что не так с fork()

Условно:

pid = fork();

if (pid == 0) {
// настроить child
execve(...);
}

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

Для обычной программы это нормально. Но для серверов и других процессов с большим address space стоимость и сложность такой модели становятся заметнее.

2️⃣Что предлагает Process Builder

Идея - сначала получить практически пустой процесс, а затем последовательно собрать его состояние:

create process
↓
install FDs
↓
set credentials
↓
configure namespaces / limits
↓
exec()

То есть создание процесса превращается из одной операции fork() в набор явно задаваемых действий.

Это особенно интересно для реализации posix_spawn() и похожих механизмов, где родитель вообще не должен становиться шаблоном нового процесса.

3️⃣Почему это интересно kernel-разработчикам

Такой подход позволяет отделить создание процесса от копирования состояния родителя.

В результате можно заранее описать, каким должен быть новый процесс, и передать это описание kernel вместо последовательности fork() → настройка → exec().

При этом проект пока находится на стадии разработки и обсуждения, а не является новым универсальным syscall, который уже можно использовать на обычной системе.

⚡️Идея Process Builder - не просто сделать fork() быстрее. Это попытка изменить саму модель создания процесса: не копировать существующий процесс и потом переделывать его, а собрать новый из нужных kernel-объектов.

💬 Вопрос на собеседовании для сисадмина

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

❓Вопрос: Что такое Transparent Huge Pages (THP) в Linux и как они влияют на производительность?

✅Ответ: Transparent Huge Pages (THP) — это механизм Linux, автоматически объединяющий обычные страницы памяти (обычно по 4 KB) в более крупные страницы (обычно по 2 MB), чтобы сократить накладные расходы на управление памятью и ускорить доступ.

Проверить текущее состояние THP можно командой:

cat /sys/kernel/mm/transparent_hugepage/enabled

Отключить, если они мешают:

echo never > /sys/kernel/mm/transparent_hugepage/enabledЯ

🫥 Сервис запустили - пора принимать поздравления и платежи

С платежами поможет pay.hot. Подключаем оплату на сайте, в приложении или Telegram:

- СБП
- Банковские карты РФ
- Международные банковские карты

🫥 Можно подключиться без ИП и ООО в России, а выручку получать в USDT.

🫥 Работаем с пополнением Steam, донатами в игры, digital-сервисами, Таро-ботами, магазинами цифровых товаров, хостингами и нейросервисами.

🫥 Согласование и подключение - обычно до 7 часов. Поддержка на связи 24/7.

🫥 Кстати, у нас есть агентская программа. Если знаете проекты, которым нужен приём платежей, можете помогать им подключаться к pay.hot и получать агентское вознаграждение.

🫥 Расскажите о своём проекте: @payhotsupport_bot

Block-layer error injection: как Linux специально ломает I/O

В Linux можно не ждать, пока диск действительно начнёт возвращать ошибки.

Kernel умеет сам подставлять ошибки для операций block layer и проверять, как на них реагируют файловая система, драйвер и сервисы.

1️⃣Включаем механизм
Нужен kernel с CONFIG_BLK_ERROR_INJECTION и смонтированный debugfs:

mount -t debugfs none /sys/kernel/debug

Для устройства появится:

/sys/kernel/debug/block/nvme0n1/error_injection

2️⃣Задаём ошибку
Например, возвращаем BLK_STS_IOERR для одного из десяти чтений:

echo 'add,op=READ,start=0,status=IOERR,chance=10' \
> /sys/kernel/debug/block/nvme0n1/error_injection

Можно ограничить правило диапазоном секторов или выбрать другую операцию:

op=READ
op=WRITE
op=DISCARD

А вместо IOERR можно, например, имитировать BLK_STS_MEDIUM.

3️⃣Что происходит дальше
Ошибка появляется не потому, что NVMe или SATA-диск физически сломался.

Запрос проходит через block layer, там срабатывает правило, и операция завершается с заданным статусом.

Дальше уже интересно смотреть, что делает верхний уровень:

dmesg -w

и параллельно проверять поведение файловой системы, device-mapper, RAID или приложения.

Правила можно удалить:

echo removeall \
> /sys/kernel/debug/block/nvme0n1/error_injection

⚡️Получается довольно мощный способ тестировать recovery: можно воспроизвести I/O error на конкретной операции и диапазоне диска, не дожидаясь реальной аппаратной неисправности.

АЙТИШНИКИ БЕСПЛАТНОЕ ОБУЧЕНИЕ

Проект «Terminal» стал крупнейшей библиотекой бесплатного образования. В одном канале собраны курсы, книги, полезные инструменты и практические тренажёры для всех разработчиков:

• Практические курсы и задания
• Книги и статьи известных авторов
• Полезные инструменты и ресурсы
• IT-новости и инсайды

Обучение по всем направлениям: SQL, Python, ML, Frontend, PHP, C++, Go, Git, Linux, QA, Java, Vibe-coding, InfoSec и др.

⌨️ подписаться

Показан открытый минималистичный браузер Northstar, полностью написанный с нуля на C.

Одно окно, одна страница, один процесс - около 177 тыс. строк оригинального кода. Сторонние движки вроде Gecko, WebKit или Blink не используются. Проект распространяется под GNU GPLv3, сборки доступны для Linux, macOS и Windows.

Northstar поддерживает актуальные HTML5, CSS и JavaScript, а соответствие стандартам проверяется непосредственно в проекте. В архитектуру заложена приватность: нет телеметрии, запросов при проверке обновлений и ИИ-функций.

Safe Browsing использует локальный список хешей SHA-256, а cookies, хранилище и кэш изолируются по origin.

⏺GTK-оболочка работает в основном потоке, а движок страниц - в отдельном со своим event loop. Поэтому загрузка страницы или выполнение JavaScript не должны блокировать интерфейс. Весь браузер работает в одном процессе, а кодовая база остаётся достаточно компактной для изучения и аудита одним разработчиком.

sched_ext: разные scheduler policies для разных групп

Обычно scheduler в Linux один для всей системы: задачи попадают в общую модель планирования, а kernel решает, когда и на каком CPU их запускать.

sched_ext позволяет вынести часть этой логики в BPF-программу. А новая модель sub-schedulers позволяет применять отдельную policy только к выбранной группе задач.
Упрощённо:

Linux scheduler
│
├── обычные процессы → CFS / fair scheduling
│
└── выбранная группа → sched_ext
│
└── своя BPF policy

Например, можно представить систему с двумя группами:

cgroup A → обычный scheduler
cgroup B → sched_ext policy

При этом sched_ext не заменяет scheduler ядра целиком. Он получает управление только там, где задача попала под соответствующую policy, а остальные задачи продолжают обслуживаться обычным scheduler path.
Проверить доступность механизма можно через:

ls /sys/kernel/sched_ext

А состояние scheduler’а:

cat /sys/kernel/sched_ext/state

Главная сложность здесь в границе ответственности. BPF-policy должна решать, какую задачу и когда запускать, но CPU, migration, interrupts и остальные базовые механизмы ядра никуда не исчезают.

То есть получается не:
один BPF scheduler вместо Linux scheduler
а скорее:

kernel scheduler
│
┌───────────┴───────────┐
↓ ↓
обычные задачи sched_ext tasks
│
BPF scheduling policy

steal time: как VM понимает, что CPU забрала виртуализация

Виртуальная машина может показывать низкую загрузку CPU, но при этом работать медленно.

Причина может быть в том, что vCPU просто не получает физический CPU: гипервизор в этот момент выполняет другую VM. Это время Linux называет steal time.

1️⃣Проверяем steal time

grep '^cpu ' /proc/stat

Или:

vmstat 1

В vmstat это колонка st:

procs -----------memory---------- ---cpu---
r b swpd free buff cache us sy id st
4 0 0 ... ... ... 35 8 42 15

st=15 означает, что около 15% времени vCPU не мог выполняться, потому что физический CPU был отдан кому-то ещё.

2️⃣Почему это отличается от обычной загрузки
Допустим, приложение хочет работать постоянно:

VM хочет CPU
↓
vCPU готов выполняться
↓
гипервизор не даёт ему pCPU
↓
steal time растёт

При этом внутри VM процесс может выглядеть вполне здоровым: нет большого iowait, нет высокой загрузки памяти, а задержки растут.

3️⃣Что с этим делают сейчас

Свежая серия steal_governor предлагает использовать steal time непосредственно для scheduler’а гостя. При высоком steal time VM уменьшает набор preferred CPUs, фактически добровольно сокращая число используемых vCPU. Когда steal снижается, CPUs возвращаются обратно.

Например, пороги в текущей серии:

steal > 5% → убрать core из preferred set
steal < 2% → вернуть core

Идея в том, что иногда лучше иметь меньше реально работающих vCPU, чем много vCPU, которые постоянно конкурируют за физические CPU. Особенно это важно, если вытесненный vCPU в этот момент держал lock.

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

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

❓Вопрос: Что такое RSS (Receive Side Scaling) и зачем он нужен на многопроцессорных серверах?

✅Ответ: RSS (Receive Side Scaling) - это механизм сетевых карт и ядра Linux, позволяющий распределять обработку входящего сетевого трафика между несколькими CPU. Без RSS весь сетевой трафик мог бы обрабатываться одним ядром, создавая bottleneck на высоких нагрузках.

Как это работает:
• NIC вычисляет хэш пакета (обычно по src/dst IP и портам).
• На основе хэша пакеты распределяются по разным RX-очередям.
• Каждая очередь привязывается к отдельному CPU через IRQ affinity.
• В результате обработка сети параллелится между ядрами.

128-bit PTE: зачем ARM понадобились таблицы страниц в 128 бит

ARM сейчас добавляет поддержку 128-битных page-table entries через FEAT_D128 и режим VMSAv9-128. Это не означает, что обычный процесс внезапно получает адресное пространство 2¹²⁸.

У PTE есть не только адрес physical page. В нём также нужны биты для управления памятью: permissions, attributes, security и другие MMU-флаги.

В 64-битном PTE пространство уже становится тесным для будущих расширений:

┌──────────────────────────────┐
│ physical address │
├──────────────────────────────┤
│ permissions / attributes │
├──────────────────────────────┤
│ MMU / software metadata │
└──────────────────────────────┘
64 bit

D128 удваивает размер записи:

64-bit PTE → 128-bit PTE

Это позволяет одновременно расширять диапазоны VA/PA и оставляет больше места под дополнительные функции MMU. При этом сама геометрия таблиц меняется: в одном уровне теперь меньше entries, поэтому размеры mappings на уровнях также отличаются.

Например, для 4-KB страниц:

D64 D128
PMD 2 MB 1 MB
PUD 1 GB 256 MB

То есть переход на 128-bit PTE - это не просто «адресов стало в два раза больше». Меняется сама организация translation tables.

Причём текущая реализация ещё не использует весь потенциал FEAT_D128: поддержка некоторых возможностей, включая 52-bit VA/PA и skip levels, пока отсутствует.

⚡️Главная идея здесь не «нам срочно понадобилось адресовать 2¹²⁸ байт». ARM заранее расширяет сам формат описания страницы, потому что 64 бит PTE постепенно становятся ограничением уже не только для адреса, но и для metadata, которую MMU должен хранить рядом с ним.

Как понять, что упёрлись в лимиты (FD, conntrack, backlog), а не в CPU

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

Сначала проверяем файловые дескрипторы - частая причина “тихих” отказов:

cat /proc/sys/fs/file-nr
lsof | wc -l

Если значение близко к лимиту - новые соединения или файлы просто не создаются, хотя CPU свободен.
Дальше conntrack - если есть NAT или firewall:

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Когда счётчик близок к max - появляются дропы и таймауты без нагрузки на CPU.

Теперь backlog и очередь входящих соединений:

ss -lnt
cat /proc/sys/net/core/somaxconn

Если растёт очередь на LISTEN или SYN backlog забит - новые подключения “висят”, хотя сервис жив.