🪟 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

🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры

Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.

Почему это важно для нас, а не только для датацентров?

Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.

Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.

Практика — запускаем готовый планировщик на продакшн-хосте:

# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds

# Ubuntu 26.04 (из репозитория):
apt install scx-scheds

# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS

# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &

# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state     # -> enabled
cat /sys/kernel/sched_ext/root/ops  # -> lavd

# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2

# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
  {
    "name": "critical",
    "matches": [["CgroupPrefix", "system.slice/nginx"]],
    "kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
  },
  {
    "name": "background",
    "matches": [["CgroupPrefix", ""]],
    "kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
  }
]
EOF

# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма

Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.

Итог: CFS — это справедливость для всех. SCHED_EXT — это справедливость там, где тебе нужно. Разница примерно как между светофором и круговым движением: второе умнее, но требует понимания.

#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future

🪟 Windows: OSConfig — GPO умерло, долго живёт drift control

Коллеги, у вас в домене есть сервера, где кто-то "временно" отключил NTLMv1 и забыл вернуть? Или изменил политику аудита "под задачу"? Или коллега поставил TLS 1.0 для совместимости с каким-то древним ПО и не сказал? Я видел такое. Называется configuration drift, и он медленно разрушает безопасный периметр, который ты тщательно выстраивал.

В Windows Server 2025 Microsoft тихо привезла ответ на этот вопрос: OSConfig. Каждые несколько часов OSConfig сканирует отклонения от baseline-конфигурации и автоматически исправляет их — без необходимости ждать GPO-обновления или вмешательства вручную.

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

Разворачиваем и настраиваем:

# Устанавливаем модуль из PSGallery (нужен WS2025)
Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Смотрим доступные сценарии
Get-OSConfigMetadata | Format-Table Name, Description -Wrap
# Сценарии: SecurityBaseline, SecuredCore, AppControl, Defender

# Применяем baseline для Member Server (более 300 настроек разом)
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Для Domain Controller — отдельный сценарий
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController

# Проверяем что применилось и нет расхождений
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Включаем drift control (автоисправление отклонений)
# По умолчанию проверка каждые 4 часа
Get-OSConfigDriftControl
# Ужесточаем — проверка каждые 45 минут
Set-OSConfigDriftControl 45

# Смотрим конкретный параметр и его текущее состояние
Get-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Setting AuditDetailedFileShare

# Кастомизируем под свои нужды (без потери drift control)
# Например, разрешаем RDP drive redirection (отключено по умолчанию)
Set-OSConfigDesiredConfiguration `
  -Scenario SecurityBaseline/WS2025/MemberServer `
  -Name RemoteDesktopServicesDoNotAllowDriveRedirection `
  -Value 0

# Проверяем соответствие требованиям CIS/DISA STIG
# (OSConfig покрывает их автоматически при применении baseline)
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer |
  Where-Object {$_.ComplianceState -ne "Compliant"} |
  Select-Object Name, ExpectedValue, ActualValue

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

Зачем это нужно:
Аудиторы любят вопрос "как вы гарантируете, что конфигурация безопасности не изменилась с момента последней проверки?". Раньше честный ответ был "ну, мы стараемся следить". Теперь ответ: "автоматический drift control каждые 45 минут с логами". CIO это оценит на следующем совещании по ИБ.

Итог: GPO — это политика на бумаге. OSConfig — это политика, которая не даёт себя обойти. Разница принципиальная.

#windows #security #osconfig #drift #windowsserver2025 #sysadmin #admin_future

🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей

Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.

Это не героизм. Это провал организации процесса.

Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.

Три кита нормального on-call:

Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.

ШАБЛОН МАТРИЦЫ ЭСКАЛАЦИИ

Уровень 1 (0–15 мин):  Дежурный инженер (primary)
  -> Автоматический runbook, первичная диагностика

Уровень 2 (15–30 мин): Дежурный инженер (secondary)
  -> Подключается если primary не отвечает или нужна помощь

Уровень 3 (30–60 мин): Тимлид / старший инженер
  -> Техническое решение нестандартной ситуации

Уровень 4 (60+ мин):   Руководитель
  -> Только для бизнес-решений: откат релиза,
     уведомление клиентов, привлечение вендора

ПРАВИЛО: каждый уровень получает уведомление автоматически.
Никакого "позвони сам если не справляешься" — это перекладывание
ответственности на усталого человека в 3 ночи.

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

Аудит алертов раз в квартал — три категории:

[ACTIONABLE]  Алерт требует действия в течение 15 минут.
              Будит людей. Должен быть в PagerDuty/Grafana OnCall.

[WATCHFUL]    Алерт требует внимания в рабочее время.
              Тикет в очередь, не звонок ночью.

[NOISE]       Алерт не требует никаких действий.
              Отключить немедленно.

Реальная статистика большинства команд при честном аудите:
- 20% алертов — ACTIONABLE
- 30% — WATCHFUL
- 50% — NOISE (которые будят людей ночью годами)

Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.

Шаблон постмортема за 30 минут:

## Постмортем: [Название инцидента] | [Дата] | Severity: P[1-3]

### Что случилось (2-3 предложения)
### Timeline (с точными временными метками)
### Влияние на пользователей и бизнес
### Root Cause (система/процесс, не человек)
### Что сработало хорошо
### Что нужно улучшить
### Action items:
  | Задача | Владелец | Дедлайн |
  |--------|----------|---------|
  | ...    | ...      | ...     |

ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
  ❌ "Инженер не заметил алерт"
  ✅ "Алерт не имел достаточного приоритета в системе"
  ❌ "админ забыл обновить конфиг"
  ✅ "Процедура деплоя не включала проверку конфигурации"

Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.

Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.

#skills #oncall #incident #postmortem #sysadmin #sre #admin_future

🐧 Linux: io_uring — самый быстрый и самый опасный интерфейс ввода-вывода в ядре

Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.

Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.

Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.

Практика: проверяем состояние io_uring в своей инфраструктуре и ограничиваем где нужно:

# Проверяем, используют ли процессы io_uring прямо сейчас
# Смотрим открытые io_uring файловые дескрипторы
find /proc/*/fd -type l 2>/dev/null | xargs ls -la 2>/dev/null | grep anon_inode

# Более точно — смотрим через lsof
lsof | grep io_uring

# Проверяем, какие приложения слинкованы с liburing
ldd /usr/bin/postgres 2>/dev/null | grep uring
find /usr/bin /usr/sbin /opt -type f -name "*.so*" 2>/dev/null | \
  xargs grep -l "io_uring" 2>/dev/null | head -20

# ---- ОГРАНИЧЕНИЕ ДЛЯ КОНТЕЙНЕРОВ ----
# Запрет io_uring через seccomp (правильный способ для Docker/Podman)
cat > /etc/docker/seccomp-no-iouring.json << 'EOF'
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["io_uring_setup", "io_uring_enter", "io_uring_register"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 38
    }
  ]
}
EOF

# Запускаем контейнер без io_uring
docker run --security-opt seccomp=/etc/docker/seccomp-no-iouring.json nginx

# ---- ДЛЯ systemd-сервисов ----
# В unit-файле — ограничение системных вызовов
# Добавляем в [Service]:
# SystemCallFilter=~io_uring_setup io_uring_enter io_uring_register

# ---- АУДИТ ----
# Если используете auditd — добавляем правила мониторинга io_uring
cat >> /etc/audit/rules.d/iouring.rules << 'EOF'
-a always,exit -F arch=b64 -S io_uring_setup -k iouring_activity
-a always,exit -F arch=b64 -S io_uring_enter -k iouring_activity
EOF
auditctl -R /etc/audit/rules.d/iouring.rules
# Смотрим активность:
ausearch -k iouring_activity | tail -20

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

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

#linux #iouring #security #kernel #sysadmin #admin_future

🪟 Windows: Patch Tuesday апрель 2026 — три проблемы из одного обновления, памятка для выживших

Коллеги, 14 апреля вышел апрельский Patch Tuesday. И он немедленно стал мемом в сообществе администраторов — но не потому что хороший. За три дня Microsoft подтвердила три отдельные проблемы от одного пакета обновлений KB5082063. Разбираем по порядку.

Что закрыли: 163 CVE, из них 8 критических, два zero-day. Самый опасный — CVE-2026-33824 с CVSS 9.8 в Windows IKE Service Extensions: уязвимость позволяет неаутентифицированному атакующему выполнить код удалённо, достаточно отправить специально сформированные пакеты на машину с включённым IKEv2. Не устанавливать нельзя.

Что сломали — проблема первая, BitLocker: некоторые Windows Server 2025 устройства с определённой конфигурацией TPM Group Policy требуют ввода ключа восстановления BitLocker при первой перезагрузке после KB5082063. Это происходит, если одновременно выполнены условия: BitLocker включён, GPO настраивает TPM PCR7, msinfo32 показывает PCR7 Binding как "Not Possible", и на устройстве уже присутствует сертификат Windows UEFI CA 2023.

Проблема вторая, ещё хуже: non-Global Catalog контроллеры домена в средах с Privileged Access Management (PAM) могут войти в бесконечный цикл перезагрузок из-за краша LSASS при старте. Затронуты Windows Server 2016, 2019, 2022 и 2025.

Проблема третья — ошибка 0x800F0983 при установке на части Windows Server 2025 систем. Обновление просто не ставится.

Что делать прямо сейчас:

# ШАГ 1 — Перед установкой KB5082063: проверяем риск BitLocker
# Проверяем состояние PCR7 Binding
Get-ComputerInfo | Select-Object BiosFirmwareType, SecureBootEnabled

# Смотрим msinfo32 через PowerShell
$csWmi = Get-WmiObject -Class Win32_ComputerSystem
# Или через msinfo32.exe — ищем строку "PCR7 Binding"
msinfo32.exe  # -> System Summary -> Secure Boot State

# Если PCR7 Binding = "Not Possible" — снимаем GPO перед патчем
# Computer Config -> Admin Templates -> Windows Components
# -> BitLocker Drive Encryption -> OS Drives
# -> "Configure TPM platform validation profile" -> Not Configured
gpupdate /force

# ШАГ 2 — Проверяем, является ли DC Global Catalog (GC)
# Если NOT GC + PAM включён = высокий риск reboot loop
# Проверяем GC статус:
Import-Module ActiveDirectory
Get-ADDomainController -Identity $env:COMPUTERNAME |
    Select-Object Name, IsGlobalCatalog, IPv4Address

# Если IsGlobalCatalog = False И в среде есть PAM ->
# НЕ устанавливать KB5082063 до появления фикса, 
# или ставить только после консультации с Microsoft Support

# ШАГ 3 — Проверяем наличие IKEv2 (CVE-2026-33824 CVSS 9.8)
# Если IKEv2 не используется — блокируем UDP 500 и 4500
netsh advfirewall firewall show rule name="IKE*"

# Временный mitigation если патч не встаёт:
netsh advfirewall firewall add rule `
    name="Block IKEv2 inbound temp" `
    dir=in action=block `
    protocol=UDP localport=500,4500

# ШАГ 4 — Экстракция BitLocker recovery ключей заранее (всегда!)
# Для всех машин домена:
Get-ADComputer -Filter * | ForEach-Object {
    Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} `
        -SearchBase $_.DistinguishedName `
        -Properties 'msFVE-RecoveryPassword' |
    Select-Object @{N='Computer';E={$_.DistinguishedName}},
                  @{N='Key';E={$_.'msFVE-RecoveryPassword'}}
} | Export-Csv "bitlocker_keys_backup_$(Get-Date -Format yyyyMMdd).csv"

Зачем это нужно:
Это уже четвёртый раз с 2022 года, когда Patch Tuesday вызывает неожиданные запросы BitLocker recovery. И второй год подряд апрельское обновление ломает контроллеры домена. Паттерн достаточно устойчив, чтобы считать его нормой и готовиться заранее: держать ключи BitLocker в AD и в оффлайн-хранилище, тестировать обновления на одном DC перед раскаткой на всю инфраструктуру.

Итог: Patch Tuesday с CVSS 9.8 пропустить нельзя. Но и ставить вслепую тоже нельзя. Проверь PCR7, проверь GC-статус DC, экспортируй ключи BitLocker. Пять минут подготовки сейчас — это не три часа ночного инцидента потом.

#windows #patchtuesday #bitlocker #activedirectory #security #sysadmin #admin_future

🧠 Skills: Мониторинг vs Observability — в чём разница и почему это важно для карьеры

Коллеги, разговор о вещи, которая кажется очевидной, но на практике разделяет инфраструктурных инженеров на два поколения.

Мониторинг — это когда знаешь заранее, что может сломаться, и смотришь на это. Дашборд с CPU, памятью, диском, статусом сервиса. Алерт когда CPU > 90%. Всё понятно, всё предсказуемо.

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

Разница не в инструментах. Разница в том, как мы думаем об инфраструктуре.

Два де-факто открытых стандарта в observability сегодня — Prometheus и OpenTelemetry. 65% организаций инвестируют в оба. Prometheus зрелее и больше используется в production (59%), OpenTelemetry быстрее растёт — 35% сейчас находятся на стадии POC и готовятся к масштабированию.

Практика: строим минимальный observability-стек на своём парке серверов:

# docker-compose.yml — базовый стек: Prometheus + Grafana + Node Exporter
# Разворачивается за 10 минут, даёт реальную видимость

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'  # Храним 30 дней истории
    ports:
      - "9090:9090"
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node_exporter
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.rootfs=/rootfs'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    ports:
      - "9100:9100"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme_immediately
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

# prometheus.yml — базовая конфигурация
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  # Сам Prometheus
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Метрики хоста
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']
        labels:
          env: 'production'
          datacenter: 'main'

  # Если есть несколько серверов — добавляем все
  - job_name: 'servers'
    static_configs:
      - targets:
          - '192.168.1.10:9100'
          - '192.168.1.11:9100'
          - '192.168.1.12:9100'

# Три PromQL-запроса, которые реально нужны каждый день:

# 1. Топ-5 процессов по CPU (не просто средний по системе)
topk(5, rate(namedprocess_namegroup_cpu_seconds_total[5m]))

# 2. Свободное место на дисках с предсказанием когда кончится
predict_linear(node_filesystem_avail_bytes[6h], 4*3600) < 0

# 3. Доступная память — реальная, не та что показывает free
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

Ключевая идея: observability as code — это когда конфигурации мониторинга управляются как код: версионируются в Git, проходят code review, разворачиваются через те же CI/CD-пайплайны, что и инфраструктура. Те же инструменты, те же принципы.

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

Зачем это важно для карьеры:
Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных.

Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер.

#skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future

🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне

Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.

До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.

Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.

Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.

Что делать практически прямо сейчас:

# Проверяем версию ядра — нужна 7.0+
uname -r

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

# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"

# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"

# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.

# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"

# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point

# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer

# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1  # offline check для диагностики

Зачем это нужно:
Для системных администраторов, отвечающих за XFS-тома на продакшн-серверах, это значимое улучшение quality-of-life. Однако эту возможность не следует использовать как замену полноценному процессу резервного копирования и восстановления. Self-healing — это safety net для конкретного класса сбоев, а не страховка от всего.

Итог: xfs_repair в 3 ночи с rescue USB — это был обряд посвящения для каждого линукс-администратора. В ядре 7.0 этот обряд стал значительно реже встречаться. Бэкапы всё равно делайте.

#linux #xfs #kernel7 #storage #filesystem #sysadmin #admin_future

🪟 Windows: Secure Boot 2011 → 2026 — у тебя есть два месяца до истечения сертификатов

Коллеги, это тот случай, когда Microsoft предупреждает заранее и громко — но в суете патч-вторников и инцидентов это всё равно тонет. Поэтому говорим сегодня, пока ещё есть время.

Сертификаты Secure Boot, которые Microsoft выпустила в 2011 году, начинают истекать в июне 2026 года. Затронуты физические и виртуальные машины на всех поддерживаемых версиях: Windows 10, Windows 11, Windows Server 2016, 2019, 2022, 2025 — всё железо с 2012 года.

Что произойдёт если не обновить: устройства продолжат запускаться и работать нормально, стандартные обновления Windows продолжат устанавливаться. Однако они больше не смогут получать новые средства защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва и средства защиты от вновь обнаруженных уязвимостей уровня загрузки. С октября 2026 года — никаких security-фиксов для Windows Boot Manager.

Критический нюанс для серверов: в отличие от клиентских Windows-машин, которые получают сертификаты 2023 года автоматически через Windows Update, Windows Server требует ручного действия. Сертификаты на сервера автоматически не прилетают.

Аудит и обновление прямо сейчас:

# ШАГ 1 — Инвентаризация: проверяем статус на каждом сервере

# Проверяем текущий статус обновления сертификатов
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status" -ErrorAction SilentlyContinue |
    Select-Object UEFICA2023Status

# Возможные значения:
# (пусто / ключ отсутствует) = обновление не начато
# "InProgress"               = в процессе
# "Updated"                  = готово, сертификаты 2023 установлены

# Проверяем включён ли Secure Boot вообще
Confirm-SecureBootUEFI

# Проверяем через Event Log — Event ID 1808 = сертификаты успешно обновлены
Get-WinEvent -LogName System |
    Where-Object {$_.Id -eq 1808} |
    Select-Object TimeCreated, Message |
    Format-List

# ШАГ 2 — Для серверов БЕЗ сертификатов 2023: запускаем обновление вручную

# Инициируем обновление Secure Boot certificates
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
    -Name "AvailableUpdates" `
    -Value 0x5944

# Запускаем scheduled task для обновления
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

# Смотрим статус — должен появиться "InProgress"
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status"

# ПЕРЕЗАГРУЖАЕМ сервер, затем запускаем task ещё раз
Restart-Computer -Force
# После перезагрузки:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Статус должен смениться на "Updated"

# ШАГ 3 — Массовый аудит через домен (все серверы сразу)
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -ExpandProperty Name

$results = foreach ($server in $servers) {
    try {
        $status = Invoke-Command -ComputerName $server -ScriptBlock {
            $s = Get-ItemProperty `
                -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
            [PSCustomObject]@{
                Server = $env:COMPUTERNAME
                Status = if ($s) { $s.UEFICA2023Status } else { "NotStarted" }
                SecureBootEnabled = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
            }
        } -ErrorAction Stop
        $status
    } catch {
        [PSCustomObject]@{Server = $server; Status = "Unreachable"; SecureBootEnabled = $null}
    }
}

$results | Sort-Object Status | Export-Csv "secureboot_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$results | Group-Object Status | Format-Table Name, Count

Зачем это нужно:
Обновление защищает от BlackLotus и аналогичных UEFI-буткитов, которые атакуют ранний процесс загрузки. После истечения 2011-сертификатов система не сможет получать mitigation-обновления против новых буткитов, даже если Patch Tuesday приходит вовремя.

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

#windows #secureboot #security #windowsserver #patching #sysadmin #admin_future

🧠 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