Однорядкові PowerShell, що замінюють 10 кліків у GUI (використовуйте щодня)

Чому однорядкові виграють у продакшені

Добрий однорядок робить три речі: опитує джерело істини, форматує результат у вигляд, який можна осмислити, і робить очевидною наступну дію. Оце й усе. Не синтаксичні ігри.

Версія через GUI зазвичай виглядає так:

• Підключитися до потрібного хоста (або до неправильного; ви ще не дізнаєтеся).
• Відкрити потрібний снеп‑ін.
• Чекати, поки він завантажиться та відрендериться.
• Клік, фільтр, сортування, ще клік.
• Зробити скриншот, бо скриншот важко дифати.

Версія PowerShell така:

• Запустити команду, яка повертає структуровані об’єкти.
• Пропхати їх через сортування, фільтрацію, групування.
• Зберегти вивід (або експортувати), щоб потім порівняти.

Також: кожного разу, коли ви копіюєте/вставляєте «те, що бачили в GUI», у тикет, ви робите переклад. Переклад вводить помилки. Найбезпечніші дані — ті, які ви не інтерпретуєте повторно.

Парафраз ідеї від Gene Kim (автор про DevOps/операції): покращення приходять від скорочення циклів зворотного зв’язку і зроблення роботи видимою. Однорядки роблять обидва — якщо використовувати їх послідовно.

Жарт №1: Клікати через Server Manager під час інциденту — як відлагоджувати з ліхтариком: технічно можливо, але ви все одно наштовхнетеся на щось.

Факти та історичний контекст (коротко, корисно)

• PowerShell з’явився у 2006 році як «Monad», побудований на .NET‑об’єктах, а не на простих текстових потоках. Ось чому конвеєр у ньому працює з об’єктами, а не рядками.
• WMI передує PowerShell; багато «сучасних» перевірок PowerShell все ще обгортають WMI/CIM‑класи, що існують з 1990‑х.
• WinRM став робочою конячкою для віддалення PowerShell, підштовхнувши Windows‑операції ближче до SSH‑подібних робочих процесів — але з більшою кількістю Kerberos і менше приємних сюрпризів.
• PowerShell 5.1 постачався з Windows 10/Server 2016 і досі є дефолтним на багатьох серверах; PowerShell 7+ — окремий і крос‑платформений.
• Get-WmiObject — це спадщина; Get-CimInstance — сучасніший підхід (на базі WS‑Man), зазвичай дружніший до фаєрволів і віддалення.
• Перформанс‑лічильники старі, але золоті; вони досі один з надійніших способів побачити тиск на CPU, пам’ять, диск і мережу в Windows.
• Журнали подій — це наближення до чорної скриньки для Windows: вони неідеальні, але при фільтрації краще, ніж «я клянусь, це сталося».
• Hyper-V і Storage Spaces рано сильно опиралися на PowerShell; багато дій у GUI фактично обгортки над командлетами.
• Group Policy і Active Directory мають командлети, які зменшують «таємні налаштування», перетворюючи стан політик у запитувані дані.

Щоденні однорядкові: завдання, вивід і рішення

Нижче — практичні, запущувані команди. Кожна містить (a) що вона робить, (b) що означає вивід і (c) рішення, яке з нього випливає. Запускайте локально або віддалено (багато підтримують -ComputerName або працюють через віддалення).

Примітка щодо блоків коду: Я показую їх ніби запуск з консолі. На практиці ви виконуватимете це в PowerShell. Команди — реальні PowerShell.

1) Перевірити вільне місце на диску (швидко, сортується, без Explorer)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Where-Object DriveLetter | Select-Object DriveLetter,FileSystemLabel,@{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},@{n='FreeGB';e={[math]::Round($_.SizeRemaining/1GB,1)}},@{n='FreePct';e={[math]::Round(($_.SizeRemaining/$_.Size)*100,1)}} | Sort-Object FreePct | Format-Table -Auto"
DriveLetter FileSystemLabel SizeGB FreeGB FreePct
----------- -------------- ------ ------ -------
C           OS              127.9   11.8     9.2
E           Logs            500.0  210.5    42.1
F           Data           2048.0 1530.2    74.7

Що це означає: FreePct — перший індикатор для триажу. Нижче ~10–15% на системних томах слід припускати, що речі можуть ламатися дивними способами (патчинг, тимчасові файли, ротація логів, дампи).

Рішення: Якщо C: мало місця, припиніть «оптимізувати» й почніть звільняти простір: очистіть відомі кеші, оберніть логи, перенесіть дампи або збільшіть том. Якщо на даному томі мало місця, знайдіть топ‑споживачів далі.

2) Знайти топ‑каталоги за розміром (відповідь на «що з’їло мій диск»)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Directory 'E:\' -Force | ForEach-Object { $s=(Get-ChildItem $_.FullName -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum; [pscustomobject]@{Path=$_.FullName; SizeGB=[math]::Round($s/1GB,2)} } | Sort-Object SizeGB -Descending | Select-Object -First 10 | Format-Table -Auto"
Path                 SizeGB
----                 ------
E:\IISLogs            96.41
E:\App\Cache          51.08
E:\App\Temp           23.77
E:\Windows\Installer  12.30

Що це означає: Це дорого для великих дерев, але чесно. Використовуйте, коли потрібні факти, а не передчуття.

Рішення: Якщо логи домінують — виправте утримання/ротацію. Якщо кеш/тимчасові каталоги домінують — підтвердіть, чи безпечно їх очищати і чому вони ростуть. Якщо росте Windows\Installer, не видаляйте наосліп — чистіть підтримуваними методами.

3) Процеси з найбільшим CPU (Task Manager, але скриптово)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU,WorkingSet64 | Format-Table -Auto"
Name           Id      CPU WorkingSet64
----           --      --- -----------
sqlservr     2440  8123.54  9126807552
w3wp         4012  1022.10   785334272
MsMpEng      1780   331.92   402653184

Що це означає: CPU тут — накопичений час CPU від старту процесу, а не «поточний відсоток». Воно відповідає на запитання «хто довго жере CPU», що часто саме потрібно.

Рішення: Якщо один і той же процес домінує і продуктивність погана зараз — переходьте до перформанс‑лічильників для реального часу й черг. Якщо це AV‑сканер, розгляньте виключення (обережно) або розклад сканів.

4) Тиск на CPU у реальному часі та черги виконання (без гадань)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\System\Processor Queue Length' -SampleInterval 2 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                              CookedValue
----                                              -----------
\\SERVER\processor(_total)\% processor time              87.12
\\SERVER\system\processor queue length                    14
\\SERVER\processor(_total)\% processor time              92.44
\\SERVER\system\processor queue length                    18

Що це означає: Стійко високий % Processor Time плюс черга, що залишається підвищеною, вказують на конкуренцію за CPU. Черга особливо показова на машинах з меншою кількістю ядер.

Рішення: Якщо черга тримається високою, визначте навантаження (топ‑процеси, заплановані задачі, AV, бекап). Якщо це віртуальна машина — перевірте також навантаження хоста. Не «просто додати vCPU» без вимірювання host ready time (інструментарій інший), але ставтеся до стійкої черги серйозно.

5) Тиск пам’яті: доступні байти й активність сторінкування

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Memory\Available MBytes','\Memory\Pages/sec' -SampleInterval 2 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                  CookedValue
----                                  -----------
\\SERVER\memory\available mbytes            312.00
\\SERVER\memory\pages/sec                    86.50
\\SERVER\memory\available mbytes            280.00
\\SERVER\memory\pages/sec                    95.00

Що це означає: Низький доступний MB плюс стійко високі pages/sec свідчать про активне сторінкування. Сторінкування не зло; стійке сторінкування під навантаженням — це проблема.

Рішення: Якщо сторінкування високе під час скарг на латентність, вам або (a) потрібно більше RAM, або (b) є витік пам’яті, або (c) кеш виріс тому, що робочий набір виріс. Підтвердіть процесні робочі набори й телеметрію додатка.

6) Затримки диска і довжина черги (сюди ходять інженери зі сховищ)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' -SampleInterval 2 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                             CookedValue
----                                                             -----------
\\SERVER\physicaldisk(_total)\avg. disk sec/read                      0.045
\\SERVER\physicaldisk(_total)\avg. disk sec/write                     0.112
\\SERVER\physicaldisk(_total)\current disk queue length               23

Що це означає: 45ms читання й 112ms запис з чергою 23 — це не «гарно». Для багатьох серверних навантажень потрібні десятки мілісекунд або менше. Є винятки, але вони мають бути свідомими.

Рішення: Якщо затримка й черга високі — знайдіть зайнятий том, потім зайнятий процес. На ВМ підтвердіть, чи проблема на гості, чи на хості. Не шукайте CPU, якщо диск тоне.

7) Хто «колотить» диск? (I/O по процесах)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Select-Object Name,Id,@{n='ReadMB';e={[math]::Round($_.IOReadBytes/1MB,1)}},@{n='WriteMB';e={[math]::Round($_.IOWriteBytes/1MB,1)}} | Sort-Object WriteMB -Descending | Select-Object -First 10 | Format-Table -Auto"
Name      Id ReadMB WriteMB
----      -- ------ -------
sqlservr 2440  5120.3  9032.8
backup   3112   120.1  2201.4
w3wp     4012   980.7   610.2

Що це означає: Це накопичувальні лічильники. Вони швидко вказують на звичних підозрюваних: бази даних, агенти бекапу, індексацію, антивірус, неконтрольоване логування.

Рішення: Якщо бекап або AV домінує в робочий час — виправте розклад. Якщо логування домінує — зменшіть рівень логування або вивантажте логи на інший том.

8) Перевірити, які порти слухають (GUI не запрошено)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object LocalPort | Select-Object -First 20 | Format-Table -Auto"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      80        4012
0.0.0.0      135       968
0.0.0.0      443       4012
0.0.0.0      3389      1156

Що це означає: Це відповідає на запитання «що фактично слухає», а не «що ми думаємо, що повинно працювати». Потім зв’яжіть з іменами процесів.

Рішення: Якщо критичний порт не слухає — перевірте сервіс/додаток. Якщо слухає несподіваний порт — це дрейф конфігурації або компрометація — ставтеся серйозно.

9) Зіставити слухаючі порти з іменами процесів (зробити дієвим)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | ForEach-Object { $p=Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue; [pscustomobject]@{Port=$_.LocalPort; Process=$p.Name; PID=$_.OwningProcess; Address=$_.LocalAddress} } | Sort-Object Port | Format-Table -Auto"
Port Process PID  Address
---- ------- ---  -------
80   w3wp    4012 0.0.0.0
135  svchost 968  0.0.0.0
443  w3wp    4012 0.0.0.0
3389 TermService 1156 0.0.0.0

Що це означає: Тепер «порт 443 впав» перетворюється на «w3wp не працює», і це різниця між панікою і ремонтом.

Рішення: Якщо PID не той, що очікували — перевірте конфігурацію служби, прив’язки сайтів IIS або параметри запуску додатка. Якщо процес невідомий — не зневажайте — визначте шлях до бінарника.

10) Перевірити, що служба Windows працює (і чому ні)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name 'Spooler','W32Time','WinRM' | Select-Object Name,Status,StartType | Format-Table -Auto"
Name    Status  StartType
----    ------  ---------
Spooler Running Automatic
W32Time Running Automatic
WinRM   Running Automatic

Що це означає: Це базова гігієна. Якщо WinRM вимкнено, ваш день віддалених операцій перетворюється на день подорожей.

Рішення: Якщо критична служба зупинена — перевірте останні зміни й системні журнали перед перезапуском. Сліпі рестарти можуть приховати докази і повторити помилки.

11) Забрати останні 50 системних помилок (Event Viewer — це лабіринт)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 50 | Select-Object TimeCreated,Id,ProviderName,Message | Format-Table -Wrap"
TimeCreated           Id ProviderName           Message
-----------           -- ------------           -------
02/05/2026 09:14:02  11 Disk                   The driver detected a controller error on \Device\Harddisk2\DR2.
02/05/2026 09:11:47 7031 Service Control Manager The SQLAgent$INST service terminated unexpectedly...

Що це означає: Level=2 — «Помилка». Шукайте патерни: помилки диска/контролера, аварійні завершення служб, проблеми синхронізації часу, скидання мережі.

Рішення: Помилки диска/контролера переводять вас з «дебаг додатка» у режим «цілісність даних і шлях апаратури». Аварійні завершення служб — до питання «що змінилося» плюс дампи.

12) Забрати помилки додатка для конкретного провайдера (цільовий триаж)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error'} -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
02/05/2026 09:12:10 1000 Faulting application name: w3wp.exe...

Що це означає: Це стрічка «чому воно впало». Побачите faulting modules, коди виключень і імена додатків.

Рішення: Якщо той самий модуль падає після патчу або зміни конфігурації — відкотіть або оновіть. Якщо випадково — підозрюйте корупцію пам’яті, погані драйвери або нестабільні залежності.

13) Перевірити недавні перезавантаження і причину (правда в логах)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -MaxEvents 10 | Select-Object TimeCreated,Message | Format-Table -Wrap"
TimeCreated           Message
-----------           -------
02/04/2026 23:01:12  The process C:\Windows\System32\svchost.exe (SERVER) has initiated the restart...

Що це означає: Подія ID 1074 часто фіксує ініціативні перезавантаження користувачем або процесом і містить рядок причини, якщо він був вказаний.

Рішення: Якщо перезавантаження несподівані — припиніть сприймати аптайм як випадкову погоду. Прив’яжіть перезавантаження до вікон патчів, автоматизації або операторів. Виправляйте процес, а не симптом.

14) Перевірити встановлені оновлення (рівень патчів без кліків)

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID,InstalledOn,Description | Format-Table -Auto"
HotFixID  InstalledOn Description
-------   ----------- -----------
KB5034765 02/02/2026  Update
KB5034123 01/15/2026  Security Update

Що це означає: Швидке підтвердження свіжості патчів. Не ідеально (деякі механізми оновлення можуть не відображатися), але надійна початкова перевірка.

Рішення: Якщо баг корелює з недавнім KB — у вас є правдоподібна гіпотеза для відкату. Якщо сервер значно відстає — не прикидайтеся, що він «стабільний»; він просто непатчений.

15) Підтвердити розв’язування DNS і тип запису (уникнути театру «мережа впала»)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name 'app01.corp.local' -Type A | Select-Object Name,Type,IPAddress | Format-Table -Auto"
Name             Type IPAddress
----             ---- ---------
app01.corp.local A    10.40.12.21

Що це означає: Якщо це не вдається або повертає неправильну IP — половина вашого «відкоту додатка» насправді проблема іменування.

Рішення: Неправильний IP означає застарілий DNS або некоректну реєстрацію; виправте TTL, інтеграцію DHCP/DNS або ручні записи. Відсутня відповідь — перевірте DNS‑сервери, форвардинги або фаєрвол.

16) Тест TCP‑сервісу від краю до краю (ping — не перевірка здоров’я)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 'app01.corp.local' -Port 443 | Select-Object ComputerName,RemotePort,TcpTestSucceeded,SourceAddress | Format-List"
ComputerName     : app01.corp.local
RemotePort       : 443
TcpTestSucceeded : True
SourceAddress    : 10.40.10.55

Що це означає: Відповідає на запитання «можна встановити TCP‑з’єднання звідси до туди». Воно не перевіряє TLS‑сертифікати або коректність додатка, але швидко звужує проблему.

Рішення: Якщо TcpTestSucceeded — false, перевірте правила фаєрволу, маршрутизацію, статус прослуховувача і балансувальники. Якщо true — рухайтеся вгору по стеку: TLS, HTTP, аутентифікація, логи додатка.

17) Знайти збої запланованих завдань (тихі саботажники)

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Get-ScheduledTaskInfo | Where-Object {$_.LastTaskResult -ne 0} | Sort-Object LastRunTime -Descending | Select-Object -First 15 TaskName,LastRunTime,LastTaskResult | Format-Table -Auto"
TaskName                 LastRunTime           LastTaskResult
--------                 -----------           --------------
DailyLogRotate           02/05/2026 01:00:01   2147942401
BackupSnapshot           02/05/2026 02:00:03   1

Що це означає: Ненульові результати вказують на помилку. Числовий код часто відповідає «файл не знайдено», «доступ заборонено» тощо.

Рішення: Якщо задачі обслуговування падають — очікуйте інцидентів через переповнення диска й деградацію продуктивності від тисяч файлів. Виправте права, шляхи й облікові записи сервісів до наступного піку.

18) SMB‑шара та хто підключений (реалії файлового сервера)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select-Object Name,Path,Description | Format-Table -Auto"
Name        Path         Description
----        ----         -----------
Finance     D:\Finance   Finance share
Profiles    E:\Profiles  User profiles

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Select-Object ClientComputerName,ClientUserName,NumOpens,Dialect | Sort-Object NumOpens -Descending | Select-Object -First 10 | Format-Table -Auto"
ClientComputerName ClientUserName     NumOpens Dialect
------------------ --------------     -------- -------
WS123              CORP\j.smith             42 3.1.1

Що це означає: Це допомагає підтвердити «чи хтось зараз користується шарами» перед техобслуговуванням і виявити клієнта, що викликає шторми замків.

Рішення: Якщо один клієнт має абсурдну кількість відкриттів — перевірте ту робочу станцію/додаток. Якщо потрібно перезавантажити шару — координуйтеся з користувачами, а не руйнуйте їм день.

19) Перевірка прав: хто має доступ до папки?

cr0x@server:~$ powershell -NoProfile -Command "(Get-Acl 'D:\Finance').Access | Select-Object IdentityReference,FileSystemRights,AccessControlType,IsInherited | Format-Table -Auto"
IdentityReference     FileSystemRights               AccessControlType IsInherited
-----------------     ----------------               ----------------- -----------
CORP\Finance-Users    Modify, Synchronize            Allow             True
CORP\Domain Admins    FullControl                    Allow             True

Що це означає: Показує ефективні записи ACL, включно з успадкуванням. Це різниця між «має працювати» і «фактично працює».

Рішення: Якщо доступ відсутній — виправте членство в групах або успадкування на потрібному рівні. Уникайте одноразових ACL для користувачів, якщо вам не подобається майбутня археологія.

20) Віддалено: виконати перевірку здоров’я на кількох серверах (флот, а не «пет‑сервери»)

cr0x@server:~$ powershell -NoProfile -Command "$servers='web01','web02','web03'; Invoke-Command -ComputerName $servers -ScriptBlock { [pscustomobject]@{ ComputerName=$env:COMPUTERNAME; UptimeDays=[math]::Round((New-TimeSpan -Start (Get-CimInstance Win32_OperatingSystem).LastBootUpTime -End (Get-Date)).TotalDays,1); FreeC=[math]::Round((Get-PSDrive C).Free/1GB,1) } } | Format-Table -Auto"
ComputerName UptimeDays FreeC
------------ --------- -----
WEB01            12.4  18.7
WEB02             2.1   6.3
WEB03            56.0  22.9

Що це означає: Одна команда — три машини — узгоджені дані. Також: WEB02 має мало місця і нещодавно перезавантажувався. Така кореляція рідко випадкова.

Рішення: Пріоритезуйте аутлайер. Не усереднюйте і не заспокоюйтеся. Виправіть WEB02 спочатку, а потім зʼясуйте, чому він відрізняється.

Жарт №2: GUI каже «Not Responding», ніби це особиста межа. Сервер каже це, бо він горить.

План швидкої діагностики: що перевірити першим/другим/третім

Це послідовність, яку я використовую, коли кажуть «додаток повільний» або «сервер вмирає», а у вас є лише hostname і передчуття. Мета — не повністю вирішити все за 60 секунд; мета — знайти клас вузького місця, щоб припинити гадати.

Спочатку: підтвердити, що скарга реальна і звужена

1. З боку клієнта: чи можете ви підключитись до порту сервісу?

   cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 'app01.corp.local' -Port 443 | Select-Object TcpTestSucceeded,RemoteAddress,RemotePort | Format-List"
   TcpTestSucceeded : True
   RemoteAddress    : 10.40.12.21
   RemotePort       : 443
   

   Інтерпретація: Якщо TCP не проходить — це мережа/прослуховувач/LB/безпека. Якщо TCP проходить — рухайтеся всередину стека.

2. На сервері: чи слухає відповідний порт і чи належить він правильному процесу?

   cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen -LocalPort 443 | ForEach-Object { $p=Get-Process -Id $_.OwningProcess; [pscustomobject]@{Port=$_.LocalPort; Process=$p.Name; PID=$p.Id} } | Format-Table -Auto"
   Port Process PID
   ---- ------- ---
   443  w3wp    4012
   

   Інтерпретація: Відсутність прослуховувача означає, що додаток впав. Неправильний процес — це невірна конфігурація або щось гірше.

По‑друге: класифікувати вузьке місце (CPU, пам’ять, диск, мережа або «додаток»)

1. Тиск на CPU: % processor time + довжина черги.

   cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\System\Processor Queue Length' -SampleInterval 2 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
   Path                                              CookedValue
   ----                                              -----------
   \\SERVER\processor(_total)\% processor time              91.33
   \\SERVER\system\processor queue length                    16
   

   Рішення: Якщо CPU зашпортований із чергуванням — визначте «гарячий» процес і що це спричинило (деплой, джоб, скан, шторм повторних спроб).

2. Тиск пам’яті: доступні MB + pages/sec.

   cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Memory\Available MBytes','\Memory\Pages/sec' -SampleInterval 2 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
   Path                                  CookedValue
   ----                                  -----------
   \\SERVER\memory\available mbytes            190.00
   \\SERVER\memory\pages/sec                   120.00
   

   Рішення: Якщо сторінкування активне, очікуйте затримок по всьому стеку. Збирайте процесні дані по пам’яті; розгляньте контрольований рестарт лише після збору доказів.

3. Тиск диска: затримка + черга.

   cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' -SampleInterval 2 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
   Path                                                             CookedValue
   ----                                                             -----------
   \\SERVER\physicaldisk(_total)\avg. disk sec/read                      0.060
   \\SERVER\physicaldisk(_total)\avg. disk sec/write                     0.140
   \\SERVER\physicaldisk(_total)\current disk queue length               27
   

   Рішення: Якщо диск проблемний — припиніть шукати «повільні запити», доки не підтверджено, що сховище не є лімітом. Затримка вгору по стеку часто спричинена вниз по шляху.

По‑третє: вирішіть «мітегувати зараз» проти «розслідувати»

• Мітегувати зараз, коли вплив на користувачів серйозний і фікс оборотний: зупинити неконтрольований джоб, обмежити чергу, переключити на запасний вузол, додати тимчасову потужність, перемістити логи.
• Спочатку розслідувати, коли дія руйнує докази: перезавантаження, рестарти служб, очищення логів, видалення тимчасових дерев без снимків.

Використовуйте наведені команди, щоб обґрунтувати рішення, а потім запишіть, що ви бачили. Якщо потім ви не зможете пояснити ланцюжок дій — ви не оперували, ви діяли.

Три корпоративні міні‑історії (що пішло не так, що нас врятувало)

Міні‑історія 1: інцидент через хибне припущення

Ми успадкували Windows‑файловий сервер, який «ніколи не мав проблем». Команда вірила, що алерти по диску зловлять усе серйозне. Моніторинг сповістив — зрештою. Проблема була в припущенні, що «місце на диску» означає «вільний простір», і це все, що має значення.

У понеділок зранку прийшла хвиля тикетів: профілі не завантажуються, повільна обробка групової політики, випадкові аварії додатків при вході користувачів. На чергуванні зробили класику: RDP, відкрити Explorer, побачити, що C: має кілька ГБ вільних, і оголосити «диск не заповнений». Потім перезапустили кілька служб. Здавалося продуктивно. Насправді — ні.

Ми запустили однорядки: вільний простір томів (досить), а потім журнали подій (не гаразд). В системному журналі були помилки диска/контролера і попередження NTFS. Диск не був заповнений; він був хворий. Затримки зростали, записи зависали, і файловий сервер фактично працював у режимі повільного I/O.

Хибне припущення було тонким: «місце — єдина проблема диска». Здоров’я диска — не одна змінна; це затримка, черги, відсоток помилок і стабільність шляху. Коли сховище починає падати, Windows не завжди дає дружнє повідомлення. Вона дає тайм‑аути і ризик корупції.

Фікс не був героїчним рестартом. Ми переключили навантаження, залучили storage‑команду і замінили несправний шлях HBA. Урок засвоєно: перевірки ємності потрібні; перевірки поведінки диска запобігають катастрофам.

Міні‑історія 2: оптимізація, що виявилася помилкою

Інженер хотів пришвидшити пошук по логах. Він увімкнув детальне логування і написав заплановане завдання для стискання логів щогодини з перенесенням на центральну шару. План здавався розумним: менші файли, централізоване розслідування, менше використання диску.

В продукції це перетворилося на повільний збій. Робота стискання запускалася на початку кожної години на кожному сервері — одночасно. CPU скакав, записів на диск стало багато, і центральна шара зазнала навантаження. Продуктивність метаданих шару впала, бо тисячі файлів створювалися, перейменовувалися і видалялися в імпульсах.

Користувачі не скаржилися на «стиск логів». Вони скаржилися, що додаток «зависає кожну годину на кілька хвилин». Симптом ідеально підходить для помилкових діагнозів. Люди звинувачували GC‑паузи, блокування в базі та мережеві затримки. Справжній винуватець — «оптимізація», що створила синхронізовану конкуренцію.

Ми довели це двома швидкими перевірками: довжина черги диска і I/O по процесах. Процес стискання не був топовим за CPU весь день, але він домінував у write I/O в точний інтервал скарг. Це доказ, який закінчує суперечки.

Ми виправили, розподіливши розклади з jitter, зменшили рівень логування і змінили пайплайн: стискати раз на добу поза хостом, а не щогодини на кожному вузлі. Оптимізації, які ігнорують патерни конкуренції — не оптимізації; це розподілений DDoS з кращими намірами.

Міні‑історія 3: нудна, але правильна практика, що врятувала день

Інша команда виконувала просту, але дисципліновану практику: щоранку запускали короткий «пульс‑скрипт» по флоту. Аптайм, вільне місце, дата останнього патчу та топ‑помилок з системного журналу. Вони робили це не через любов до дашбордів. Вони робили це, бо ненавиділи сюрпризи.

Одного вівторка пульс помітив один сервер з дивною комбінацією: швидке зменшення вільного місця на E:, збої запланованих задач і повторювані попередження від агента бекапу. Ніхто ще не скаржився. Ось ключ: система пошепкила, перш ніж закричати.

Вони розслідували збої задач і виявили, що завдання ротації логів почало падати після зміни прав. Логи накопичувалися, бекап таймаутив через величезні каталоги логів, і том міг заповнитися упродовж 24 годин.

Вони виправили ACL, вручну виконали ротацію один раз і підтвердили, що задача знову працює. Сервер не дійшов до 0 байт вільного, бекап відновився, і бізнес нічого не помітив.

Це не сексуально. Це не отримує архітектурних нагород. Воно дає спокій на чергуванні. Нудна практика — не скрипт; це звичка дивитися щодня на ті самі сигнали і трактувати відхилення як реальні.

Поширені помилки: симптоми → корінна причина → виправлення

1) «Сервер повільний», але CPU виглядає нормально

Симптом: Навантаження CPU помірне, але користувачі бачать тайм‑аути і зависання.

Корінна причина: Обмеження через затримку диска/черги або тиск сторінкування пам’яті. CPU чекає, а не працює.

Виправлення: Спочатку перевірте лічильники диска і пам’яті, а не «відчуття» з Task Manager.

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Current Disk Queue Length','\Memory\Pages/sec' -SampleInterval 2 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                             CookedValue
----                                                             -----------
\\SERVER\physicaldisk(_total)\avg. disk sec/read                      0.080
\\SERVER\physicaldisk(_total)\current disk queue length               31
\\SERVER\memory\pages/sec                                            110

2) «Порт відкритий», бо ping проходить

Симптом: Хтось наполягає, що сервіс доступний, бо ICMP відповідає.

Корінна причина: Ping тестує ICMP, а не доступність додатка. Фаєрволи, балансувальники і прослуховувачі можуть ігнорувати ваш ping.

Виправлення: Тестуйте реальний TCP‑порт із тієї ж мережі, що й клієнт.

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 'db01.corp.local' -Port 1433 | Select-Object TcpTestSucceeded,RemoteAddress,RemotePort | Format-List"
TcpTestSucceeded : False
RemoteAddress    : 10.40.20.10
RemotePort       : 1433

3) «Служба працює», але додаток все одно недоступний

Симптом: Get-Service каже Running; користувачі все одно не можуть підключитись.

Корінна причина: Служба жива, але не слухає, зависла або прив’язана до неправильної інтерфейсу/порту. Або залежність (сертифікат, бекенд) зламана.

Виправлення: Підтвердіть прослуховувача й зіставте з процесом; перевірте помилки в журналі Application.

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen -LocalPort 443 | Measure-Object | Select-Object Count"
Count
-----
0

4) «Ми почистили диск» і тепер додаток не стартує

Симптом: Після видалення «сміття» служби падають, інсталятори ламаються або патчі не виконуються.

Корінна причина: Хтось видалив файли, які не були сміттям (кеш інсталятора, стан додатка, бази даних, бекапи конфігурації IIS).

Виправлення: Будьте конкретні: ідентифікуйте джерело росту, налаштуйте політики збереження і видаляйте лише відомо‑безпечні цілі. Якщо потрібно видалити — робіть снапшот спочатку (VM‑snapshot або Volume Shadow Copy залежно від політики).

5) Віддалення працює на деяких серверах, але не на інших

Симптом: Invoke-Command періодично фейлиться по флоту.

Корінна причина: WinRM відключено, відмінності в правилах фаєрволу, проблеми з резолвом DNS або налаштуванням довірених хостів.

Виправлення: Стандартизувати: переконайтеся, що служба WinRM запущена, правила фаєрволу однакові, DNS коректний. Уникайте «TrustedHosts = *» як тимчасового патчу в продакшені.

6) Сортування виводу виглядає неправильно

Симптом: Ви сортуєте за колонкою і порядок абсурдний (наприклад, «100» перед «9»).

Корінна причина: Ви занадто рано відформатували; перетворили об’єкти на рядки з Format-Table перед сортуванням.

Виправлення: Сортуйте об’єкти спочатку, формат — в кінці.

Контрольні списки / покроковий план

Щоденна 10‑хвилинна рутина операцій (робіть це, не сперечайтеся)

1. Перевірка простору: знайдіть томи з менше ніж 15% вільного; створіть тикет до того, як стане критично.
2. Скан помилок: останні 50 системних помилок; виявити повтори (диск, скидання NIC, падіння служб).
3. Перевірка патчів: підтвердити останні хотфікси; позначити машини, що відхиляються.
4. Збої задач: заплановані задачі з ненульовими результатами; виправляйте нудні спочатку.
5. Перевірка аутлайнерів: запустіть один і той самий однорядок по флоту і шукайте дивні сервери.

Чекліст реагування на інцидент (перші 15 хвилин)

1. Підтвердити доступність: Test-NetConnection до порту сервісу з релевантного сегменту мережі.
2. Підтвердити прослуховувач/процес: Get-NetTCPConnection + зіставлення процесів.
3. Класифікувати вузьке місце: черга CPU, сторінкування пам’яті, затримка/черга диска.
4. Зібрати докази: топ‑процеси, зріз журналів подій, вибірки лічильників.
5. Мітегувати безпечно: лише після того, як можна обґрунтувати дію спостережуваними даними.

Чекліст перевірки змін (після деплоїв/патчів)

1. Підтвердити стан служби: очікувані служби працюють, правильні типи запуску.
2. Підтвердити порти: очікувані порти слухають і належать очікуваним бінарникам.
3. Підтвердити логи: просканувати Application і System помилки з часу деплою.
4. Підтвердити продуктивність: порівняти зрізи лічильників (затримка, черги) з базовим рівнем.

FAQ

1) Коли використовувати Windows PowerShell 5.1 або PowerShell 7?

Використовуйте 5.1, коли потрібна максимальна сумісність зі старими модулями на Windows Server. Використовуйте 7, коли ви контролюєте середовище і хочете сучасних можливостей і крос‑платформності. У змішаних підприємствах ви врешті‑решт використовуватимете обидва.

2) Чому ви постійно використовуєте перформанс‑лічильники замість просто «топ» процесів?

Тому що лічильники показують тиск (черги, затримки, сторінкування), тоді як списки процесів дають атрибуцію. Вам потрібні обидва. Якщо дивитися лише на процеси, можна пропустити справжній клас вузького місця.

3) Чи помер Get-WmiObject?

Не помер, просто застарів. Віддавайте перевагу Get-CimInstance для сучасних скриптів, особливо з віддаленням. Але в реальному житті ви все ще побачите WMI скрізь, включно з скриптами вендорів.

4) Чому деякі лічильники показують числа, що не збігаються з Task Manager?

Відрізняються вибірки й визначення. Task Manager часто показує миттєві або усереднені значення; лічильники можуть брати вибірки на різних інтервалах і представляти інші моделі обчислення. Робіть інтервал вибірки явним і беріть кілька зразків.

5) Можу я запускати ці однорядки віддалено без RDP?

Так, з PowerShell Remoting (Invoke-Command), коли WinRM налаштований. Для деяких мережевих перевірок також можна робити запити зі своєї машини (наприклад, Test-NetConnection). Стандартизувати WinRM варто рано; це окупається щотижня.

6) Як уникнути проблем «занадто раннього форматування»?

Правило: виконуйте всі фільтрації/сортування/групування поки конвеєр містить об’єкти, а потім форматируйте в кінці. Якщо ви пропхали в Format-Table, ви фактично завершили роботу з даними.

7) Чи безпечно вставляти однорядки в продакшн?

Команди лише для читання зазвичай безпечні. Все, що видаляє, зупиняє служби, рестартує або змінює конфіг — має стати скриптом з логуванням і режимом dry‑run. Якщо не можете пояснити радіус ураження — не запускайте.

8) Який найшвидший спосіб виявити «цей сервер відрізняється» у кластері?

Запустіть ту саму команду по всіх вузлах і відсортуйте за метрикою, що вас цікавить (вільний простір, аптайм, кількість помилок, значення лічильників). Аутлайери — там, де ховається правда.

9) Моя команда повільна (наприклад, перевірка розміру директорій). Що робити?

Використовуйте дорогі перевірки лише коли потрібно, і обмежуйте їх: менші шляхи, менше рекурсійних цілей, або запускайте в позаробочий час. Для постійного моніторингу інструментуйте логи і квоти замість повторного сканування файлової системи кожного разу.

Практичні наступні кроки

Зробіть це завтра вранці:

1. Виберіть п’ять серверів, до яких ви заходите щотижня. Запустіть флот‑однорядок для аптайму і вільного місця. Знайдіть аутлайера і виправте його.
2. Додайте 2‑хвилинну вибірку лічильників для черги CPU, сторінкування і затримки диска до своїх стандартних нотаток інцидентів. Припиніть діагностувати зі скриншотів.
3. Побудуйте (або позичте) маленький «pulse check» скрипт із наведених команд і запускайте щодня. Мета не досконалість; мета — помічати дрейф до того, як він стане інцидентом.
4. Коли GUI все ж потрібен — використовуйте його свідомо: для глибокої конфігурації, а не для панічного пошуку.

Якщо хочете лакмусовий тест, чи покращується ваша практика операцій: виміряйте, як часто ви можете відповісти «що змінилося?» з доказами менш ніж за п’ять хвилин. Однорядки — не магія. Вони — важіль.