🚌 Skills: «Фактор автобуса» — главный риск, о котором молчат сисадмины

Представьте ситуацию: вы единственный, кто знает, как работает связка вашей базы данных, DMZ-зоны и хитрого скрипта очистки логов. А теперь представьте, что вы выиграли в лотерею и улетели на острова без связи. Или, что менее приятно, попали под автобус (отсюда и термин Bus Factor).

Фактор автобуса — это количество людей в команде, которых нужно потерять, чтобы IT-инфраструктура компании полностью встала. Если этот фактор равен единице (только вы), это катастрофа и для бизнеса, и лично для вас.

Почему это вредит лично вам:

— Невозможно уйти в нормальный отпуск. Телефон будет звонить даже на пляже.
— Невозможно пойти на повышение. Вас банально некем заменить на текущем месте, вы стали заложником собственной инфраструктуры.
— Выгорание. Вы несете ответственность за все системы 24 на 7.

Как повышать Bus Factor в 2026 году:

— Пароли: Никаких личных блокнотов и файлов на рабочем столе. Только корпоративный менеджер паролей с доступом для коллег.
— Документация: Описывайте не только «как сделать», но и «почему мы сделали именно так».
— Перекрестное обучение: Возьмите за правило раз в неделю садиться с коллегой и показывать ему одну из ваших систем. Разбирали вчера архитектуру DMZ-сервера? Проведите мини-презентацию для отдела.

Незаменимых людей нет, есть люди, после ухода которых приходится всё перестраивать с нуля. Делитесь знаниями и не будьте узким горлышком своей инфраструктуры.

#skills #management #busfactor #sysadmin #bestpractices #admin_future

🐧 Linux: Хватит раскидывать ключи ssh-rsa. Переходим на SSH-сертификаты

Коллеги, управлять ключами SSH даже в небольшой команде — это боль. Мы генерируем ключи, копируем их в authorized_keys на десятки серверов. А когда администратор увольняется или теряет ноутбук, мы судорожно пытаемся вспомнить, на каких именно машинах нужно срочно зачистить его доступы. В 2026 году такой подход — это дыра в безопасности.

Современный стандарт — настройка внутреннего удостоверяющего центра (CA) для SSH.

Как это работает:

— Вы генерируете одну пару ключей для Удостоверяющего Центра (CA).
— Публичный ключ CA кладется на все ваши серверы в конфигурацию sshd.
— Когда инженеру нужен доступ, он отправляет свой публичный ключ на CA.
— CA выдает ему подписанный сертификат, в котором жестко указано: кому он выдан и сколько времени он действует (например, ровно 8 часов).

Зачем это нужно:
У вас на серверах больше нет файла authorized_keys с десятками непонятных строк. Вы полностью избавляетесь от процесса отзыва доступов. Если человек ушел в отпуск или уволился — его сертификат просто истекает к концу рабочего дня и превращается в тыкву. Взлом ноутбука инженера на выходных больше не дает хакеру ключи от всего продакшена.

Настроить SSH CA можно за пару часов встроенными средствами OpenSSH. Это тот самый случай, когда внедрение крутой безопасности делает жизнь админа проще, а не сложнее.

#linux #ssh #security #sysadmin #bestpractices #admin_future

🪟 Windows: Обновляем весь зоопарк софта одной командой через WinGet

Раньше для централизованного обновления стороннего софта (браузеры, архиваторы, мессенджеры) на парке машин мы использовали тяжеловесные решения вроде SCCM, сторонние патч-менеджеры или писали километровые скрипты-обертки.

Сейчас все стало гораздо элегантнее. Встроенный пакетный менеджер WinGet давно оброс мускулами и отлично справляется с этой задачей через консоль.

Скрипт для PowerShell (запускать от администратора):

winget upgrade --all --silent --accept-package-agreements --accept-source-agreements

Как это работает:

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

Уязвимости нулевого дня в браузерах и PDF-читалках — это любимый вектор атак шифровальщиков. Повесьте этот скрипт в Планировщик задач на компьютерах пользователей, например, на обеденное время среды. Система сама закроет 90% дыр в стороннем софте без вашего ручного вмешательства.

#windows #powershell #winget #automation #sysadmin #admin_future

🧠 Skills: Бэкап Шредингера — почему ваши резервные копии ничего не стоят

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

Суровая истина системного администрирования гласит: бэкап, который никогда не восстанавливали — это не бэкап. Это просто дорогой файл, занимающий место на диске.

Что происходит на практике в момент аварии:
Выясняется, что скрипт полгода копировал пустые папки. Пароль от зашифрованного архива знает только бывший сотрудник. Свежая база данных отказывается разворачиваться на старой версии СУБД, а файл с конфигурацией Nginx почему-то вообще не попал в список исключений для бэкапа.

Как лечить:

Внедряйте правило Disaster Recovery Day (День аварийного восстановления). Раз в квартал выделяйте чистый тестовый сервер. Отключайтесь от основной сети и пытайтесь поднять копию критического сервиса, используя исключительно вашу документацию и ночные бэкапы.

Опыт инженера измеряется не умением написать bash-скрипт для архивации, а гарантированным временем (RTO), за которое он способен поднять компанию из пепла. Тестируйте восстановление, пока это можно сделать без паники и седых волос.

#skills #backup #disasterrecovery #management #sysadmin #admin_future

🐧 LINUX: КАК НАЙТИ РУТКИТ ИЛИ МАЙНЕР, КОТОРЫЙ ПРЯЧЕТСЯ ОТ КОМАНДЫ PS

Коллеги, если сервер в DMZ тормозит, а команды top и ps aux показывают нормальную загрузку, возможно, вы столкнулись с процессом, который спрятали в изолированном PID-namespace.
Современные майнеры активно используют архитектуру Linux для маскировки, и базовой гигиены здесь уже недостаточно.

Стандартные утилиты читают директорию /proc. Если злоумышленник примонтировал поверх /proc пустую файловую систему tmpfs, вы ничего не увидите.

Скрипт для поиска скрытых процессов через обход пользовательских mount namespaces:

mkdir /mnt/real_proc
mount -o bind /proc /mnt/real_proc
ls -l /mnt/real_proc | grep '^[0-9]'

Зачем это нужно:
Для глубокого аудита безопасности инфраструктуры. Простые проверки больше не работают. Этот трюк позволяет увидеть реальную картину процессов на уровне ядра, игнорируя пользовательские маскировки.

#linux #security #namespaces #sysadmin #admin_future

👻 WINDOWS: ОХОТА ЗА ПРИЗРАКАМИ. УДАЛЯЕМ МЕРТВЫЕ SID ИЗ ПРАВ ДОСТУПА

При реорганизации инфраструктуры и чистке домена от легаси-объектов мы часто удаляем старые учетные записи. Но права доступа на файловых серверах (NTFS ACL) остаются. Вместо имен пользователей там появляются неопознанные SID (начинаются с S-1-5-21...).

Это не просто эстетическая проблема. При миграции серверов или глубоком аудите эти мертвые души сильно тормозят пересчет прав, ломают наследование и создают хаос в политиках безопасности.

PowerShell скрипт для поиска и удаления мертвых SID:

$Path = "C:\Shares\Department"
$ACLs = Get-Acl -Path $Path
$Rules = $ACLs.Access | Where-Object { $_.IdentityReference -match "^S-1-5-21" }

foreach ($Rule in $Rules) {
    $ACLs.RemoveAccessRule($Rule) | Out-Null
    Write-Host "Удален мертвый SID: " $Rule.IdentityReference
}
Set-Acl -Path $Path -AclObject $ACLs

Зачем это нужно:
Порядок в Active Directory должен отражаться порядком в файловых системах. Идеально подходит для включения в план реструктуризации домена и вывода из эксплуатации старых систем вроде Windows 2012 R2.

#windows #powershell #activedirectory #security #admin_future

🐧 Linux: eBPF-трейсинг вместо strace — хирургия без анестезии

Коллеги, когда в 3 ночи продакшн-сервис начинает вести себя странно, первый рефлекс — запустить strace на процесс. И вот ты сидишь, смотришь в поток syscall-ов, теряешь контекст, а overhead от strace в худшем случае убивает процесс быстрее, чем сам баг.

В 2026 году так делать стыдно. Добро пожаловать в bpftrace — если strace это кувалда, то bpftrace это эндоскоп.

Хочешь знать, какие файлы открывает конкретный процесс, сколько времени он тратит в ядре и где реально лежит латентность — без остановки сервиса и почти без overhead:

# Все открываемые файлы процессом nginx в реальном времени
bpftrace -e '
  tracepoint:syscalls:sys_enter_openat
  /comm == "nginx"/
  {
    printf("%s -> %s\n", comm, str(args->filename));
  }
'

# Латентность read() по перцентилям — находим I/O-узкое место
bpftrace -e '
  tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
  tracepoint:syscalls:sys_exit_read  /@start[tid]/
  {
    @lat = hist(nsecs - @start[tid]);
    delete(@start[tid]);
  }
'

Зачем это нужно:
Бизнес платит за uptime, а не за твои ночные медитации над strace-логом. bpftrace работает в ядре, не требует перезапуска процессов, не ломает продакшн и даёт гистограммы латентности за секунды. Когда Роман спрашивает "в чём причина деградации?", у тебя есть ответ с цифрами, а не с "ну, мы смотрим".

Итог: strace незаменим для разработки. Но в живом продакшне — только eBPF. Это разница между вскрытием и МРТ.

#linux #ebpf #bpftrace #performance #sysadmin #admin_future

🪟 Windows: LAPS v2 + Entra ID — хватит хранить пароль локального админа в Excel

Коллеги, я знаю, что где-то в вашей сети до сих пор живёт локальный Administrator с паролем из 2019 года, который записан в заметках у Богдана. И Богдан уже полгода как уволился.

Классический LAPS первого поколения умел ротировать пароль и класть его в AD — и это было неплохо. Но LAPS v2, встроенный в Windows Server 2025 и Windows 11, это уже другой уровень: шифрование пароля в AD, история паролей, поддержка Entra ID (Azure AD) для гибридных сред и ротация по требованию через PowerShell или Intune.

Включаем и настраиваем правильно:

# 1. Обновляем схему AD (один раз, на DC)
Update-LapsADSchema

# 2. Настраиваем права на OU с рабочими станциями
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# 3. Создаём GPO-политику через PowerShell (или через GUI GPMC)
# Путь в GPO: Computer -> Admin Templates -> LAPS
# Ключевые параметры:
#   - Enable password backup to AD: Enabled
#   - Password complexity: Large letters + small + digits + specials
#   - Password age: 30 days
#   - Enable encrypted password: Enabled  <-- вот это обязательно в v2

# 4. Смотрим пароль для конкретной машины (только авторизованным)
Get-LapsADPassword -Identity "PC-FINANCE-01" -AsPlainText

# 5. Принудительная ротация после инцидента
Invoke-LapsPolicyProcessing  # на машине
# или удалённо:
Reset-LapsPassword -Identity "PC-FINANCE-01"

Зачем это нужно:
Lateral movement через один скомпрометированный локальный пароль — классика пентестов и реальных атак. LAPS v2 с шифрованием и историей убирает этот вектор полностью. Пентестеры будут грустить, аудиторы — радоваться, а ты — спать спокойно.

Итог: Если у тебя больше 20 машин в домене и LAPS не настроен — это не техдолг, это открытая дверь. Закрой её сегодня, это займёт два часа.

#windows #laps #activedirectory #security #sysadmin #admin_future

🌐 Networking: WireGuard + wg-quick — это хорошо. WireGuard + netbird — это продакшн

Коллеги, WireGuard как замена OpenVPN уже давно не новость. Но я вижу, как большинство коллег до сих пор управляют им через wg-quick и ручное редактирование конфигов на каждом узле. Добавить новый хост — значит зайти на каждый пир, добавить PublicKey и AllowedIPs руками. В сети на 15 узлов это уже ад.

В 2026 году для mesh VPN на базе WireGuard есть нормальный инструментарий. Один из лучших — Netbird (self-hosted, open source, с management plane и ACL через UI или API).

Поднимаем self-hosted Netbird за 10 минут:

# На управляющем сервере (Ubuntu 24.04 LTS)
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/netbird_management_linux_amd64.tar.gz \
  | tar -xz -C /usr/local/bin

# Используем официальный docker-compose (рекомендуемый путь)
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/docker-compose.yml
wget https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/.env.example -O .env

# Правим .env: домен, TURN-сервер, OIDC-провайдер (или отключаем auth для лаборатории)
nano .env

docker compose up -d

# На каждом узле (Linux, Windows, macOS — клиент один и тот же)
curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://your-netbird-domain:443 --setup-key YOUR_KEY

После этого все узлы видят друг друга через зашифрованный mesh, ACL настраиваются в веб-интерфейсе, новый хост добавляется за 30 секунд по setup key. Никаких правок конфигов на каждом пире.

Зачем это нужно:
Когда Богдан в 9 утра просит "срочно добавить новый сервер в VPN", ты генерируешь setup key в UI и скидываешь ему одну команду. Всё. Не надо помнить, какие PublicKey у каких нод, и не надо объяснять ему структуру wg-quick конфигов.

Итог: wg-quick — для домашней лаборатории и понимания основ. Для инфраструктуры от 5 узлов — нужен management plane. Иначе ты не строишь сеть, ты коллекционируешь конфиги.

#networking #wireguard #netbird #vpn #mesh #sysadmin #admin_future

🕵️‍♂️ Security: DPI переезжает в ваш смартфон. Как и зачем российские приложения ищут VPN

Коллеги, пока мы воевали с ТСПУ и маскировали трафик на серверах, регуляторы изящно сменили тактику. Цензура и DPI переезжают прямо на клиентские устройства.

К 15 апреля 2026 года Минцифры обязало российский бигтех (Яндекс, Сбер, VK, маркетплейсы) жестко ограничивать пользователей с включенным VPN. Не выполнишь — лишение IT-аккредитации. И маркетплейсы уже взяли под козырек: с 7 апреля Ozon и Wildberries начали резать загрузку каталогов при активном туннеле.

Как это выглядит под капотом (спойлер — это легализованное шпионское ПО):
Ребята из RKS Global декомпилировали 30 самых популярных ру-приложений для Android. Результаты аудита: 22 из 30 приложений целенаправленно ищут VPN, а 19 — молча отправляют этот статус на сервера (и далее товарищу майору).

Методы детекции, которые сейчас зашиты в ваш телефон:
— Чтение интерфейсов: Приложения (как мессенджер MAX) сканируют систему на наличие поднятых tun/ppp/tap адаптеров.
— Прямой запрос: Самокат и МегаМаркет через queryIntentServices("android.net.VpnService") тупо собирают список всех VPN-клиентов на устройстве.
— Скан соседей: Avito держит в манифесте блок queries на 200+ чужих пакетов. Он точно знает, стоят ли у вас клиенты конкурентов или запрещенные соцсети.
— Поведенческая биометрия: Банки (Т-Банк, Сбер, ВТБ) пишут каждое касание экрана (dispatchTouchEvent) с координатами и силой нажатия.
— Поиск инструментов: Яндекс Браузер целенаправленно ищет установленный Tor, а Яндекс Музыка сканирует систему на наличие Frida (инструмент динамического анализа), защищаясь от реверс-инжиниринга.

Как с этим жить инженеру?
Разделяй и властвуй. Идеальный сетап в 2026 году — это физически второй (старый) смартфон чисто под банки и маркетплейсы. Если телефон один, вас спасет только аппаратная виртуализация Android — Work Profile (через приложение Shelter).

Скрипт для параноиков. Проверяем через ADB, кто из приложений имеет системное право сканировать другие программы на вашем телефоне (тот самый QUERY_ALL_PACKAGES):

adb shell pm list packages --user 0 | sed 's/package://' | while read pkg; do adb shell dumpsys package $pkg | grep -q "android.permission.QUERY_ALL_PACKAGES" && echo "$pkg"; done

Зачем это нужно:
Чтобы понимать масштаб угрозы. Если приложение из этого списка вам не жизненно необходимо — сносите. Для оставшихся в живых: жестко отрезаем работу в фоне (Настройки — Батарея — Ограничено), отзываем доступ к контактам, логам звонков и локации.

Итог: Государство успешно делегировало цензуру частному бизнесу. Split tunneling больше не спасает — приложения видят поднятый tun0 на уровне системы. Поднимайте VPN-туннели аппаратно на домашних роутерах (MikroTik/Keenetic), чтобы телефон получал уже «чистый» Wi-Fi без локальных VPN-клиентов.

#security #vpn #android #privacy #sysadmin #admin_future

🐧 Linux: Bcachefs выгнали из ядра — и это хорошая новость для тех, кто понимает

Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.

Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.

Что это означает на практике — собираем пул с erasure coding:

# Устанавливаем DKMS-модуль (Ubuntu 24.04 / Debian 13)
apt install bcachefs-tools bcachefs-dkms linux-headers-$(uname -r)

# Форматируем пул из 4 дисков с erasure coding (аналог RAID 5)
# 3 диска данных + 1 диск паритета
bcachefs format \
  --label=storage \
  --erasure_code \
  --replicas=1 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Монтируем (UUID рекомендуется для надёжности)
mount -t bcachefs /dev/sdb:/dev/sdc:/dev/sdd:/dev/sde /mnt/storage

# Проверяем статус пула
bcachefs fs usage /mnt/storage

# Смотрим здоровье устройств
bcachefs show-super /dev/sdb

Зачем это нужно:
ZFS на Linux — всё ещё лицензионный компромисс. Btrfs RAID5/6 в дистрессе ест данные — и сообщество в глубоком отрицании. Bcachefs с erasure coding — это первая GPL-нативная альтернатива, которая делает это правильно. Для хранилища на Proxmox или bare-metal — смотреть обязательно.

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

#linux #bcachefs #filesystem #storage #sysadmin #admin_future

🪟 Windows: SMB через порт 445 в 2026 году — это как ходить в интернет через telnet

Коллеги, признайтесь: у скольких из вас в DMZ или для удалённого офиса проброшен TCP 445 с каким-нибудь ACL "только для своих"? Я видел такое на аудите буквально в прошлом квартале, и это зрелище не для слабонервных.

Windows Server 2025 принёс кое-что важное для всех изданий, не только Azure Edition: SMB over QUIC — это SMB, инкапсулированный в QUIC-протокол и работающий через UDP 443 с TLS 1.3. Для удалённого пользователя это выглядит как обычная сетевая папка, но транспорт полностью зашифрован и firewall-friendly. Никакого VPN, никакого открытого 445-го.

Включаем через PowerShell (WAC для 2025 пока не поддерживает, только PS):

# 1. Убеждаемся что SMBv1 мёртв
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# 2. Включаем аудит — смотрим кто ещё не умеет шифрование
Set-SmbServerConfiguration -AuditClientDoesNotSupportEncryption $true
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 3. Привязываем сертификат к SMB over QUIC
# (сертификат нужен с SAN = FQDN файл-сервера, можно Let's Encrypt)
$thumb = (Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {$_.Subject -like "*fileserver*"}).Thumbprint

Set-SmbServerCertificateMapping `
  -Name "QuicCert" `
  -Thumbprint $thumb `
  -StoreName "My" `
  -Force

# 4. Включаем QUIC-листенер на интерфейсе
New-SmbServerNetworkInterface `
  -InterfaceAlias "Ethernet" `
  -QuicListener $true

# 5. Проверяем — клиент должен видеть QUIC
Get-SmbConnection | Select ServerName, Dialect, TransportName
# TransportName = QUIC — победа

Зачем это нужно:
Всё SMB-соединение, включая аутентификацию и авторизацию, находится внутри TLS-туннеля и никогда не открыто на сетевом уровне.

Итог: TCP 445 — это наследие 1996 года. У вас есть Windows Server 2025 и три команды в PowerShell. Нет причин не закрыть этот вопрос сегодня.

#windows #smb #quic #security #windowsserver2025 #sysadmin #admin_future

🧠 Skills: Твоя инфраструктура работает. А ты — нет. О выгорании инженера

Коллеги, поговорим о том, о чём не принято говорить на конференциях между докладами про Kubernetes.

Выгорание — это не просто стресс. Это затяжное состояние полного умственного, физического и эмоционального истощения. И это, пожалуй, самая серьёзная и недооценённая проблема в профессии системного администратора.

Я видел это по-разному. Коллега, который держит на себе всю инфраструктуру потому что "он единственный кто понимает как это работает" — это Bus Factor = 1 и верный путь к выгоранию. Коллега, который берёт задачи из личного чата в 23:00 потому что неловко отказать — туда же. Знакомо?

Те, кто не выгорает, научились справляться со стрессом без саморазрушения, просить о помощи когда нужно, и поддерживать баланс между работой и жизнью за её пределами.

Практический алгоритм выхода из режима "я незаменим":

Шаг 1 — ИНВЕНТАРИЗАЦИЯ НАГРУЗКИ
  Фиксируй всё что делаешь 2 недели в любом трекере.
  Цель: увидеть реальную картину, а не ощущение.

Шаг 2 — РАЗДЕЛЕНИЕ НА КАТЕГОРИИ
  [A] Только я (требует моей экспертизы)
  [B] Может делать обученный коллега
  [C] Должно быть автоматизировано
  [D] Не нужно делать вообще

Шаг 3 — ИЗБАВЛЕНИЕ ОТ КАТЕГОРИИ D
  Гарантированно 20-30% задач там.
  Просто перестать делать и посмотреть что случится.
  Обычно — ничего.

Шаг 4 — АВТОМАТИЗАЦИЯ КАТЕГОРИИ C
  Один скрипт, одна задача. Не "потом".
  Сейчас. Это инвестиция, а не трата времени.

Шаг 5 — ДЕЛЕГИРОВАНИЕ КАТЕГОРИИ B
  Задокументировать -> передать -> принять что будет сделано
  не идеально, но достаточно хорошо.

Шаг 6 — ЖЁСТКИЕ ГРАНИЦЫ
  Рабочий чат отключается в 19:00.
  Это не грубость. Это профессиональная гигиена.

Зачем это нужно:
К 2026 году от администраторов ожидают больше uptime, больше безопасности и больше автоматизации — как правило, с той же командой и меньшим терпением. Чтобы работать в таких условиях годами, а не месяцами — нужно управлять собой с той же методичностью, с которой ты управляешь инфраструктурой.

Итог: Твои серверы мониторятся. Твой CPU-load отслеживается. А кто мониторит тебя? Настрой алерт. Себе.

#skills #burnout #sysadmin #teamwork #карьера #admin_future

🐧 Linux: Ядро 7.0 вышло — и вот что из этого реально важно для продакшна

Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.

Три изменения, за которыми стоит следить:

Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.

Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.

Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.

Как проверить, что вы не сломаетесь при переходе:

# Смотрим текущую версию и параметры компиляции
uname -r
cat /boot/config-$(uname -r) | grep -E "CONFIG_MODULE_SIG|CONFIG_RUST"

# Проверяем подписи установленных DKMS-модулей
dkms status
# Все модули должны пересобраться под новое ядро автоматически

# Для XFS — проверяем здоровье до обновления (на всякий случай)
xfs_info /dev/sda1
dmesg | grep -i xfs | grep -iE "error|corrupt|repair"

# После перехода на 7.0 — смотрим, что новый самохил XFS активен
dmesg | grep -i "xfs.*repair\|xfs.*heal"

# Ubuntu 26.04 LTS получит 7.0 из коробки (выход 23 апреля)
# На текущих системах — через mainline PPA для тестирования:
sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update && apt list --upgradable | grep linux-image

Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.

Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.

#linux #kernel #xfs #security #sysadmin #admin_future

🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться

Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.

Звучит хорошо. Но есть нюанс.

Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.

Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:

# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor

# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory

$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor

foreach ($OU in $OUs) {
    $acl = Get-Acl "AD:$($OU.DistinguishedName)"
    $acl.Access | Where-Object {
        $_.ActiveDirectoryRights -match "CreateChild" -and
        $_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
        # ObjectType для msDS-DelegatedServiceAccount
    } | Select-Object IdentityReference, ActiveDirectoryRights |
    ForEach-Object {
        [PSCustomObject]@{
            OU       = $OU.Name
            Identity = $_.IdentityReference
            Rights   = $_.ActiveDirectoryRights
        }
    }
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation

# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
  "*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
  Select TimeCreated, Message | Format-List

Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.

Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.

#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future

🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму

Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.

Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.

Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.

Шаблон runbook, который реально работает:

---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---

## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"

## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
  $ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica

## Шаг 2 — Проверка репликации
  $ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.

## Шаг 3 — Failover (только если мастер недоступен)
  $ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.

## Шаг 4 — Проверка после failover
  $ patronictl -c /etc/patroni/config.yml list
  $ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)

## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)

## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni

Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.

Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.

#skills #documentation #runbook #sysadmin #teamwork #admin_future

🎓 Собеседование сисадмина. Выпуск #12: Kubernetes — то, что спрашивают в 2026 году

Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.

Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".

---

❓ Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»

❌ Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».

✅ Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.

Алгоритм траблшутинга:

# Шаг 1 — Смотрим текущие логи
kubectl logs <pod-name> -n <namespace>

# Если контейнер упал слишком быстро — логи уже улетели.
# Берём логи предыдущего запуска:
kubectl logs <pod-name> -n <namespace> --previous

# Шаг 2 — Описание pod: ищем Reason в Last State
kubectl describe pod <pod-name> -n <namespace>
# Смотрим секцию "Last State" и "Events"
# Причины бывают разные:
#   OOMKilled     -> контейнер убит за превышение лимита памяти
#   Error (exit 1) -> приложение упало само (ошибка конфига/зависимость)
#   RunContainerError -> не может стартовать (нет образа, нет прав на том)

# Шаг 3 — Если OOMKilled: смотрим лимиты и правим манифест
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# Временно поднимаем memory limit, чтобы убедиться в диагнозе:
# resources.limits.memory: 512Mi -> 1Gi

# Шаг 4 — Проверяем ConfigMap и Secret: существуют ли они в этом namespace?
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>
# Если приложение не может найти конфиг — оно упадёт с exit code 1

Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает.

---

❓ Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?»

❌ Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли».

✅ Ответ инженера:
Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий.

Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний.

Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша).

Что будет если перепутать:

# ПЛОХОЙ пример: Liveness смотрит на /ready (страница прогрева)
# При старте приложению нужно 30 секунд на инициализацию БД.
# Liveness видит 503 -> убивает контейнер -> перезапускает -> снова 503
# -> бесконечный CrashLoopBackOff на старте.

# ПРАВИЛЬНАЯ конфигурация:
livenessProbe:
  httpGet:
    path: /healthz      # Легкая проверка: "процесс жив?"
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready        # Тяжелая проверка: "готов принимать трафик?"
    port: 8080
  initialDelaySeconds: 20 # Даём время на прогрев
  periodSeconds: 5
  failureThreshold: 2

Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией.

---

❓ Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?»

❌ Ответ новичка: «Secrets зашифрованы, поэтому безопасны».

✅ Ответ инженера:
Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.

По умолчанию Kubernetes Secrets хранятся в etcd только в формате base64, а не в зашифрованном виде. В продакшне необходимо включать шифрование данных at rest и ограничивать доступ через RBAC.

Base64 — это кодировка, а не шифрование. Любой, у кого есть доступ к etcd или к объекту Secret в API — видит пароль в открытом виде.

Как это исправить — три уровня защиты:

# Уровень 1: Включаем Encryption at Rest в etcd
# В конфиге kube-apiserver добавляем:
# --encryption-provider-config=/etc/kubernetes/enc/enc.yaml
# enc.yaml:
# resources:
#   - resources: ["secrets"]
#     providers:
#       - aescbc:
#           keys:
#             - name: key1
#               secret: <base64-encoded-32-byte-key>
#       - identity: {}

# Уровень 2: RBAC — минимальные права на чтение Secrets
kubectl create role secret-reader \
  --verb=get,list \
  --resource=secrets \
  --namespace=production

# Уровень 3 (продакшн-стандарт 2026): External Secrets Operator
# Secrets хранятся в Vault / AWS Secrets Manager / Azure Key Vault
# Kubernetes их НИКОГДА не держит у себя в etcd
# Манифест ExternalSecret:
# apiVersion: external-secrets.io/v1beta1
# kind: ExternalSecret
# spec:
#   secretStoreRef:
#     name: vault-backend
#   data:
#     - secretKey: db-password
#       remoteRef:
#         key: production/db
#         property: password

Секреты никогда не должны попадать в Git в открытом виде. Стандарт 2026 года: внешние хранилища (HashiCorp Vault, Cloud KMS) с инъекцией через External Secrets Operator или CSI-драйвер.

---

💡 Золотое правило собеса: Когда вас спрашивают про Kubernetes — интервьюер проверяет не знание синтаксиса kubectl, а понимание того, что происходит под капотом. Фраза "pod упал — я смотрю логи предыдущего запуска через --previous флаг, потому что текущие уже затёрты" — мгновенно выдаёт человека, который это делал в реальном продакшне, а не только читал документацию.

Сохраняйте пост — Kubernetes на собесах уже не опциональная тема!

#собеседование_AF #kubernetes #k8s #devops #sysadmin #контейнеры #admin_future

🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно

Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.

Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.

Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.

Сначала — аварийный аудит. Находим всё, что ещё на SysV:

# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null

# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"

# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
  while read unit _; do
    unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
    [[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
  done

# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s

# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service

Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.

Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.

#linux #systemd #sysv #sysadmin #ubuntu #admin_future

🪟 Windows: Hotpatch по умолчанию с мая 2026 — разбираемся, что это значит для твоей инфраструктуры

Коллеги, тихая, но важная новость: начиная с майского обновления безопасности 2026 года, Windows Autopatch включает hotpatch-обновления по умолчанию для всех eligible-устройств под управлением Microsoft Intune. Если ты управляешь парком Windows 11 24H2 через Intune — с мая твои машины начнут получать патчи безопасности без перезагрузки. Автоматически. Хочешь ты этого или нет.

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

Как это работает: hotpatch следует строгому квартальному циклу: в январе, апреле, июле и октябре — полное накопительное обновление с перезагрузкой (baseline), в остальные месяцы — hotpatch-пакеты, которые патчат только код запущенных процессов в памяти, без рестарта. Итого: 4 перезагрузки в год вместо 12.

Звучит идеально. Но есть нюансы:

# Проверяем, готово ли устройство к hotpatch
# Требования: Windows 11 24H2+, VBS включён, апрельский baseline установлен

# 1. Проверяем версию и билд
Get-ComputerInfo | Select-Object WindowsVersion, OsBuildNumber, OsDisplayVersion

# 2. Проверяем статус Virtualization-Based Security (обязательное требование)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (хорошо), 0 = Not enabled (hotpatch не получим)

# 3. Смотрим в Intune — статус по устройствам (через Graph API)
# Или через портал: Intune -> Devices -> Monitor -> Hotpatch quality update report

# 4. Если нужно ОТКЛЮЧИТЬ hotpatch для группы устройств или всего тенанта
# Intune -> Devices -> Windows updates -> Quality updates -> Edit policy
# Переключить "When available, apply without restarting" -> Block

# 5. Через реестр на конкретной машине (для тестовых сценариев)
Set-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
  -Name "HotPatchRestrictions" `
  -Value 1 -Type DWORD
# Value 1 = отключить hotpatch, Value 0 = включить

# 6. Проверяем, какой тип обновления был установлен последним
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
# Hotpatch-обновления будут иметь KB-номер с пометкой "Hotpatch" в описании

Важное предупреждение, которое Microsoft тихо упомянула в документации: устройства с включённым hotpatch могут падать при операции "Reset This PC" — после первой фазы сброса машина перезагружается обратно на рабочий стол с ошибкой. Это задокументированная проблема. Если у тебя есть сценарии переустановки через Push Button Reset — проверь это в лабе до мая.

Зачем это нужно:
Устройства, установившие апрельский baseline и соответствующие требованиям, начнут автоматически получать hotpatch-обновления с 11 мая 2026 года. Если ты ещё не готов — контроль отказа доступен с 1 апреля через Intune. Срок уже прошёл. Проверяй настройки сегодня.

Итог: Меньше перезагрузок — это хорошо для uptime и для нервов пользователей. Но "включилось само" в enterprise без понимания механики — это риск. Проверь VBS на всём парке, убедись в апрельском baseline и реши явно: включаешь или отключаешь. Случайных изменений в инфраструктуре не бывает.

#windows #hotpatch #intune #autopatch #patching #sysadmin #admin_future