🧠 Skills: Как правильно использовать ИИ в работе администратора — без иллюзий и без паники

Коллеги, разговор, которого многие избегают, потому что тема кажется либо хайпом, либо угрозой. Ни то ни другое. Это просто новый инструмент — и как любой инструмент, он работает хорошо там, где его применение осмысленно, и создаёт проблемы там, где его применяют вслепую.

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

Где ИИ реально помогает прямо сейчас — три конкретных паттерна:

ПАТТЕРН 1: ГЕНЕРАЦИЯ И ОТЛАДКА СКРИПТОВ

Плохой запрос:
"Напиши мне PowerShell-скрипт для AD"

Хороший запрос:
"Я Senior Systems Administrator. Среда: Windows Server 2025,
PowerShell 7.4, домен corp.local, модуль ActiveDirectory установлен.
Напиши скрипт который находит все неактивные компьютерные аккаунты
(не логинились больше 90 дней), экспортирует в CSV с полями:
Name, LastLogonDate, OU, Enabled.
Добавь обработку ошибок и -WhatIf параметр для безопасного тест-запуска."

Разница: второй запрос даёт рабочий результат с первого раза.
Контекст среды — это ключ. Без него ИИ галлюцинирует cmdlets.

ПАТТЕРН 2: ТРАБЛШУТИНГ КАК ДИАЛОГ

Ситуация: непонятная ошибка в логах, нет времени читать man.
Метод: вставить полный текст ошибки + контекст системы
и спросить "объясни что происходит и дай 3 гипотезы"

Пример:
"На RHEL 9 в journalctl вижу:
kernel: EXT4-fs error (device sdb1): ext4_find_entry:1455
Система: PostgreSQL 15, база на /dev/sdb1 ext4, kernel 6.18.
Что это может быть и что проверить в первую очередь?"

Результат: структурированные гипотезы, команды для диагностики.
Ты всё равно принимаешь решение — ИИ даёт карту возможностей.

ПАТТЕРН 3: ДОКУМЕНТАЦИЯ КАК ПОБОЧНЫЙ ПРОДУКТ

После решения инцидента: скармливаешь ИИ
- timeline событий из логов
- команды которые выполнял
- итог

Просишь: "Напиши postmortem по этому инциденту в формате:
Timeline / Root Cause / Impact / Actions Taken / Prevention"

За 2 минуты получаешь структурированный документ.
Который раньше не писал вообще, потому что "некогда".

Где ИИ НЕ стоит использовать без проверки:

КРАСНЫЕ ФЛАГИ:

[!] Любые деструктивные операции без -WhatIf / --dry-run
    Всегда тестируй сгенерированный скрипт в тестовой среде

[!] Конфигурации безопасности (firewall rules, SELinux policies)
    ИИ не знает твою топологию — он угадывает

[!] Чувствительные данные в промпте
    Не вставляй пароли, ключи, имена пользователей в публичные ИИ

[!] "ИИ сказал что так правильно" как аргумент
    ИИ уверенно ошибается. Всегда проверяй по официальной документации

Практический подход — три правила зрелого использования ИИ:

Первое — контекст решает всё. Чем точнее описана среда (ОС, версия, конкретная задача, ограничения), тем выше качество ответа. Потрать 30 секунд на формулировку — сэкономишь 30 минут на исправление.

Второе — ИИ как черновик, не как финал. Каждый сгенерированный скрипт читай как код коллеги на code review: понимаешь ли что делает каждая строка? Нет — разбирай дальше или переписывай.

Третье — документируй промпты которые работают. Если нашёл промпт который даёт хорошие результаты для регулярной задачи (аудит AD, проверка сертификатов, генерация отчётов) — сохрани его в своём репозитории промптов. Это твои инструменты, не одноразовые запросы.

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

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

#skills #AI #автоматизация #sysadmin #карьера #powershell #admin_future

🐧 Linux: Ubuntu 26.04 LTS вышла сегодня — что важно для сервера

Коллеги, 23 апреля 2026 — день релиза Ubuntu 26.04 LTS «Resolute Raccoon». Поддержка 5 лет бесплатно (до 2031), с Ubuntu Pro — 10 лет. Это первый LTS после 24.04.

Три вещи, важных конкретно для серверной эксплуатации:

Первое — sudo-rs теперь дефолтный sudo-провайдер. Оригинальный sudo переименован в sudo.ws. Пакет sudo-ldap удалён: LDAP-аутентификация теперь только через PAM. Если у вас sudo через LDAP — проверьте конфигурацию до апгрейда.

Второе — systemd в этом релизе убирает поддержку cgroup v1 полностью. Только унифицированная иерархия cgroup v2. Если какие-то контейнеры или легаси-сервисы у вас были привязаны к v1 — они не запустятся.

Третье — ядро Linux 7.0 из коробки. Это XFS self-healing, стабильный Rust, улучшенная производительность памяти (время аллокации больших блоков упало с 3.6 до 0.43 секунды), создание контейнеров стало на 40% быстрее.

# Проверяем готовность к апгрейду с 24.04
# Смотрим есть ли sudo через LDAP
grep -r "ldap" /etc/sudo* /etc/nsswitch.conf 2>/dev/null

# Проверяем cgroup версию
stat -fc %T /sys/fs/cgroup/
# tmpfs = v1 (проблема), cgroup2fs = v2 (порядок)

# Официальный апгрейд (когда будет открыт путь 24.04→26.04):
sudo do-release-upgrade

Зачем это нужно:
Для продакшн-серверов рекомендуется подождать релиза 26.04.1 в августе 2026 — первый point release включает несколько месяцев исправлений и открывает официальный путь апгрейда с 24.04.

Итог: новые серверы — ставьте 26.04 сегодня. Продакшн 24.04 — дождитесь августа.

#linux #ubuntu #lts #sysadmin #admin_future

🪟 Windows: Апрельский Patch Tuesday сломал DC — и Microsoft уже выпустила OOB-фикс

Коллеги, если вы ещё не слышали — апрельское обновление KB5082063 наломало дров. Контроллеры домена в средах с Privileged Access Management (PAM) уходили в бесконечный цикл перезагрузок из-за краша LSASS. Затронуты все версии Windows Server от 2016 до 2025.

Хорошая новость: 19 апреля Microsoft выпустила внеплановые OOB-обновления. Для Windows Server 2025 — KB5091157 (стандартный) или KB5091470 (для hotpatch-сред, без перезагрузки).

# Проверяем установлен ли проблемный патч
Get-HotFix | Where-Object {$_.HotFixID -eq "KB5082063"}

# Проверяем статус LSASS и не крутится ли DC в петле
Get-Service lsass | Select-Object Status
Get-EventLog -LogName System -Newest 20 |
    Where-Object {$_.Source -like "*LSASS*" -or $_.Source -like "*SAM*"}

# Устанавливаем OOB-фикс вручную (скачать с Microsoft Update Catalog)
# Для WS2025: KB5091157
# Для WS2022: KB5091575
# Для WS2019: KB5091574

# Если DC уже в петле — загружаемся в DSRM и откатываем:
# В меню Advanced Boot Options -> Directory Services Restore Mode
# Затем из cmd:
dism /image:C:\ /get-packages | findstr /i "KB5082063"
# dism /image:C:\ /remove-package /packagename:[имя_пакета]

Зачем это нужно:
Апрельские апдейты ломали контроллеры домена уже три года подряд. Вывод простой: DC обновляем последними, держим снапшот перед каждым Patch Tuesday и знаем наизусть путь в DSRM.

Итог: KB5091157 ставим немедленно. Без него KB5082063 на DC — это потенциальная недоступность домена.

#windows #activedirectory #patchtuesday #sysadmin #admin_future

🧠 Skills: Домашняя лаборатория — лучшая инвестиция в карьеру сисадмина

Коллеги, разговор о том, что разделяет администраторов, которые растут, от тех, кто стоит на месте. Ответ чаще всего один — наличие личной лаборатории.

Домашняя лаборатория — безопасное место для провалов, экспериментов и роста без страха положить продакшн. Облако не заменило homelab. Лаборатория стала ещё актуальнее — это место, где можно практиковать Git, IaC, CI/CD и контейнеры бесплатно, не получив счёт на 100 тысяч долларов из облака.

Минимальный стартовый стек в 2026 году:

ЖЕЛЕЗО (один сервер — уже лаборатория):
  Б/у десктоп / NUC: 32GB RAM, SSD 512GB
  Или: старый игровой ноут с 16GB RAM
  Гипервизор: Proxmox VE (бесплатно)

СЕРВИСЫ ДЛЯ ПРАКТИКИ:
  - Proxmox + несколько VM: Linux + Windows Server
  - Self-hosted Git (Gitea) — всё в Git с первого дня
  - Ansible — автоматизируем конфиги вместо ручного тыка
  - Prometheus + Grafana — мониторинг как в продакшне
  - WireGuard — VPN для удалённого доступа к лабе

ЧТО ПРАКТИКОВАТЬ:
  Неделя 1-2: поднять Proxmox, создать несколько VM
  Неделя 3-4: настроить сеть, VLAN, DNS
  Месяц 2:    Ansible playbook для автодеплоя Ubuntu/WinServer
  Месяц 3:    Kubernetes (k3s) + мониторинг
  Месяц 4+:   Сломай и восстанови. Повтори.

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

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

Итог: лаборатория — это не хобби. Это твой личный учебный полигон, где можно освоить то, что в продакшне трогать страшно. Начни с одного старого ПК и Proxmox. Дальше само затянет.

#skills #homelab #карьера #proxmox #sysadmin #admin_future

🐧 Linux: nullfs в ядре 7.0 — зачем нужна «чёрная дыра» в файловой системе

Коллеги, одна из тихих, но важных вещей в ядре 7.0 — новый псевдофайловый тип nullfs. Звучит странно. Разберёмся зачем.

nullfs решает давнюю проблему initramfs: раньше pivot_root() не работал на реальной корневой ФС, потому что её нельзя было размонтировать. Userspace вынужден был делать хрупкий switch_root — рекурсивное удаление initramfs вручную перед продолжением загрузки.

Теперь схема чистая: nullfs — это минималистичная иммутабельная псевдо-ФС, она становится истинным корнем иерархии монтирования. Поверх неё монтируется mutable rootfs (tmpfs). Это позволяет сделать chdir + pivot_root + umount атомарно, без воркараундов.

Бонус для безопасности: каждый kernel thread получит nullfs как свою корневую ФС — это изолирует потоки ядра от файловой системы init-процесса. Сейчас все kernel threads разделяют файловое состояние init, что создаёт риск.

Что это значит на практике:

# nullfs включён по умолчанию в ядре 7.0
# Проверяем что он есть в системе:
cat /proc/filesystems | grep null

# Быстрее загружается initramfs — меньше задержек при старте
# Полезно замерить разницу до и после апгрейда на Ubuntu 26.04:
systemd-analyze
systemd-analyze blame | head -20

# Смотрим дерево монтирования — nullfs будет в корне:
findmnt --tree | head -5

Зачем это нужно:
Надёжнее загрузка → меньше случаев когда сервер не поднялся после патча. Для флотов с автоматическим деплоем ядра — это снижение риска.

Итог: nullfs — это не экзотика. Это архитектурная чистка, которая делает Linux-boot предсказуемее. Ubuntu 26.04 уже с ней.

#linux #kernel7 #boot #filesystem #sysadmin #admin_future

🧠 Skills: Переводи downtime в деньги — или тебя не будут слушать

Коллеги, есть навык, который отличает инженера от архитектора инфраструктуры. Не знание конкретной технологии. Умение объяснить цену отказа на языке бизнеса.

Когда ты говоришь "нам нужна избыточность" — тебя слышат как расходы. Когда ты говоришь "один час простоя стоит нам X рублей" — тебя слышат как управление рисками. Разница принципиальная.

Даже один час даунтайма обходится средней компании в 300 000+. Для крупных предприятий цифры уходят в миллионы. Переведи это на свой контекст — и у тебя появится аргумент.

Простая формула для любого разговора с руководством:

ФОРМУЛА СТОИМОСТИ ДАУНТАЙМА:

Стоимость = Минуты простоя × Стоимость минуты

Стоимость минуты включает:
  + Потерянная выручка (продажи/транзакции в час ÷ 60)
  + Простой сотрудников (кол-во × зарплата в час ÷ 60)
  + Стоимость восстановления (инженер-часы × ставка)
  + Штрафы по SLA (если есть)
  + Репутационные потери (сложнее считать, но упоминать)

ПРИМЕР:
  Интернет-магазин: 500 000 руб/час выручки
  50 сотрудников простаивают: 50 × 2000 руб/час = 100 000 руб/час
  Инженер на восстановление: 5000 руб/час × 3 часа = 15 000 руб
  
  Итого 3 часа даунтайма:
  (500 000 + 100 000) × 3 + 15 000 = 1 815 000 руб

  HA-решение стоит 300 000 руб/год.
  ROI очевиден.

Переход от 99.0% к 99.9% uptime может означать сотни тысяч сэкономленных рублей в год — часто больше, чем стоит само улучшение инфраструктуры.

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

Итог: посчитай стоимость одного часа простоя своего самого критичного сервиса. Запиши число. Именно с него начинается любой разговор о надёжности.

#skills #downtime #sla #карьера #sysadmin #admin_future

🪟 Windows: Создатель диспетчера задач признался — CPU% всегда было «некрологом недавнего прошлого»

Коллеги, на этой неделе Дэйв Пламмер — инженер Microsoft, написавший оригинальный Task Manager — объяснил то, о чём многие из нас догадывались, но не формулировали чётко. Цифра загрузки CPU в диспетчере задач никогда не была «сейчас».

«Число CPU в диспетчере задач — это движущийся некролог недавнего прошлого», объяснил Пламмер. «Не то, что происходило в момент, когда ваши глаза остановились на строке».

Как это работало изнутри:

Windows не хранит никакого магического значения загрузки CPU, готового к считыванию. Вместо этого Task Manager работал по таймеру: при каждом срабатывании запрашивал у ядра накопленное процессорное время каждого процесса и сравнивал с предыдущим снимком.

Это решение умное и дешёвое — но у него есть фундаментальное ограничение на современном железе:

«Современная загрузка CPU больше похожа на то, насколько было заполнено шоссе, а не на то, сколько миль реально проехали. Полупустое шоссе с Ferrari может пропустить гораздо больше трафика, чем забитое шоссе со старыми грузовиками».

Процессоры с Turbo Boost, тепловым троттлингом и глубокими состояниями простоя разорвали связь между «занятым временем» и «реально выполненной работой». 73% в диспетчере может означать совершенно разный объём вычислений в зависимости от того, на какой частоте работал CPU в этот момент.

Что из этого следует практически — чем смотреть вместо Task Manager:

# Реальная утилизация CPU с учётом частоты (не просто время)
# Performance Monitor — метрика "Processor Information\% Processor Utility"
# Именно её Microsoft начала использовать по умолчанию с июля 2025

# Через PowerShell — утилизация с учётом частоты:
Get-Counter '\Processor Information(_Total)\% Processor Utility' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# Сравниваем с классическим % (время):
Get-Counter '\Processor(_Total)\% Processor Time' |
    Select-Object -ExpandProperty CounterSamples |
    Select-Object CookedValue

# На нагруженном сервере разница между двумя метриками
# может достигать 30-40% — именно столько "врал" старый Task Manager

# Для глубокого анализа — PAL (Performance Analysis of Logs)
# или просто смотрим в Windows Admin Center -> Performance Monitor

Кстати, Microsoft уже исправила это: с июля 2025 года Task Manager использует стандартную метрику утилизации для отображения нагрузки CPU на всех вкладках — Processes, Performance и Users — приводя её в соответствие с отраслевыми стандартами и сторонними инструментами.

Зачем это знать:
Если вы делаете выводы о нагрузке на сервер по старому диспетчеру задач — вы смотрите на интерпретацию прошлого через упрощённую формулу. Для реального capacity planning используй Performance Monitor, метрику % Processor Utility и нормальный мониторинг с историей.

Пламмер точно сформулировал суть: «Инструмент мониторинга, который требует семинара по инженерии перед завтраком, уже проиграл». Task Manager и не должен был быть точным осциллографом. Он должен был быть быстрым и понятным — и он им был. Просто не путай его с инструментом точного анализа.

Итог: то, что ты видишь в Task Manager — это не ложь. Это упрощение. Разница принципиальная, и понимать её важно, особенно когда объясняешь бизнесу почему 40% в мониторинге это не то же самое, что 40% реальной нагрузки.

#windows #performance #troubleshooting #sysadmin #admin_future

🐧 Linux: Cilium без kube-proxy — eBPF как замена iptables в Kubernetes

Коллеги, если у вас Kubernetes и kube-proxy на iptables — вы работаете с инструментом 2001 года. Не метафорически, буквально.

Проблема простая: iptables не был спроектирован для динамических сред. При каждом изменении Service или Endpoint правила перезаписываются целиком — на кластере из 500+ сервисов это создаёт заметную задержку и нагрузку на CPU.

Cilium в режиме kube-proxy replacement решает это через eBPF: таблицы маршрутизации хранятся в BPF maps, обновляются атомарно и обрабатываются прямо в ядре без userspace-прыжков.

# Устанавливаем Cilium с отключённым kube-proxy (k3s / kubeadm)
# При инициализации кластера убираем kube-proxy:
kubeadm init --skip-phases=addon/kube-proxy

# Устанавливаем Cilium через Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true

# Проверяем что kube-proxy replacement активен
cilium status --verbose | grep -i "kube-proxy"
# KubeProxyReplacement: True

# Смотрим BPF-таблицы сервисов напрямую
cilium service list
cilium bpf lb list

# Мониторинг сетевых событий в реальном времени
cilium monitor --type drop

Зачем это нужно:
Cilium с eBPF даёт встроенную наблюдаемость L3/L4/L7 без sidecar-контейнеров, встроенный network policy без overhead iptables, и Hubble — визуализацию трафика между подами в реальном времени. Для кластеров от 50 нод разница в latency ощутима.

Итог: iptables в Kubernetes — это как держать Zabbix 2.0 вместо Prometheus. Работает, но не для 2026 года.

#linux #kubernetes #ebpf #cilium #networking #sysadmin #admin_future

🪟 Windows: hotpatch в мае — что изменилось и одна важная ловушка

Коллеги, с 11 мая hotpatch включается по умолчанию для всех eligible Windows 11 24H2 устройств через Intune. Разбираем быстро что важно знать прямо сейчас.

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

Схема простая: 4 раза в год (январь, апрель, июль, октябрябрь) — полный baseline с перезагрузкой. Остальные 8 месяцев — hotpatch без рестарта.

Но апрельский цикл преподнёс сюрприз: установка KB5091157 (OOB-фикс для апрельского Patch Tuesday) требует перезагрузки и приостанавливает hotpatching. Hotpatch-обновления возобновятся только после июльского baseline. То есть если поставили фикс — ближайшие два месяца работаете в обычном режиме.

# Проверяем статус hotpatch на устройстве
Get-WmiObject -Namespace "root\cimv2" `
  -Class Win32_QuickFixEngineering |
  Sort-Object InstalledOn -Descending |
  Select-Object HotFixID, InstalledOn -First 5

# Смотрим включён ли hotpatch через реестр
Get-ItemProperty `
  -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Update\TargetingInfo\Installed\*" `
  -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -like "*Hotpatch*" }

# В Intune — статус через Graph API
# Intune Portal → Devices → Windows updates →
# Quality updates → Hotpatch quality update report

# Проверяем VBS (обязательное требование для hotpatch):
Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (можно hotpatch), 0 = отключён (hotpatch не работает)

Зачем это нужно:
После установки OOB KB5091157 с перезагрузкой hotpatching приостанавливается до июльского baseline. Это задокументированное поведение — планируй обслуживание соответственно.

Итог: hotpatch — хорошая технология. Но "включилось само" без понимания цикла — это потеря контроля над maintenance windows. Проверь VBS и пойми свой текущий статус до 11 мая.

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

🧠 Skills: CMDB — кладбище данных или реальный инструмент. Зависит от одного решения

Коллеги, у большинства из нас есть CMDB. У меньшинства она актуальна. Это не проблема инструмента — это проблема подхода.

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

Главная ошибка — CMDB заполняется вручную и живёт отдельно от реальных изменений инфраструктуры. Основная проблема CMDB — сложность актуализации данных. Идея CMDB формировалась в эпоху статичных «железных» конфигураций. Для современных динамичных сред нужен другой подход.

Единственный подход который работает в 2026 — автообнаружение + IaC как источник истины:

РАБОЧАЯ СХЕМА ДЛЯ CMDB:

Источники данных (автоматически, не вручную):
  ├── Terraform/Ansible state → что задеплоено и как
  ├── Netbox/NetAct → сетевые устройства и IP
  ├── Zabbix/Prometheus → что живёт и что мониторится
  └── AD/Entra → пользователи и машины

Принцип: если изменение не прошло через IaC —
оно не существует с точки зрения CMDB.

Что хранить в CMDB (только это, ничего лишнего):
  [CI]        Сервер / VM / контейнер
  [Атрибуты]  ОС, IP, owner, окружение (prod/stage/dev)
  [Связи]     Что от чего зависит (БД → приложение → балансер)
  [Статус]    Active / Decommissioned / Maintenance

Что НЕ хранить:
  ✗ Версии ПО (это в Ansible inventory)
  ✗ Пароли и ключи (это в Vault)
  ✗ История изменений (это в Git)

Ключевой вопрос перед добавлением любого атрибута в CMDB: кто будет поддерживать это актуальным и как? Если ответа нет — атрибут не нужен.

Зачем это нужно:
CMDB с актуальными зависимостями отвечает на вопрос "что упадёт если я выключу этот сервер?" за секунды, а не за час расследования. Это разница между проактивным и реактивным администрированием.

Итог: хорошая CMDB — это не большая, а актуальная. Лучше 50 записей которым все верят, чем 5000 которые никто не читает.

#skills #cmdb #itsm #infrastructure #sysadmin #admin_future

🐧 Linux: CVE-2026-31429 — дыра в сетевом стеке ядра, патчить не откладывая

Коллеги, на прошлой неделе тихо появилась CVE-2026-31429 — уязвимость в подсистеме управления памятью сетевого стека Linux. Разбираем быстро.

Баг находится в функции skb_kfree_head() — логике освобождения памяти socket buffer. Когда включён KFENCE (Kernel Electric-Fence, дебаг-детектор памяти), функция kfence_ksize() возвращает точный запрошенный размер вместо размера slab-бакета. Это приводит к освобождению объекта в неправильный slab-кэш — classic cross-cache free.

Уязвимость находится в «горячем, активно используемом сетевом пути» — через него проходит каждый сетевой пакет. Это делает её особенно опасной несмотря на узкий технический контекст. Возможные последствия: повреждение памяти ядра, privilege escalation или kernel panic.

# Проверяем включён ли KFENCE на сервере
cat /proc/cmdline | grep -o "kfence.sample_interval=[0-9]*"
# Если вывод пустой или значение > 0 — KFENCE активен

# Проверяем версию ядра — патч уже в stable tree
uname -r

# Ubuntu: ставим обновление ядра
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r)
sudo reboot

# RHEL/Rocky: 
sudo dnf update kernel -y && sudo reboot

# Временный митигейшн пока патч не встал:
# Отключаем KFENCE через параметр загрузки
# В /etc/default/grub добавляем в GRUB_CMDLINE_LINUX:
# kfence.sample_interval=0
sudo update-grub  # или grub2-mkconfig -o /boot/grub2/grub.cfg

# Дополнительно: ограничиваем доступ к BPF для непривилегированных
sysctl -w kernel.unprivileged_bpf_disabled=1
echo "kernel.unprivileged_bpf_disabled=1" >> /etc/sysctl.d/99-hardening.conf

Зачем это нужно:
Серверы, которые не могут немедленно применить патч, должны рассмотреть ограничение сетевого доступа через firewall-правила для сокращения поверхности атаки и мониторинг журналов на предмет необычных крашей или ошибок памяти.

Итог: KFENCE по умолчанию отключён в большинстве продакшн-дистрибутивов — проверь, прежде чем паниковать. Но патч ядра в любом случае ставим при ближайшем обслуживании.

#linux #kernel #cve #security #sysadmin #admin_future

🪟 Windows: Entra Passkeys на Windows — пароли официально умирают с этой недели

Коллеги, новость которую стоит знать прямо сейчас, потому что она касается твоих пользователей и твоих политик — молча, без запроса разрешения.

Microsoft Entra passkeys на Windows достигли General Availability с конца апреля 2026. Функция позволяет создавать device-bound passkeys в контейнере Windows Hello и аутентифицироваться через лицо, отпечаток или PIN. Важно: расширяет passwordless-аутентификацию на устройства, которые не присоединены к Entra ID — включая личные и общие Windows-устройства.

Ключевое изменение по сравнению с preview: больше не требуется явно разрешать Windows Hello AAGUID через allow-list в passkey-профиле. Если ваш профиль допускает device-bound, non-attested passkeys — пользователи начнут регистрировать passkeys на Windows автоматически, без дополнительной настройки администратором.

# Проверяем текущее состояние FIDO2/passkey политики в Entra
# Нужна роль Authentication Policy Administrator

# Через Graph API (требует модуль Microsoft.Graph):
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "fido2" |
  Select-Object -ExpandProperty AdditionalProperties

# Что проверить в Entra Admin Center:
# Identity → Security → Authentication methods → Policies → Passkey (FIDO2)
# Смотрим: включён ли, какие группы в scope, есть ли Key Restrictions

# Если хотим ЗАБЛОКИРОВАТЬ Windows Hello passkeys (только для конкретных сред):
# Добавляем Windows Hello AAGUID в block list профиля
# Windows Hello AAGUIDs:
# 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (Windows Hello hardware)
# 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (Windows Hello software)

# Проверяем зарегистрированные passkeys пользователя:
Get-MgUserAuthenticationFido2Method -UserId "user@domain.com" |
  Select-Object DisplayName, CreatedDateTime, AaGuid

Зачем это нужно:
Passkeys криптографически привязаны к устройству и никогда не передаются по сети — атакующий не может их украсть при фишинге или через вредоносное ПО для обхода MFA. Функция закрывает брешь в безопасности, которая оставляла личные и общие устройства с паролями после недавней волны атак на Entra SSO.

Итог: действие сегодня — зайди в Entra и убедись что знаешь, что будет происходить с passkeys в твоём тенанте. «Включилось само» — не оправдание на следующем аудите.

#windows #entra #passkeys #fido2 #security #sysadmin #admin_future

🧠 Skills: Capacity Planning — или как перестать тушить пожары и начать их предотвращать

Коллеги, честный вопрос: у вас есть прогноз нагрузки на инфраструктуру на следующий квартал? Не ощущение, а цифры? Если нет — вы занимаетесь реактивным администрированием. И рано или поздно вас накроет.

Capacity Planning — это дисциплина, которая превращает IT из реактивного «пожарного» в проактивного архитектора роста бизнеса. Её цель — оптимизировать производительность при непрерывной и пиковой нагрузке, понимая изменения в использовании: сезонные всплески, релизы продуктов, рост команды.

Минимальный рабочий фреймворк:

ШАГ 1 — СОБИРАЕМ БАЗОВЫЕ МЕТРИКИ (это уже должно быть)
  Prometheus / Zabbix / любой мониторинг:
  - CPU utilization (средний и p95 за 3 месяца)
  - RAM: available vs total, swap usage
  - Disk: usage growth rate (ГБ/неделя)
  - Network: throughput и packet loss тренды

ШАГ 2 — СЧИТАЕМ FORECAST (predict_linear в Prometheus)
  # Когда кончится диск при текущем темпе роста?
  predict_linear(
    node_filesystem_avail_bytes[30d], 90*24*3600
  ) < 0
  # Если True — через 90 дней диск будет забит

  # Когда CPU упрётся в потолок?
  predict_linear(
    rate(node_cpu_seconds_total{mode!="idle"}[30d]), 
    90*24*3600
  ) > 0.85

ШАГ 3 — МАТРИЦА РЕШЕНИЙ
  Текущий p95 < 60%  → мониторить ежемесячно
  Текущий p95 60-80% → планировать расширение в квартале
  Текущий p95 > 80%  → действовать сейчас, не ждать

ШАГ 4 — РАЗГОВОР С БИЗНЕСОМ
  "Сейчас диск растёт на 50 ГБ/неделю.
   Через 3 месяца заканчивается. 
   Расширение стоит X рублей.
   Инцидент обойдётся в Y рублей.
   Решаем сейчас?"

Распространённая ошибка: планирование в изоляции. IT-команды, которые прогнозируют спрос без информации от бизнеса, обречены на провал. Capacity plan должен опираться на бизнес-цели, а не только на исторические IT-данные.

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

Итог: capacity planning — это не документ раз в год. Это ежемесячные 30 минут с дашбордом и одним вопросом: "когда что-то упрётся в потолок?". Ответ на него должен быть у тебя всегда.

#skills #capacityplanning #мониторинг #инфраструктура #sysadmin #admin_future

🐧 Linux: systemd hardening — твои сервисы запущены в привилегиях которые им не нужны

Коллеги, большинство unit-файлов в продакшне выглядят так: Type=simple, ExecStart=..., Restart=on-failure — и всё. Сервис запускается с правами процесса, может писать куда угодно, видит всю файловую систему и весь сетевой стек. Это нормально для 2010 года.

В systemd 260 (Ubuntu 26.04, Fedora 44) появились дополнительные директивы изоляции и Memory THP-контроль на уровне юнита. Но главное — большинство директив безопасности были доступны давно, просто их не используют.

# Оцениваем текущий security score сервиса
systemd-analyze security nginx
# Покажет оценку от 0 (UNSAFE) до 10 (SAFE) и что именно проседает

# Добавляем hardening в override без правки оригинального юнита:
systemctl edit nginx

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
# Приватная /tmp — сервис не видит /tmp хоста
PrivateTmp=true

# Запрет на запись в домашние директории
ProtectHome=true

# /usr, /boot, /etc монтируются read-only
ProtectSystem=strict

# Разрешаем писать только в нужные директории
ReadWritePaths=/var/log/nginx /var/cache/nginx /run/nginx

# Убираем все capabilities кроме нужных
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Запрет на новые привилегии через setuid/setgid
NoNewPrivileges=true

# Только нужные syscall-группы
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

# Изолируем сетевые namespace-ы (если сервис только слушает)
# PrivateNetwork=true  # раскомментировать для полной изоляции

# Контроль памяти (новое в systemd 260)
# Отключаем THP для сервисов где он мешает (Java, Redis)
MemoryTHP=never

# После правки:
systemctl daemon-reload && systemctl restart nginx

# Проверяем новый score
systemd-analyze security nginx
# Цель: зелёный (8+)

Зачем это нужно:
Скомпрометированный nginx с PrivateTmp и ProtectSystem=strict не доберётся до ваших SSH-ключей, конфигов баз данных или других сервисов. Изоляция на уровне юнита — это дешёвый слой defence-in-depth, который не требует контейнеров.

Итог: запусти systemd-analyze security на своих сервисах сегодня. Гарантирую — будет неприятно, но полезно.

#linux #systemd #hardening #security #sysadmin #admin_future

🪟 Windows: Native NVMe в WS2025 — +80% IOPS, и это ещё не включено по умолчанию

Коллеги, фича которая доступна с октября 2025-го, но большинство администраторов её не включили — потому что она opt-in и спрятана за реестром.

Всё Windows Server до 2025 включительно общался с NVMe-дисками через SCSI-эмуляцию. Команды NVMe переводились в SCSI и обратно — лишний слой абстракции, shared locks в kernel I/O path, лишние CPU-циклы. Включение native NVMe даёт до 80% выше IOPS и до 45% ниже CPU utilization под высокой I/O нагрузкой.

Это особенно важно для Storage Spaces Direct, SQL Server и любых disk-intensive workloads.

# Проверяем установлено ли обновление KB5066835 (октябрь 2025) или новее
Get-HotFix | Where-Object {$_.InstalledOn -gt "2025-10-01"} |
  Select-Object HotFixID, InstalledOn |
  Sort-Object InstalledOn -Descending | Select-Object -First 5

# Включаем Native NVMe через реестр (требует перезагрузки):
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides" `
  /v 1176759950 /t REG_DWORD /d 1 /f

# Проверяем что драйвер переключился
# После перезагрузки в Device Manager NVMe диски должны показывать
# "NVM Express Controller" вместо "Standard SATA AHCI Controller"
Get-PnpDevice | Where-Object {$_.Class -eq "DiskDrive"} |
  Select-Object FriendlyName, Status

# Бенчмарк до и после — замеряем IOPS с DiskSpd:
# (скачать с https://github.com/microsoft/diskspd)
.\diskspd.exe -b4K -d30 -o32 -t8 -r -w0 -L C:\testfile.dat

# Для S2D кластеров — проверяем здоровье после включения
Get-StoragePool | Get-VirtualDisk | Select-Object FriendlyName, HealthStatus, IOPS

Зачем это нужно:
Windows Server 2025 больше не трактует все устройства хранения как SCSI. Native NVMe обеспечивает прямой многоочередной доступ к устройствам — это означает возможность достичь реальных пределов производительности железа.

Итог: если у тебя WS2025 с NVMe-дисками и это не включено — ты буквально оставляешь 80% производительности хранилища на столе. Одна команда в реестре и перезагрузка. Сделай это сегодня.

#windows #nvme #storage #performance #windowsserver2025 #sysadmin #admin_future

🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически

Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?

Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.

Два подхода в зависимости от инструмента:

# ---- ANSIBLE: детекция дрейфа через --check --diff ----
# Запускаем playbook в режиме проверки без изменений
ansible-playbook site.yml \
  -i inventories/production/hosts.yml \
  --check \
  --diff

# Вывод покажет ВСЕ расхождения между кодом и реальностью
# Строки с "-" = что есть сейчас, "+" = что должно быть по коду

# Автоматизируем: добавляем в cron или CI/CD pipeline
# crontab -e:
# 0 9 * * 1 ansible-playbook /opt/ansible/site.yml -i production --check --diff \
#   2>&1 | mail -s "Weekly drift report" admin@company.com

# ---- TERRAFORM: детекция дрейфа через plan ----
# Показывает расхождения между state и реальным состоянием ресурсов
terraform plan -detailed-exitcode
# Exit code: 0 = нет изменений, 1 = ошибка, 2 = есть изменения (drift!)

# В CI/CD (GitLab CI пример):
# drift_check:
#   schedule: "0 8 * * *"  # каждый день в 8:00
#   script:
#     - terraform init
#     - terraform plan -detailed-exitcode
#   allow_failure: false

# ---- ПРАВИЛО: что делать при обнаруженном дрейфе ----
# Вариант 1: исправить реальность под код (правильно)
#   ansible-playbook site.yml -i production  # применяем playbook
#   terraform apply                           # применяем план

# Вариант 2: зафиксировать реальность в код (если изменение было намеренным)
#   Обновить playbook/tf-файл, commit, PR, code review
#   terraform import resource_type.name resource_id  # импортируем в state

Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.

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

#skills #iac #ansible #terraform #drift #sysadmin #admin_future

🐧 Linux: CVE-2026-4631 — Cockpit открывает root без пароля. Патчить немедленно

Коллеги, на прошлой неделе тихо закрыли одну из самых неприятных уязвимостей апреля в Linux-мире. Если вы используете Cockpit на RHEL, Rocky, AlmaLinux или Oracle Linux — читайте внимательно.

CVE-2026-4631: Cockpit передаёт имя пользователя и имя хоста напрямую в ssh без санитизации. Злоумышленник может указать имя пользователя вида "x; touch /tmp/flag; #" — и SSH выполнит инжектированную команду до того, как проверит корректность логина. Аутентификация не нужна.

Два вектора атаки: инъекция через поле username и инъекция через hostname (параметр передаётся без разделителя "--"). Результат — RCE на хосте с Cockpit.

# Проверяем версию Cockpit
rpm -q cockpit
# или
apt show cockpit 2>/dev/null | grep Version

# Смотрим открыт ли порт Cockpit наружу (по умолчанию 9090)
ss -tlnp | grep 9090
# Если виден на 0.0.0.0 — критично

# Немедленный митигейшн: закрываем доступ снаружи
# Firewalld:
firewall-cmd --remove-service=cockpit --permanent
firewall-cmd --reload

# iptables:
iptables -A INPUT -p tcp --dport 9090 -j DROP

# ---- ПАТЧ ----
# RHEL / Rocky / AlmaLinux 8:
dnf update cockpit -y  # целевой пакет: cockpit-334.x или новее

# RHEL / Rocky / AlmaLinux 9:
dnf update cockpit -y  # целевой пакет: cockpit-344.x или новее

# RHEL 10:
dnf update cockpit -y  # целевой пакет: cockpit-344-3.el10_1 или новее

# Проверяем что обновились
rpm -q cockpit
systemctl restart cockpit

Зачем это важно: Red Hat оценил уязвимость как Critical. Эксплуатация не требует аутентификации — достаточно сетевого доступа к порту 9090. PoC уже опубликован на GitHub.

Итог: если Cockpit у тебя слушает на публичном интерфейсе и без патча — это не вопрос "могут ли взломать", а вопрос "когда". Два действия: закрыть порт и обновить пакет.

#linux #cve #cockpit #rhel #security #sysadmin #admin_future

🪟 Windows: Kerberos RC4 enforcement уже включился — что сломалось и что делать

Коллеги, апрельский Patch Tuesday принёс не только патчи, но и тихое изменение, которое уже ломает аутентификацию в тех средах, где не подготовились.

Начиная с апреля 2026 года, апрельское накопительное обновление меняет дефолтное поведение Kerberos KDC: для учётных записей без явно заданного msDS-SupportedEncryptionTypes теперь выдаются только AES-SHA1-билеты. RC4 больше не используется по умолчанию.

Что это значит практически: сервисные учётки, NAS-устройства, принтеры, старые приложения и любая учётка без явного атрибута шифрования — потенциальная жертва. Симптомы: ошибки "KDC has no support for encryption type", сервисы не стартуют, авторизация в приложениях падает.

В июле 2026 поведение зафиксируется окончательно и откат в режим аудита станет невозможен. Времени мало.

# ШАГ 1: Ищем учётки БЕЗ AES-ключей
# Скрипт от Microsoft (GitHub: microsoft/Kerberos-Crypto):
# List-AccountKeys.ps1 — находит аккаунты с RC4 но без AES

# Ручная проверка: смотрим Event ID 201, 202 в System Log DC
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List

# ШАГ 2: Для сервисных учёток — сбрасываем пароль (генерирует AES-ключи)
Set-ADAccountPassword -Identity "svc_sql" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ssw0rd!" -AsPlainText -Force)

# ШАГ 3: Явно задаём шифрование для проблемных учёток
# 0x18 = AES128 + AES256, 0x1C = AES128 + AES256 + RC4 (временно)
Set-ADUser -Identity "svc_legacy_app" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Временный откат если уже всё сломалось
# Возвращаем DC в режим аудита (работает ДО июля 2026):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" `
    -Name "RC4DefaultDisablementPhase" -Value 1

# ШАГ 5: Проверяем krbtgt — если пароль не менялся с 2008 года, AES-ключей нет
Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes,PasswordLastSet |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet старше 2012 — сбрасываем ДВАЖДЫ с репликацией между сбросами

Зачем это нужно:
RC4 позволяет Kerberoasting: атакующий запрашивает билет, зашифрованный RC4, и взламывает его оффлайн. Современные GPU делают это за минуты. Microsoft убирает RC4 принудительно — и это правильно.

Итог: аудит уже три месяца доступен через Event ID 201-202. Если ты не смотрел — посмотри сегодня. Июль ждать не будет.

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

🧠 Skills: EOL-трекер — самый недооценённый инструмент в арсенале администратора

Коллеги, вопрос на пятницу: вы знаете, какое ПО в вашей инфраструктуре уходит на EOL в следующие 12 месяцев?

Не "примерно знаете". Точно. С датами.

Если нет — вы уже опаздываете. CentOS 7 умер в 2024-м и до сих пор живёт в продакшне у большинства. Ubuntu 20.04 LTS уходит в апреле 2025-го. Python 3.9 EOL был в октябре 2025-го. Каждый из них — потенциальная уязвимость без патчей и потенциальный инцидент.

Практический минимум: один источник правды для всего EOL в вашей инфраструктуре.

# ---- endoflife.date — лучший бесплатный EOL-трекер ----
# API бесплатный, покрывает 300+ продуктов

# Проверяем конкретную версию прямо из CLI:
curl -s https://endoflife.date/api/ubuntu/22.04.json | \
    python3 -m json.tool
# Покажет: eol date, lts, support status

# Скрипт: проверяем весь стек разом
#!/bin/bash
PRODUCTS=("ubuntu/22.04" "rhel/9" "postgresql/14" "python/3.10" "nginx/1.24")
echo "=== EOL CHECK $(date +%Y-%m-%d) ==="
for p in "${PRODUCTS[@]}"; do
    result=$(curl -s "https://endoflife.date/api/${p}.json")
    eol=$(echo $result | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('eol','unknown'))")
    support=$(echo $result | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('support','unknown'))")
    echo "$p | EOL: $eol | Support ends: $support"
done

# Пример вывода:
# ubuntu/22.04  | EOL: 2027-04-01 | Support ends: 2024-04-01
# rhel/9        | EOL: 2032-05-31 | Support ends: 2027-05-31
# postgresql/14 | EOL: 2026-11-12 | Support ends: 2026-11-12
# python/3.10   | EOL: 2026-10-04 | Support ends: 2026-10-04  <- скоро!
# nginx/1.24    | EOL: false      | Support ends: 2025-04-24  <- уже!

Как выстроить процесс:

1. ИНВЕНТАРИЗАЦИЯ (один раз, потом поддерживается)
   Список всех ОС + версий + приложений + версий
   Храним в Git, обновляем при каждом деплое

2. АВТОМАТИЧЕСКИЙ МОНИТОРИНГ (ежемесячно)
   Запускаем скрипт выше через CI/CD или cron
   Алерт если до EOL < 180 дней — планируем обновление
   Алерт если до EOL < 90 дней — критично, ставим в спринт

3. РАЗГОВОР С БИЗНЕСОМ (когда алерт сработал)
   "PostgreSQL 14 уходит на EOL 12 ноября 2026.
    После этой даты — нет патчей безопасности.
    Миграция на PG 17: 3 дня работы.
    Риск без миграции: [вставить стоимость инцидента]."

Зачем это нужно:
EOL-компонент без патчей — это не технический долг. Это открытая CVE без срока закрытия. Апрельский Cockpit RCE затронул установки, которые просто не обновлялись. Большинство громких инцидентов — это не zero-day, это известные уязвимости в давно устаревшем ПО.

Итог: endoflife.date + 15 строк bash + cron — и у тебя есть система которая скажет о проблеме за полгода, а не за день до инцидента.

#skills #eol #инфраструктура #patching #sysadmin #admin_future