BIOS, драйвер чи Windows: хто керує вашим обладнанням (і як перевірити)

Працююча ментальна модель: хто за що відповідає і коли

Уявіть собі контроль апаратури як естафету з трьома бігунами і дивовижною кількістю упущених паличок:

• BIOS/UEFI (платформна прошивка): вмикає систему, перераховує пристрої, застосовує політики платформи (навчання пам’яті, налаштування PCIe link, таблиці ACPI), а потім здебільшого відходить убік.
• Прошивка пристрою (в SSD/NIC/HBA/GPU): реалізує поведінку пристрою: управління чергами, відновлення після помилок, термостатування, кешування, особливості узгодження лінку і інколи чорний гумор виробника.
• Драйвери: перетворюють запити ОС на операції пристрою; реалізують енергоменеджмент, обробку переривань, налаштування DMA, інтеграцію з плануванням вводу/виводу, офлоади та специфічні тюнінги. Саме тут часто виграється чи втрачається продуктивність.
• Windows (ядро + підсистеми зберігання/мережі): визначає політику: планування, управління пам’яттю, поведінку I/O-стека, плани живлення, безпеку та що означає «здорово».

Отже, хто «контролює» апаратне забезпечення? Той шар, який приймає рішення в цей момент:

• Під час завантаження: BIOS/UEFI за кермом. Він задає початкові умови. Він також вирішує, у що Windows має вірити щодо апаратури через ACPI та перерахунок пристроїв.
• Після завантаження: Windows і драйвери здебільшого керують. Прошивка пристрою залишається «рефлексами» пристрою: термобрейка, фонове прибирання, скидання лінку, внутрішні таймаути.
• Під навантаженням / під час збоїв: прошивка часто стає реальним босом. Якщо контролер починає відновлення після помилок або скидається, ОС може лише реагувати.

Коли ви налагоджуєте, ви не питаєте «хто винен?» Ви питаєте:

1. Який шар приймає рішення, що відповідає моєму симптому?
2. Які докази я можу зібрати за 5 хвилин, щоб це підтвердити?
3. Яка зміна є відновлюваною та безпечною?

Цитата, яка збереже вас від помилок. Це перероблена ідея від John Allspaw (операції/надійність): paraphrased idea — «Надійність не виправляється через пошук винних; її виправляють, вивчаючи, як система насправді поводиться.»

Жарт №1: Якщо ви думаєте, що ваш сервер «просто вирішив» працювати в режимі PCIe x1 — вітаю, ви зустріли найменш кумедну гру «обери свою пригоду».

Історичний контекст та цікаві факти (те, що кусає пізніше)

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

1. BIOS не був розроблений для сучасного обладнання. Класичний BIOS походить з ранньої ери ПК; UEFI з’явився, щоб впоратися з сучасним завантаженням, великими дисками та багатшими перед-ОС сервісами.
2. ACPI — це контракт. Windows значною мірою покладається на таблиці ACPI від прошивки, щоб розуміти стани живлення, топологію пристроїв і можливості платформи. Поганий ACPI може роками виглядати як «помилка Windows».
3. Option ROM колись керували процесом. Контролери зберігання і мережі історично постачали BIOS-розширення (Option ROM), які виконували ініціалізацію пристрою під час завантаження. UEFI-драйвери замінили багато цього, але спадкові поведінки досі переслідують шляхи завантаження.
4. NVMe — «просто» за дизайном. NVMe скоротив шари порівняно з SATA/AHCI, але це зробило взаємодію драйвера і прошивки більш видимою: черги, переривання та стани живлення мають значення негайно.
5. Модерація переривань стара, але її все ще неправильно розуміють. NIC-и вже десятиліттями збирають переривання. Це чудово для пропускної здатності, погано для затримок, і часто налаштовується у драйверах — інколи «з корисною метою».
6. Storport замінив старіші моделі зберігання в Windows для продуктивності. Сучасні високопродуктивні storage miniport-ери лежать на Storport; тому HBA/RAID/NVMe драйвери поводяться інакше, ніж «просте» зберігання.
7. Управління живленням у Windows стало агресивнішим з часом. CPU C-states, PCIe ASPM, політики простою пристроїв і сучасний режим очікування змінили стандартні припущення. Чудово для ноутбуків; іноді пікантно для серверів.
8. Secure Boot і підпис драйверів змінили гру драйверів. Тепер ви не можете просто так завантажити сумнівні ядрові драйвери. Це добре — поки ви тестуєте хотфікс від вендора о 2-й ночі.

Межі контролю: BIOS/UEFI vs прошивка vs драйвери vs Windows

Що насправді контролює BIOS/UEFI

BIOS/UEFI контролює платформу. Він не «керує» вашими пристроями в робочому стані, але визначає початкові умови:

• Топологія PCIe і тренінг лінків (ширина ліній, узгоджена швидкість, налаштування біфуркації).
• Навчання пам’яті і таймінги (і чи працюють DIMM-ні слоти на заявленій швидкості або в «безпечному режимі»).
• Функції CPU та віртуалізаційні перемикачі (VT-x/VT-d, увімкнення SR-IOV у прошивці, поведінка IOMMU, яка експонується ОС).
• Політики живлення і терморежими (обмеження PL1/PL2, криві вентиляторів, «тихий режим», який робить сервери невідомо повільними).
• Порядок завантаження, Secure Boot, TPM, вимірюване завантаження.
• Таблиці ACPI, які Windows читає як писання.

BIOS/UEFI також постачає мікрокод і елементи керування платформою. Але якщо ви налагоджуєте падіння пропускної здатності опівдні в середу, BIOS не бігає в циклі, пересилаючи ваші пакети.

Що контролює прошивка пристрою (і без запиту)

Прошивка всередині пристрою — це місце, де фактично живе «поведінка апаратури»:

• Відновлення після помилок і повторні спроби: таймаути, abort-и, скидання лінку, ремапінг поганих блоків.
• Термобрейка: SSD і GPU це роблять; дехто з NIC теж; ОС дізнається про це постфактум.
• Внутрішнє планування: NAND FTL, поведінка відправлення/завершення NVMe, політики кешування RAID-контролера.
• Фонова робота: garbage collection, wear leveling, patrol reads, scrubs.

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

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

Драйвери сидять на межі, де намір стає реальністю:

• Стратегія обробки переривань: лінійні vs MSI/MSI-X, прив’язка до CPU, модерація/згортання.
• DMA-мапінг: як буфери закріплюються та відображаються, що взаємодіє з налаштуваннями IOMMU.
• Енергоменеджмент: idle-політика пристрою, стани лінку, selective suspend.
• Офлоади: RSS/RSC/LSO у NIC; глибина черги та поведінка кешу записів у зберіганні.
• Поверхня помилок: баг драйвера може зашпаклювати систему або «лише» обмежити продуктивність до 30% без явних помилок.

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

Що контролює Windows (політика та оркестрація)

Windows — це планувальник, рефері і іноді той, хто рухає ворота:

• Планування CPU і розміщення потоків.
• Управління пам’яттю, включно з поведінкою кешу сторінок, яка може зробити результати бенчмарків підозрілими.
• Політика I/O-стека: черги зберігання, поведінка файлової системи, кешування, write barriers.
• Безпека: HVCI/Memory Integrity, Credential Guard, VBS — вони можуть змінювати характеристики продуктивності.
• Плани живлення та політики пристроїв щодо енергоспоживання.

Windows також зберігає журнали подій. Якщо ви їх не читаєте — ви налагоджуєте в пов’язці на очах.

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

Це «у мене 15 хвилин перед тим, як дзвінок по інциденту стане гіршим» план. Мета не ідеальна істина. Мета — знайти шар-винуватець з високою впевненістю та мінімальним впливом.

Перше: підтвердьте, що симптом реальний і локальний

• Одна машина чи багато? Одна машина кричить «апаратне, драйвер або локальна конфігурація». Багато машин кричить «оновлення Windows, політика, зсув навантаження або спільна залежність».
• Один клас пристроїв? Лише зберігання? Лише мережа? Лише GPU? Не узагальнюйте. Класифікуйте.
• Чи можна відтворити простим тестом? Одиночне читання диска, простий мережевий тест типу iperf (у Windows теж є інструменти), одноядерний CPU-стрес.

Друге: зіставте вузьке місце з підсистемою

• Зберігання: висока затримка диска, довжини черг, скидання або таймаути контролера.
• Мережа: дропи, ретрансмісії, високий CPU в обробці переривань/DPC або низьке узгоджене лінк-швидкість.
• CPU/живлення: частота застрягла низько, дивні C-state, термоблокування.
• PCIe: ширина/швидкість лінка понижена, AER-помилки, флапінг пристроїв.

Третє: вирішіть, який шар перевіряти першим

1. Політика/конфігурація Windows (швидко перевірити, легко відмінити): план живлення, VBS-функції, політика кешу записів, версії драйверів.
2. Поведінка драйвера (середньо): переривання, офлоади, глибина черг, storport скиди, події мініпорту.
3. Прошивка/BIOS/UEFI (повільніше, ризикованіше): біфуркація PCIe, перемикачі SR-IOV, ASPM, оновлення BIOS, прошивка пристрою.

Правило: якщо ви не можете пояснити, як налаштування BIOS впливає на симптом, не чіпайте його під час інциденту. Це не дисципліна; це виживання.

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

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

Завдання 1: Визначити версію BIOS/UEFI і дату випуску прошивки

cr0x@server:~$ wmic bios get smbiosbiosversion, releasedate
ReleaseDate                SMBIOSBIOSVersion
20231108000000.000000+000  2.1.7

Значення: Ви дивитесь версію платформної прошивки і дату випуску. Стара прошивка не означає автоматично «погано», але часто означає «відомі дивні поведінки».

Рішення: Якщо ви бачите відомі проблеми в середовищі (пониження PCIe link, скиди NVMe), заплануйте контрольоване оновлення BIOS. Не під час збою.

Завдання 2: Підтвердити збірку Windows та рівень патчів

cr0x@server:~$ systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"Hotfix(s)"
OS Name:                   Microsoft Windows Server 2022 Standard
OS Version:                10.0.20348 N/A Build 20348
Hotfix(s):                 5 Hotfix(s) Installed.

Значення: Номер збірки важливий; поведінка ядра/зберігання змінюється з накопичувальними оновленнями.

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

Завдання 3: Подивитись, які драйвери завантажені (не те, що ви думаєте встановлено)

cr0x@server:~$ driverquery /v /fo table | findstr /I "stor nvme iastor mlx e1d"
stornvme.sys     ...   Microsoft Corporation   ...
storport.sys     ...   Microsoft Corporation   ...
mlx5.sys         ...   Mellanox Technologies   ...
e1d68x64.sys     ...   Intel Corporation       ...

Значення: Завантажений драйвер — це правда. Скриншот Device Manager — лише відчуття.

Рішення: Якщо ви очікували вендорський NVMe-драйвер, а бачите stornvme.sys, ваші припущення про тюнінг хибні. Коригуйте відповідно.

Завдання 4: Перевірити помилки контролера зберігання в системному журналі подій

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=129 or EventID=153 or EventID=157)]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-StorPort
  Event ID: 129
  ...
  Description: Reset to device, \Device\RaidPort0, was issued.

Значення: Event ID 129 — це таймаут/скидання Storport. Це не «додаток повільний». Це стогін стеку зберігання.

Рішення: Якщо 129/153/157 з’являються під час сплесків латентності, перестаньте тюнити кеш Windows і почніть досліджувати драйвер/прошивку та фізичний рівень (кабелі/бэкплейн/PCIe).

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

cr0x@server:~$ typeperf "\PhysicalDisk(*)\Avg. Disk sec/Read" "\PhysicalDisk(*)\Avg. Disk sec/Write" "\PhysicalDisk(*)\Current Disk Queue Length" -sc 3
"(PDH-CSV 4.0)","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Read","\\server\PhysicalDisk(0 C:)\Avg. Disk sec/Write","\\server\PhysicalDisk(0 C:)\Current Disk Queue Length"
"10.000000","0.003412","0.089532","7.000000"
"10.000000","0.002981","0.102114","9.000000"
"10.000000","0.003105","0.095220","8.000000"

Значення: Читання в нормі, записи ~100ms, черга диска немала. Це зазвичай прошивка/пристрій, відключений кеш запису, тиск write barrier або контролер в стресі.

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

Завдання 6: Підтвердити поведінку TRIM/ReTrim (SSD) і чи вважає Windows диск SSD

cr0x@server:~$ fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0
ReFS DisableDeleteNotify = 0

Значення: 0 означає, що TRIM увімкнено. Якщо TRIM відключено на SSD-накопичувачах, довгострокова продуктивність запису може погіршитись.

Рішення: Якщо ви бачите тривалу деградацію записів протягом тижнів/місяців, перевірте TRIM і поведінку GC у прошивці пристрою.

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

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

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

Рішення: Для критично важливих серверів переходьте на High performance (після перевірки температур) або явно налаштуйте мінімальний стан процесора.

Завдання 8: Підтвердити, що частота CPU не застрягла низько (термальні/енергетичні обмеження)

cr0x@server:~$ wmic cpu get name, currentclockspeed, maxclockspeed
CurrentClockSpeed  MaxClockSpeed  Name
1896               3500           Intel(R) Xeon(R) Silver ...

Значення: Якщо current clock значно менше за max під навантаженням, можливо обмеження живлення, термоблокування або агресивна політика живлення.

Рішення: Корелюйте з навантаженням; якщо під навантаженням значення все ще низьке — перевірте BIOS-обмеження живлення, охолодження та налаштування Windows.

Завдання 9: Перевірити наявність PCIe-пристрою та коди проблем

cr0x@server:~$ pnputil /enum-devices /problem /class System
Instance ID: PCI\VEN_8086&DEV_2030&SUBSYS_...
Problem: 0000000A (CM_PROB_FAILED_START)

Значення: Пристрої з кодами проблем не «працюють частково». Вони не працюють. Іноді Windows переключається на загальні шляхи.

Рішення: Виправте прив’язку драйвера та налаштування прошивки перед тюнінгом. Ви не зможете оптимізувати пристрій, який не стартував.

Завдання 10: Проінспектувати стан NIC — лінк і швидкість

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed, DriverInformation"
Name   Status  LinkSpeed DriverInformation
Ethernet0 Up   1 Gbps    Intel(R) Ethernet Controller X710 ...

Значення: Якщо ви очікували 10/25/40/100GbE, а маєте 1Gbps — припиніть усе інше. Це ваш вузький місце.

Рішення: Перевірте конфіг switch-порту, кабель/трансівер і розширені властивості NIC. Не звинувачуйте TCP.

Завдання 11: Перевірити NIC-офлоади, які можуть допомогти або зашкодити

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet0 | Where-Object {$_.DisplayName -match 'RSS|RSC|LSO|Checksum'} | Select-Object DisplayName, DisplayValue"
DisplayName                 DisplayValue
Receive Side Scaling        Enabled
Receive Segment Coalescing  Enabled
Large Send Offload v2 (IPv4) Enabled
IPv4 Checksum Offload       Rx & Tx Enabled

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

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

Завдання 12: Шукати тиск DPC/ISR (класичний вузький місце драйвера)

cr0x@server:~$ typeperf "\Processor(_Total)\% DPC Time" "\Processor(_Total)\% Interrupt Time" -sc 5
"(PDH-CSV 4.0)","\\server\Processor(_Total)\% DPC Time","\\server\Processor(_Total)\% Interrupt Time"
"1.000000","12.482931","6.193847"
"1.000000","14.110332","7.003218"
"1.000000","11.802104","6.552190"
"1.000000","13.224987","6.990114"
"1.000000","12.901443","6.401008"

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

Рішення: Якщо DPC/Interrupt постійно високі при помірному навантаженні — зосередьтеся на версіях NIC/стор драйверів, модерації переривань, RSS-конфігурації та прошивці.

Завдання 13: Підтвердити статус VBS/HVCI (функції безпеки, що можуть змінювати продуктивність)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning"
1
2

Значення: Непорожній вивід вказує, що сервіси безпеки (як Credential Guard або HVCI) запущені. Це не «погано», але це змінна, яку треба враховувати.

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

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

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, IsWriteCacheEnabled"
FriendlyName        MediaType  BusType IsWriteCacheEnabled
NVMeDisk0           SSD        NVMe    True
SATADisk1           HDD        SATA    False

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

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

Завдання 15: Підтвердити скиди пристрою та помилки PCIe в журналах подій

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger']]]" /c:5 /f:text
Event[0]:
  Provider Name: Microsoft-Windows-WHEA-Logger
  Event ID: 17
  ...
  Description: A corrected hardware error has occurred.

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

Рішення: Якщо WHEA 17/19 корелює зі спадом продуктивності — перевірте сідіння PCIe, бэкплейн, райзери, BIOS-налаштування PCIe та прошивку пристрою. Це не баг додатку.

Жарт №2: Єдина річ більш оптимістична за «ймовірно, все гаразд» — це «ймовірно, це DNS».

Три корпоративні міні-історії з передової

1) Інцидент через хибне припущення: «BIOS налаштовує швидкість NIC, так?»

Середня компанія розгорнула новий стійок Windows Server для внутрішнього latency‑чутливого сервісу. План розгортання був чистим: ідентичне обладнання, однаковий профіль BIOS, автоматизований інстал та швидке smoke-тестування. Smoke-тест пройшов — CPU, пам’ять, диск виглядали нормально.

Потім прийшов продакшен-трафік. Латентність подвоїлася. Пропускна здатність вирівнялася. Графіки виглядали як класична проблема CPU, але навантаження CPU підозріло було низьким. Люди робили те, що люди роблять: сварилися про те, чи то «додаток».

Припущення було, що BIOS «налаштовує NIC» і тому NIC має бути в порядку. Швидка перевірка Get-NetAdapter зруйнувала це: NIC-і домовилися про 1Gbps замість очікуваної вищої швидкості. Профіль BIOS був неважливим; узгодження лінку було між NIC та комутатором. Деякі порти були зафіксовані в несподіваному режимі швидкості/дуплексу через успадкований шаблон комутатора.

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

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

2) Оптимізація, що зіграла злий жарт: «Увімкніть усі офлоади — це безкоштовно»

Інша організація мала pipeline для інжесту файлів на Windows, який «занадто навантажував CPU». Хтось, намагаючись допомогти, увімкнув набір офлоадів NIC по всьому парку: large send, receive coalescing, checksum offloads та кілька вендорних поліпшень. CPU упав. Всі святкували. Тікет закрили з задоволеним коментарем і без плану перевірки після впровадження.

Через два тижні інцидент: періодичні зависання і ретрансмісії, але лише під певними патернами трафіку. Моніторинг показав періодичні сплески DPC time і мережевої латентності. Зберігання виглядало нормально. Логи додатку були шумні, але неінформативні.

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

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

Мораль: ручки продуктивності — як спеції. Трохи — чудово. Вилити всю банку — будете шкодувати.

3) Нудна, але правильна практика, що врятувала день: «Знімки базової лінії до і після»

Велике підприємство експлуатувало Windows-хости з мішаниною NVMe та RAID-підтриманого зберігання. У них була практика, що виглядала болісно бюрократичною: кожна зміна платформи вимагала зняття базового пакету — інвентар драйверів, ключові лічильники перфу та короткий синтетичний I/O тест. Це було автоматизовано і зберігалося разом із записом про зміну.

В одного кварталу набір хостів почав бачити спорадичні storport скиди (Event ID 129) і сплески затримки запису. Першою реакцією було звинувачення останнього накопичувального оновлення Windows. Така теорія була емоційно приємна й технічно правдоподібна.

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

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

Нудна практика — консистентні базові знімки — не лише зекономила час. Вона запобігла відкату патчу безпеки, який насправді не був причетний.

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

1) «Диск повільний» під час бенчмарків, а додатки в порядку

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

Корінь: Файлова кешування та поведінка write-back; бенчмарк вимірює RAM або скидання кешу, а не пристрій.

Виправлення: Використовуйте послідовну методологію тестування; дивіться Avg. Disk sec/* і довжину черги; запускайте тести, що обходять кеш коли потрібно (або як мінімум очищуйте між запусками). Порівнюйте з лічильниками, а не лише MB/s.

2) Мережевий throughput обрізано рівно на 1Gbps (або 10Gbps) на «швидшому» обладнанні

Симптом: Пропускна здатність упирається в жорстку межу; CPU низький; помилок немає.

Корінь: Узгодження лінку або профіль порту комутатора; неправильний кабель/трансівер; інколи примусовий режим NIC.

Виправлення: Перевірте Get-NetAdapter link speed; валідуйте конфіг комутатора і фізичний рівень; уникайте думки «це має бути Windows».

3) Випадкові I/O-зависання зі sкидами Storport

Симптом: Event ID 129 хвилями; сплески латентності; інколи тимчасові «зависання».

Корінь: Таймаути драйвера зберігання, відновлення прошивки, проблеми сигналу PCIe або кеш контролера.

Виправлення: Корелюйте журнали подій з латентністю; оновіть драйвер зберігання і прошивку пристрою в контрольованому вікні; перевірте кабелі/бэкплейн/райзери; перевірте виправлені WHEA-помилки.

4) Продуктивність погіршилась після «укріплення безпеки»

Симптом: Зростання витрат CPU; більш варіабельна затримка I/O; інколи більше контекстних перемикань.

Корінь: VBS/HVCI/Device Guard змінюють поведінку ядра і обмеження виконання драйверів; деякі драйвери працюють гірше в таких умовах.

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

5) CPU виглядає недовантаженим, але система «повільна»

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

Корінь: Високий час DPC/переривань; драйверні шторм-ефекти; поганий RSS; переривання зберігання прив’язані до одного ядра.

Виправлення: Перевірте % DPC Time і % Interrupt Time; оновіть/налаштуйте NIC/диск драйвери; налаштуйте RSS; обережно відрегулюйте модерацію переривань.

6) NVMe «швидкий диск» працює як SATA

Симптом: Менше очікуваних IOPS/пропускної здатності; висока затримка під навантаженням.

Корінь: PCIe-лінк тренований вниз (x1, Gen1/Gen2); термоблокування; проблеми зі станами живлення.

Виправлення: Перевірте WHEA-помилки; перевірте BIOS-налаштування PCIe; підтвердьте охолодження; перевірте драйвер; оцініть стійку продуктивність, а не лише короткі сплески.

7) «Кеш контролера RAID робить все швидким», а потім страх втрати даних

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

Корінь: Write-back cache увімкнено без батарейного/флеш-бекованого захисту; ОС очікує гарантії надійності, які не надаються.

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

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

Контрольний список A: Перед тим як чіпати налаштування BIOS/UEFI

1. Зафіксуйте поточну версію BIOS (wmic bios) і експортуйте конфігурацію BIOS, якщо інструменти вендора це підтримують.
2. Запишіть поточну збірку Windows та інвентар драйверів (systeminfo, driverquery).
3. Зберіть зразки журналів подій: Storport, WHEA та відповідні постачальники пристроїв.
4. Запустіть коротку базову перевірку: затримки диска, DPC/Interrupt лічильники, швидкість NIC link.
5. Визначте план відкату: як повернути налаштування BIOS, як відновити систему якщо вона не завантажується.

Контрольний список B: Контрольована зміна драйвера (розумний підхід)

1. Визначте поточний завантажений драйвер і версію (driverquery /v).
2. Змінюйте по одному компоненту за раз (NIC або драйвер зберігання, а не обидва одночасно).
3. Розгорніть на невеликій канарковій вибірці з репрезентативним навантаженням.
4. Вимірюйте: пропускна здатність, латентність, DPC/Interrupt час, журнали подій.
5. Піднімайте поступово; майте готовий відомий‑хороший пакет драйверів для відкату.

Контрольний список C: Ізоляція вузького місця зберігання за 30 хвилин

1. Перевірте storport скиди/таймаути (Event 129/153/157).
2. Виміряйте Avg. Disk sec/Read, Avg. Disk sec/Write, довжину черги.
3. Перевірте стан кешу записів (Get-PhysicalDisk) і підтвердьте припущення про довговічність.
4. Пошукайте WHEA виправлені помилки навколо тих же часових позначок.
5. Якщо є невідповідності прошивок/драйверів між хостами — сегментуйте і порівняйте.

Контрольний список D: Ізоляція мережевого вузького місця за 30 хвилин

1. Підтвердьте узгоджену швидкість лінку (Get-NetAdapter).
2. Виміряйте DPC/Interrupt час; корелюйте з провалами пропускної здатності.
3. Перегляньте налаштування офлоадів; порівняйте з відомим‑хорошим хостом.
4. Шукайте скиди драйвера або попередження в системному журналі подій.
5. Ескалюйте до фізичного рівня (комутатор/трансівер/кабель) якщо лінк неправильний.

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

1) Чи контролює BIOS мою продуктивність зберігання після завантаження?

Зазвичай не безпосередньо. BIOS задає початкові умови (PCIe link, ACPI, режим контролера). Після завантаження домінують драйвер Windows і прошивка пристрою.

2) Якщо я оновлю драйвер, чи треба також оновлювати прошивку?

Не завжди, але для критичних пристроїв (NIC, HBA, NVMe) слід розглядати драйвер і прошивку як пару. Багато «помилок драйвера» — це взаємодії з прошивкою.

3) Чому я бачу Storport Event ID 129, але диски «виглядають здоровими»?

Бо «здорово» в термінах SMART може все одно включати таймаути і скиди. Event 129 стосується таймаутів I/O і відновлення, яке може відбуватися через маргінальні PCIe‑лінки, зупинки прошивки або проблеми драйвера.

4) Чи поганий вбудований драйвер Microsoft?

Ні. Inbox-драйвери часто стабільні і надійні. Але вендорні драйвери можуть відкривати тюнінги, офлоади або телеметрію, які вам потрібні. Використовуйте драйвер, який відповідає вашим вимогам і протестуйте його.

5) Чи можуть налаштування живлення Windows справді впливати на продуктивність сервера?

Так. Плани живлення і політики idle впливають на поведінку частоти CPU і інколи на стани живлення PCIe. Якщо вам потрібна передбачувана латентність — явно перевірте конфігурацію живлення.

6) Як зрозуміти, чи вузьке місце — переривання?

Перевірте % DPC Time і % Interrupt Time за допомогою typeperf. Якщо вони високі і корелюють з проблемами пропускної здатності чи латентності — часто це драйвер.

7) Чому продуктивність відрізняється між «ідентичними» серверами?

Бо вони рідко ідентичні: різні ревізії прошивки, різні версії драйверів, різне розведення PCIe слотів, різні BIOS‑дефолти, різні порти комутатора або різні термальні умови.

8) Чи слід змінювати налаштування BIOS під час інциденту?

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

9) Як уникнути обману кешування у дискових тестах?

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

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

Припиніть трактувати «BIOS vs драйвер vs Windows» як філософське питання. Це проблема меж контролю. Швидкі команди перемагають, довівши, який шар володіє симптомом, а потім роблячи по одній відновлюваній зміні.

1. Автоматизуйте збір базового пакету: версія BIOS, збірка Windows, завантажені драйвери, швидкість NIC link, ключові лічильники продуктивності та витяги журналів подій.
2. Додайте дві перевірки введення в експлуатацію для кожного нового хоста: очікувана швидкість NIC link і відсутність потоків виправлених WHEA-помилок.
3. Побудуйте матрицю драйверів/прошивок для критичних пристроїв і зафіксуйте версії. «Найновіше» — це не стратегія; це надія.
4. Практикуйте швидкий план діагностики на здоровій системі, щоб не вчитися командам під час інциденту.

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