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

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

Версія через 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 все ж потрібен — використовуйте його свідомо: для глибокої конфігурації, а не для панічного пошуку.

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

Чому підбір PSU — це проблема SRE, а не тільки закупівель

Підбір PSU часто сприймають як пункт у чеклисті закупівель: вибрати потужність, позначити «резервний», відправити. У продуктивних системах такий підхід дає збій з тієї ж
причини, з якої «просто додамо вузли» дає збій: ігнорує перші жорсткі обмеження, які спрацьовують.

PSU — це місце, де ваша робоче навантаження стає фізикою. Сплески навантаження перетворюються на стрибки струму. Поведінка прошивки — в енергії вентиляторів. Нова мережна карта —
це кілька ватів, на які ви ніколи не заклали бюджет. І найобразливіше: коли з харчуванням щось йде не так, симптоми не завжди кричать «харчування».
Ви отримуєте нестабільні диски, несподівані перезавантаження, скиди NIC, пошкоджені датчики BMC або «випадкові» kernel panic. Проблеми з харчуванням маскуються під софтверні.

Ви прагнете трьох результатів:

• Жодних відмов, спричинених спрацьовуванням автоматів, перевантаженням PSU чи просадками напруги.
• Жодних втрат через надмірно великі PSU, що працюють у низькоефективному режимі.
• Швидкого відновлення, коли PSU виходить з ладу, падає живлення або PDU вас обдурює.

Якщо ваш метод підбору PSU — «підсумувати TDP і округлити вгору», ви керуєте продакшеном на надії. Надія — не джерело живлення.

Цікаві факти та трохи історії (щоб ви не повторювали старі помилки)

1. Ранні ПК-блоки живлення були орієнтовані на навантаження з тяжінням на 5V. Сучасні сервери в основному 12V-центровані, а DC-DC перетворення перемістилося на плату.
2. ATX12V (початок 2000-х) перекинув більше потужності на 12V для живлення CPU, змінивши значення «рейлів» та обмежень струму в реальних збірках.
3. 80 PLUS (сер. 2000-х) зробило ефективність маркетинговою і закупівельною позицією, але його тестові точки не покривають ваші спікоподібні навантаження.
4. Дата-центри змістилися від «один великий UPS» до розподілених UPS і розумних PDU, що спростило вимірювання — якщо ви справді ними користуєтесь.
5. Резервні PSU стали стандартом не тому, що вони модні, а тому, що гаряча заміна PSU краще, ніж вікно техпідтримки о 2-й ночі.
6. Сучасні CPU і GPU ввели агресивне підвищення частоти; миттєва потужність може перевищувати «TDP» у спосіб, який закупівельні презентації рідко згадують.
7. Криві вентиляторів змінили правила гри: вентилятори з високим статичним тиском можуть споживати значну потужність на повній швидкості, а оновлення прошивки можуть змінити поведінку вночі.
8. Щільність стояків зросла із появою віртуалізації і GPU; потужність і охолодження стали першими обмеженнями, а не лише місця в стійці.
9. Координація автоматів у будівлях еволюціонувала, але автомати все ще спрацьовують швидше за ваше оповіщення — особливо щодо пускового струму.

Здорова модель мислення: середнє, пікове і кепські секунди між ними

Помилки у підборі PSU виникають через використання одного числа, коли потрібно принаймні три:

• Середньостатистичне споживання в steady-state: що сервер споживає більшу частину часу.
• Тривалий пік: що він споживає під реальною роботою, не за синтетичною «TDP»-логікою.
• Транзієнт/пусковий струм: що він споживає під час завантаження, одночасного запуску дисків, розгону вентиляторів або стрибків GPU.

Додайте четверте, якщо використовуєте резервування:
режим з одним PSU — бо в конфігурації 1+1 вам все одно треба вижити на одному PSU без колапсу.

Що насправді означає «потужність PSU»

«1200W» PSU зазвичай сертифікований для певної вхідної напруги, температури, повітряного потоку і іноді висоти над рівнем моря. Це також означає максимальний DC-вихід за тих умов.
Це не означає, що ваша система безпечно може безперервно споживати 1200W у будь-якій стійці, за будь-якої температури і поки пил накопичується в корпусі як утеплювач.

Цитата, яку варто мати на стіні

«Надія — не стратегія.» — Gen. Gordon R. Sullivan

Не SRE, але сенс болісно релевантний. У плануванні живлення «ймовірно, не піде в пік» — це надія, переодягнена в інженерію.

Жарт №1: PSU сервера — як парашут: якщо ви дізнаєтеся, що він замалий тільки коли він потрібен, у вас буде поганий день.

Що вимірювати (і що специфікації вам не скажуть)

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

Вимірюйте на кількох рівнях

• Вхідна потужність на стіні / PDU: за що ви платите і що може спровокувати спрацьовування автомата.
• Вихід PSU (рідко безпосередньо видимий): що система споживає у термінах DC.
• Підказки на рівні компонентів: потужність пакета CPU, GPU, активність дисків, оберти вентиляторів та PWM.

Знайте обмеження, які важливі

• Гілковий ланцюг (рейтинг автомата; практика дерейтингу для безперервного навантаження відрізняється по регіонах і кодексу).
• Обмеження PDU і вилки (C13/C14 vs C19/C20, перетин кабелю, ліміти на вихід).
• Номінал PSU на вашу вхідну напругу (поширена пастка: 120V vs 208/230V — продуктивність і доступний запас різняться).
• Режим резервування (розподіл навантаження vs активний/резервний; і чи витримає платформа один PSU при повному навантаженні).

Не плутайте ці терміни

• TDP: точка теплового проєктування, а не контрактне обмеження потужності.
• PL1/PL2 (та еквіваленти вендорів): тривале проти boost-політики потужності; прошивка може їх змінити.
• Уявна потужність (VA) vs реальна потужність (W): UPS і PDU можуть показувати одне або інше; коефіцієнт потужності важливий, коли ви близькі до лімітів.

Практичні завдання вимірювання (команди, виходи, рішення)

Ви не зможете «спроєктувати» шляхом уникнення вимірювання. Нижче — конкретні, виконувані завдання. Кожне має: команду, що означає вихід, і яке рішення вона підтримує.
Використайте їх, щоб побудувати профіль потужності для кожної моделі сервера і класу навантаження.

Завдання 1: Прочитати миттєву потужність, що її повідомляє BMC (IPMI)

cr0x@server:~$ ipmitool sensor | egrep -i 'Power|Pwr Consumption|Watts'
Pwr Consumption   | 312        | Watts      | ok

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

Завдання 2: Витягнути історію потужності / min-max якщо платформа це експонує

cr0x@server:~$ ipmitool sdr elist | egrep -i 'Pwr|Power'
System Level      | 00h | ok  |  3.1 | Power Meter
System Level      | 01h | ok  |  3.2 | Power Max
System Level      | 02h | ok  |  3.3 | Power Min

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

Завдання 3: Виміряти обмеження потужності пакета CPU і струм (Intel RAPL через powercap)

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
225000000

Значення: 225,000,000 µW = 225W довготривале обмеження пакета (PL1-подібне) для цього домену RAPL.
Рішення: Якщо ваш підбір PSU базувався на «CPU 165W», але прошивка дозволяє 225W тривало, оновіть бюджет або встановіть обмеження.

Завдання 4: Виміряти енергію RAPL для оцінки середнього споживання CPU за інтервал

cr0x@server:~$ E1=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); sleep 10; E2=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); echo $(( (E2-E1)/10000000 ))
186

Значення: Приблизно 186W в середньому для того пакета за 10 секунд (енергія в µJ поділена на 10s).
Рішення: Ідентифікуйте навантаження з тривалим високим споживанням CPU — саме вони роблять «пік» не рідкісною подією.

Завдання 5: Перевірити споживання GPU і ліміти (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,power.draw,power.limit,clocks.sm --format=csv,noheader
NVIDIA A10, 126.54 W, 150.00 W, 1395 MHz

Значення: Реальне споживання GPU 126W з лімітом 150W.
Рішення: Для GPU-серверів підбір PSU без реальної телеметрії GPU — це показуха. Якщо кілька GPU можуть одночасно досягти ліміту, закладайте цей пік.

Завдання 6: Перевірити поточну частоту CPU і статус тротлінгу (швидка перевірка)

cr0x@server:~$ lscpu | egrep -i 'Model name|CPU max MHz|CPU MHz'
Model name:          Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:         3200.0000
CPU MHz:             2001.102

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

Завдання 7: Перевірити журнали ядра на події, пов’язані з живленням

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'power|brown|thrott|vrm|PSU|over current|watchdog' | tail -n 20
kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: b200000000070005
kernel: EDAC MC0: CPU power throttling detected

Значення: Апаратура/прошивка повідомили про тротлінг або помилки, які можуть бути пов’язані з доставкою живлення (не завжди, але варто корелювати).
Рішення: Якщо це корелює зі сплесками або перезавантаженнями, припиніть шукати «випадкову нестабільність» і перевірте живлення, PSU і терміку.

Завдання 8: Перевірити статус PSU і режим резервування через IPMI (якщо підтримується)

cr0x@server:~$ ipmitool sdr type 'Power Supply'
PS1 Status       | ok
PS2 Status       | ok
PS1 Input Power  | 165 Watts
PS2 Input Power  | 162 Watts

Значення: Обидва PSU активні і приблизно рівномірно ділять навантаження.
Рішення: Якщо ви очікували режим 1+1 з одним активним і одним в резерві, можливо ви не в тому режимі резервування, який думаєте. Оновіть модель відмови.

Завдання 9: Виміряти потужність від стіни через метрований Rack PDU (приклад SNMP)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.7.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.7.1 = INTEGER: 356

Значення: OID вендора повертає потужність на розетці в ватах (приклад: 356W). Семантика MIB відрізняється; підтвердіть одиниці виміру один раз, а потім автоматизуйте.
Рішення: Використовуйте показники PDU як істину для планування ланцюгів і ризику автомату. Показники BMC — «приємні для перегляду», але не ваш фінансовий орієнтир.

Завдання 10: Перевірити струм на виході PDU, щоб виявити ризик близький до спрацьовування

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.5.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.5.1 = INTEGER: 28

Значення: Струм на розетці (приклад: 2.8A якщо пристрій використовує декаампера); знову ж таки, залежить від вендора.
Рішення: Переведіть у ампери, порівняйте з лімітами ланцюга та PDU. Якщо ви близько — не додавайте «ще один вузол».

Завдання 11: Корелювати навантаження з потужністю за допомогою контрольованого тесту навантаження (CPU)

cr0x@server:~$ sudo apt-get -y install stress-ng
...
cr0x@server:~$ stress-ng --cpu 32 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info:  [8421] dispatching hogs: 32 cpu
stress-ng: metrc: [8421] cpu                60.00s  19184.12 bogo ops/s

Значення: Ви створили відтворюване навантаження на CPU. Паралельно знімайте показники PDU/BMC.
Рішення: Побудуйте для платформи «CPU-only пік» як базову величину. Потім робіть те саме з диском і мережею, щоб побачити комбіновані піки.

Завдання 12: Активність дисків і кількість приводів важливі — виміряйте це (нагрузка на сховище)

cr0x@server:~$ iostat -dx 2 3
Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await  svctm  %util
nvme0n1         820.0   110.0   128.0    24.0     358     2.10   2.1   0.6   55.0

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

Завдання 13: Перевірити події заряджання батареї/модуля кеш-контролера

cr0x@server:~$ sudo dmesg | egrep -i 'battery|cachevault|supercap|charging' | tail -n 20
megaraid_sas 0000:3b:00.0: CacheVault charging started

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

Завдання 14: Перевірити оберти вентиляторів і PWM — вентилятори не безкоштовні

cr0x@server:~$ sudo ipmitool sdr | egrep -i 'FAN|RPM' | head
FAN1            | 7800   | RPM  | ok
FAN2            | 8100   | RPM  | ok

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

Завдання 15: Перевірити вхідну напругу PSU (бо 120V vs 208V має значення)

cr0x@server:~$ ipmitool sensor | egrep -i 'Inlet|VIN|AC|Voltage' | head
PS1 Inlet Volt   | 208        | Volts     | ok
PS2 Inlet Volt   | 208        | Volts     | ok

Значення: PSU бачать 208V, що зазвичай покращує ефективність і зменшує струм при однаковій потужності.
Рішення: Якщо ви на 120V і збільшуєте щільність, подумайте про переведення на вищу напругу живлення там, де це можливо. Це часто найпростіший спосіб збільшити потужність.

Завдання 16: Швидкий і грубий спостережний тест пускового струму через лог піків PDU (якщо підтримується)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.4.3.1.6.1
SNMPv2-SMI::enterprises.318.1.1.26.4.3.1.6.1 = INTEGER: 47

Значення: Лічильник «пік струму з моменту останнього скидання» (приклад). Точний OID залежить від вендора і моделі.
Рішення: Якщо піковий струм значно вищий за установившийся, рознесіть завантаження і уникайте синхронного підключення після відключень.

Резервні PSU: 1+1 не завжди означає 1+1

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

• Потужності на один PSU порівняно з піковими потребами системи.
• Поведінки розподілу навантаження (active/active або active/standby).
• Поводження при обмеженні потужності, коли один PSU відсутній (деякі системи автоматично тротлять; інші просто падають).
• Незалежності живлення (два PSU на одному PDU — це не резервування; це оптимізм із зайвими кроками).

Простими словами про N+1

Якщо у вас два 800W PSU у конфігурації 1+1, важливе питання:
Чи може сервер працювати на піку на одному 800W PSU?
Якщо реальний виміряний пік — 780W біля стіни і PSU при високій вхідній температурі дерейтується, ви не «в безпеці». Ви стоїте на тонкому технічному розрахунку.

Балансування навантаження не гарантоване

Якщо два PSU погано ділять навантаження (через прошивку, несумісні PSU, старіння або кабелювання), один PSU може працювати гарячіше і ближче до ліміту. Коли він виходить з ладу,
інший пережимає навантаження, що може спричинити другий відмову або перезавантаження. Це «подвійне влучення резервного PSU», і воно таке ж приємне, як звучить.

Пусковий струм (inrush): автоматові байдуже ваші таблиці

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

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

Жарт №2: Автомати як інженери on-call: вони багато чого терплять, але пам’ятають саме ту одну останню соломинку.

Як зменшити ризик inrush

• Рознесіть завантаження (PDU, зовнішня автоматизація або гачки оркестратора).
• Уникайте синхронного розгону вентиляторів шляхом оновлення прошивки у контрольованих хвилях, а не «всі разом у п’ятницю».
• Знайте поведінку HDD: параметри staggered spin-up на HBA збережуть ваш автомат і гордість.
• Вимірюйте піковий струм там, де можливо: деякі метровані PDU і UPS ведуть логи пікiв та inrush-подій.

Дереатинг: температура, висота над рівнем моря, пил і чому «1200W» інколи фантазія

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

Дереатинг проявляється як:

• Менший доступний вихід при вищій температурі на впуску.
• Збільшена потужність вентиляторів (що підвищує системне споживання і знижує ефективність).
• Раніше термозахистне вимкнення або захисне тротлінгування.

Температура — множник ризику

Сервер, що «в нормі» при 18°C на впуску, може стати крихким при 30°C на впуску, коли один PSU виходить з ладу, а залишений працює гарячіше і голосніше.
Саме в такий момент найгірше дізнатися, що ваша припущення про резервування базувалося на лабораторному буклеті.

Висота над рівнем моря — це реальна річ (так, правда)

На великій висоті зменшується густина повітря, а отже і ефективність охолодження. Багато вендорів вказують дереатинг вище певної висоти. Ігнорувати це можна, але PSU не переконаєте вашою впевненістю.

Криві ефективності: вати, які ви не витягуєте, все одно коштують вам

Ефективність — це не константа. Це крива. Більшість PSU «щасливі» десь на 40–60% навантаження, залежно від конструкції. При дуже низькому навантаженні ефективність падає,
і ви втрачаєте потужність у вигляді тепла. При дуже високому навантаженні ефективність теж може падати, і терміка стає некрасивою.

За замовчуванням надмірне збільшення PSU здається «безпечним», але воно може вести до марнотратства у трьох напрямках:

• Capex: моделі PSU більшої потужності коштують дорожче.
• Opex: нижча ефективність на холостому ходу по всьому парку — неприємно для рахунку за електрику.
• Охолодження: втрачені вати перетворюються на тепло, яке ваш об’єкт має відвести.

Що робити замість сліпого oversizing

Виміряйте реальний пік і виберіть PSU так, щоб:

• Ваш середній режим знаходився в ефективній частині кривої.
• Ваш тривалий пік залишався нижче консервативного порогу (особливо в режимі N+1).
• Ваш inrush не спрацьовував гілкові автомати під час масових подій у флоті.

Це менш гламурно, ніж купувати найбільший доступний блок. Але саме так ви уникнете проведення вихідних у холодному коридорі з ліхтариком.

Три корпоративні міні-історії з краю «має бути нормально»

Міні-історія 1: Інцидент через неправильне припущення

Компанія розгорнула нову партію серверів з великим сховищем: багато дисків, подвійні контролери і «резервні» PSU. Закупівля підібрала PSU, підсумувавши TDP CPU, RAM і «трохи для дисків».
Вони також стандартизували 120V живлення в застарілій кімнаті, бо воно «вже було там».

У steady-state усе виглядало нормально. Графіки моніторингу були нудні, і розгортання оголосили успішним. Потім майже планове обслуговування електропостачання. Після відновлення живлення
весь ряд спробував завантажитися одночасно. Декілька автоматів спрацювали миттєво. Декілька стійок піднялися напівжитими: деякі сервери зациклилися на завантаженні, деякі втратили диски, а пару контролерів піднялися деградованими.

Постмортем був брудний, бо перша хвиля дебагу пішла в сторону софту: версії ядра, порядок завантаження, прошивка RAID. Видимим натяком було те, що відмови групувалися по стійках і PDU, а не по збірках ОС.
Хтось нарешті витягнув логи пікових струмів PDU і порівняв їх з рейтингом гілкового автомату.

Причина не в тому, що сервери «споживали забагато» в середньому. Причина в тому, що inrush і одночасний запуск дисків перевищили толерантність автомата при 120V, де струм вищий при тій самій потужності.
«Резервні PSU» не допомогли, бо резервування не заважає автомату спрацювати.

Виправлення було нудним: рознесення завантаження, увімкнення staggered spin-up на HBA та переведення найщільніших стійок на вищу напругу де було можливо. Також почали фіксувати пікову потужність на PDU під час приймальних тестів.
Наступний сеанс обслуговування пройшов без пригод — а це найкращий тип події.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Інша організація серйозно взялася за енергоефективність і вирішила агресивно «підібрати» PSU. Вони помітили, що сервери в простое споживають близько 120–160W і вирішили, що менші PSU покращать ефективність на холостому ході.
Вони затвердили стандартну конфігурацію з низькопотужними PSU для нового обчислювального флоту.

Лабораторні тести виглядали добре. Ідл-ефективність трохи покращилася. Закупівля була в захваті через скорочення витрат. Флот розгорнули в продакшен, де навантаження було імпульсним — аналітика батчами та сплески API.
Під час сплесків поведінка CPU boost підштовхнула тривалу потужність вище, ніж очікували.

Все ще «у специфікації» для одного PSU — до тих пір, поки PSU не вийшов з ладу.

За 1+1 резервуванням один PSU повинен був нести повне навантаження. На папері це можливо. На практиці, при вищих температурах на впуску і більший запиленості, ніж в лабораторії, залишений PSU працював гарячіше.
Прошивка платформи відповіла тротлінгом продуктивності. Сервіс не впав, але затримки зросли з «добре» до «чому черга тане». SREs сприйняли це як регресію софту, бо нічого не впало. Просто стало повільно й непередбачувано.

Проблема не в самій ідеї підбору; проблема була в тому, що це робили на підставі тестів холостого ходу й ігнорували режим N+1 та дерейтинг середовища. Вирішили підняти PSU на крок, запровадити обмеження потужності для найбільш імпульсивних вузлів і припинити оцінювати успіх виключно по ефективності в idle.
Ефективність важлива. Передбачуваність важить більше.

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

Команда, що керувала змішаним флотом (GPU-коробки, ноди сховища, звичайні обчислювальні), мала скупу політику: кожна нова модель заліза мала пройти «характеризацію потужності» перед тим, як потрапити в продакшен.
Це означало вимірювання idle, 50-го процентиля навантаження, тривалого піку і пускового inrush — використовуючи той самий PDU, що й у продакшені.

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

Якось постачальник доставив «незначний ревізійний» варіант тієї ж моделі. Та сама родина SKU, той самий маркетинговий лист, інша прошивка і трохи інша поведінка вентиляторів. Характеризація виявила, що нова ревізія має різкіший розгін вентиляторів при певних порогах датчиків, що підвищувало пикове споживання достатньо, щоб важити при відмові PSU.

Оскільки у них були початкові дані, це не стало інцидентом. Вони відкоригували розміщення в стійці (менша щільність на той ланцюг для цієї ревізії), налаштували прошивку там, де дозволено, і оновили бюджет потужності.
Місяць по тому справжній відмовник PSU стався в продакшені під важкою задачею. Вузол залишився в мережі. Жодного впливу на клієнтів. Жодних героїчних дій. Просто тиха радість нудної інженерної практики, що спрацювала як слід.

План швидкої діагностики

Коли щось пахне електропостачанням — випадкові перезавантаження, відмови, що групуються по стійці, падіння продуктивності після виходу PSU — не блукайте. Перевіряйте в цьому порядку.
Мета — знайти вузьке місце за хвилини, а не після переписування половини планувальника.

Перше: підтвердіть, що саме відмовляє (вузол, стійка, ланцюг чи кімната)

• Чи відмови групуються по стійці/PDU або по моделі заліза?
• Чи події корелюють з бойовими завантаженнями, обслуговуванням або стрибками температури?
• Чи бачите ви спрацьовування автоматів або тривоги UPS?

Друге: довіряйте PDU/UPS для вхідної потужності, потім перехресно перевірте BMC

• Перевірте PDU на рівні розетки: вати/ампери і будь-які лічильники піків.
• Порівняйте з BMC-значеннями; великі несходження вказують на погані сенсори або різні точки вимірювання.
• Підтвердіть вхідну напругу. Низька напруга означає вищий струм при тій самій потужності і менший запас.

Третє: протестуйте поведінку резервування під навантаженням

• У контрольованих умовах витягніть один PSU і спостерігайте: чи стрибне потужність? чи розженуться вентилятори? чи тротлить хост?
• Підтвердіть, що кожен PSU підключений до різних живильних вводів і що вводи справді незалежні.
• Якщо продуктивність змінюється суттєво, сприймайте це як ризик для продакшену, а не «приємний факт».

Четверте: ізолюйте транзієнтні причини

• Пусковий струм і старт дисків: шукайте події автомата або піки PDU при відновленні живлення.
• Зміни прошивки/криві вентиляторів: корелюйте з останніми оновленнями.
• Сплески навантаження: корелюйте з телеметрією CPU/GPU і часом інцидентів.

Поширені помилки (симптом → корінь → виправлення)

1) Випадкові перезавантаження під навантаженням

Симптом: Хости перезавантажуються, коли стартують пакетні задачі або сплески використання GPU.
Корінь: Перевантаження PSU або проблеми транзієнтної реакції; інколи один PSU слабкий/старіє і колапсує на крок-навантаженнях.
Виправлення: Виміряйте на PDU під час навантаження. Протестуйте з одним PSU виключеним. Замініть підозрілий PSU. Якщо піки реальні — підвищуйте потужність PSU або обмежуйте потужність.

2) Спрацьовування автоматів після обслуговування або відновлення живлення

Симптом: Цілі стійки темні, автомати спрацьовують одразу при подачі живлення.
Корінь: Пусковий струм плюс синхронне завантаження; запуск дисків і розгін вентиляторів це посилює, особливо при 120V.
Виправлення: Рознесіть завантаження. Увімкніть staggered spin-up. Знизьте щільність на ланцюг або переведіть на вищу напругу.

3) «Резервний» PSU але один вихід спричиняє падіння продуктивності

Симптом: Без відмови, але затримки зростають і пропускна здатність падає, коли один PSU помирає.
Корінь: Режим з одним PSU викликає обмеження потужності або термальний стрес; залишений PSU працює гарячим і прошивка тротлить CPU/GPU.
Виправлення: Підберіть так, щоб один PSU міг витримати тривалий пік з запасом при найгіршій вхідній температурі. Тестуйте і документуйте продуктивність у режимі відмови.

4) PDU показує високі вати, BMC — низькі (або навпаки)

Симптом: Два «авторитетних» числа розходяться на 20–40%.
Корінь: Різні точки вимірювання (вхід проти обчисленого), дрейф калібрування сенсорів або баги прошивки BMC.
Виправлення: Довіряйте PDU/UPS як істині для виставлення рахунків і автомата. Використовуйте BMC для трендів. При потребі калібруйте разом з відомим метрологічним приладом.

5) Нова прошивка спричинила перевитрату бюджету потужності

Симптом: Після оновлення BIOS/BMC вартість стійки зросла або стрибнула потужність вентиляторів; з’явилися тривоги автомата або UPS.
Корінь: Оновлені криві вентиляторів, вищі ліміти boost-потужності або інші профілі за умовчанням.
Виправлення: Повторно характеризуйте споживання після змін прошивки. Фіксуйте профілі потужності. Rollout оновлень хвилями з моніторингом PDU.

6) «Ми підібрали по TDP» і тепер усе тісно

Симптом: Математика з табличок каже, що ви в безпеці; реальні виміри говорять протилежне.
Корінь: TDP — не обмеження; накладні витрати платформи, пам’ять, диски, NIC, вентилятори і поведінка boost не були враховані.
Виправлення: Побудуйте виміряну модель потужності для кожної платформи: idle, типовий, тривалий пік, inrush і режим N+1. Припиніть використовувати суму TDP як остаточну відповідь.

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

Покроково: як підібрати PSU для моделі сервера (без гадань)

1. Визначте джерело істини для вимірювань. Для планування ємності використовуйте метрований PDU/UPS (вхідні вати); BMC — для трендів і статусу резервування.
2. Зафіксуйте умови впуску. Занотуйте вхідну напругу та приблизну температуру на впуску під час тестів. Дані потужності без умов — плітки.
3. Виміряйте чотири точки потужності:
   • Idle (після завантаження, сервіси стабільні)
   • Типове навантаження (репрезентативний продакшен-мікс)
   • Тривалий пік (стрес-тест, що імітує реальні вузькі місця)
   • Пуск/inrush (холодний старт, не теплий ребут)
4. Протестуйте поведінку N+1. Під навантаженням відключіть один PSU і спостерігайте стабільність, тротлінг і поведінку вентиляторів. Зафіксуйте потужність і терміку.
5. Застосуйте маржу свідомо. Додайте запас для помилок вимірювання, змін середовища, старіння і «сюрпризної прошивки». Уникайте миттєвої реакції «подвоїмо».
6. Перевірте відповідність ланцюгу. Переведіть вати в ампери при вашій напрузі і переконайтеся, що ви не фліртуєте з лімітом гілки під піками і inrush.
7. Визначте розмір PSU і режим резервування. Оберіть модель PSU так, щоб режим з одним PSU залишався стабільним на тривалому піку з реальним запасом.
8. Документуйте профіль. Зберігайте виміряні значення і умови тестів у вашому runbook по залізу, щоб наступна людина не займалась археологією.
9. Операціоналізуйте моніторинг. Налаштуйте оповіщення при незвичному зростанні потужності, але також при втраті резерву і несподіваних змінах в поділі навантаження.
10. Повторно тестуйте після суттєвих змін. BIOS/BMC оновлення, нові NIC/HBA, зміни моделі GPU або зсуви в навантаженнях заслуговують повторного вимірювання.

Контрольний список: бюджету стояка, який ви зможете захистити на нараді

• На стійку: виміряний типовий і виміряний пік, а не просто сума шильдиків.
• На гілку: ампераж при фактичній напрузі з чіткими припущеннями про допустиму безперервну завантаженість.
• План по inrush: процедура рознесення завантаження задокументована і протестована.
• План резервування: PSU на різних вводах; PDU на різних upstream де можливо.
• Тести приймання: кожна нова модель заліза проходить прогін характеристик потужності перед розгортанням.

Контрольний список: версія «ми збираємося додавати GPU»

• Виміряйте ліміт потужності GPU на карту і підтвердьте загальну рамку потужності платформи.
• Підтвердіть обмеження PCIe auxiliary power і riser; не припускайте, що проводка шасі відповідає маркетингу GPU.
• Протестуйте сумарний CPU+GPU пік під реальними навантаженнями (не лише синтетичними).
• Перевірте поведінку резервування при відключенні одного PSU під GPU-навантаженням.
• Підтвердіть ланцюг і тип розетки PDU (C13 vs C19) та ліміти на розетку.

FAQ

1) Чи можу я підібрати PSU, підсумувавши TDP компонентів?

Використовуйте суму TDP лише як орієнтовний нижній межа. Реальні системи перевищують його через boost-поведінку, потужність вентиляторів, зарядні явища контролерів і транзієнти.
Вимірюйте на PDU.

2) Чи завжди купувати PSU з максимальною потужністю?

Ні. Надмірне збільшення може витрачати гроші і знижувати ефективність при низькому навантаженні. Купуйте для виміряного тривалого піка плюс запас, і переконайтеся, що режим з одним PSU безпечний, якщо ви використовуєте резервування.

3) Який запас слід додати?

Однозначної величини немає. Додавайте запас для помилки вимірювання, змін середовища, старіння і майбутніх доповнень. Правильний запас — це той, що проходить режим N+1 при найгіршій вхідній температурі без тротлінгу чи нестабільності.

4) Кому довіряти більше: BMC чи PDU?

Для планування автомата і ємності: PDU/UPS вхідні вати. Для трендів по хосту і статусу резервування: BMC корисний. Якщо вони розходяться, розберіться, але бюджетуйте за PDU.

5) Чому споживання стрибає після оновлення BIOS/BMC?

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

6) Як резервні PSU впливають на ефективність?

При спільному розподілі навантаження кожен PSU працює на нижчому відсотку завантаження, що може винести вас із «солодкої точки» ефективності. При active/standby один PSU може працювати близько до солодкої точки, але інший все одно споживатиме резервну потужність.
Виміряйте, не припускайте.

7) Що таке VA vs W при підборі UPS і ланцюгів?

W — реальна потужність; VA — уявна потужність. UPS і PDU можуть вказувати одне або інше. Якщо коефіцієнт потужності далеко від 1.0, VA може бути значно вищим за W, і це може стати обмеженням для ємності UPS, навіть коли вати в нормі.

8) Як уникнути спрацьовування автоматів під час перезапусків флоту?

Рознесіть завантаження, увімкніть staggered spin-up дисків де можливо і уникайте «усі вузли одночасно вгору». Підтвердіть за допомогою логів піків PDU і проведіть контрольований тест.

9) Чи треба мені хвилюватися про ліміти рейлів PSU?

Менше ніж у старих десктопів з багатьма рейлами, але так — інколи. Серверні PSU і бэкплейни зазвичай абстрагують це, але при високій щільності GPU і розподілі riser можна наткнутися на приховані ліміти.
Якщо ви бачите нестабільність під навантаженням GPU, перевіряйте розподіл живлення платформи, а не лише сумарні вати.

10) Який практичний спосіб обмежити потужність серверів, щоб не перевищувати ліміти?

Використовуйте інструменти вендора або профілі прошивки де можливо і перевіряйте через PDU. Для CPU обмеження на базі RAPL може допомогти, але підтвердіть поведінку під вашими навантаженнями — деякі навантаження міняють затримку заради ватів у неприємний спосіб.

Наступні кроки, які ви можете зробити цього тижня

• Виберіть одну модель сервера і створіть профіль потужності: idle, типове, тривалий пік, пуск/inrush і результати тесту N+1.
• Зробіть PDU джерелом істини для вхідної потужності і піків; підключіть SNMP-опитування до вашого пайплайна метрик.
• Проведіть контрольований тест резервування: під значним навантаженням витягніть PSU і стежте за тротлінгом, розгоном вентиляторів і стрибками потужності.
• Напишіть процедуру рознесення завантаження і відрепетируйте її. Після відключення не час виявляти, що ваші інструменти не вміють секвенувати.
• Оновіть вимоги до закупівель: вимагайте метровані PSU/BMC сенсори де можливо і просіть вендорів описати поведінку в режимі одного PSU.
• Повторно перевіряйте після оновлень прошивки. Підходьте до «незначних ревізій» як до нових моделей, поки не виміряєте їх.

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

Що таке шурхіт насправді: пропущені дедлайни, а не «поганий звук»

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

• Клацання/потріскування: короткі недоопрацювання—відсутні семпли.
• Затирання (stutter): повторні недоопрацювання або цикли ресинхронізації в Bluetooth.
• Робот/шифрування голосу: дрейф тактування, агресивне пересемплювання або втрата пакетів (часто на Bluetooth).
• Відпади (dropouts): скидання пристрою, події живлення USB або перезапуски драйверів.

Інженерний термін, який ви побачите в інструментах — затримка DPC/ISR:

• ISR (Interrupt Service Routine): швидкий обробник переривань високого пріоритету від апаратури.
• DPC (Deferred Procedure Call): робота, запланована ISR для виконання трохи пізніше, все ще з підвищеним пріоритетом.

Якщо драйвер «жере» час DPC — мережа, GPU, сховище, ACPI, USB — аудіо не зможе запуститися вчасно. Ваше завантаження CPU може бути 10% і при цьому чутися клацання, бо це не про «продуктивність». Це про «латентність під навантаженням».

Перефразована ідея від Werner Vogels (CTO Amazon): Усе ламається; стійкість приходить від проєктування та експлуатації систем, які витримують і відновлюються після помилок.

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

Швидкий план діагностики (робіть у вказаному порядку)

Спочатку: класифікуйте шурхіт

1. Лише на Bluetooth? Перейдіть до Bluetooth‑аудіо та затирання.
2. Лише на USB DAC/гарнітурі? Перейдіть до USB і хаби.
3. Лише в одній програмі (Teams/Discord/гра/DAW)? Перейдіть до Налаштування буферів у додатках.
4. Системно (YouTube + локальне аудіо + сповіщення)? Зазвичай це DPC/драйвер/живлення.

По-друге: вимірюйте затримку, не орієнтуйтесь на відчуття

1. Запустіть інструмент для DPC (LatencyMon — найпоширеніший) і відтворіть шурхіт.
2. Якщо він вказує на драйвер: не видаляйте все підряд. Підтвердіть зміною конкретних пристроїв (див. завдання нижче).

По-третє: приберіть три головні підозри у безпечному порядку

1. План живлення: переключіться на стабільний план, вимкніть USB selective suspend, протестуйте.
2. Мережа: тимчасово вимкніть Wi‑Fi, потім відключіть NIC offloads, потім оновіть/відкатайте драйвер.
3. GPU/аудіо (HDMI): відключіть невикористовувані «NVIDIA/AMD High Definition Audio» кінцеві точки, оновіть GPU‑драйвер чистою інсталяцією.

По-четверте: зафіксуйте відому‑добру аудіо конфігурацію

1. Встановіть 48 kHz (або 44.1 kHz, якщо ваш робочий процес орієнтований на музику), 24‑біт.
2. Вимкніть enhancements, вимкніть spatial, перевірте exclusive mode ввімкненим/вимкненим залежно від сценарію.

По-п’яте: якщо це USB — ставтеся до нього як до шини, а не як до кабелю

1. Перенесіть DAC/гарнітуру в інший порт (передня панель vs задня, контролер USB 2 vs USB 3).
2. Вилучіть хаби/доки. Тестуйте пряме підключення.
3. Вимкніть USB selective suspend і забороніть Windows вимикати пристрій для економії енергії.

Зупиніться, коли шурхіт зникне. Далі починається культ оптимізації: правки реєстру та «latency optimizer»‑програми, що часто погіршують ситуацію.

Цікаві факти та коротка історія (чому це повторюється)

• Аудіо в Windows раніше змішувалося в ядрі в старіших версіях; сучасний Windows переніс мікшування в user mode (WASAPI) для стабільності та безпеки, але драйвери все ще мають значення.
• Сплески затримки DPC не новина; вони відомі професійним аудіокористувачам щонайменше з ери Windows XP.
• 48 kHz стало «дефолтом» здебільшого через відео/ТВ стандарти; багато PC‑аудіопайплайнів припускають 48 kHz навіть для музичних джерел у 44.1 kHz.
• ACPI енергоменеджмент став розумнішим (і складнішим) з роками — корисно для батареї, але іноді погано для реальних тайм‑дедлайнів аудіо.
• USB‑аудіо — isochronous — воно резервує пропускну здатність і очікує вчасної доставки; якщо контролер хоста затримується, ви чуєте це негайно.
• Драйвери Wi‑Fi часто винні через сплески, переходи в енергозбереження та інтенсивні переривання.
• GPU‑драйвери можуть блокувати систему таким чином, що це не видно як «високе завантаження CPU» в Диспетчері завдань, бо час витрачається на підвищеному IRQL в DPC/ISR.
• Bluetooth‑аудіо — втратне і з буфером; воно створене для маскування відпадів через буферизацію, але Windows плюс радіоперешкоди можуть все одно спричинити чутні артефакти.
• «Enhancements» — це DSP‑плагіни (APO), вставлені в пайплайн; деякі баговані, деякі додають затримку, деякі просто конфліктують зі змінами частоти дискретизації.

Практичні завдання: команди, виводи та рішення (12+)

Ці команди розраховані на звичайний комп’ютер з Windows 11 і вбудованими засобами. Я використовую PowerShell і стандартні утиліти. Кожне завдання включає: команду, приклад виводу, що це означає та яке рішення прийняти.

Завдання 1: Визначте аудіо‑кінцеві точки та їх стан

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class AudioEndpoint | Select-Object Status,FriendlyName,InstanceId | Format-Table -AutoSize"
Status FriendlyName                                   InstanceId
------ ------------                                   ----------
OK     Speakers (Realtek(R) Audio)                    SWD\MMDEVAPI\{0.0.0.00000000}.{...}
OK     Headphones (USB Audio DAC)                     SWD\MMDEVAPI\{0.0.0.00000000}.{...}
OK     NVIDIA High Definition Audio                   SWD\MMDEVAPI\{0.0.0.00000000}.{...}

Значення: Ви бачите кожну відтворювальну кінцеву точку, яку Windows надає, включаючи HDMI/DP‑аудіо з GPU.

Рішення: Якщо ви ніколи не користуєтесь «NVIDIA High Definition Audio» (або аналогом AMD), заплануйте відключення цієї кінцевої точки, щоб зменшити площу атаки драйверів.

Завдання 2: Перелік фактичних аудіо‑пристроїв (драйверів) за кінцевими точками

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Sound,VideoAndGameControllers | Select-Object Status,FriendlyName,InstanceId | Format-Table -AutoSize"
Status FriendlyName                 InstanceId
------ ------------                 ----------
OK     Realtek(R) Audio             HDAUDIO\FUNC_01&VEN_10EC&DEV_...
OK     USB Audio DAC                USB\VID_1234&PID_5678\...
OK     NVIDIA Virtual Audio Device  ROOT\...

Значення: Це драйвери в режимі ядра, які можуть впливати на поведінку DPC.

Рішення: Якщо у вас декілька аудіостеків (Realtek + USB + віртуальні пристрої GPU), спростіть: відключіть те, чим ви не користуєтесь під час діагностики.

Завдання 3: Швидка перевірка плану живлення CPU (типова причина шурхотів)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Значення: «Balanced» часто дозволяє агресивне енергозбереження (особливо на ноутбуках).

Рішення: Для тесту перемкніться на «Високу продуктивність» або «Ultimate Performance» (якщо доступно). Якщо шурхіт зникає — корінь проблеми в енергоменеджменті, а не в «аудіо‑залізі».

Завдання 4: Переключитись на Високу продуктивність (тест, не закріплюйте назавжди)

cr0x@server:~$ powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Значення: Ви кажете Windows віддавати пріоритет продуктивності й зменшити кількість станів сну.

Рішення: Перевірте аудіо за своїм найважчим навантаженням (гра + Discord + браузер). Якщо стабільно, згодом ми налаштуємо кастомний план замість постійного використання «Високої продуктивності».

Завдання 5: Перевірте налаштування USB selective suspend

cr0x@server:~$ powercfg /qh SCHEME_CURRENT SUB_USB | findstr /i "Selective Suspend"
    USB selective suspend setting  (GUID: 2a737441-1930-4402-8d77-b2bebba308a3)
      Current AC Power Setting Index: 0x00000001
      Current DC Power Setting Index: 0x00000001

Значення: Значення 1 зазвичай означає «Увімкнено».

Рішення: Якщо ви використовуєте USB‑аудіо, вимкніть selective suspend для діагностики (особливо на ноутбуках і доках).

Завдання 6: Вимкнення USB selective suspend (AC + DC)

cr0x@server:~$ powercfg /setacvalueindex SCHEME_CURRENT SUB_USB 2a737441-1930-4402-8d77-b2bebba308a3 0
cr0x@server:~$ powercfg /setdcvalueindex SCHEME_CURRENT SUB_USB 2a737441-1930-4402-8d77-b2bebba308a3 0
cr0x@server:~$ powercfg /S SCHEME_CURRENT

Значення: Порти USB менше ймовірно будуть вимикатися для економії енергії в невідповідний момент.

Рішення: Якщо це усуває клацання на USB DAC/гарнітурі, тримайте цю опцію вимкненою (або вимкніть тільки на AC, якщо вам важлива батарея).

Завдання 7: Знайти ризики «вимкнути цей пристрій» для USB хабів/контролерів

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class USB | Where-Object {$_.FriendlyName -match 'Hub|Controller'} | Select-Object Status,FriendlyName | Format-Table -AutoSize"
Status FriendlyName
------ ------------
OK     USB Root Hub (USB 3.0)
OK     Generic USB Hub
OK     USB xHCI Compliant Host Controller

Значення: Ви перелічили інфраструктуру, від якої може залежати аудіо.

Рішення: Для хабів/контролерів перевірте Диспетчер пристроїв → вкладка «Power Management» і зніміть «Allow the computer to turn off this device to save power». (Немає універсального CLI‑перемикача для всіх драйверів.)

Завдання 8: Визначте NIC (мережеві адаптери — класичні DPC‑злочинці)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,InterfaceDescription,LinkSpeed | Format-Table -AutoSize"
Name   Status InterfaceDescription                     LinkSpeed
----   ------ --------------------                     ---------
Wi-Fi  Up     Intel(R) Wi-Fi 6E AX211                 1.2 Gbps
Ethernet Up   Realtek PCIe GbE Family Controller      1 Gbps

Значення: Тепер ви знаєте, які адаптери можна тимчасово відключити для тесту.

Рішення: Якщо шурхіт корелює з мережею (завантаження, дзвінки Teams), спочатку протестуйте з вимкненим Wi‑Fi.

Завдання 9: Тимчасово вимкніть Wi‑Fi, щоб ізолювати вплив драйвера

cr0x@server:~$ powershell -NoProfile -Command "Disable-NetAdapter -Name 'Wi-Fi' -Confirm:\$false"

Значення: Ви прибрали велике джерело переривань із системи.

Рішення: Якщо аудіо стало ідеальним одразу — вам не потрібен новий DAC. Потрібен фікс Wi‑Fi драйвера/налаштувань (оновлення/відкат, вимкнення енергозбереження, тонке налаштування offloads).

Завдання 10: Перевірте дати встановлення драйверів (шукайте недавні «корисні» оновлення)

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceClass -in 'MEDIA','NET'} | Select-Object DeviceName,DriverVersion,DriverDate | Sort-Object DriverDate -Descending | Select-Object -First 10 | Format-Table -AutoSize"
DeviceName                           DriverVersion  DriverDate
----------                           -------------  ----------
Intel(R) Wi-Fi 6E AX211              23.40.0.4      2025-01-15
Realtek(R) Audio                     6.0.9652.1     2024-12-02
NVIDIA High Definition Audio         1.4.0.1        2024-11-20

Значення: Ви можете зв’язати початок шурхоту з оновленнями драйверів.

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

Завдання 11: Перевірте здоров’я аудіосервісів Windows (рідко, але швидко)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Audiosrv,AudioEndpointBuilder | Format-Table -AutoSize Name,Status,StartType"
Name                 Status StartType
----                 ------ ---------
Audiosrv             Running Automatic
AudioEndpointBuilder Running Automatic

Значення: Якщо ці сервіси зупинені або скакають — у вас інша проблема, не DPC‑латентність.

Рішення: Якщо вони не Running — відновіть стан сервісу спочатку (і перевірте Event Viewer, чому він зупиняється).

Завдання 12: Витягніть системні журнали подій щодо аудіо/скидань драйверів

cr0x@server:~$ powershell -NoProfile -Command "wevtutil qe System /q:\"*[System[(Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 86400000]]]\" /f:text /c:40"
Event[0]:
  Log Name: System
  Source:   Kernel-PnP
  Level:    Error
  ...
  Message:  The device USB\VID_1234&PID_5678... was not migrated due to partial or ambiguous match.

Значення: Kernel‑PnP, USB і помилки драйверів за останні 24 години часто є явними підказками для відпадів.

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

Завдання 13: Перевірте, який процес «жере» CPU у момент шурхоту (перевірка здорового глузду)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 8 Name,Id,CPU,WorkingSet | Format-Table -AutoSize"
Name            Id    CPU WorkingSet
----            --    --- ----------
chrome        1040  812.4  950000000
dwm           1880  210.1  240000000
audiodg       1324   45.7   65000000

Значення: Це не DPC‑вимірювання, але ловить очевидні сценарії «CPU реально завантажений» (паблік із браузерною вкладкою, що шалено працює).

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

Завдання 14: Підтвердіть, що тиск пам’яті не викликає пейджинг під час аудіо

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Memory\Available MBytes','\Memory\Pages/sec' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -AutoSize"
Path                       CookedValue
----                       -----------
\Memory\Available MBytes        5120
\Memory\Pages/sec                 3

Значення: Дуже мало вільної пам’яті плюс високий Pages/sec можуть спричиняти непередбачувані «пасти» системи.

Рішення: Якщо Available MB дуже мало і Pages/sec постійно високий під час шурхоту — закрийте програми або виправляйте витік пам’яті. Не романтично, але ефективно.

Завдання 15: Захопіть короткий perf‑трейс для доказів DPC/ISR (вбудовано)

cr0x@server:~$ wpr -start generalprofile
cr0x@server:~$ powershell -NoProfile -Command "Start-Sleep -Seconds 20"
cr0x@server:~$ wpr -stop C:\Temp\audio-latency.etl
WPR: Tracing session stopped.
WPR: Trace file saved to C:\Temp\audio-latency.etl

Значення: Ви створили ETL‑трейс, який можна відкрити в Windows Performance Analyzer, щоб побачити використання CPU по DPC/ISR і які драйвери винні.

Рішення: Якщо LatencyMon не дає чіткої відповіді (або потрібен доказ), цей трейс дозволяє припинити сперечатися з відчуттями і вказати на конкретні драйвери.

Тріаж драйверів: типові підозрювані та як це довести

Більшість інцидентів «клацання в Windows 11» — це не сам аудіодрайвер. Аудіодрайвер — перший, кого звинувачують, бо його чутно. Звичайні підозрювані:

• Wi‑Fi драйвери (шторми переривань, переходи в енергозбереження).
• GPU драйвери (сплески DPC, невикористовувані HDMI‑аудіо кінцеві точки).
• Драйвери сховища (рідше, але трапляється з дивними RAID/фільтр драйверами).
• ACPI / чіпсет (платформний енергоменеджмент, поведінка таймерів).
• USB контролери (проблеми драйвера host controller, selective suspend).
• APO‑ефекти (audio enhancements) (DSP‑плагіни від OEM‑пакетів).

Що означає «виправити драйвери» насправді

«Оновити драйвер» іноді правильно, а іноді ви створюєте нову проблему. У виробничому підході: драйвери — це модулі ядра; ставтеся до них як до ризикових деплойментів.

• Якщо шурхіт почався після Windows Update або оновлення OEM: відкат — дійсна міра пом’якшення.
• Якщо у вас дуже старий драйвер: оновлення може виправити відомі баги DPC.
• Якщо ви на ноутбучних OEM‑стеках: «найновіший generic драйвер» може прибрати OEM‑налаштування і порушити визначення роз’ємів або масиви мікрофонів.

Вимикайте те, чим не користуєтесь (зменшуйте площу ураження)

Аудіо‑кінцеві точки, якими ви не користуєтесь, все одно завантажують компоненти і можуть опитуватись. Вимкнення невикористаних HDMI‑аудіо кінцевих точок NVIDIA/AMD — одне з найбезпечніших рішень «менше процесів = менше проблем».

Та сама логіка для OEM‑«ефектів». Якщо вони вам не потрібні — вимкніть enhancements. Ваші вуха потребують стабільності, не віртуальної концертної зали.

Жарт #1: Клацання аудіо у Windows — це просто ваш ПК, що намагається додати перкусію до плейлиста. Воно не найняте, тож звільніть його.

Енергоменеджмент: тихий генератор шурхотів

Енергозбереження працює, даючи обладнанню заснути, паркуючи ядра CPU і знижуючи тактові частоти. Кожен перехід має затримку. Аудіо ненавидить сплески затримки більше, ніж трохи повільніший CPU.

Найважливіші налаштування

• Мінімальний стан процесора: надто низьке значення може спричиняти швидкі зміни частоти і затримки пробудження.
• PCI Express Link State Power Management: може додавати затримку пробудження для пристроїв за PCIe (включно з деякими аудіошляхами).
• USB selective suspend: може «усипляти» ваш аудіопристрій або хаб у найневідповідніший момент.
• Енергозбереження бездротового адаптера: обмін батареї на сплески латентності.

Мій однозначний принцип

Якщо вам важливе реальне аудіо на ноутбуці з Windows, створіть присвячений «Audio» план живлення. Balanced — для таблиць. High performance — для тестування. Кастомний план — для повсякденного використання.

У корпоративному середовищі часто говорять «ми не можемо змінювати політики живлення». Зазвичай можна: налаштування плану живлення на рівні користувача зазвичай дозволені, навіть якщо BIOS‑зміни закриті.

USB і хаби: де «працює добре» перетворюється на провал

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

• гарнітуру через хаб монітора,
• потім через док,
• потім через контролер USB, спільний з вебкамерою,
• в той час як selective suspend намагається зекономити 0.3 ватта,
• і драйвер генерує DPC‑сплески.

Практична стратегія ізоляції USB

1. Підключайте безпосередньо до ПК. Приберіть хаби/доки.
2. Спробуйте інший контролер. Задні порти зазвичай відрізняються від портів на передній панелі; USB‑C може бути на іншому контролері.
3. Для деяких DAC‑ів віддавайте перевагу USB 2 порту, якщо постачальник рекомендує. Це не «повільніше»; іноді простіше.
4. Вимкніть selective suspend (Завдання 6).
5. Вимкніть «Allow the computer to turn off this device» для хабів/контролерів у Диспетчері пристроїв.

Чого не робити

• Не «вирішуйте» шурхіт купівлею випадкового живленого хабу. Це підкидання монети з додатковими проводами.
• Не думайте, що USB DAC імунний до системної латентності. Шина все одно потребує вчасного обслуговування.

Bluetooth‑аудіо та затирання: затримки з додатковими кроками

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

Типові режими відмов Bluetooth

• Завантаженість 2.4 GHz: Wi‑Fi, мікрохвильовки, шум USB 3, і дешеві донгли все борються в цьому діапазоні.
• Переключення профілю Hands‑Free: гарнітура переходить в HFP/HSP для використання мікрофона і якість падає, іноді з артефактами.
• Енергозбереження: радіо може «дрімати» в невідповідні моменти.
• Проблеми стеку драйверів: OEM‑стеки Bluetooth сильно відрізняються.

Що дійсно допомагає

• Використовуйте 5 GHz Wi‑Fi (або Ethernet), щоб зменшити конкуренцію в 2.4 GHz.
• Розмістіть Bluetooth‑антену/донгл далі від USB 3 портів/кабелів (USB 3 може створювати RF‑шум у діапазоні 2.4 GHz).
• У комунікаційних додатках обирайте правильний пристрій: «Headset» vs «Headphones» має значення.
• Оновіть Bluetooth‑драйвери від OEM/вендора, якщо система використовує комбінований Wi‑Fi/Bluetooth чіпсет.

Жарт #2: Bluetooth‑аудіо — як стендап‑зустріч через готельний Wi‑Fi: працює, доки це справді важливо, потім винаходить нові склади.

Налаштування звуку Windows, які насправді мають значення

Люди часто натискають налаштування в надії, що щось зміниться. Робімо менше кліків, але з розумом.

Встановіть адекватний формат за замовчуванням

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

• Для загального Windows + відео: 48 kHz, 24‑біт.
• Для музичної продукції на 44.1 kHz: 44.1 kHz, 24‑біт і тримайте DAW синхронізованим.

Вимкніть enhancements і spatial audio (для діагностики)

Enhancements — це Audio Processing Objects (APOs). Вони можуть працювати. Але можуть і бути причиною проблем.

Для діагностики: вимкніть enhancements і spatial audio. Якщо шурхіт зникає, вмикайте по одному елементу — як контрольований rollout, а не фестиваль.

Exclusive mode: розумійте, що він робить

Exclusive mode дозволяє додатку говорити безпосередньо з пристроєм, минаючи загальний міксер. Це може зменшити затримку і пересемплювання, але також може:

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

Якщо ви усуваєте системний шурхіт — тестуйте і exclusive увімкнений, і вимкнений. Якщо ви DAW‑користувач — exclusive (або ASIO) часто правильний вибір; для робочого ноутбука з Teams — стабільність спільного режиму важливіша.

Налаштування буферів на рівні додатків і DAW

Якщо шурхіт виникає лише в одній програмі — не поспішайте звинувачувати Windows. Додатки самі обирають розміри буферів, частоти та іноді використовують exclusive mode без попередження.

Браузери та додатки для конференцій

• Teams/Zoom/Discord: вони можуть перемикати пристрої, брати exclusive‑шлях і викликати зміни Bluetooth‑профілів при включенні мікрофона.
• Браузери: апаратне прискорення може змінювати поведінку GPU‑драйвера і опосередковано впливати на сплески латентності.

DAW і професійне аудіо

Якщо ви користуєтесь DAW:

• Почніть з розміру буфера, що віддає перевагу стабільності (256–512 семплів) і зменшуйте лише для запису з моніторингом у реальному часі.
• Використовуйте ASIO‑драйвер вендора, коли є; WASAPI shared mode не найкращий інструмент для низької латентності в продакшені.
• Погоджуйте частоту проєкту з пристроєм, щоб уникати постійного пересемплювання.

Професійне аудіо на Windows може бути стабільним. Просто воно вимагає ставитися до змін драйверів і живлення як до змін у продакшені: по одній, з планом відкату.

Три корпоративні історії з латентних окопів

Інцидент №1: неправильне припущення (і дорога зустріч)

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

IT створили «war room». Команда відтворила проблему: почати демонстрацію, розпочати дзвінок, потім запустити велике завантаження у фоні. Клацання з’являлось гарантовано. Навантаження CPU було низьким. Це важлива деталь; вона виключила «недостатньо потужності».

Вони запустили інструменти латентності і побачили DPC‑сплески, пов’язані з Wi‑Fi драйвером. Ключова деталь: ноутбуки були налаштовані на агресивне енергозбереження Wi‑Fi, щоб продовжити батарею в дорозі. Добре по наміру, але не для демонстрацій. Демонстрації — не сон.

Виправлення не було в гарнітурах. Це була зміна політики: вимкнути агресивне енергозбереження Wi‑Fi на AC, оновити Wi‑Fi драйвер до стабільної версії і заборонити OS віднергозагати адаптер посеред дзвінка. Клацання щезло. Гарнітури стали «необов’язковими» і закупівля тихо припинила масові замовлення.

Урок: аудіопристрій був невинний. Планувальник не винен. Поведінка переривань одного драйвера в конкретному навантаженні — справжня область відмови.

Інцидент №2: оптимізація, що відкотилася (батарея виграла, аудіо програло)

Інша організація — інженерна, багато відеодзвонів — вирішила стандартизувати енергозбереження. Вони розіслали налаштування: зменшили мінімальний стан процесора, зробили selective suspend агресивнішим і оптимізували link‑state. На папері батарея покращилась, і хтось побачив гарні числа у дашборді.

Але черга до служби підтримки стала музичним музеєм: потріскування, затирання, «робот‑голос», особливо у користувачів з USB‑спікерфонами і док‑станціями. Патерн був тонким: гірше після простою. Перший дзвінок дня — ок. Другий після обіду — хаос.

Спочатку звинувачували доки. Заміняли. Все марно. Потім підключили журнали: переходи харчування USB і скидання пристроїв співпали з початком дзвінків. Selective suspend робив свою справу: вимикав частини USB‑ланцюга. Коли аудіо відновлювалось, латентність пробудження і іноді переенумерація створювали відпади.

Виправлення було негарним: вимкнути selective suspend для користувачів з USB‑аудіо на доках і налаштувати живлення по‑іншому на AC vs батареї. Батарея трохи постраждала. Аудіо перестало принижувати людей. Дашборди стали менш зеленими. Протоколи зустрічей стали точнішими.

Інцидент №3: нудна практика, що врятувала день (контроль змін драйверів)

Мала SRE‑команда підтримувала трейдинговий підрозділ, де аудіо важливе для запису дзвінків і відповідності. У них було правило: жодних оновлень драйверів на підлозі без тестової кільцевої групи. Звучало бюрократично, допоки не знадобилось.

Windows Update запропонував новий пакет драйверів GPU. В офісному флоті це би пройшло непомітно. Але тут GPU‑драйвери пов’язані з кількома моніторами, відеодекодингом і — сюрприз — HDMI‑аудіо кінцевими точками. Одна машина у пілотній групі отримала оновлення. Через кілька годин пілот повідомив про періодичні пліки при переміщенні вікон між моніторами під час дзвінка.

Команда захопила трейс (WPR) і побачила DPC‑сплески, пов’язані з шляхом GPU драйвера під час переконфігурації дисплея. Вони відкотили драйвер на пілотній машині, перевірили стабільність і заблокували оновлення для ширшого кола, поки не протестували іншу версію.

Без героїзму. Без ночних чергувань. Просто поетапний rollout і відкат. Практика була нудною — і саме тому спрацювала. Продуктивне аудіо залишилось чистим. Compliance нікого не турбувала. Пілот отримав каву і легку вдячність — емоційний максимум для такого середовища.

Типові помилки: симптом → корінь → виправлення

Клацання лише під час завантаження або дзвінків

• Симптом: Аудіо пшикає під час мережевої активності; в іншому — ок.
• Корінь: NIC/Wi‑Fi драйвер — DPC‑сплески, offloads, переходи енергозбереження.
• Виправлення: Оновіть/відкотіть NIC‑драйвер, вимкніть агресивне енергозбереження бездротового адаптера, тестуйте з вимкненим Wi‑Fi (Завдання 9), віддавайте перевагу Ethernet для дзвінків.

USB‑гарнітура клацає після простою або при підключенні дока

• Симптом: Перше аудіо після простою клацає; док/відкріплення викликає відпади.
• Корінь: USB selective suspend, управління живленням хабів, топологія дока.
• Виправлення: Вимкніть USB selective suspend (Завдання 5–6), вимкніть живлення для хабів, підключіть аудіопристрій безпосередньо або до іншого контролера/порту.

Клацання почалося після оновлення GPU‑драйвера

• Симптом: Потріскування під час ігор, переміщення вікон або перемикання моніторів.
• Корінь: GPU‑драйвер — DPC‑сплески; невикористані HDMI‑аудіо кінцеві точки; оверлеї.
• Виправлення: Чиста інсталяція стабільного GPU‑драйвера, відключення невикористаних GPU‑аудіо кінцевих точок, вимкнення оверлеїв, тестування апаратного прискорення в додатку.

Лише Bluetooth репетує; дротове аудіо чисте

• Симптом: Bluetooth‑аудіо рветься; USB/3.5 мм — чисто.
• Корінь: Перешкоди у 2.4 GHz, перемикання профілю, енергозбереження/драйвер Bluetooth.
• Виправлення: Використовуйте 5 GHz Wi‑Fi, розташуйте донгл подалі від шуму USB 3, переконайтесь у виборі правильної кінцевої точки, оновіть Bluetooth‑драйвери.

Клацання в одній конкретній програмі

• Симптом: DAW клацає при малому буфері; інші програми в порядку.
• Корінь: Буфер занадто малий, невідповідність частот, конфлікт exclusive mode.
• Виправлення: Збільшіть буфер, вирівняйте частоти, використовуйте ASIO, вимкніть інші аудіо‑додатки, тестуйте exclusive mode.

Клацання при увімкнених «enhancements»

• Симптом: Увімкнення spatial/enhancements погіршує потріскування.
• Корінь: Багований APO/DSP, додаткова обробка, затримка.
• Виправлення: Вимкніть enhancements/spatial; якщо вони потрібні — оновіть OEM‑пакет і вмикайте ефекти по одному.

Клацання незважаючи на низький CPU і «все оновлено»

• Симптом: Диспетчер завдань спокійний; аудіо все одно клацає.
• Корінь: Висока DPC/ISR‑витрата часу (пріоритет ядра), не видно в юзер‑CPU.
• Виправлення: Вимірюйте Latency за допомогою інструментів; ізолюйте відключенням пристроїв по черзі; використайте WPR‑трейс (Завдання 15) для ідентифікації драйвера.

Чеклісти / покроковий план

Чекліст A: 20‑хвилинний план «зробіть так, щоб перестало»

1. Відтворіть шурхіт на вимогу (та сама пісня/відео, такий самий гучність, те саме навантаження).
2. Переключіться на Високий план живлення (Завдання 4). Повторіть тест.
3. Вимкніть USB selective suspend (Завдання 6). Повторіть тест (особливо для USB‑аудіо).
4. Тимчасово вимкніть Wi‑Fi (Завдання 9). Повторіть тест з локальним аудіо.
5. Вимкніть невикористані аудіо кінцеві точки (GPU HDMI, віртуальні пристрої) в Диспетчері пристроїв. Повторіть тест.
6. Вимкніть enhancements/spatial для активного пристрою відтворення. Повторіть тест.
7. Встановіть формат за замовчуванням 48 kHz 24‑біт (або під свій робочий процес). Повторіть тест.
8. Якщо Bluetooth: тимчасово перейдіть на дріт, щоб підтвердити, що це радіо‑проблема.

Чекліст B: Стабілізація без постійного High performance

1. Клонувати поточний план у власний «Audio» план.
2. На AC: підвищити мінімальний стан процесора, вимкнути USB selective suspend, зменшити PCIe link‑state power saving.
3. На батареї: зберегти розумні дефолти, але уникати найагресивнішого енергозбереження бездротового адаптера, якщо ви приймаєте дзвінки на батареї.
4. Задокументувати версії драйверів, що стабільні (Wi‑Fi, GPU, аудіо, чіпсет).
5. Після кожного циклу Windows Update: повторно перевірити 5‑хвилинним аудіотестом.

Чекліст C: Коли потрібні докази (для IT, вендорів або майбутнього вас)

1. Захопіть WPR‑трейс під час шурхоту (Завдання 15).
2. Експортуйте відповідні системні журнали подій по часових мітках (Завдання 12).
3. Запишіть: використовуваний пристрій (USB/Bluetooth/вбудований), стан живлення (AC/DC) і активну мережу (Wi‑Fi/Ethernet).
4. Зробіть одну зміну. Повторіть тест. Ведіть нотатки.

FAQ

1) Чому аудіо клацає при низькому завантаженні CPU?

Бо проблема зазвичай у затримці DPC/ISR, а не в середньому завантаженні CPU. Драйвер може коротко блокувати важливі шляхи і спричиняти underrun буфера.

2) Чи обов’язковий LatencyMon?

Ні, але він зручний. Ви також можете використати вбудований WPR/WPA‑трейс (Завдання 15), щоб побачити поведінку DPC/ISR і знайти проблемні драйвери.

3) Чи варто вимкнути «audio enhancements»?

Для діагностики — так. Enhancements — DSP‑компоненти, що можуть додавати затримку або бути багованими. Якщо вимкнення вирішує проблему — вмикайте тільки потрібні ефекти.

4) Яку частоту дискретизації обрати: 44.1 чи 48 kHz?

Для загального Windows і відео 48 kHz зазвичай найменш несподівана. Для музичного проєкту на 44.1 kHz встановіть пристрій і проєкт на 44.1 kHz, щоб зменшити пересемплювання.

5) Чи вирішить купівля зовнішнього USB DAC завжди клацання?

Ні. Він може покращити аналоговий шум і обійти поганий вбудований кодек, але не вирішить DPC‑затримки або проблеми з USB‑енергозбереженням.

6) Чому Bluetooth гірший за дріт?

Bluetooth додає радіоперешкоди, буферизацію кодеків і перемикання профілів (особливо при активному мікрофоні). Дротові шляхи прибирають ці класи помилок.

7) Чи варто використовувати «Ultimate Performance»?

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

8) Який найшвидший спосіб ізолювати проблемний драйвер?

Вимикайте пристрої по черзі: Wi‑Fi, Bluetooth, невикористані GPU‑аудіо кінцеві точки, доки/хаби. Для надійних доказів захопіть WPR‑трейс і проаналізуйте DPC/ISR за драйвером.

9) Я чую клацання лише в іграх — що спробувати спочатку?

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

10) Чи може сховище спричинити клацання аудіо?

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

Наступні кроки (нудний стабільний стан)

Якщо ви хочете аудіо без шурхоту в Windows 11 без покупки обладнання, виграшний крок — це не магічна опція. Це дисциплінований цикл:

1. Відтворіть проблему надійно. Якщо не можна відтворити — ви не можете виправити, лише перемістити проблему.
2. Вимірюйте затримку, не вгадуйте. Використовуйте інструменти латентності або WPR‑трейс за потреби.
3. Стабілізуйте живлення. Кастомний «Audio» план кращий за постійний «High performance».
4. Спрощуйте драйвери. Вимикайте те, чим не користуєтесь; оновлюйте або відкачуйте «винного».
5. Тримайте USB простим. Прямі порти, без хабів, без selective suspend для USB‑аудіо.
6. Змінюйте одне за раз. Ви налагоджуєте, а не виконуєте ритуал.

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

Що ви насправді будуєте (і чому це перегріває ноутбуки)

На Windows із WSL2 «запуск Kubernetes» рідко означає лише «запуск Kubernetes».
Це стек вкладених абстракцій, кожна з яких має власні уявлення про планування CPU, звільнення пам’яті, семантику файлової системи та мережу.
Коли будь-який шар помиляється, вашим ноутбуком розплачуються.

Типове налаштування Kubernetes на WSL2 виглядає так:

• Операційна система Windows (хост)
• VM WSL2 (легка Hyper-V VM з віртуальним диском)
• Дистрибутив Linux userland (Ubuntu, Debian тощо)
• Рuntime контейнерів (Docker Engine, containerd або стек nerdctl)
• Дистрибуція Kubernetes (kind, k3d, minikube, microk8s або інтегрований кластер Docker Desktop)
• Ваші робочі навантаження: бази даних, оператори, конвеєри збірки, ingress-контролери, service mesh — тобто «малий продакшн»

Перегрів зазвичай походить з одного з трьох місць:

1. Пам’ять: WSL2 охоче кешує сторінки і не завжди швидко їх віддає. Kubernetes розподіляє поди, поки вузол «здається» нормальним, аж поки це перестає бути правдою.
2. Зберігання: перетин кордону між Windows і Linux-файловими системами може перетворити нормальний I/O у повільний інцидент. Бази даних підсилюють проблему через fsync і дрібні випадкові записи.
3. Мережа/DNS: kube-dns, Windows DNS, віртуальні мережеві інтерфейси WSL2 та клієнти VPN утворюють трикутник суму.

Мета — не «зробити блискавично швидко в бенчмарках». Мета — «зробити передбачувано достатньо швидко»,
і що важливіше, зробити режими відмов очевидними.
Надійність у деві важлива, бо дев — це місце, де ви вирішуєте, про що потім пошкодуєте у проді.

Кілька фактів і історичний контекст (щоб дивні речі були зрозумілі)

Це коротко з наголосом на потрібному. Це оновлення ментальної моделі, що заощаджує години пошуку примар.

1. WSL1 був трансляцією системних викликів; WSL2 — справжнє ядро Linux у VM. Саме тому WSL2 може правильно запускати Kubernetes, але й поводиться як VM з власними дисковими й пам’ятними політиками.
2. WSL2 за замовчуванням зберігає файли Linux у віртуальному диску (VHDX). Цей диск може швидко рости і не завжди зменшується, поки ви явно не компактнете його.
3. Доступ до файлів Linux з Windows — не те саме, що доступ до Windows з Linux. Характеристики продуктивності дуже відрізняються, і повільний шлях вдарить по базах даних і збірках образів.
4. Kubernetes не був створений для ноутбуків. Він про кластери, де «вузол — це корівна VM», і можна спалювати CPU на циклах реконциляції, не чутливо до вентиляторів.
5. kind запускає Kubernetes у Docker-контейнерах. Це чудово для відтворюваності, але додає ще один шар, де зберігання і мережа можуть стати «креативними».
6. k3s (і відповідно k3d) створено як легковаговий варіант. Він використовує SQLite за замовчуванням, що підходить локально, але все одно навантажує диск при великій кількості контролерів.
7. cgroups v2 змінив поведінку ізоляції ресурсів. Багато розмов «чому ігнорується ліміт пам’яті?» насправді про режим cgroup.
8. DNS — топова причина відмов у локальних кластерах. Не тому, що DNS складний, а тому, що корпоративні VPN і split-horizon DNS можуть непомітно все перекреслити.
9. Збірка образів карає за метадані файлової системи. Різниця між швидкою файловою системою і «переправленою» стає очевидною при багатоступеневих збірках з тисячами дрібних файлів.

Виберіть локальний Kubernetes: kind vs k3d vs minikube (і що я рекомендую)

Моя стандартна рекомендація: kind у WSL2 з обмеженнями

Для більшості розробників і SRE, що працюють з платформою, kind дає відтворюваність, швидкість і чисте знищення середовища.
Кластер — «просто контейнери», і ви можете зафіксувати версію Kubernetes легко.
Ключ — обмежити ресурси WSL2 і тримати робочі навантаження на файловій системі Linux.

Коли віддати перевагу k3d (k3s у Docker)

Якщо ваша ціль — «запустити практичний дев-платформений стек з мінімальними накладними витратами», k3d відмінний вибір.
k3s обрізає зайве: менше компонентів, менше пам’яті. Він більш поблажливий на менших ноутбуках.
Також він ближчий до того, що часто використовують на edge-пристроях, що корисно, якщо ви деплоїте в обмежені середовища.

Коли використовувати minikube

minikube підходить, коли ви хочете «один інструмент для багатьох драйверів».
Але на WSL2 minikube може загнати вас у плутанину драйверів: Docker driver, KVM (зазвичай ні), Hyper-V (по стороні Windows),
і тоді ви почнете дебажити драйвер більше, ніж кластер.
Якщо ви вже комфортно користуєтеся Docker всередині WSL2, Docker driver minikube придатний.

Чого уникати (якщо немає вагомої причини)

• Запускати важкі stateful навантаження на /mnt/c і потім звинувачувати Kubernetes у повільності. Це не Kubernetes; це межа файлових систем, яка просить припинити.
• Перевиділяти CPU та RAM «бо це локально». WSL2 це прийме, Windows відповість, а ваш браузер програє.
• Намагатися робити «як у проді» з усім увімкненим. Service mesh + розподілене трасування + три оператори + база даних + CI — це не дев-кластер; це хобі-центр обробки даних.

Короткий жарт, як обіцяно: Kubernetes схожий на кухню з 30 шефами — ніхто не готує швидше, але всі роблять звіт.

Базові положення WSL2: ліміти, ядро та речі, про які Windows не скаже

Встановіть обмеження WSL2 або прийміть хаос

За замовчуванням WSL2 буде масштабувати використання пам’яті до значної частини вашого системного ОЗП.
Це не злий намір. Це Linux робить свої Linux-справи — використовує пам’ять під кеш.
Проблема в тому, що Windows не завжди повертає цю пам’ять у спосіб, який відчувається ввічливо.

Покладіть файл .wslconfig у ваш профіль користувача Windows (на стороні Windows).
Потрібен верхній ліміт пам’яті та CPU, і бажано swap, який існує, але не замінює RAM.

cr0x@server:~$ cat /mnt/c/Users/$WINUSER/.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
localhostForwarding=true

Рішення: Якщо у вас 16GB RAM загалом, 8GB для WSL2 зазвичай розумно.
Якщо 32GB — можна 12–16GB. Більше зазвичай приховує витоки та погані межі подів.

Поведінка звільнення пам’яті WSL2: використайте наявні інструменти

У WSL2 поліпшили звільнення пам’яті, але іноді вона все ще прилипає після важких збірок або зміни кластерів.
Якщо потрібно швидко повернути пам’ять, вимкнення WSL — грубий, але дієвий інструмент.

cr0x@server:~$ wsl.exe --shutdown
...output...

Що означає вивід: Відсутність виводу — нормально. Це зупиняє всі дистрибутиви WSL і VM WSL2.
Рішення: Використовуйте це, коли Windows стискає пам’ять і потрібно повернути її негайно, а не під час налагодження проблем у кластері.

Використовуйте systemd у WSL2 (якщо доступно) і будьте явними

Сучасний WSL підтримує systemd. Це робить запуск Docker/containerd і інструментів Kubernetes менш незграбним.
Перевірте, чи увімкнено systemd.

cr0x@server:~$ ps -p 1 -o comm=
systemd

Що означає вивід: Якщо PID 1 — systemd, ви можете використовувати звичайне управління сервісами.
Якщо інше (наприклад, init), доведеться керувати демонами по-іншому.
Рішення: Віддавайте перевагу WSL з systemd для стабільності і менше «чому це не запустилося?» загадок.

Зберігання в WSL2: різниця між «працює» і «не ненавидить вас»

Правило №1: тримайте дані Kubernetes у файловій системі Linux

Розміщуйте стан кластера, образи контейнерів і дані персистентних томів у файловій системі дистрибутива Linux (наприклад, /home, /var).
Уникайте розміщення інтенсивних записів на /mnt/c.
Шар інтеграції може підходити для редагування коду, але це пастка для баз даних і всього, що інтенсивно викликає fsync.

Правило №2: зрозумійте, куди йдуть байти

Docker/containerd зберігає образи й writable-леєри десь під /var/lib.
kind і k3d додають власні шари.
Якщо ви багато будуєте образів або запускаєте CI-подібні навантаження, ваш VHDX ростиме. Він може не зменшуватись.
Це не моральний дефект; так працюють віртуальні диски.

Правило №3: вимірюйте I/O нудним способом

Вам не потрібні спеціальні інструменти зберігання, щоб помітити великі проблеми. Потрібні два порівняння:
продуктивність файлової системи Linux і продуктивність Windows-монту.
Якщо одна швидкість у 10 разів менша, не «налаштовуйте Kubernetes». Перенесіть навантаження.

cr0x@server:~$ dd if=/dev/zero of=/home/cr0x/io-test.bin bs=1M count=512 conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.24 s, 433 MB/s

Що означає вивід: Це грубий послідовний запис з флашем. Сотні MB/s очікувані на SSD.
Рішення: Якщо це однозначні MB/s, ваша VM під I/O тиском або диск має проблеми. Виправляйте це перед Kubernetes.

cr0x@server:~$ dd if=/dev/zero of=/mnt/c/Users/$WINUSER/io-test.bin bs=1M count=256 conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 12.8 s, 21.0 MB/s

Що означає вивід: Якщо ви бачите таке падіння, це шлях інтеграції.
Рішення: Не розміщуйте /var/lib/docker, /var/lib/containerd або каталоги PV на /mnt/c.
Тримайте там код, якщо потрібно, але кеші збірки та бази даних — у Linux-просторі.

Зростання VHDX: компактування — це обслуговування, а не одноразовий фікс

Якщо ваш віртуальний диск WSL2 виріс через збірки образів і churn, ви можете його компактнути — але це не автоматично.
Спочатку очистіть всередині Linux: видаліть невикористані образи, prune томи, очистіть кеші.
Потім компактніть зі сторони Windows. Конкретні кроки відрізняються в залежності від збірки Windows і інструментів, але принцип постійний:
видаліть невикористані блоки в гості, потім скажіть хосту компактнути.

Суха правда: локальні кластери створюють дані. Вони рідко їх видаляють так агресивно, як ви думаєте.
Якщо ставитись до дев-середовища як до продакшену, треба планувати обслуговування як у проді. Ось така угода.

Мережа: NodePorts, ingress, DNS і пастка localhost

Localhost — це не філософія; це рішення маршрутизації

У WSL2 «localhost» може означати localhost Windows або localhost WSL залежно від того, як запущено процес.
З localhostForwarding=true WSL може форвардити порти на Windows, але це не магія для всіх шаблонів трафіку.

Якщо ви запускаєте kind у WSL2 і відкриваєте сервіс через NodePort, ви часто будете звертатися до нього з Windows через форвард порти
або звертаючись до IP VM WSL. Обидва способи можуть працювати. Важливо бути послідовним і документувати, який метод використовує ваша команда.

DNS: мовчазний вбивця kubectl

Багато скарг «Kubernetes повільний» насправді — це таймаути DNS.
kubectl виглядає так, ніби завис, але чекає на виклики API-сервера, які ніяк не розв’язуються.
VPN-клієнти ускладнюють це, впроваджуючи резолвери або змушуючи split DNS.

Ваше завдання — відокремити «API-сервер повільний» від «розв’язування імен повільне» менш ніж за п’ять хвилин.
Потім можна сперечатися з корпоративним VPN.

Практичні завдання (команди, виводи та рішення)

Це реальні задачі, які ви виконуватимете при налаштуванні та під час налагодження.
Кожна містить, що означає вивід і яке рішення з нього випливає.
Робіть їх по черзі при створенні нового середовища; вибірково — коли все горить.

Завдання 1: Підтвердіть, що ви на WSL2 (не WSL1)

cr0x@server:~$ wsl.exe -l -v
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2

Що означає вивід: VERSION 2 означає справжню Linux-VM. VERSION 1 — трансляцію системних викликів.
Рішення: Якщо у вас VERSION 1, зупиніться і конвертуйте. Kubernetes потребує реальної поведінки ядра.

Завдання 2: Перевірте ядро та режим cgroup

cr0x@server:~$ uname -r
5.15.146.1-microsoft-standard-WSL2

cr0x@server:~$ mount | grep cgroup2
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)

Що означає вивід: cgroup2 змонтований означає єдину ієрархію.
Рішення: Якщо ваше ПО очікує cgroup v1 (старі конфігурації Docker, деякі агенти моніторингу), готуйтеся до сюрпризів.

Завдання 3: Підтвердьте systemd і контроль сервісів

cr0x@server:~$ systemctl is-system-running
running

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

Завдання 4: Підтвердьте здоров’я runtime контейнерів (приклад Docker)

cr0x@server:~$ docker info --format '{{.ServerVersion}} {{.CgroupVersion}}'
24.0.7 2

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

Завдання 5: Швидко виміряйте тиск пам’яті

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       5.9Gi       310Mi       160Mi       1.5Gi       1.3Gi
Swap:          4.0Gi       1.2Gi       2.8Gi

Що означає вивід: available важливіший за free. Використання swap свідчить про тиск.
Рішення: Якщо available менше ~1Gi і swap росте, зменшіть кластер, знизьте ліміти або підвищте пам’ять WSL.

Завдання 6: Перевірте заповненість диска там, де це важливо

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb       250G  180G   71G  72% /

Що означає вивід: Це файловa система вашого дистрибутива, підкріплена VHDX.
Рішення: Вище ~85% заповнення продуктивність і поведінка компактування погіршуються. Обріжте образи і старі PV.

Завдання 7: Встановіть і створіть кластер kind з розумними налаштуваннями

cr0x@server:~$ kind create cluster --name dev --image kindest/node:v1.29.2
Creating cluster "dev" ...
 ✓ Ensuring node image (kindest/node:v1.29.2) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-dev"
You can now use your cluster with:

kubectl cluster-info --context kind-dev

Що означає вивід: Кластер створено, контекст встановлено. StorageClass інстальовано (зазвичай standard).
Рішення: Якщо встановлення CNI зависає, підозрюйте DNS/proxy/VPN або проблеми з підтягуванням образів — не повторюйте спроби бездумно.

Завдання 8: Перевірте живучість кластера та здоров’я компонентів

cr0x@server:~$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:40685
CoreDNS is running at https://127.0.0.1:40685/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

cr0x@server:~$ kubectl get nodes -o wide
NAME                STATUS   ROLES           AGE   VERSION   INTERNAL-IP   OS-IMAGE
dev-control-plane   Ready    control-plane   2m    v1.29.2   172.18.0.2    Debian GNU/Linux 12 (bookworm)

Що означає вивід: API-сервер доступний, вузол Ready, внутрішня IP-адреса призначена.
Рішення: Якщо вузол NotReady — одразу дивіться kubectl describe node і логи CNI — не перевстановлюйте все поки що.

Завдання 9: Знайдіть справжніх споживачів ресурсів (вузли + поди)

cr0x@server:~$ kubectl top nodes
NAME                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
dev-control-plane   620m         15%    2240Mi          56%

Що означає вивід: metrics-server працює (kind часто включає його через addons або ви його встановили).
Рішення: Якщо пам’ять висока в режимі простою — перевірте нав’язливі контролери, витоки dev-зборок або завислий лог-шифтер.

Завдання 10: Перевірка DNS у кластері (дешевий smoke test)

cr0x@server:~$ kubectl run -it --rm dns-test --image=busybox:1.36 --restart=Never -- nslookup kubernetes.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default.svc.cluster.local
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
pod "dns-test" deleted

Що означає вивід: CoreDNS відповідає, service discovery працює.
Рішення: Якщо це таймаутиться, виправте DNS перед тим, як налагоджувати додаток. Додаток невинний, поки не доведено інше.

Завдання 11: Підтвердіть, чи повільний kubectl через мережу або API-латентність

cr0x@server:~$ time kubectl get pods -A
NAMESPACE     NAME                                        READY   STATUS    RESTARTS   AGE
kube-system   coredns-76f75df574-2lq9r                    1/1     Running   0          4m
kube-system   coredns-76f75df574-9x2ns                    1/1     Running   0          4m
kube-system   etcd-dev-control-plane                      1/1     Running   0          4m
kube-system   kindnet-4cdbf                               1/1     Running   0          4m
kube-system   kube-apiserver-dev-control-plane            1/1     Running   0          4m
kube-system   kube-controller-manager-dev-control-plane   1/1     Running   0          4m
kube-system   kube-proxy-4xw26                            1/1     Running   0          4m
kube-system   kube-scheduler-dev-control-plane            1/1     Running   0          4m

real    0m0.312s
user    0m0.127s
sys     0m0.046s

Що означає вивід: 300ms — нормально для локального. Кілька секунд підозрілі — DNS, плутанина контекстів kubeconfig або проблеми API-сервера.
Рішення: Якщо це повільно, запустіть kubectl get --raw /readyz?verbose далі.

Завдання 12: Перевірте готовність API-сервера для реального блокера

cr0x@server:~$ kubectl get --raw='/readyz?verbose'
[+]ping ok
[+]log ok
[+]etcd ok
[+]informer-sync ok
[+]poststarthook/start-apiserver-admission-initializer ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
readyz check passed

Що означає вивід: Якщо etcd або informer sync повільні/відмовляють, контрольна площина — вузьке місце.
Рішення: Повільний etcd часто означає затримку зберігання. Це натяк перевірити диск і уникати крос-файлової I/O.

Завдання 13: Знайдіть под, що «спалює» ваш ноутбук (CPU/пам’ять)

cr0x@server:~$ kubectl top pods -A --sort-by=memory | tail -n 10
default       api-7b7c7d8f6c-9bq5m             1/1     980Mi
observability prometheus-0                      2/2     1210Mi
observability loki-0                            1/1     1530Mi

Що означає вивід: Ви бачите топ-споживачів.
Рішення: Якщо ваш дев-кластер включає Prometheus/Loki за замовчуванням, ви щойно знайшли причину «чому гаряче?».
Зменшіть масштаб, скоротіть ретенцію або використайте легші інструменти локально.

Завдання 14: Перевірте використання диска runtime контейнерів (Docker)

cr0x@server:~$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          42        12        18.4GB    12.1GB (65%)
Containers      19        6         1.2GB     720MB (60%)
Local Volumes   27        9         9.8GB     6.3GB (64%)
Build Cache     124       0         22.6GB    22.6GB

Що означає вивід: Build cache часто — мовчазний пожирач диска.
Рішення: Якщо reclaimable велике, чистіть свідомо. Не чекайте, поки VHDX досягне 95% і все сповільниться.

Завдання 15: Працюйте з prune обережно (і прийміть компроміс)

cr0x@server:~$ docker builder prune --all --force
Deleted build cache objects:
v8m3q8qgk7yq4o0l5u3f7s1m2
...
Total reclaimed space: 22.6GB

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

Завдання 16: Перевірте, чи випадково не запускаєте навантаження на /mnt/c

cr0x@server:~$ kubectl get pv -A -o wide
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE   VOLUMEMODE
pvc-1d2c7f7e-2f5d-4c0d-9a3a-2c6f9d8b1a7c   10Gi       RWO            Delete           Bound    default/db-data           standard                8m    Filesystem

Що означає вивід: Це не показує шлях хоста. У kind провайдер local-path і поведінка provisioning відрізняються.
Рішення: Розгляньте storage class і поведінку provisioner; якщо воно прив’язується до hostPath на Windows-монту, виправте негайно.

Завдання 17: Діагностика kubelet/container через логи вузла (контейнер kind node)

cr0x@server:~$ docker ps --format 'table {{.Names}}\t{{.Status}}' | grep dev-control-plane
dev-control-plane   Up 6 minutes

cr0x@server:~$ docker logs dev-control-plane | tail -n 20
I0205 09:10:12.123456       1 server.go:472] "Kubelet version" kubeletVersion="v1.29.2"
I0205 09:10:15.234567       1 kubelet.go:2050] "Skipping pod synchronization" error="PLEG is not healthy"
...

Що означає вивід: Якщо PLEG нездоровий, kubelet бореться — часто через I/O диска або повільний runtime контейнерів.
Рішення: Перевірте затримки диска, здоров’я runtime і кількість логів.

Завдання 18: Швидка перевірка «штормів логів» (вони можуть бути найгарячішим навантаженням)

cr0x@server:~$ kubectl logs -n kube-system deploy/coredns --tail=20
.:53
[INFO] plugin/reload: Running configuration SHA512 = 7a9b...
[INFO] 10.244.0.1:52044 - 46483 "A IN kubernetes.default.svc.cluster.local. udp 62 false 512" NOERROR qr,aa,rd 114 0.000131268s

Що означає вивід: Деякі DNS-логи — нормальні. Тисячі на секунду — ні.
Рішення: Якщо логи «гарячі», знизьте рівень логування, виправте цикл повторних спроб клієнта або ви заплатите CPU і дисковими записами.

Три корпоративні міні-історії з поля бою

Міні-історія 1: Інцидент через неправильне припущення

Команда, з якою я працював, стандартизувала WSL2 для дев-кластерів, бо це «майже Linux».
Вони тримали репозиторій на файловій системі Windows для зручності IDE, а потім монтували його в контейнери для збірок і тестів.
Здавалося, усе було добре для невеликих сервісів. Потім платформа додала локальний Postgres, контролер і тестовий набір, що запускав міграції при кожному запуску.

Симптом був дивний: міграції іноді займали 30 секунд, іноді 10 хвилин.
Люди звинувачували «накладні витрати Kubernetes» і «той оператор».
Один інженер намагався виправити це, підвищивши ліміти CPU. Стало гірше — більше CPU тільки прискорило досягнення дискового вузького місця.

Неправильне припущення було простим: вони вважали /mnt/c «ще однією файловою системою».
Це не так. Це межа з іншою поведінкою кешування, іншою продуктивністю метаданих і іншою семантикою скидання.
Їхній том бази даних і кеші збірки були на повільному шляху.

Виправлення було непривабливим: перемістити базу даних і кеші збірки у файлову систему Linux, і тримати вихідний код на Windows лише якщо потрібно.
Вони також додали preflight-скрипт, що відмовлявся запускати стек, якщо виявляв PV, спрямовані на /mnt/c.
Продуктивність стабілізувалась миттєво. Ніхто не святкував — отже, це було правильне рішення.

Міні-історія 2: Оптимізація, що обернулася проти

Інша компанія хотіла «швидші локальні кластери», тому заздалегідь підвантажила все: стек спостереження, ingress, cert-manager і кілька операторів.
Ідея була благородна: скоротити час онбордингу, гарантувати однакову базу для всіх, уникнути «працює на моєму ноутбуці».
Вони навіть створили внутрішній скрипт, що створював кластер і встановлював усі чарти за один раз.

Потім почалися тікети. Ноутбуки нагрівалися на нарадах. Тривалість роботи акумулятора впала.
kubectl іноді лагав на кілька секунд. Розробники почали відключати компоненти «тимчасово», що перетворилося на постійний дріфт.
Команда платформи відповіла, підвищивши дефолтні ліміти ресурсів і кількість реплік, бо «парність з продом».

Зворотний ефект виник через фонову роботу контролерів і їхню активність.
Prometheus scraping, Loki ingest, cert-manager reconciliation і цикли операторів — це не безкоштовно.
У реальному кластері цю вартість амортизує кілька серверів. На ноутбуку ви відчуваєте це щоразу, коли вентилятор розкручується.

Виправлення — визначити два профілі: core (ingress + DNS + storage + metrics-server) і full (важкий стек).
Core — за замовчуванням; full — за бажанням для налагодження.
Вони також знизили інтервали скрейпу і ретенцію в локальному режимі. Іронія: онбординг прискорився, бо люди перестали боротись із середовищем.

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

Регульована підприємницька організація (та, що любить таблиці) мала дивно гладкий досвід WSL2 Kubernetes.
Секрет не в досконалому стеку інструментів. Секрет — дисципліна: фіксація версій, відтворюване створення кластера і агресивне прибирання.
Кожен розробник мав той самий образ kind node, ті самі версії чартів і однакові дефолтні ліміти ресурсів.

Вони також мали тижневу рутинну процедуру: prune невикористані образи, видаляти невживані неймспейси і компактувати дев-середовище при потребі.
Це було заплановано, задокументовано і нудно.
Розробники спочатку скаржилися — ніхто не любить «день обслуговування» для ноутбука.

Потім стався день, коли оновлення Windows змінило щось тонке в мережі.
Піворганізації почали отримувати переривчасті DNS-збої.
Команди з різними середовищами мали хаос: різні версії CNI, випадкові kubeconfig, непослідовні локальні DNS-переопреділення.
Дисципліновані команди швидко відтворили проблему і порівняли «яблука з яблуками».

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

Швидкий план діагностики: що перевіряти спочатку, потім, далі

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

Перш за все: чи зазнає хост (Windows + WSL2) навантаження по ресурсам?

1. Перевірте використання пам’яті і swap WSL2: free -h. Якщо available низький і swap росте — ви обмежені пам’яттю.
2. Перевірте заповненість диска: df -h /. Якщо майже повний — усе стає повільнішим і вразливішим.
3. Швидка перевірка I/O: dd ... conv=fdatasync на Linux FS vs /mnt/c. Якщо Linux FS теж повільний — проблема на рівні системи.

Друге: чи здорова контрольна площина Kubernetes або вона застрягла?

1. API readyz: kubectl get --raw='/readyz?verbose'. Якщо перевірки etcd повільні — підозрюйте затримку зберігання.
2. Стан вузлів: kubectl get nodes і kubectl describe node. Якщо NotReady — дивіться CNI і симптоми kubelet.
3. Smoke test CoreDNS: запустіть busybox nslookup. Якщо DNS зламаний — зупиніть притягування додатка у відповідальність.

Третє: яке навантаження справді «спалює» CPU/пам’ять/I/O?

1. Топ-споживачі: kubectl top pods -A --sort-by=memory і --sort-by=cpu.
2. Шторми логів: перевірте логи підозрюваних подів. Висока швидкість запису = тиск на I/O = загальне уповільнення.
3. Частота збірок/образів: docker system df і при потребі prune build cache, якщо він роздувся.

Парафраз ідеї Вернера Фогельса: «Усе ламається, постійно». Будуйте локальне середовище так, щоб відмова була швидко діагностованою, а не загадковою.

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

1) Симптом: вентилятори ноутбука спрацьовують, коли кластер «в режимі простою»

Корінна причина: фонові контролери (стек спостереження, оператори) постійно роблять реконциляцію; або под у crash loop записує логи.

Виправлення: kubectl top pods -A, знайдіть хижака; зменшіть масштаб; скоротіть ретенцію/інтервали скрейпу; виправте crash loop; встановіть розумні requests/limits.

2) Симптом: kubectl іноді виконується 5–30 секунд

Корінна причина: таймаути DNS або втручання VPN-резолвера; іноді kubeconfig вказує на мертвий контекст.

Виправлення: запустіть time kubectl get pods -A, потім kubectl get --raw='/readyz?verbose'. Якщо readyz у порядку, перевірте DNS у кластері. Якщо DNS ламається — вирішіть resolv.conf/policy split DNS або працюйте без VPN для локальних задач.

3) Симптом: Postgres/MySQL у кластері надто повільні

Корінна причина: PV або bind mounts на /mnt/c або іншому повільному кордоні; fsync-інтенсивні навантаження підсилюють це.

Виправлення: тримайте дані PV у файловій системі Linux; використовуйте local-path provisioner, що пише в /var всередині WSL, а не на Windows-монти.

4) Симптом: WSL2 поглинає RAM і ніколи не віддає

Корінна причина: кеш сторінок Linux + поведінка звільнення WSL2; великі збірки і pull образів заповнюють кеш; не задано ліміт пам’яті.

Виправлення: встановіть обмеження у .wslconfig; перезапускайте WSL через wsl.exe --shutdown коли потрібно; зменшіть відбиток кластера і уникайте запуску всього одночасно.

5) Симптом: диск «таємниче» заповнюється

Корінна причина: шари образів контейнерів, build cache, залишкові PV дані і логи; VHDX росте; prune не виконувалися.

Виправлення: docker system df і docker builder prune --all; видаліть невикористані неймспейси/PV; слідкуйте за df -h.

6) Симптом: вузол стає NotReady; поди зависають у ContainerCreating

Корінна причина: CNI зламаний або kubelet/runtime контейнерів страждають через I/O; контейнер kind node нездоровий.

Виправлення: перевірте логи контейнера kind node; перевірте CNI-поди в kube-system; виправте дисковий тиск; відновіть кластер, якщо образ вузла пошкоджено.

7) Симптом: ingress працює з WSL, але не з Windows

Корінна причина: неправильні очікування форвардингу портів; брандмауер Windows/VPN; плутанина між IP WSL і localhost Windows.

Виправлення: оберіть один метод доступу (форвардинг localhost або IP WSL); задокументуйте його; відкрийте ingress з передбачуваним відображенням; перевірте curl з обох сторін.

8) Симптом: збірки всередині контейнерів повільніші за збірки на Windows

Корінна причина: дерево сорсів на Windows-монті; інтенсивні операції з метаданими через межу; антивірус Windows сканує шлях.

Виправлення: тримайте вихідник у файловій системі Linux для збірок; користуйтеся IDE через інтеграцію WSL; виключіть каталоги збірки з AV, якщо політика дозволяє.

Другий і останній короткий жарт: Якщо ваш дев-кластер потребує runbook — вітаю, ви побудували малий продакшен з гіршим фінансуванням.

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

План налаштування (зробіть це одного разу на ноутбук)

1. Встановіть ліміти WSL2 у .wslconfig: обмежте пам’ять і CPU; увімкніть розумний swap.
2. Увімкніть systemd у WSL (якщо підтримується) і стандартизуйте це в команді.
3. Виберіть один runtime: Docker Engine у WSL2 підходить; уникайте змішування Docker Desktop + WSL Docker, якщо вам не до вподоби невизначеність.
4. Виберіть один інструмент Kubernetes: kind (рекомендовано) або k3d. Виберіть і стандартизируйте скрипти створення кластера.
5. Тримайте дані кластера в Linux FS: переконайтеся, що зберігання runtime і PV не на /mnt/c.
6. Визначте профілі: «core» за замовчуванням; «full» — опційно. Ноутбук — не staging.
7. Зафіксуйте версії: image версії kind node, версії чартів і критичних аддонів.

Щоденний робочий список (залишайтесь швидкими і адекватними)

1. Перед важкою роботою: free -h і df -h /. Якщо низько — зробіть prune перш ніж починати.
2. Після важкого дня збірок: docker system df. Якщо build cache величезний — prune.
3. Коли щось здається повільним: спочатку тест DNS і перевірки /readyz, перш ніж щось міняти.
4. Тримайте репозиторій там, де інструменти найшвидші: якщо збірки у Linux — робочу копію тримайте у Linux.

Щотижневий чеклист обслуговування (нудно, але дієво)

1. Prune build cache: docker builder prune --all.
2. Prune невикористані образи і контейнери: docker system prune (обережно: зрозумійте, що видаляється).
3. Видаліть невикористані неймспейси і PV у дев-кластері.
4. Пересоздайте кластер, якщо накопичився дріфт. Розрив і пересоздання — це функція.
5. Поверніть пам’ять, якщо Windows прижимає: wsl.exe --shutdown.

Питання й відповіді

1) Чи використовувати Docker Desktop чи Docker Engine у WSL2?

Якщо ви хочете найпростішу інтеграцію з Windows і в компанії стандартизовано Docker Desktop — це нормально.
Якщо хочете менше рухомих частин і більш передбачувану поведінку Linux — використовуйте Docker Engine у WSL2.
Виберіть одне і дотримуйтеся; змішані налаштування породжують фольклор дебагу.

2) Чому зберігання даних на /mnt/c таке проблемне?

Тому що ви перетинаєте віртуалізаційний/інтероперабельний кордон з різним кешуванням і семантикою метаданих.
Бази даних роблять багато дрібних записів і викликів fsync. Цей шлях карає їх.
Тримайте інтенсивні I/O в Linux-файловій системі і сприймайте /mnt/c як «добре для документів, не для гарячих даних».

3) kind чи k3d: що менше «розплавить» мій ноутбук?

k3d часто вимагає менше пам’яті за замовчуванням, бо k3s компактніший.
kind надзвичайно передбачуваний і легко фіксувати версії. Обидва можуть бути безпечними для ноутбука, якщо навантаження помірне і встановлено ліміти WSL2.
Моя уподобання: kind для роботи з платформою та імітації мультивузловості; k3d для «просто запустити стек».

4) Скільки RAM виділити WSL2?

На 16GB всього: 6–8GB як верхня межа — хороший вибір.
На 32GB: 12–16GB підходить.
Якщо виділити занадто багато, ви заховаєте погані ліміти подів і тонко голодуватимете Windows-додатки.

5) Чому WSL2 тримає пам’ять після зупинки навантажень?

Linux агресивно використовує пам’ять під файловий кеш. Це зазвичай добре.
Звільнення пам’яті WSL2 назад у Windows може бути повільнішим, ніж хочеться.
Якщо треба RAM негайно — вимкніть WSL; якщо хочете довготривалу нормальність — обмежте пам’ять і зменшіть фоновий шум.

6) Чому kubectl повільний лише коли увімкнений VPN?

VPN-клієнти часто впроваджують DNS-резолвери і правила маршрутизації.
Kubernetes залежить від DNS внутрішньо, а kubectl — від надійного з’єднання з API.
Діагностуйте за допомогою тесту DNS і readyz; потім вирішіть, чи split-tunnel, налаштування резолверів або робота з локальним кластером без VPN.

7) Як відкрити сервіси в Windows з кластера у WSL2?

Визначте, чи використовуєте ви форвардинг localhost або IP VM WSL.
Для передбачуваного UX багато команд роблять порт-форвард (kubectl port-forward) або запускають ingress, який відображається на відомих портах.
Задокументуйте метод, щоб команда не дебагала «localhost» заради розваги.

8) Чи можна запускати stateful навантаження (Postgres, Kafka) локально у WSL2 Kubernetes?

Так, але будьте реалістичні. Postgres підходить для деву, якщо дані живуть у файловій системі Linux і ви не запускаєте ще п’ять важких стеків.
Kafka можлива, але часто локальна «парність» перетворюється на «локальне покарання». Розгляньте легші замінники, якщо не дебажите специфічну поведінку Kafka.

9) Як часто пересоздавати локальний кластер?

Якщо ви працюєте з платформою та багатьма CRD і контролерами, пересоздавання щотижня або раз на два тижні — нормально.
Якщо кластер стабільний і лаконічний, можна тримати його довше.
Пересоздавайте одразу, коли підозрюєте дріфт: дивний DNS, застряглі вебхуки або таємничі admission-помилки.

10) Яка найпоширеніша корінна причина «все повільно»?

Зберігання. Або навантаження на неправильному шляху файлової системи, або диск майже повний, або система пише логи ніби за рядок платять.
Пам’ять — друга. DNS — третя. Kubernetes рідко перший винуватець; він просто сцена, на якій проблема виступає.

Наступні кроки, які можна зробити сьогодні

1. Встановіть ліміти WSL2 (пам’ять, CPU, swap). Якщо робити лише одну річ — зробіть це.
2. Перемістіть гарячі дані з /mnt/c: storage runtime, PV, бази даних, кеші збірки — тримайте їх у файловій системі Linux.
3. Оберіть лаконічний профіль кластера: kind або k3d з лише основними addon-ами. Зробіть «повний стек» опційним.
4. Прийміть швидкий план діагностики: перевірка тиску хоста, потім здоров’я контрольної площини, потім топ-споживачі. Хватить гадати.
5. Заплануйте нудне обслуговування: prune кеші, видаляйте невикористані неймспейси і пересоздавайте кластер, коли з’являється дріфт.

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

Брехня: чому «переписати з нуля» здається правильним

Переписи продають надію. Вони пропонують чистий розрив із накопиченим безладом: більше ніяких застарілих фреймворків, ніяких «тимчасових» хаків з 2017 року, ніяких нетестованих модулів, ніякої тієї одної збереженої процедури, до якої всі бояться торкатися. Подача емоційно правильна. Проблема в тому, що продакшн‑системи не працюють на емоціях. Вони працюють на інваріантах.

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

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

Переписи ігнорують те, що «вимоги» не в системі тикетів. Вони в графіках продакшну, у нотатках on‑call і у тих тихих припущеннях, які тримають світло ввімкненим. Коли ви переписуєте, ви видаляєте ці припущення — а потім знову їх відкриваєте о 2:13 ранку.

Жарт №1: План перепису — це як купити нову бігову доріжку, щоб стати у формі. Купівля здається продуктивною; біг — це те, де з’являється реальність.

Чому переписи провалюються в продакшні (справжні причини)

1) Паритет функцій — це пастка, а не етап

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

Коли перепис прагне паритету, він орієнтується на видиму поверхню UI/API і пропускає брудні частини, що важливі: як система поводиться, коли платіжний шлюз таймаутиться, коли бекенд повільний, коли клієнт повторює POST, коли годинники розходяться або коли потрібно перебігати день подій.

2) Дані — це продукт, і дані важкі

Більшість систем — це системи даних, що носять UI. Перепис, який не починається з семантики даних — що означають записи, як вони змінюються з часом, що можна робити з eventual consistency — відхилиться у «нову схему бази, яка приємніша», а потім вріже об реальність під час вирубки.

Міграція даних — це не проект на вихідні. Це тривала вправа на надійність з бекфілами, dual‑write (або change data capture), звірками й планами відкату. Якщо ваш план перепису не включає місяці одночасної роботи обох шляхів даних, ви не плануєте cutover — ви плануєте підкидання монети.

3) Перепис створює організацію зі «split‑brain»

Два кодові бази означають дві пріоритети, дві черги баґів, дві моделі експлуатації й одну спільну базу клієнтів, яка очікує однакового сервісу. Зазвичай старші люди витягують у перепис, лишаючи легасі зменшеним у потужності та зростаючим ризиком. Потім у легасі відбувається інцидент, і графік перепису розкрадають, щоб реагувати. Перепис гальмує. Легасі деградує. Всі програють.

4) Операційна готовність — це не «ми тепер маємо Kubernetes»

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

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

5) Продуктивність — це властивість, що виникає, її не можна запрограмувати в unit‑тестах

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

6) Нова система правильна в малому і неправильно в великому

Код‑рев’ю ловлять локальні проблеми. Вони не ловлять поведінку системи під частковими відмовами. Переписи провалюються, бо моделюють світ як надійний і консистентний. Продакшн цим не є.

7) Безпека та відповідність не «потім»

Переписи часто відсувають контролі безпеки, журнали аудиту, правила зберігання та принцип найменших привілеїв. Потім виявляється, що «дивні» логування й доступи в легасі були через те, що колись аудитор поставив дуже конкретне питання. Ви або метушитеся, або відкладаєте cutover. Обидва варіанти дорогі.

Факти й історія: індустрія вже була тут раніше

• 1980–1990‑ті: Великі організації неодноразово намагалися робити переписи на базі CASE‑інструментів головнихфрейм‑систем; багато проектів розвалювалися через обсяг і складність міграції даних.
• Рік 2000 (Y2K) навчив підприємства жорсткого уроку: замінити все рідко реально; виправлення і триаж на основі ризиків часто перемагають.
• Епоха «big bang» впроваджень ERP показала закономірність: cutover‑и провалюються, коли бізнес‑процеси не змодельовані під реальні робочі потоки і винятки.
• Зростання сервісно‑орієнтованої архітектури (SOA) обіцяв модульність; багато проєктів дали розподілені моноліти з більшими затримками й складнішим дебагом.
• Популярність мікросервісів (середина 2010‑х) збільшила спокусу переписати, але також підвищила витрати на операційну зрілість: трасування, мапування залежностей і локалізація відмов стали обов’язковими.
• Інструменти change data capture (CDC) дозріли і зробили інкрементальні міграції більш практичними, змінивши економіку на користь не «big‑bang» переписів.
• Хмарна еластичність зменшила деякі ризики ємності, але внесла нові: «шиліди шуму» (noisy neighbors), квоти сервісів і інциденти через білінг.
• Observability як дисципліна (метрики, логи, трасування) стала мейнстримом; вона показала, що багато «легасі» аварій насправді були проблемами залежностей і ємності.

Три короткі історії з корпоративних окопів

Коротка історія 1: Інцидент через хибне припущення

Середня SaaS‑компанія переписала свій білінговий сервіс на новій мові, щоб «зробити його підтримуванішим». Команда ретельно попрацювала над unit‑тестами та контрактом API. Вони побудували чисту схему бази і випустили за feature‑флагом.

Хибне припущення було тонким: вони вважали, що всі клієнти ставитимуться до POST /charge як до неідемпотентної операції й ніколи не повторюватимуть автоматично. У легасі тихо реалізували ідемпотентність через токен, який надсилав клієнт, бо років тому мобільний клієнт повторював запити через непевні мережі.

Перепис цього не реалізував. Під час рутинних мережевих коливань між регіонами частина клієнтів повторила платежі. Новий сервіс правильно створив кілька платежів. Підтримка загорілася. Фінанси втрутилися. Інженерів заспамили сторінками за «інцидент коректності даних», що довго боліло навіть коли графіки виключилися.

Виправлення не було «додати ще тестів». Виправлення — вважати ідемпотентність і повтори вимогою першого порядку, задокументувати їх як інваріанти і побудувати інструменти звірки. Також вони додали canary, що симулював повтори і перевіряв стабільність бухгалтерії.

Мораль: якщо ви явно не змоделюєте поведінку клієнта, мережа зробить це за вас.

Коротка історія 2: Оптимізація, що відкотилася

Внутрішня платформа великого підприємства переписала пайплайн звітності, щоб знизити витрати. Вони замінили агрегаційні job‑и на стрімінговий пайплайн і агресивно налаштували батчинг, щоб мінімізувати CPU і зберігання.

Оптимізація виглядала чудово у синтетичних бенчмарках. Продакшн був іншим. Їхній батчинг збільшив end‑to‑end затримку і створив сплески навантаження на downstream‑сервіси. «Дешевий» пайплайн перетворився на генератор thundering herd. Нижчестоячі сервіси ввімкнули rate‑limit. Повтори накопичилися. Внутрішні буфери стрімінгової системи зросли, і логіка backpressure почала скидати повідомлення під тривалим навантаженням.

Тепер система мала дві проблеми замість одної: звіти запізнювалися і деякі були неправильні. Команда витратила тижні на побудову компенсуючих контролів: dead‑letter черги, інструменти для реплею і процес корекції «пізніх даних». Витрати зросли, а не впали, бо операційні витрати теж — просто оплачуються людською увагою.

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

Коротка історія 3: Нудна, але правильна практика, що врятувала ситуацію

Компанія, що модернізувала стек автентифікації, втрималася від спокуси переписати і зробила боляче непоказну річ: побудувала сумісну тест‑систему на основі реального продакшн‑трафіку. Не просто unit‑тести — записані запити, крайові токени і представницькі режими відмов.

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

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

Коли вони нарешті переключили трафік, запуск був майже нудним. On‑call отримав кілька сторінок — здебільшого через надмірну чутливість дашбордів — а потім все стабілізувалося. «Нудна практика» означала ставлення до міграції як до збору доказів, а не як до героїчного стрибка.

Що насправді працює: патерни, що переживають зіткнення з реальністю

Почніть з інваріантів, а не з архітектури

Перш ніж сперечатися про фреймворки, запишіть інваріанти. Речі, що мають залишатися істинними навіть коли залежності відмовляють:

• Правила ідемпотентності: які операції можна безпечно повторювати і як саме.
• Обмеження коректності даних: що «не може трапитися» (подвійне списання, від’ємний баланс, втрачені записи аудиту).
• Бюджети затримки і цілі доступності: що користувач потерпить.
• Вимоги консистентності: де допустима eventual consistency, а де ні.
• Вимоги відката: що означає скасувати деплой, міграцію або бекфіл.

Використовуйте патерн strangler fig (і робіть це серйозно)

Патерн strangler fig працює, бо поважає, що продакшн‑системи — живі екосистеми. Ви не замінюєте дерево за один день; ви вирощуєте нову систему навколо нього і поступово переводите відповідальності.

Практично це означає:

• Поставте шар маршрутизації (API‑gateway, reverse proxy або ingress сервісної сітки) перед старою системою.
• Переносьте по одній кінцевій точці, одному робочому процесу або одній доменній частці за раз.
• Тримайте швидкий відкат: миттєво маршрутизувати трафік назад.
• Використовуйте shadow‑читання та порівняння, коли це можливо.

Надавайте перевагу «заміні за інтерфейсом» над «переписати все»

Коли підсистема справді прогнила, замініть її за стабільним інтерфейсом. Збережіть контракт. Збережіть метрики. Збережіть рунибуки з експлуатації. Змініть внутрішню реалізацію. Це зменшує радіус ураження і перешкоджає командам перебудовувати весь світ лише щоб полагодити одну стіну.

Міграція даних: dual‑write або CDC, плюс звірка

Оберіть отруту обережно:

• Dual‑write: застосунок пише в старе і нове сховища. Простішe концептуально, складніше зробити коректним при часткових відмовах.
• CDC: трактуйте стару базу як джерело істини і стриміть зміни в нове сховище. Часто більш надійно, але вимагає уважного порядку і дисципліни еволюції схем.

У будь‑якому разі потрібна звірка: періодичні завдання, що порівнюють підрахунки, контрольні суми і інваріанти між старим і новим. Без звірки ви працюєте на відчуттях.

Побудуйте операційну паритетність перед функціональним паритетом

Операційна паритетність — це здатність запускати, відлагоджувати і відновлювати. Вона включає:

• Дашборди, що показують насичення, помилки, затримки і здоров’я залежностей.
• Алертинг, який дієво (pages за симптоми, а не шум).
• Рунибуки, що передбачають часткові відмови і включають відкати.
• Навантажувальне тестування, що відповідає формі продакшна, а не тільки обсягу.

Цитата, яку варто приклеїти до монітора

Надія — це не стратегія. — Джеймс Кемерон

Операції не цинічні; вони алергічні до магічного мислення. Плануйте режими відмов, які у вас точно будуть.

Тримайте стару систему здоровою під час міграції

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

Жарт №2: Єдина річ гірша за одну крихку систему — це дві крихкі системи, які сперечаються, чия це провина.

Практичні завдання: команди, виводи, що це означає, і що ви вирішуєте

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

1) Визначити насичення CPU проти скарг на затримки

cr0x@server:~$ uptime
 14:22:01 up 37 days,  4:11,  2 users,  load average: 18.42, 17.96, 16.88

Що це означає: Середнє навантаження значно вище за кількість ядер (треба знати cores) — це свідчить про конкуренцію за CPU або накопичення runnable‑черги, можливo також I/O‑wait залежно від навантаження.

Рішення: Не починайте перепис через «повільно». Спочатку визначте, чи ви CPU‑bound, I/O‑bound або lock‑bound. Далі: перевірте розподіл CPU і чергу виконуваних процесів.

2) Перевірити використання CPU по ядрах та iowait

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (prod-app-01)  02/04/2026  _x86_64_  (16 CPU)

22:22:10     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22:22:11     all   62.11    0.00   11.83   18.44    0.00    0.52    0.00    0.00    0.00    7.10
22:22:11       0   71.00    0.00   12.00   10.00    0.00    0.00    0.00    0.00    0.00    7.00

Що це означає: Високий %iowait вказує, що CPU чекає диск/мережеве сховище. Високий %usr — завантаження обчисленнями. Тут обидва: CPU зайнятий і чекає на I/O.

Рішення: Дослідіть затримки сховища та бази даних перед переписом логіки застосунку. Перепис не змінить ваші диски.

3) Перевірити тиск пам’яті і свопінг

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        54Gi       1.1Gi       1.8Gi       6.9Gi       4.2Gi
Swap:          8.0Gi       2.7Gi       5.3Gi

Що це означає: Використання swap‑у — нетривіальне. Якщо система активно свопиться, хвостова затримка різко зросте.

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

4) Перевірити активний свопінг і major‑faults

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  2 2795520 1187328  9120 6852140   0  64  1220  1780 8210 9230 61 11  7 21  0
 7  1 2795584 1169000  9120 6854100   0 128  1100  1650 8030 9012 60 12  8 20  0

Що це означає: so (swap out) вказує на активний свопінг. wa також високий, що узгоджується з I/O‑wait.

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

5) Знайти головних споживачів CPU

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 8123 java            345.2 18.4
 9001 redis-server     72.1  3.2
 7442 nginx            38.0  0.8

Що це означає: Один процес, що споживає кілька ядер, може бути очікуваним, але підтвердіть, чи це узгоджується з пропускною здатністю. Якщо CPU високий, а пропускна здатність низька — ви крутитеся в циклі або є contention.

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

6) Швидко ідентифікувати вузькі місця диска

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (prod-db-01)  02/04/2026  _x86_64_  (16 CPU)

Device            r/s     w/s   rMB/s   wMB/s  await  svctm  %util
nvme0n1         220.0   410.0    35.2    88.1  18.40   0.90  92.50

Що це означає: Високий %util і зростаючий await означають, що пристрій насичений або черга зростає. Низький svctm при високому await вказує на проблему з чергою/латентністю, а не на сиру повільність пристрою.

Рішення: Потрібна оптимізація запитів, зміни індексів або розподіл I/O. Перепис, що зберігає ті самі шаблони доступу, натрапить на ту саму стіну.

7) Перевірити ємність файлової системи та виснаження inode

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  855G   45G  96% /

cr0x@server:~$ df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2  5900000 5892000     8000  100% /

Що це означає: Майже повний диск — погано; виснаження inode — підступніше і може зламати деплої, логування і тимчасові файли.

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

8) Перевірити помилки мережі і повторні передачі

cr0x@server:~$ netstat -s | egrep -i 'retrans|listen|listenoverflows|packet receive errors' | head
    12455 segments retransmitted
    37 packet receive errors

Що це означає: Повторні передачі і помилки прийому можуть давати «випадкові затримки». Ваш застосунок може бути невинним.

Рішення: Дослідіть NIC, невідповідності MTU, перевантажені балансувальники навантаження або проблеми між зонами доступності перед переписом шару застосунку.

9) Інспектувати стани TCP‑з’єднань (витоки або повільні клієнти)

cr0x@server:~$ ss -s
Total: 14021
TCP:   10234 (estab 812, closed 9132, orphaned 5, timewait 7210)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       29        25        4
TCP       1102      1011      91
INET      1131      1036      95
FRAG      0         0         0

Що це означає: Надмірний timewait може вказувати на короткоживучі з’єднання без keep‑alive або агресивну поведінку клієнтів з повтореннями.

Рішення: Налаштуйте повторне використання з’єднань, параметри балансувальника навантаження та поведінку клієнтів. Перепис не змінить фізику TCP.

10) Перевірити тротлінг контейнерів (Kubernetes CPU limits)

cr0x@server:~$ kubectl -n payments top pods | head
NAME                           CPU(cores)   MEMORY(bytes)
payments-api-6d8d6c6b6c-2qz7m  980m         740Mi
payments-api-6d8d6c6b6c-pk9h4  995m         755Mi

cr0x@server:~$ kubectl -n payments describe pod payments-api-6d8d6c6b6c-2qz7m | egrep -i 'Limits|Requests|throttl' -n | head -n 20
118:    Limits:
119:      cpu:     1
120:      memory:  1Gi

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

Рішення: Перегляньте CPU limits/requests і політики HPA. Якщо ви переписуєте на Kubernetes без розуміння тротлінгу, ви просто перенесли проблему у YAML.

11) Виявити lock‑контенцію в базі даних (класична сліпота при переписі)

cr0x@server:~$ psql -U postgres -d appdb -c "select pid, wait_event_type, wait_event, state, query from pg_stat_activity where wait_event_type is not null order by pid limit 5;"
 pid  | wait_event_type |   wait_event   | state  |                  query
------+-----------------+----------------+--------+------------------------------------------
 4142 | Lock            | transactionid  | active | UPDATE invoices SET status='paid' ...
 4221 | Lock            | relation       | active | ALTER TABLE ledger ADD COLUMN ...

Що це означає: Запити блокуються через локи. Проблеми з продуктивністю можуть бути через DDL‑міграції, а не через якість коду застосунку.

Рішення: Плануйте важкі міграції, зменшуйте обсяги блокувань, використовуйте онлайн‑зміни схем. Не переписуйте через «Postgres повільний», коли ви тримаєте локи.

12) Перевірити повільні запити і знайти топ‑винуватців

cr0x@server:~$ psql -U postgres -d appdb -c "select calls, mean_exec_time, rows, left(query,120) as q from pg_stat_statements order by mean_exec_time desc limit 5;"
 calls | mean_exec_time | rows | q
-------+----------------+------+------------------------------------------------------------
   412 |         982.14 |   12 | SELECT * FROM orders WHERE customer_id = $1 ORDER BY created_at DESC LIMIT 50
   201 |         744.33 |    1 | SELECT balance FROM accounts WHERE id = $1 FOR UPDATE

Що це означає: У вас є конкретні цілі: додати індекси, змінити форму запиту, зменшити блокування. Зазвичай це дешевше, ніж перепис.

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

13) Перевірити лаг реплікації перед cutover

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep -i 'Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running'
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 43

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

Рішення: Або прийміть застарілість явно (і спроектуйте для неї), або не переключайте читання, поки лаг не буде стабільно низьким.

14) Виявити зміну частоти помилок під час canary‑релізу

cr0x@server:~$ kubectl -n payments logs deploy/payments-api --since=5m | egrep -c " 5[0-9][0-9] "
27

Що це означає: Зростаюча кількість 5xx після деплою — це канар‑фейл поки не доведено протилежне.

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

15) Підтвердити достатню кількість дескрипторів файлів під навантаженням

cr0x@server:~$ ulimit -n
1024

cr0x@server:~$ cat /proc/$(pgrep -n nginx)/limits | egrep -i "open files"
Max open files            1024                 1024                 files

Що це означає: 1024 FD часто замало для навантажених проксі/сервісів. Ви можете отримувати помилки з’єднань, що виглядають як «новий ап flaky».

Рішення: Підніміть ліміти, перевірте налаштування рантайму контейнера і повторно протестуйте. Знову: виправте фундаментальні речі перш ніж перебудовувати всесвіт.

Швидкий план діагностики: що перевіряти перше/друге/третє

Це процедура, коли хтось каже «легасі — вузьке місце» або «перепис буде швидшим». Ви можете виконати це за годину на живому інциденті (акуратно) або в стенді з продакшн‑подібним навантаженням.

Перше: Насичення, помилки чи затримка залежностей?

• Перевірити рівень помилок (сплески 5xx/4xx, таймаути). Якщо помилки стрибнули, продуктивність може бути симптомом часткової відмови.
• Перевірити насичення: CPU iowait, disk await, мережеві retransmits, з’єднання DB, пул потоків.
• Перевірити здоров’я залежностей: БД, кеш, брокер повідомлень, зовнішні API, DNS, термін дії сертифікатів.

Мета: класифікувати проблему: compute‑bound, I/O‑bound, lock‑bound, network‑bound або відмова залежності.

Друге: Знайдіть тісний цикл у шляху запиту

• Виберіть одну кінцеву точку, що впливає на користувача (найбільший трафік або найвища затримка).
• Протрейсіть її наскрізь (distributed tracing, якщо є; інакше — кореляційні ID у логах).
• Виміряйте час у: CPU застосунку, запитах БД, кеші, апстримі, серіалізації, повторних спробах.

Мета: з’ясувати, куди йде час, а не куди здається, що йде.

Третє: Підтвердіть контрольованим експериментом

• Зробіть одну зміну (індекс, TTL кешу, розмір pool‑у з’єднань, ліміт CPU).
• Запустіть її як canary на невеликій частці трафіку.
• Порівняйте: latency percentiles, error rates, метрики насичення.

Мета: рішення на підставі доказів. Якщо пропозиція перепису не витримує такого рівня перевірки, це проект моралі, а не інженерний проєкт.

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

«Ми переписали, а затримка погіршилася»

Симптоми: p95/p99 затримки вгору, CPU в нормі, дашборди показують більше мережевих викликів.

Корінь: Ви розклали в процесі виклики на RPC‑ланцюжки без бюджету затримки, перетворивши in‑process виклики в RPC‑ланцюги. Ви побудували розподілений моноліт.

Виправлення: Згорніть балакучі межі, пакетизуйте виклики, введіть локальний кеш і вимагайте бюджети на кожен хоп. Надавайте перевагу грубозернистим API перед «чистими» межами мікросервісів.

«Cutover спрацював, потім з’явився дрейф даних»

Симптоми: Звіти не співпадають, баланси різняться, клієнти бачать неконсистентні стани через дні.

Корінь: Dual‑write без semantics exactly‑once; відсутня звірка; події приходять у різному порядку; різні правила часових зон/округлень.

Виправлення: Реалізуйте завдання звірки та перевірки інваріантів; використовуйте ключі ідемпотентності; визначте авторитетне джерело для полів; за можливості прийміть CDC з гарантіями порядку.

«Нова система стабільна, але on‑call гірший»

Симптоми: Більше алертів, складніший дебаг, більше невідомих невідомих.

Корінь: Відтермінували observability і рунибуки; алерти побудовані на сирих метриках замість сигналів впливу на користувача; немає трасування.

Виправлення: Інструментувати «золоті» сигнали (latency, traffic, errors, saturation). Додати трасування. Переписати алерти під симптоми і пов’язати з SLO.

«Ми не можемо відпустити, бо женемося за паритетом назавжди»

Симптоми: Проєкт перепису тягнеться квартали/роки, бізнес додає фічі в легасі, перепис не наздоганяє.

Корінь: Мислення big‑bang; відсутні інкрементальні cutover‑и; команда перепису ізольована від реальних продуктових пріоритетів.

Виправлення: Патерн strangler з тонкими вертикальними зрізами. Переносьте один робочий процес наскрізь. Заморозьте певні легасі‑фічі або перенаправляйте нові фічі лише в новий шлях.

«Ми замінили схему бази даних і все болить»

Симптоми: Повільні запити, contention по локу, розширення вікон міграцій, ризикові відкати.

Корінь: Перепроект схеми ігнорував шаблони доступу й експлуатаційні обмеження; відсутні індекси; незмірені міграції.

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

«Ми переписали заради безпеки і ввели нові дірки»

Симптоми: Відсутні журнали аудиту, слабші перевірки авторизації, розростання секретів.

Корінь: Контролі безпеки були імпліцитні в легасі і не змоделовані; новий стек випущено без threat‑modeling.

Виправлення: Інвентаризуйте інваріанти безпеки (правила authz, логування, зберігання). Додайте автоматичні перевірки в CI. Використовуйте принцип найменших привілеїв і централізоване управління секретами з першого дня.

Чек‑листи / покроковий план

Чек‑лист рішення: чи варто взагалі переписувати?

1. Чи можете назвати вузьке місце? Якщо ні — спочатку вимірювання (див. завдання й план діагностики).
2. Проблема в підтримуваності коду чи в поведінці системи? Якщо інциденти здебільшого через ємність/залежності, перепис коду не допоможе.
3. Чи є стабільний контракт? Якщо інтерфейс нестабільний, зафіксуйте його перед зміною інтернів.
4. Є план щодо даних? Якщо ви не можете описати dual‑write/CDC, звірку й відкат — ви не готові.
5. Чи маєте опс‑зрілість? Дашборди, алерти, трасування, рунибуки, поетапні релізи. Якщо ні — побудуйте це спочатку.
6. Чи можете закрити дві системи ресурсами? Якщо ні — робіть поступову заміну, а не паралельні переписи.

Безпечніший план модернізації (працює навіть при обмеженому часі)

1. Інвентар інваріантів: ідемпотентність, правила коректності, зберігання, авторизація, коди помилок, ліміти швидкості.
2. Інструментувати легасі, якщо воно сліпе: додайте request‑ID, гістограми затримок, таксономію помилок.
3. Поставте шар маршрутизації: gateway/proxy, що може розділяти трафік і миттєво відкатувати.
4. Виберіть один вертикальний зріз: один робочий процес, що дає реальну цінність і зачіпає реальні залежності.
5. Shadow спочатку: нова система обчислює відповіді і логгує невідповідності, але не віддає їх.
6. Canary: 1% трафіку, потім 5%, потім 25%, вимірюючи SLO і інваріанти.
7. Обережно переключайте шляхи читання: застарілі читання видимі користувачу. Використовуйте бюджети консистентності і явну поведінку.
8. Перемикайте шляхи запису останніми: переконайтеся, що ідемпотентність, повтори і звірка доведені.
9. Деактивуйте по частинах: видаляйте легасі‑endpoint‑и коли трафік для них сходить до нуля; зберігайте шляхи архівації для аудиту.

Чек‑лист релізу для мігрованого компонента

• SLO визначений; дашборди показують золоті сигнали.
• Алертинг налаштований; on‑call має рунибуки і інструкції відкату.
• Тестовано ємність під навантаженням, що імітує форму продакшна.
• Таймаути залежностей і повтори налаштовані (з бюджетами).
• Ідемпотентність реалізована для небезпечних операцій.
• Завдання звірки даних на місці; процес триажу невідповідностей визначений.
• Контролі безпеки перевірені: паритет authz, журнали аудиту, зберігання.
• Проведено game‑day: відмова залежності, повільна БД, частковий деплой, відкат.

Часті питання

1) Коли перепис насправді виправданий?

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

2) Хіба інкрементальна міграція не повільніша за перепис?

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

3) У нас жахлива якість коду. Хіба це не вимагає перепису?

Погана якість коду вимагає меж, тестів навколо інваріантів і експлуатаційної видимості. Часто можна ізолювати найгірші модулі і замінити їх за інтерфейсом. Повний перепис скидає якість коду до «невідомої», що не обов’язково краще.

4) Як уникнути «дві системи назавжди»?

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

5) Який найбільший прихований ризик у переписах?

Семантичне відхилення: нова система поводиться інакше при повторних спробах, часткових відмовах і дивному вводі. Користувачі не пишуть тикети про «семантичне відхилення». Вони пишуть тикети про зниклі гроші, неправильні дані і «ваш API ненадійний».

6) Чи потребує мікросервісна архітектура перепису?

Ні. Ви можете витягувати сервіси з моноліту поступово. Перший крок часто — створити внутрішні модульні межі і витягти одну доменну частку з чіткою відповідальністю і контрактами даних.

7) Як виконати міграцію даних без простою?

Використовуйте CDC або dual‑write, потім звіряйте. Переключайте читання, коли застарілість прийнятна або її пом’якшено; переключайте записи останніми з сильною ідемпотентністю. Завжди майте маршрут відкату і план бекфілів.

8) Що має вимірювати керівництво, щоб знати, що міграція здорова?

Не story points. Вимірюйте досягнення SLO, частоту інцидентів, частоту відкатів, час до виявлення/відновлення і прогрес міграції у вигляді вилученої легасі‑поверхні (видалені endpoints/робочі процеси).

9) Як зупинити інженерів від «закипання океану»?

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

Наступні кроки, які можна відправити цього кварталу

Якщо ви сидите на зустрічі, де хтось пропонує перепис як панацею, ось що робити натомість — практично, без драм:

1. Запустіть швидкий план діагностики і опублікуйте класифікацію вузького місця. Виведіть дебати з площини естетики.
2. Запишіть інваріанти (ідемпотентність, коректність, бюджети затримки, правила авторизації). Зробіть їх доступними для рев’ю і тестування.
3. Виберіть один робочий процес і мігруйте його з маршрутизацією + канарі + відкат. Доведіть, що можете переміщувати зрізи безпечно.
4. Інвестуйте в операційну паритетність: дашборди, трасування, гігієна алертів, рунибуки. Зробіть підтримку систем простішою, ніж сперечання про них.
5. Зробіть звірку даних продуктною фічею, а не побічним квестом. Якщо ви не можете довести коректність даних, у вас немає коректності.

Брехня «переписати з нуля» живе доти, доки пропонує історію, де складність зникає. У реальних систем складність не зникає; вона переміщується. Ваше завдання — перемістити її в місця, де її можна виміряти, контролювати і зробити нудною. Нудне недооцінене. Нудне відправляється.

Швидкий план діагностики (перший/другий/третій)

Коли Панель керування NVIDIA «відсутня», вузьке місце зазвичай одна з трьох речей: невірний тип драйвера (DCH проти Standard), пошкоджений пакет додатка (Store/AppX) або зупинена служба NVIDIA Display Container. Ви можете з’ясувати це за кілька хвилин.

Перший крок: визначте, що у вас запущено (апарат, модель драйвера, сесія)

• У вас ноутбук із гібридною графікою? Якщо внутрішня панель керується iGPU, опції Панелі керування NVIDIA можуть бути обмежені або переміщені.
• Ви використовуєте DCH драйвери? Якщо так, Панель керування часто постачається як додаток Microsoft Store; його можна втратити незалежно від драйвера.
• Ви в RDP/віртуальній машині? Віддалені сесії та ВМ можуть приховувати інтерфейс або показувати інший адаптер.

Другий крок: перевірте службу, що хостить UI

• NVIDIA Display Container LS — типовий підозрюваний. Якщо вона зупинена/відключена, Панель керування може не з’являтись у контекстному меню або не запускатись коректно.

Третій крок: перевірте реєстрацію додатка (Store-пакет / виконуваний файл)

• Якщо DCH: підтвердіть, що пакет Панель керування NVIDIA (AppX) існує для вашого користувача та не в пошкодженому стані.
• Якщо Standard: підтвердіть, що nvcplui.exe існує та його можна запустити.

Лише після цих кроків варто «вдарити молотком» (DDU, повна перевстановлення). У більшості випадків це можна виправити без очищення стеку драйверів.

Цікаві факти й контекст (чому це відбувається)

Частина цього безладу має історичне коріння. Частина — сучасні механізми Windows для додатків. У будь-якому разі ви будете діагностувати швидше, якщо розумієте, з чим маєте справу.

1. DCH драйвери змінили механіку розповсюдження. З DCH (Declarative, Componentized, Hardware Support Apps) постачальники можуть відвантажувати частини UI як окремі додатки замість вбудовування всього в інсталятор драйвера.
2. Панель керування NVIDIA може бути додатком із Store (AppX). На багатьох системах панель — це AppX-пакет; Windows може оновлювати або видаляти його незалежно від драйвера GPU.
3. Контекстне меню при правому кліку робочого столу не гарантується. Shell Windows і обробники контекстного меню залежать від політик, збірки та коректного перезапуску Explorer.
4. OEM-образи часто прив’язують конкретну гілку драйверів. Виробники ноутбуків іноді кастомізують INF і включають утиліти; перехід на універсальний драйвер може залишити деякі UI-компоненти сиротами.
5. Раніше NVIDIA постачала більше постійних tray-елементів і компонентів UI. З часом вендори прагнуть зменшити час запуску. Це добре, поки є служба, яка зв’язує UI і стан драйвера, і її не вимикають.
6. Microsoft посилила розділення драйвера та UI для безпеки й обслуговування. Компонентна модель теоретично покращує оновлення, але на практиці додає більше рухомих частин, що можуть відмовити.
7. Політики можуть блокувати Store і AppX. У корпоративних середовищах доступ до Store може бути обмежений, через що DCH UI зникає, хоча драйвер працює.
8. Віддалений робочий стіл може вводити в оману. RDP може показувати інший шлях драйвера відображення; ви можете діагностувати протокол віддаленого доступу, а не стек GPU.
9. Windows Update іноді замінює драйвери. Фічевий апдейт може переключити ваш NVIDIA-пакет на іншу гілку, залишивши Панель керування не синхронізованою або видаленою.

Що означає «відсутня» насправді (режими відмов)

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

1) Додаток UI не встановлено (або встановлено для іншого користувача)

Поширено для DCH драйверів. Драйвер присутній, nvidia-smi працює, але пакет Панелі керування не встановлений для вашого профілю користувача або взагалі відсутній.

2) Додаток UI встановлений, але пошкоджений (проблема реєстрації AppX або залежностей)

Store-пакети можуть опинитися в дивному стані після міграції профілю, інструментів очищення або корпоративних політик. Пакет існує, але не запускається або запускається й миттєво закривається.

3) Служба-хост зупинена/відключена

Панель залежить від служб та запланованих завдань. Якщо NVDisplay.ContainerLocalSystem зупинена або відключена, інтеграція UI часто зникає.

4) Насправді ви не використовуєте NVIDIA GPU для шляху відображення

На ноутбуках з Optimus/iGPU внутрішній дисплей може керуватись iGPU, а NVIDIA виконує рендер/обчислення. Деякі налаштування переміщуються, зникають або вимагають підключення дисплея до порту, прив’язаного до NVIDIA.

5) Інсталяція драйвера часткова або пошкоджена

Класичний стан «ніби працює»: пристрій видно, але ключові компоненти відсутні. Часто спричинено перерваними оновленнями, утилітами очищення, що видаляють елементи driver store, або змішуванням OEM і generic пакетів.

6) Неправильні очікування: контекстне меню Windows 11 та shell-розширення

Навіть коли все встановлено правильно, контекстне меню Windows 11 може ховати застарілі записи під «Show more options», або політика може прибрати обробники.

Одна суха істина з інженерії надійності: «Якщо ви не можете виміряти, ви не можете виправити». Це перефразована думка, часто притаманна W. Edwards Deming. Тому ми вимірюємо: служби, пакети, драйвери та політику.

Жарт №1: Панель керування NVIDIA не «зникає». Вона просто підвищується до середнього керівництва, де ніхто її не може знайти.

Практичні завдання: команди, результати, рішення

Це реальні завдання, які ви можете виконати у Windows. Кожне включає: команду, що означає типовий результат, і рішення, яке треба прийняти далі. Запускайте PowerShell від імені Адміністратора, якщо не зазначено інше.

Завдання 1: Підтвердіть збірку та редакцію Windows (мають значення політики Store)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows 11 Pro     23H2           22631

Що це означає: У вас Windows 11 Pro 23H2. Поведінка Store і AppX відрізняється між збірками; корпоративні політики часто застосовуються на Pro/Enterprise.

Рішення: Тримайте «DCH + Store app» серед основних підозрюваних. Якщо це Enterprise, вважайте Store обмеженим, поки не доведете протилежне.

Завдання 2: Підтвердіть присутність NVIDIA GPU і встановлений драйвер

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Display | Format-Table -AutoSize Status,FriendlyName,InstanceId"
Status FriendlyName                      InstanceId
------ ------------                      ----------
OK     NVIDIA GeForce RTX 3070 Laptop GPU PCI\VEN_10DE&DEV_24DD&SUBSYS_...
OK     Intel(R) Iris(R) Xe Graphics      PCI\VEN_8086&DEV_9A49&SUBSYS_...

Що це означає: Гібридна графіка. Якщо внутрішній дисплей керується iGPU, деякі опції Панелі керування NVIDIA можуть бути обмежені.

Рішення: Не робіть висновку, що опції «зникли» через відсутність додатка. Спочатку підтвердіть, чи додаток відсутній або просто не відображається в shell.

Завдання 3: Перевірте дату/версію драйвера у Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceClass -eq 'DISPLAY' -and $_.Manufacturer -match 'NVIDIA'} | Select-Object DeviceName,DriverVersion,DriverDate | Format-Table -AutoSize"
DeviceName                         DriverVersion DriverDate
----------                         ------------- ----------
NVIDIA GeForce RTX 3070 Laptop GPU 31.0.15.5176  2024-01-15

Що це означає: Драйвер встановлено і Windows його бачить.

Рішення: Якщо Панель керування відсутня, ймовірно, причина в пакуванні/службі/shell, а не у відсутності драйвера.

Завдання 4: Підтвердіть наявність і стан служб NVIDIA

cr0x@server:~$ powershell -NoProfile -Command "Get-Service *NVIDIA* | Sort-Object Status,Name | Format-Table -AutoSize Name,Status,StartType"
Name                         Status  StartType
----                         ------  ---------
NVDisplay.ContainerLocalSystem Stopped Automatic
NVIDIAFrameViewSDKService     Running Manual
NvContainerLocalSystem        Running Automatic

Що це означає: Служба Display Container зупинена. Це червоний прапорець для інтеграції Панелі керування.

Рішення: Запустіть її та перевірте Панель керування ще раз. Якщо не стартує — витягніть журнали.

Завдання 5: Запустіть службу Display Container (швидке виправлення)

cr0x@server:~$ powershell -NoProfile -Command "Start-Service NVDisplay.ContainerLocalSystem; Get-Service NVDisplay.ContainerLocalSystem | Format-List Status,StartType"
Status    : Running
StartType : Automatic

Що це означає: Служба успішно запустилась.

Рішення: Вийдіть із сесії/увійдіть або перезапустіть Explorer; потім перевірте контекстне меню робочого столу та меню Пуск для Панелі керування NVIDIA.

Завдання 6: Якщо служба не стартує — візьміть помилку з журналу System

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddHours(-2)} | Where-Object {$_.Message -match 'NVDisplay.Container'} | Select-Object -First 3 TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated      : 2/4/2026 8:12:44 AM
Id               : 7000
LevelDisplayName : Error
Message          : The NVDisplay.ContainerLocalSystem service failed to start due to the following error: The system cannot find the file specified.

Що це означає: Служба вказує на відсутній бінарник. Це пошкоджена інсталяція або надто ретельний інструмент очищення.

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

Завдання 7: Визначте, чи Панель керування встановлена як AppX-пакет (шлях DCH)

cr0x@server:~$ powershell -NoProfile -Command "Get-AppxPackage -Name *NVIDIACorp.NVIDIAControlPanel* | Select-Object Name,Version,Status,PackageFullName"
Name                             Version      Status PackageFullName
----                             -------      ------ ---------------
NVIDIACorp.NVIDIAControlPanel    8.1.962.0    Ok     NVIDIACorp.NVIDIAControlPanel_8.1.962.0_x64__56jybvy8sckqj

Що це означає: Пакет додатка встановлений і здоровий.

Рішення: Якщо він все ще «відсутній», швидше за все мова про проблеми shell/контекстного меню або шлях запуску.

Завдання 8: Якщо AppX-пакет відсутній — перевірте, чи Store заблоковано політикою

cr0x@server:~$ powershell -NoProfile -Command "reg query HKLM\SOFTWARE\Policies\Microsoft\WindowsStore /v RemoveWindowsStore"
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore
    RemoveWindowsStore    REG_DWORD    0x1

Що це означає: Store вимкнено політикою. На DCH-системах це часто означає «без Панелі керування».

Рішення: Або (a) отримайте виняток політики для розгортання пакета NVIDIA Control Panel, або (b) перейдіть на пакет драйвера, який включає UI без залежності від Store (часто OEM або non-DCH/Standard, якщо підтримується).

Завдання 9: Запустіть Панель керування NVIDIA прямо (працює навіть коли меню не показує)

cr0x@server:~$ powershell -NoProfile -Command "Start-Process shell:AppsFolder\\NVIDIACorp.NVIDIAControlPanel_56jybvy8sckqj!NVIDIACorp.NVIDIAControlPanel"

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

Рішення: Виправляйте інтеграцію shell (перезапуск Explorer, налаштування контекстного меню, стан служби), а не перевстановлення всього стека.

Завдання 10: Перезапустіть Explorer, щоб відновити обробники контекстного меню

cr0x@server:~$ powershell -NoProfile -Command "Stop-Process -Name explorer -Force; Start-Process explorer.exe"

Що це означає: Explorer перезапустився. Це часто відновлює записи при правому кліку після оновлення служби/додатка.

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

Завдання 11: Перевірте наявність класичного виконуваного файлу для Standard драйверів

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'C:\Program Files\NVIDIA Corporation\Control Panel Client\nvcplui.exe'; Get-Item 'C:\Program Files\NVIDIA Corporation\Control Panel Client\nvcplui.exe' -ErrorAction SilentlyContinue | Select-Object FullName,Length,LastWriteTime"
True

FullName                                                       Length LastWriteTime
--------                                                       ------ -------------
C:\Program Files\NVIDIA Corporation\Control Panel Client\nvcplui.exe  708512 1/15/2024 6:34:10 PM

Що це означає: Виконуваний файл існує. Якщо додаток «відсутній», скоріш за все проблема в ярликах/контекстному меню, а не в бінарнику.

Рішення: Спробуйте запустити його; якщо він не запускається — перевірте залежності/стан служби.

Завдання 12: Запустіть виконуваний файл напряму (шлях Standard)

cr0x@server:~$ powershell -NoProfile -Command "& 'C:\Program Files\NVIDIA Corporation\Control Panel Client\nvcplui.exe'"

Що це означає: Якщо він відкривається, створіть ярлик у меню Пуск і не витрачайте на це півдня.

Рішення: Відновіть віднаходження (ярлики, контекстне меню), а не перевстановлення.

Завдання 13: Перевірте реєстрацію контекстного меню Панелі керування NVIDIA (перевірка)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKCR\Directory\Background\shellex\ContextMenuHandlers' | findstr /i nvidia"
{0BB76A54-...}
NvCplDesktopContext

Що це означає: Обробник існує. Якщо пункт меню все ж відсутній, Windows 11 може ховати його під «Show more options», або Explorer потребує оновлення.

Рішення: Перевірте класичне контекстне меню; врахуйте можливі конфлікти shell-розширень; перезапустіть Explorer.

Завдання 14: Підтвердіть працездатність драйвера через nvidia-smi

cr0x@server:~$ nvidia-smi
Tue Feb  4 09:10:12 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 551.76       Driver Version: 551.76       CUDA Version: 12.4     |
|-------------------------------+----------------------+----------------------|
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
|  0  RTX 3070 ... Off          | 00000000:01:00.0  On |                  N/A |
+-------------------------------+----------------------+----------------------+

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

Рішення: Зосередьте увагу на доставці UI (AppX/служба/shell), а не на виявленні GPU.

Завдання 15: Аудит недавніх встановлень драйверів (хто змінив що)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-DriverFrameworks-UserMode/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/3/2026 6:44:18 PM 2003 Driver package added: oem86.inf
2/3/2026 6:44:21 PM 2004 Driver package installed for device PCI\VEN_10DE...

Що це означає: Нещодавно щось змінилось, і це зафіксовано. Добре.

Рішення: Якщо Панель керування зникла відразу після цього, припустіть зміну типу драйвера (DCH/Standard або OEM/generic) або часткове оновлення.

Завдання 16: Перевірте базові показники стану диска (так, дійсно)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName,HealthStatus,OperationalStatus | Format-Table -AutoSize"
FriendlyName      HealthStatus OperationalStatus
------------      ------------ -----------------
NVMe Samsung 980  Healthy      OK

Що це означає: Сховище явно не розвалюється.

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

Жарт №2: «Спробували вимкнути та увімкнути?» смішно, поки ви це не зробите і воно не працює — тоді ви винні всесвіту вибаченням.

Три корпоративні історії з практики

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

Ситуація: команда дизайнерів на ноутбуках з Windows 11, що працювали з зовнішніми дисплеями. Вночі частина користувачів повідомила, що Панель керування NVIDIA зникла, і профілі кольору перестали поводитись очікувано. Служба підтримки зробила те, що роблять служби: перевстановила драйвери. Половина машин покращилась. Половина — стала гірше.

Хибне припущення було простим: «Панель керування — це частина драйвера». На тих ноутбуках IT давно перейшло на DCH драйвери. UI постачався з AppX-пакетом, а доступ до Store у компанії був закритий суворіше, ніж бюджетні витрати.

Що сталося? Windows Update доставив оновлення драйвера. Драйвер встановився нормально. Але додаток Панелі керування не зміг перевстановитись або оновитись, бо Store був заблокований, а pipeline AppX не був налаштований для цього пакета. Користувачі не втратили апаратне прискорення — вони втратили UI, який керував потрібними їм контролами.

Виправлення не було в перевстановленні драйвера. Потрібна була політика і пакування: вони додали виняток для розгортання цього конкретного пакета і провізіювали його для всіх користувачів на машинах. Потім задокументували процедуру, включно з перевіркою наявності AppX-пакета.

Після інциденту команда припинила трактувати «відсутність Панелі керування» як збій драйвера і почала розглядати це як проблему доставки. Середній час відновлення зменшився, і служба підтримки перестала грати в рулетку з перевстановленнями.

Міні-історія 2: Оптимізація, що відбилася боком

Фінансовий відділ поскаржився, що ноутбуки «повільно завантажуються». Хтось вирішив оптимізувати: GPO «оптимізація запуску»: відключити непотрібні служби, зменшити кількість tray-додатків і посилити фон-режими. Це спрацювало — логіни стали відчутно швидшими.

Через два тижні інженери почали повідомляти, що Панель керування NVIDIA зникла і контекстні меню, пов’язані з GPU, пропали. Деякі машини також втратили збереження налаштувань дисплея після перезавантаження. Драйвери NVIDIA були на місці. nvidia-smi працював. Це ускладнило сприйняття скарг, поки кілька людей не витратили годин на відновлення масштабування для зовнішніх моніторів.

Причина: політика відключила NVDisplay.ContainerLocalSystem. Хтось побачив «container» і вирішив, що це опціональна хмарна штука. Це припущення має місце в музеї поганих ідей.

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

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

VFX-студія підтримувала стандартний образ робочих станцій для різних команд. IT-лідер не любив «таємничих змін», тому вони фіксували базовий драйвер для кожної моделі обладнання, прив’язували за device ID і перевіряли щоквартально. Також у них був невеличкий скрипт, що перевіряв: присутність пристрою NVIDIA, роботу Display Container, встановлення пакету Панелі керування (де застосовно) і відомий робочий спосіб запуску.

Після хвилі фічевих оновлень Windows кілька машин втратили Панель керування NVIDIA. Паніка почалась. Але базові перевірки студії запускались при вході і відзначили точну відмову: AppX-пакет був відсутній для нових профілів користувачів, створених після оновлення.

Вони не перевстановлювали драйвери. Не витирали машини. Провізіювали додаток для всіх користувачів і заново зареєстрували його для уражених профілів. Проблема зникла до обіду, а художники повернулись сперечатись про размиття об’єктива замість драйверних UI.

«Нудна практика» — просто ставитись до кінцевих точок як до флоту: фіксовані базові версії, невеликі health-чекі й задокументовані шляхи відновлення. Це не гламурно. Але це утримує систему в роботі.

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

Цей розділ існує, щоб зупинити вас від дорогих дій для дешевих проблем.

1) Симптом: Панель керування відсутня в контекстному меню робочого столу (Windows 11)

Корінна причина: Windows 11 ховає застарілі записи контекстного меню під «Show more options», або Explorer не оновився після інсталяції/оновлення.

Виправлення: Використайте «Show more options», перезапустіть Explorer і запустіть через AppsFolder. Якщо AppsFolder працює — проблема вирішена.

2) Симптом: Панелі керування немає в пошуку меню Пуск

Корінна причина: AppX встановлено, але індекс пошуку не оновлений; або інсталяція прив’язана до конкретного профілю користувача.

Виправлення: Запустіть напряму (AppsFolder або nvcplui.exe), потім закріпіть у меню Пуск. Якщо відсутній лише для одного користувача — перевірте і перевірте повторну реєстрацію AppX для цього профілю.

3) Симптом: Панель керування відкривається й миттєво закривається

Корінна причина: Пошкоджена реєстрація AppX, несумісні компоненти після оновлення драйвера або відключений NVIDIA Display Container.

Виправлення: Переконайтесь, що Display Container працює. Якщо так — перевірте повторну реєстрацію/перевстановлення AppX-пакета Панелі керування. Якщо служба не стартує через відсутній файл — виконайте чисту перевстановку драйвера.

4) Симптом: Панель керування встановлена, але відсутні налаштування «Display»

Корінна причина: Гібридна графіка; iGPU володіє шляхом відображення (часто на ноутбуках). Панель керування NVIDIA не покаже налаштувань дисплея, які вона не контролює.

Виправлення: Використовуйте налаштування Windows і засоби iGPU (Intel/AMD); або підключіть дисплей до порту, прив’язаного до NVIDIA GPU (залежить від моделі); або перемкніть MUX у BIOS, якщо підтримується.

5) Симптом: Драйвер є, але AppX-пакет Панелі керування не встановлено, а Store заблоковано

Корінна причина: DCH UI залежить від Store/AppX; корпоративна політика блокує Store.

Виправлення: Провізіонуйте додаток через затверджений корпоративний механізм AppX або змініть стратегію пакування драйверів у контрольований спосіб. Не просіть користувачів «просто увійти в Store» — це проблема відповідності політикам.

6) Симптом: Перевстановлення драйверів «інколи» виправляє проблему

Корінна причина: Ви періодично перемикаєтесь між OEM та generic пакетами або між моделями драйверів, і іноді UI випадково опиняється в робочому стані.

Виправлення: Виберіть один підтриманий шлях пакета для цієї моделі машини. Стандартизуйтесь. Перевіряйте сервіс + пакет додатка + тест запуску.

7) Симптом: Панель керування відсутня лише під час віддаленого робочого столу

Корінна причина: RDP-сесія використовує інший шлях драйвера відображення або політику; UI може не показувати ті самі опції.

Виправлення: Перевіряйте локально/консольно. Якщо управління через віддалений доступ необхідне — використовуйте OOB-методи або забезпечте сесію з прискоренням GPU, де потрібно.

8) Симптом: Панель керування зникла після «debloat» або утиліт очищення

Корінна причина: Ці інструменти видаляють AppX-пакети, служби або заплановані завдання, не розуміючи залежностей.

Виправлення: Скасуйте зміни інструмента, якщо можливо; відновіть пакет/службу; інакше виконайте чисту перевстановку. Потім забороніть цей інструмент на продакшн-пристроях.

Чек-листи / покрокові плани

План A: Мінімальний, розсудливий шлях (виправлення без перевстановлення)

1. Перевірте присутність GPU (Завдання 2). Якщо пристрій NVIDIA не в порядку, проблема не в «відсутній Панелі керування», а в драйвері/обладнанні.
2. Перевірте службу Display Container (Завдання 4). Якщо зупинена — запустіть її (Завдання 5). Якщо не стартує — візьміть журнал подій (Завдання 6).
3. Перевірте, чи Панель керування — AppX (Завдання 7). Якщо є — запустіть через AppsFolder (Завдання 9). Якщо запускається — виправляйте віднаходження (Завдання 10).
4. Якщо існує виконуваний файл Standard драйвера (Завдання 11) — запустіть його (Завдання 12), потім закріпіть у меню Пуск.
5. Повторно перевірте симптом: пошук у меню Пуск, контекстне меню правого кліку та прямий запуск. Не оголошуйте перемогу, поки не зможете відтворити виправлення.

План B: Корпоративне середовище (враховуючи політику)

1. Перевірте політику Store (Завдання 8). Якщо Store вимкнено і ви на DCH, вважайте, що UI потребує корпоративної провізії.
2. Визначте спосіб доставки, що підтримується: провізіонуйте AppX для всіх користувачів або оберіть OEM-пакет, який включає UI і не залежить від Store у вашому середовищі.
3. Підтвердіть через health-check при вході: служба працює, пакет встановлений, тест запуску. Розглядайте це як гігієну кінцевих точок.
4. Заморозьте відому добру версію драйвера для кожної моделі і змінюйте її навмисно, а не коли Windows Update «надихнеться».

План C: Чиста перевстановлення (коли файли/служби дійсно пошкоджені)

1. Підтвердіть, що служба не працює через відсутні бінарні файли (Завдання 6). Якщо так — припиніть намагатись «перегорнути» служби.
2. Видаліть конфліктуючі пакети стандартними шляхами видалення. Уникайте змішування OEM і generic інсталяторів «на ходу».
3. Встановіть відомий добрий пакет драйвера, відповідний для hardware і вашого середовища (DCH з провізією AppX або Standard де підтримується).
4. Негайно перевірте: служба працює, Панель керування запускається, контекстне меню відображається, налаштування зберігаються після перезавантаження.

Операційний чек-лист: що задокументувати на наступний раз

• Гілка драйвера і версія, що працює для цієї моделі машини.
• Чи система використовує DCH і тому потребує провізії AppX.
• Необхідні служби (особливо NVDisplay.ContainerLocalSystem) і їхній StartType.
• Відомий робочий спосіб запуску (команда AppsFolder або шлях nvcplui.exe).
• Примітки щодо обмежень гібридної графіки (який порт прив’язаний до якого GPU, поведінка BIOS MUX).

FAQ

Чому Панель керування NVIDIA зникла після оновлення драйвера?

Тому що драйвер і UI можуть постачатись окремо (особливо з DCH). Драйвер оновився; додаток UI міг не оновитись, бути видаленим або не встановитись через політику.

Чи Панель керування NVIDIA тепер — додаток Microsoft Store?

На багатьох DCH-установках — так: це AppX-пакет (часто від NVIDIA Corporation). Це полегшує оновлення, але й ускладнює ситуацію в обмежених середовищах.

Я не можу використовувати Microsoft Store на робочому ПК. Як повернути Панель керування?

Спочатку перевірте, чи Store заблоковано політикою (Завдання 8). Далі потрібен корпоративно-затверджений спосіб провізії AppX-пакета Панелі керування NVIDIA або підтримуваний шлях пакування драйвера для вашого флоту. «Просто увійдіть особистим обліковим записом» — не рішення; це питання відповідності політикам.

Додаток встановлено, але нема в контекстному меню. Чи він зламався?

Не обов’язково. Windows 11 може ховати запис під «Show more options», і Explorer може не оновити shell-розширення після оновлення. Перезапустіть Explorer (Завдання 10) і спробуйте запуск напряму (Завдання 9 або 12).

Чому всередині Панелі керування відсутні налаштування «Display»?

На багатьох ноутбуках iGPU керує вбудованим дисплеєм. NVIDIA може не контролювати пайплайн відображення, тому вона не покаже налаштувань, які вона не може застосувати. Це нормально.

Яку службу перевіряти перш за все?

NVDisplay.ContainerLocalSystem (часто відображається як NVIDIA Display Container LS). Якщо вона зупинена або відключена — інтеграція UI часто зникає.

Чи можна просто скопіювати nvcplui.exe з іншої машини?

Можна, але не варто. Панель керування пов’язана з компонентами драйвера та реєстраціями. Копіювання бінарників створює крихкий, непідтримуваний стан. Виправляйте через коректну інсталяцію або провізію AppX.

Чи впливає GeForce Experience на появу Панелі керування?

GeForce Experience не є обов’язковим для Панелі керування, але може впливати на шляхи інсталяції драйверів і вибір компонентів. При діагностиці збережіть стек простим: драйвер + необхідні служби + пакет Панелі керування.

Чому все працює локально, але не по RDP?

Тому що RDP може представляти інший шлях графіки і не відкривати ті самі UI-хуки. Спочатку перевіряйте локально; віддалену поведінку розглядайте окремо.

Що робити, якщо nvidia-smi працює, а Панель керування ні?

Зазвичай це означає, що драйвер у порядку, а проблема — у доставці UI (AppX відсутній/пошкоджений) або у службі/shell-інтеграції. Почніть з Завдань 4, 7 і 9.

Висновок: дієві кроки далі

Припиніть ставитись до відсутньої Панелі керування NVIDIA як до містичної історії. Розглядайте систему як набір компонентів: драйвер, служби, пакет додатка і інтеграція shell. Спершу вимірюйте, потім змінюйте по одному параметру.

1. Пройдіть швидкий план діагностики: пристрій присутній, Display Container працює, пакет/виконуваний файл існує, прямий запуск працює.
2. Якщо служба зупинена, запустіть її і перезапустіть Explorer. Це найвищий ROI-виправлення.
3. Якщо Store заблоковано і ви на DCH, піднімайте питання провізії AppX або змінюйте шлях пакування на підтримуваний. Не боріться з політикою хаками.
4. Якщо інсталяції пошкоджені, робіть чисту перевстановку — але лише після доведення її необхідності.
5. Документуйте вашу базу (версія драйвера, DCH/Standard, необхідні служби, спосіб запуску), щоб наступного разу все було нудно й швидко.