🐧 Linux: Броня для конфигов — делаем файлы бессмертными через `chattr` 🛡

Знакомая боль: ты кропотливо прописал свои DNS в `/etc/resolv.conf`, а после ребута `NetworkManager` или `systemd-resolved` радостно всё затер и вернул дефолт. Или у тебя есть критически важный баш-скрипт, который стажер может случайно удалить командой `rm -rf`.

В Linux есть магия, которая делает файл неизменяемым. Вообще. Даже для пользователя `root`.

Как повесить «броню»:
Используем утилиту chattr (change attribute) с флагом +i (immutable).

# Делаем файл полностью неизменяемым (нельзя удалить, переименовать, записать)
sudo chattr +i /etc/resolv.conf

# Проверяем, повесился ли атрибут (будет буква 'i' в выводе)
lsattr /etc/resolv.conf

Как снять, когда нужно обновить конфиг:

sudo chattr -i /etc/resolv.conf

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

#linux #chattr #security #hardening #sysadmin #troubleshooting #admin_future

🪟 Windows Server: Кто ребутнул прод? Ищем виновного в два клика на PowerShell 🕵️‍♂️

Ты заходишь с утра в мониторинг, а аптайм у главного Контроллера Домена — 2 часа. Сервер ночью перезагрузился. Сразу возникает два вопроса: это был сбой питания, синий экран или чей-то шаловливый RDP-сеанс с кнопкой «Обновить и перезагрузить»?

Не нужно листать бесконечный Event Viewer глазами. Заставляем PowerShell найти ответы за пару секунд.

Техническая база:
Нам нужны два Event ID из журнала System:

* 1074 — Штатная перезагрузка/выключение (покажет пользователя и причину).
* 6008 — Неожиданное завершение работы (питание, BSOD, зависание).

Сниппет для расследования:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074, 6008} -MaxEvents 5 | 
Select-Object TimeCreated, Id, @{Name="Action";Expression={
    if ($_.Id -eq 1074) { "Штатный ребут/выключение. Детали: $($_.Message.Split("`n")[0..1] -join ' ')" }
    else { "КРИТИЧЕСКИЙ СБОЙ (Питание/BSOD)" }
}} | Format-List

Ты сразу увидишь точное время и, главное, логин того самого `Administrator` или `Ivanov_I`, который отправил сервер в ребут.

#windows #powershell #activedirectory #troubleshooting #sysadmin #eventviewer #admin_future

🐧 Linux: Когда `/var/log/journal` съел диск — правильная диета для логов 🧹

Классика жанра: мониторинг орет, что на корневом разделе осталось 0 байт. Ты лезешь разбираться и видишь, что системный журнал `systemd-journald` разросся до размеров Вселенной, храня логи за последние три года.

Удалять файлы руками через `rm` — плохая примета (можно сломать целостность журнала). Делаем красиво через штатные инструменты.

Команды для очистки:

# 1. Смотрим, сколько реально занимают логи
journalctl --disk-usage

# 2. Оставляем логи только за последние 2 дня (остальное в /dev/null)
sudo journalctl --vacuum-time=2d

# 3. ИЛИ ограничиваем жестким размером (например, оставить 500 МБ)
sudo journalctl --vacuum-size=500M

Админский лайфхак: Чтобы не чистить вручную каждый раз, пропиши в `/etc/systemd/journald.conf` параметр `SystemMaxUse=1G` и перезапусти службу.

#linux #systemd #logs #maintenance #sysadmin #troubleshooting #admin_future

🎓 Собеседование сисадмина. Выпуск №3: Траблшутинг и «Железная» логика

Привет, коллеги! Сегодня разберем три вопроса, которые отделяют «человека с сертификатом» от реального системного администратора.
Здесь важен не просто правильный ответ, а понимание физики процессов.

❓ Вопрос 1: «На сервере Linux резко вырос Load Average (LA), при этом CPU Usage всего 10%. Что происходит и где искать проблему?»
❌ Ответ новичка: «Наверное, какой-то процесс завис, надо ребутнуть сервер или убить лишние задачи».
✅ Ответ инженера:

Load Average — это очередь процессов, ожидающих выполнения. Если CPU свободен, значит, процессы стоят в очереди Disk I/O (ожидание ввода-вывода).
Что делать: Смотрим колонку %wa (iowait) в top или запускаем iostat -x 1.
Причина: Скорее всего, «умирает» диск, перегружена дисковая полка или база данных делает тяжелый Swapping. Нужно искать процесс, который генерирует максимум чтений/записей через iotop.
Pro-tip: Упомяните, что LA может расти и из-за сетевых задержек (NFS/Samba), если файловая система примонтирована по сети и «отвалилась».

❓ Вопрос 2: «Пользователи жалуются, что "интернет тормозит". Пинг до 8.8.8.8 идеальный (2 мс), но страницы открываются по 10 секунд. Ваши действия?»
❌ Ответ новичка: «Позвоню провайдеру, пусть проверят линию, или почищу куки в браузере».
✅ Ответ инженера:

Если ICMP (пинг) летит быстро, проблема на уровнях выше.
DNS: Самая частая причина. Резолвер тормозит, и браузер тратит 5–8 секунд только на то, чтобы узнать IP сайта. Проверяем через dig или nslookup.
MTU/MSS: Если пинг (маленький пакет) проходит, а HTTP (большой пакет) — нет, значит, где-то на пути пакеты дропаются из-за фрагментации. Проверяем пингом с большой нагрузкой: ping -s 1472 -M do 8.8.8.8.
Браузер/Прокси: Проверяем настройки WPAD или наличие «кривых» корпоративных расширений/антивирусов, которые инспектируют трафик.

❓ Вопрос 3: «В RAID 10 вылетел один диск. Насколько это критично и каковы ваши действия по замене?»
❌ Ответ новичка: «RAID 10 надежный, ничего страшного. Просто вытащу старый и вставлю новый в любое время».
✅ Ответ инженера:

RAID 10 — это «зеркало страйпов».
Риски: Если вылетит второй диск в той же зеркальной паре — массив рассыплется и данные будут потеряны. Это критическая ситуация.
Действия: * Проверить статус массива через утилиту контроллера (например, perccli или mdadm).
Важно: Перед заменой убедиться, что у нас есть свежий бэкап. Ребилд (восстановление) — это огромная нагрузка на диски, и именно в этот момент чаще всего «сыпется» второй диск в паре.
Менять диск лучше в часы минимальной нагрузки на сервер, чтобы ускорить процесс ребилда и снизить риск отказа остальных дисков.

💡 Золотое правило собеса: Если не знаешь ответа — описывай, как ты будешь его искать.
Фраза «Я полезу в /var/log/syslog и посмотрю ошибки ввода-вывода» звучит в сто раз лучше, чем «Я не знаю».

Сохраняйте пост, это база, которая спасает на интервью!

#собеседование_AF #sysadmin #linux #networking #raid #troubleshooting #admin_future

🐧 Linux: Здоровье ваших NVMe — заглядываем в «мозги» диска через nvme-cli 🏎️

В 2026 году обычные SATA SSD в серверах — это уже почти легаси. Все сидят на NVMe, но многие по привычке проверяют их через smartctl. Однако для глубокой диагностики накопителей на шине PCIe есть родной и более мощный инструмент — nvme-cli.

Техническая суть:
Утилита позволяет не только смотреть SMART, но и управлять очередями, форматировать блоки под разный размер (LBA) и проверять реальный износ ячеек памяти (NAND Endurance).

Команды для проверки:

# Установка (если еще нет)
sudo apt install nvme-cli

# Вывести список всех NVMe дисков и их базовую инфу
sudo nvme list

# Показать детальный лог здоровья (критические предупреждения, температуру, износ)
sudo nvme smart-log /dev/nvme0n1

Зачем это нужно: В поле percentage_used вы увидите реальный износ в процентах. Если там >80% — пора планировать замену, не дожидаясь внезапного Read-Only режима.

#linux #nvme #storage #performance #troubleshooting #sysadmin #admin_future

Вывод
Понимание того, как пакеты «влезают» в интерфейсы и почему сервер «тупит» при свободном процессоре — это ваш страховой полис. Без этого вы будете бесконечно докупать RAM и ядра там, где нужно было просто поправить один параметр в sysctl или заменить «уставший» NVMe. Спокойствие админа в 2026-м стоит на трех слонах: мониторинг задержек, контроль износа железа и правильный MTU.

#собеседование_AF #networking #mtu #load_average #nvme #sysadmin #troubleshooting #admin_future

🐧 Linux: Смерть динозавров. Почему ты должен забыть про `ifconfig` и `netstat` в 2026-м

Привет, коллеги! Сегодня пятница, 13-е, и самое время провести экзорцизм — изгнать из твоих пальцев привычку вводить команды из учебников 20-летней давности. Если ты до сих пор ставишь пакет `net-tools` на свежую ОС, ты добровольно ставишь себе деревянные протезы вместо современных карбоновых манипуляторов. На ARM-серверах и современных ядрах Linux эти утилиты показывают погоду на Марсе, а не реальное состояние стека.

Техническая суть:

Переходим на связку iproute2 (`ip`) и **iproute2-ss** (`ss`).
Под капотом: Старый `netstat` читает информацию из `/proc/net/`, что при большом количестве соединений превращается в пытку для CPU и диска. Современная утилита `ss` (Socket Statistics) использует механизм Netlink, запрашивая данные напрямую у ядра. Это в десятки раз быстрее и точнее, особенно когда у тебя тысячи IPv6-соединений.

Практика:

Заменяем старые привычки на актуальный CLI. Почувствуй скорость:

# 1. Вместо 'ifconfig' — смотрим адреса и статистику ошибок на интерфейсе
ip -c -s link show eth0
ip -6 addr # Только IPv6, только хардкор

# 2. Вместо 'netstat -tulpn' — ищем, кто слушает порты
# -l (listening), -n (numeric), -p (process), -t (tcp), -4/6 (family)
ss -ltnp4

# 3. Киллер-фича: ищем все соединения от конкретного IP, которые тупят
ss -o state established '( dport = :http or sport = :http )'

# 4. Мониторим изменения в сети в реальном времени (кто поднял интерфейс, кто упал)
ip monitor

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

Для личного спокойствия. Когда сервер под нагрузкой «приляжет», старый `netstat` может просто зависнуть, пытаясь распарсить `/proc`. `ss` выдаст результат мгновенно, позволив тебе быстро найти и отстрелить проблемный процесс.

#linux #networking #ss #iproute2 #troubleshooting #admin_future

🪟 Windows: Детектив событий. Фильтруем Event Log без GUI

Коллеги, признавайтесь, кто до сих пор ждет по пять минут, пока «Просмотр событий» (Event Viewer) соизволит отрисовать список ошибок? В 2026 году в условиях Server Core и жесткой изоляции сегментов, GUI — это непозволительная роскошь. Если ты не умеешь вытаскивать причину падения сервиса одной строкой в PowerShell, ты беззащитен перед лицом инцидента.

Техническая суть:

Используем Get-WinEvent с XML-фильтрацией.
Под капотом: Старый Get-EventLog медленный, потому что он выкачивает все события и только потом их фильтрует. Get-WinEvent умеет отправлять запрос (FilterXML или FilterHashtable) прямо в движок журнала. В 2026-м это единственный способ быстро найти событие среди миллионов записей аудита в «цифровой крепости».

Практика:
Перестань страдать в графическом интерфейсе. Стань мастером запросов:

# 1. Найти 5 последних ошибок в системном журнале (мгновенно)
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 5

# 2. Кто заблокировал учетку? Ищем событие 4740 в журнале Security
# Работает в разы быстрее через FilterHashtable
$filter = @{
    LogName = 'Security'
    Id = 4740
}
Get-WinEvent -FilterHashtable $filter | Select-Object TimeCreated, Message

# 3. Выгрузка ошибок конкретного приложения за последние 2 часа
$startTime = (Get-Date).AddHours(-2)
Get-WinEvent -FilterXPath "*[System[(Level=2 or Level=3) and TimeCreated[@SystemTime >= '$($startTime.ToUniversalTime().ToString('s'))Z')]]" -LogName "Application"

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

Оперативность. В 2026 году требования к безопасности (ИБ) обязывают админа реагировать на подозрительные события в течение минут. Прямые запросы к логам позволяют автоматизировать алертинг и не тратить время на ожидание прогрузки тяжелых консолей управления.

#windows #powershell #eventlog #security #troubleshooting #admin_future

🪟 Windows: tnc — Твой универсальный сетевой швейцарский нож

В 2026-м пытаться проверить доступность порта через `telnet` — это как пытаться зажечь огонь трением палочек. В PowerShell давно есть нативный инструмент `Test-NetConnection` (сокращенно — `tnc`), который делает всё и сразу.

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

1. Проверка порта: Не надо гадать, закрыл ли порт фаервол в «цифровой крепости».
2. Трассировка: Сразу показывает маршрут до цели.
3. Диагностика: Выдает детальную инфу, почему пакет не дошел.

Примеры использования:

# Просто проверить, открыт ли порт веб-сервера
tnc 192.168.1.50 -Port 443

# Сделать проверку и сразу увидеть маршрут (TraceRoute)
tnc google.com -TraceRoute

# Проверить только ICMP (старый добрый пинг, но с нормальным объектом на выходе)
tnc 8.8.8.8 -InformationLevel Detailed

Pro Tip: Результат tnc — это объект. Его можно легко засунуть в условие if внутри твоего скрипта авто-деплоя.

#windows #powershell #networking #troubleshooting #tnc

🪟 Windows: Охота на зависшие службы через PowerShell

Классика: служба зависла в состоянии Stopping. Перезапуск не работает, сервер тупит, ждать нельзя.

Решаем жестко через PowerShell:

$ServiceName = "YourServiceName"
$Service = Get-Service $ServiceName

if ($Service.Status -eq "Stopping" -or $Service.Status -eq "Pending") {
    $ServicePID = (Get-CimInstance Win32_Service -Filter "Name='$ServiceName'").ProcessId
    Stop-Process -Id $ServicePID -Force
    Write-Host "Служба $ServiceName прибита. Можно запускать заново." -ForegroundColor Cyan
} else {
    Restart-Service $ServiceName -Force
}

Зачем это:
Экономит время на ребутах. Быстро возвращает систему в строй, если служба зависла на ресурсах или сети.

#windows #powershell #troubleshooting #services #admin_future

🐧 Linux: Кто держит мой файл и не дает его удалить?

Привет, коллеги! Пятница, 20 марта. Ситуация классическая: ты пытаешься размонтировать диск или удалить огромный старый лог, а система выдает Device or resource busy. В 2026 году, когда на одном сервере крутится сотня контейнеров и сервисов, искать виновника вручную — это как искать иголку в стоге сена.

Используй lsof (LiSt Open Files). Это твой рентген для файловой системы. Он покажет всё: какой процесс открыл файл, какой у него PID и что он с ним делает.

Практика:

# Найти процесс, который занял конкретный файл
lsof /var/log/nginx/access.log

# Посмотреть всё, что открыто в конкретной папке (удобно при размонтировании)
lsof +D /mnt/data/

# Узнать, какие сетевые файлы открыты конкретным пользователем
lsof -u admin -i

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

Для скорости. Вместо того чтобы гадать и перезапускать сервисы наугад, ты за одну секунду находишь PID процесса и решаешь, что с ним делать — подождать или культурно убить через kill. В пятницу вечером каждая сэкономленная минута приближает тебя к отдыху.

#linux #lsof #troubleshooting #admin_future

🐧 Linux: ss — Твой новый сетевой бинокль

Привет, коллеги! Начинаем неделю с правильных инструментов. Если ты до сих пор по привычке вбиваешь netstat, чтобы посмотреть открытые порты, то пора обновлять мышечную память. В современных дистрибутивах netstat считается устаревшим (legacy), а на замену ему пришла утилита ss из пакета iproute2.

Почему ss лучше:

1. Скорость: Она берет информацию напрямую из недр ядра (через tcp_diag), а не сканирует файлы в /proc, что критично на серверах с тысячами соединений.
2. Детализация: Она показывает гораздо больше внутренней информации о TCP-стеке, включая таймеры и параметры заторов.
3. Фильтры: Ты можешь искать соединения не просто через grep, а используя встроенные фильтры по состояниям или портам.

Практика:

# Показать все слушающие TCP и UDP порты с именами процессов
ss -tulpn

# Показать только установленные соединения (Established)
ss -t state established

# Найти все соединения с конкретным IP
ss dst 192.168.1.50

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

#linux #networking #ss #iproute2 #troubleshooting #admin_future

🔍 Linux: grep — Видеть больше, чем одну строку

Привет, коллеги! Вторник — день глубокого погружения в логи. Часто бывает так: ты находишь ошибку через grep, но одна строка ничего не говорит о причинах падения. Тебе нужно знать, что происходило за секунду до этого или какая ошибка вылетела следом.

Вместо того чтобы открывать файл в vim и мотать тысячи строк, используй флаги контекста. Это сэкономит тебе уйму времени и нервов.

Практика:

# Показать строку с ошибкой и 5 строк ПОСЛЕ нее (After)
grep -A 5 "crit" /var/log/syslog

# Показать 3 строки ДО ошибки (Before) — полезно, чтобы увидеть причину
grep -B 3 "connection refused" /var/log/nginx/error.log

# Показать контекст: 2 строки до и 2 строки после (Context)
grep -C 2 "panic" /var/log/dmesg

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

Для быстрого расследования. Ты сразу видишь последовательность событий. Например, сначала отвалилась база (Before), а потом упало приложение (Match). Это база эффективного траблшутинга в консоли.

#linux #grep #logs #troubleshooting #admin_future

🌐 Linux: mtr — Пинг и трассировка в одном флаконе

Привет, коллеги! Среда — время разгребать сетевые затыки. Если ты до сих пор по очереди запускаешь ping, а потом traceroute, чтобы понять, где теряются пакеты по пути к серверу, то ты тратишь время зря. В 2026 году диагностика должна быть наглядной и динамической.

Используй mtr (My Traceroute). Это инструмент, который объединяет возможности обеих команд и постоянно обновляет статистику по каждому узлу (хопу) на пути трафика.

Почему:

1. Видно потери на каждом этапе: Если пакеты пропадают на втором хопе — виноват твой роутер или провайдер. Если на последнем — проблема на целевом сервере.
2. Отслеживание джиттера: Ты видишь не просто средний пинг, а то, как он скачет в реальном времени.
3. Отчеты для провайдера: Можно запустить mtr в режиме отчета и отправить его техподдержке как неопровержимое доказательство их лагов.

Практика:

# Запустить интерактивно (самый частый вариант)
mtr google.com

# Выдать отчет за 10 циклов проверки (удобно для пересылки)
mtr -rw -c 10 8.8.8.8

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

Чтобы не гадать. mtr сразу показывает, является ли задержка разовой аномалией или это стабильная проблема конкретного узла в сети. В 2026-м сеть стала сложнее, и такие инструменты — твой основной радар.

#linux #networking #mtr #troubleshooting #admin_future

🔄 Skills: Ребут — это не решение, а временная мера

Давайте будем честными: фраза «попробуйте перезагрузить» спасла миллионы админских нервов. Но в 2026 году, когда системы стали сложнее, простой рестарт сервера — это не только спасение, но и потеря всех улик.

Почему не стоит сразу тянуться к кнопке Reset:

1. Исчезновение логов: Если проблема в памяти или в конкретном процессе, перезагрузка сотрет текущее состояние, и ты не узнаешь причину сбоя.
2. Маскировка симптомов: Ребут лечит следствие (зависший сервис), но не причину (утечка памяти или конфликт драйверов). Через неделю всё повторится.
3. Риск не подняться: Старое железо или сервер с кривым конфигом может просто не пережить перезагрузку.

Что делать вместо этого:

1. Сними дамп: Если процесс завис — выгрузи его состояние.
2. Проверь ресурсы: Глянь btop или Get-Process, кто именно съел ресурсы.
3. Читай логи ДО ребута: Потом их может не быть в оперативной памяти.

Вывод: Перезагрузка — это крайняя мера. Настоящий профи сначала ставит диагноз, а потом «лечит». Иначе ты превращаешься в оператора кнопки, а не системного инженера.

#skills #troubleshooting #bestpractices #management #sysadmin #admin_future

🐧 Linux: bpftrace — Твой рентген для ядра

Привет, коллеги! Если ты когда-нибудь бился над проблемой, которую не видят логи и не ловит strace, значит, пришло время заглянуть глубже. Инструмент bpftrace позволяет писать однострочники, которые вытаскивают данные прямо из функций ядра в реальном времени.

1. Ноль оверхеда: В отличие от тяжелых отладчиков, bpftrace практически не грузит систему. Можно безопасно запускать на боевом сервере под нагрузкой.
2. Универсальность: Хочешь увидеть, какие файлы открывает конкретный процесс? Или почему сетевой пакет дропается на уровне стека TCP? Легко.

Практика (однострочники на вес золота):

# Показать распределение времени выполнения системного вызова read (гистограмма)
bpftrace -e 'tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; } tracepoint:syscalls:sys_exit_read /@start[tid]/ { @runtime = hist(nsecs - @start[tid]); delete(@start[tid]); }'

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

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

Чтобы перестать гадать. Когда сервер тормозит, а CPU и RAM в норме, bpftrace покажет, что, например, процесс застревает в ожидании блокировки диска или тратит вечность на переключение контекста. Это высший пилотаж траблшутинга.

#linux #ebpf #bpftrace #performance #troubleshooting #admin_future

📁 Windows: Проверяем, кто заблокировал файл через PowerShell

Знакомая боль: пытаешься удалить лог или переместить папку, а Windows выдает издевательское «Файл открыт в другой программе». И сидишь гадаешь — то ли это антивирус, то ли забытая сессия коллеги, то ли сам сервер решил придержать файл «на память».

Раньше мы качали Unlocker или Process Explorer, но в 2026-м всё, что нам нужно, уже есть в системе.

Скрипт для поиска «виновника» (запускай от админа):

# Ищем процесс, который держит файл (замените путь на свой)
$LockedFile = "C:\inetpub\logs\LogFiles\u_ex260401.log"

Get-Process | Where-Object { 
    $_.Modules.FileName -contains $LockedFile -or $_.HandleCount -gt 0 
} | Select-Object Name, Id, Description | Format-Table -AutoSize

Примечание: Если файл заблокирован системой, используйте команду `handle.exe` из пакета Sysinternals — это база.

Чтобы не гадать и не ребутать весь сервер ради одного файла. Часто виновником оказывается зависший агент бэкапа или старая сессия PowerShell, которую вы сами же забыли закрыть. Пять секунд — и вы знаете, какой PID нужно «прибить».

Инструменты админа стали точнее. Не нужно сносить дерево, если мешает одна ветка.

#windows #powershell #troubleshooting #sysadmin #files #admin_future

🐧 Linux: Забудь про netstat, твой новый лучший друг — ss

Коллеги, если вы до сих пор по привычке набираете `netstat -tulpn` на сервере с современным Linux, вы зря тратите процессорное время (и свое тоже). Команда `netstat` официально устарела, медленно парсит `/proc` и не вытягивает современные нагрузки.

В 2026 году стандарт де-факто — это утилита `ss` (Socket Statistics). Она общается напрямую с ядром через Netlink, поэтому работает молниеносно даже на серверах с десятками тысяч открытых соединений.

Синтаксис почти тот же, но возможностей больше:

# Классика: показать все слушающие порты (TCP/UDP) с процессами
ss -tulnp

# Найти все established соединения на 443 порт (считаем клиентов)
ss -tan state established '( sport = :443 )'

# Показать сводную статистику по сокетам (кто съел лимиты)
ss -s

При DDoS-атаке или мощном всплеске трафика `netstat` может просто зависнуть, пытаясь прочитать статус тысяч сокетов. `ss` отдаст вам результат мгновенно, позволив быстро заблокировать проблемные IP через iptables/nftables.

Привычки — это хорошо, но ИТ не стоит на месте. Переучиваем мышечную память на две буквы `ss`.

#linux #networking #troubleshooting #sysadmin #ss #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

🧠 Skills: journalctl — 10 команд, которые заменяют grep по /var/log

Коллеги, навык недели. Начиная с Debian 12 rsyslog по умолчанию не ставится — классических текстовых логов на свежих инсталляциях может просто не быть. Всё уходит в бинарный журнал systemd-journald.

🛠 10 БАЗОВЫХ КОМАНД
Bash

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

⚠️ ПРОВЕРЬТЕ ПЕРСИСТЕНТНОСТЬ (сохраняются ли логи после ребута)
Bash

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

Если каталога /var/log/journal нет — журнал по дефолту сбрасывается в tmpfs (RAM). После аварийной перезагрузки расследовать причину сбоя будет физически невозможно:

Bash

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

💡 В ЧЁМ СУТЬ

Связка флагов

-b -1

и

-p err

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

SystemMaxUse

в

journald.conf

— обязательный базовый харденинг, который настраивается сразу после установки ОС.

#skills #linux #systemd #journalctl #debian #troubleshooting #sysadmin #admin_future