🪟 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

🐧 Linux: CVE-2026-31431 «Copy Fail» — LPE до root из 732 байт Python-кода

Коллеги, 30 апреля опубликованы подробности уязвимости, которая затрагивает практически каждый Linux-сервер в вашей инфраструктуре. Срочно читать.

CVE-2026-31431 «Copy Fail» — локальное повышение привилегий до root для любого локального пользователя без специальных условий. Уязвимость присутствует в ядрах начиная с Linux 4.14 (2017 год). Эксплоит — 732 байта Python-кода, уже опубликован.

Проблема в authencesn — криптографическом шаблоне ядра — и эксплуатируется через интерфейс AF_ALG. Исправлена в ядрах 6.18.22, 6.19.12 и 7.0.

Действия прямо сейчас:

# ШАГ 1 — Проверяем версию ядра
uname -r
# Затронуты: 4.14 — 6.19.11, 6.18.0 — 6.18.21

# ШАГ 2 — Митигейшн БЕЗ перезагрузки (если патч ещё не вышел)
# Отключаем модуль algif_aead
lsmod | grep algif_aead
rmmod algif_aead 2>/dev/null || echo "Module not loaded — safe"

# Запрещаем загрузку модуля навсегда:
echo "install algif_aead /bin/false" >> /etc/modprobe.d/disable-algif-aead.conf
echo "blacklist algif_aead" >> /etc/modprobe.d/disable-algif-aead.conf

# ШАГ 3 — Обновляем ядро (для дистрибутивов с патчем)
# Ubuntu 22.04 / 24.04:
apt update && apt install --only-upgrade linux-image-generic -y

# RHEL 9 / AlmaLinux 9 / Rocky 9:
dnf update kernel -y

# Debian 12:
apt update && apt full-upgrade -y

# ШАГ 4 — Проверяем активность AF_ALG в среде
# Смотрим открытые AF_ALG сокеты
ss -a | grep ALG
# Если пусто — модуль не используется, отключение безопасно

# ШАГ 5 — Перезагружаемся после обновления ядра
# Проверяем что загрузились с новым ядром:
uname -r  # должен показать исправленную версию

Зачем это важно:
Уязвимость быстро закроют в облаках и Kubernetes-кластерах. Но длинный хвост старых и забытых Linux-систем — роутеры, IoT, терминалы, промышленные системы — останется уязвимым ещё годами. В вашей инфраструктуре наверняка есть такие «забытые» хосты.

Итог: два действия сегодня — blacklist algif_aead на всех серверах где нет патча, обновить ядро там где патч доступен. PoC публичный, счёт идёт на часы.

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

🪟 Windows: Майский Patch Tuesday — hotpatch возобновляется, но есть нюанс

Коллеги, 11 мая — первый hotpatch-вторник после апрельского OOB-фикса, который прервал цикл. Разбираем коротко что происходит и чего ждать.

Напомню схему: январь, апрель, июль, октябрь — полный baseline с перезагрузкой. Февраль, март, май, июнь и т.д. — hotpatch без рестарта. Май по плану должен быть hotpatch-месяцем.

Но апрель внёс коррективу: OOB-фикс KB5091157 для апрельского DC reboot-loop потребовал перезагрузки и приостановил hotpatching. Для тех кто его установил — hotpatch возобновится только с майского обновления.

Ещё важный момент о стоимости: hotpatch для Windows Server 2025 вне Azure требует Azure Arc и платной подписки через Azure Arc — это не бесплатная функция для on-premises серверов.

# Проверяем текущий статус hotpatch на сервере
# Смотрим что установлено последним
Get-HotFix | Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, InstalledOn -First 3

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

# Проверяем подключение к Azure Arc (нужно для on-prem hotpatch):
azcmagent show 2>$null | Select-String "Status"
# Connected = готов к hotpatch

# Смотрим историю hotpatch vs обычных обновлений:
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" |
    Where-Object {$_.Id -eq 19} |  # ID 19 = успешная установка
    Select-Object TimeCreated, Message |
    Format-List |
    Select-Object -First 5

# Если нужно временно отключить hotpatch (например для тестов):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
    -Name "HotPatchRestrictions" -Value 1 -Type DWORD
# Вернуть: Value 0

Зачем это нужно:
Hotpatch не охватывает все обновления — .NET-патчи, несекьюрити-обновления и патчи сторонних компонентов по-прежнему требуют перезагрузки. Нельзя считать, что сервер с hotpatch больше никогда не перезагружается.

Итог: четыре перезагрузки в год вместо двенадцати — реальное улучшение для uptime. Но hotpatch не бесплатен на on-prem и не заменяет полный patch management. Знай что у тебя включено и почему.

#windows #hotpatch #patchtuesday #windowsserver2025 #sysadmin #admin_future

🧠 Skills: Говори на языке бизнеса — или вечно жди выделения бюджета

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

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

Разрыв между ними — не технические знания. Это умение переводить с инженерного на бизнесовый.

Три конкретных паттерна, которые работают:

ПАТТЕРН 1: ПРОБЛЕМА → РИСК → ДЕНЬГИ

Инженерный язык:
"Нам нужно обновить PostgreSQL 14 — он уходит на EOL в ноябре"

Бизнесовый язык:
"PostgreSQL 14 теряет поддержку безопасности 12 ноября.
 После этой даты критические уязвимости в БД не будут
 получать патчи. Миграция займёт 3 дня и стоит X рублей.
 Инцидент с компрометацией данных — от Y рублей плюс
 репутационные потери."

Результат: решение принимается за 10 минут, а не за 3 месяца.

ПАТТЕРН 2: ПРЕДЛОЖЕНИЕ СО СТАТУС-КВО

Плохо:
"Нам нужно внедрить мониторинг"

Хорошо:
"Сейчас мы узнаём об инцидентах от пользователей.
 В среднем это 40+ минут до начала реакции.
 Prometheus + Grafana за 2 дня работы сократит это
 до 2 минут. Последний инцидент обошёлся в Z рублей.
 Инструмент бесплатный."

Результат: ты не просишь — ты предлагаешь ROI.

ПАТТЕРН 3: АПДЕЙТ ДЛЯ РУКОВОДИТЕЛЯ (еженедельно, 3 пункта)

Формат:
✓ Что сделано (с бизнес-результатом, не с техническим)
⚠ Что требует решения (с вариантами, не с вопросом)
→ Что планируется (с ожидаемым результатом)

Пример:
✓ Завершена миграция БД — теперь есть поддержка
  безопасности до 2029 года
⚠ Срок действия SSL-сертификата сайта — 14 мая.
  Вариант A: автообновление (0 руб). Вариант B: платный
  сертификат (5000 руб). Рекомендую A.
→ На следующей неделе аудит прав доступа — снизим
  риск инсайдерских инцидентов

Умение «продавать» решения руководству — это не политика и не манипуляция. Это умение предоставить цифры, обосновать ценность с точки зрения бизнес-задач и рассчитать риски.

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

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

#skills #карьера #коммуникация #sysadmin #admin_future