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

Що насправді означає ця проблема (і чому вона повторюється)

«Порт» — це перевантажений термін. Іноді він означає «компілюється і проходить юніт-тести». Іноді — «може бути зібраний у нашому дистрі». Іноді — «ми винесли API, але реалізація — no-op». А іноді — «працює, якщо примружитися і уникати половини функцій».

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

• Наявність під час збірки без можливостей під час виконання. Бінарний файл містить код, але kernel, файловою система, апаратне забезпечення або права блокують шлях.
• Часткова реалізація. Працює «щасливий шлях», краєві умови — ні, а саме ці краєві випадки й влучають у продакшн: відмови, затори, ресинхронізація, відкат.
• Невідповідність прапорців функцій. Перемикач є, але ввімкнення нічого не активує, бо відсутня інша передумова (налаштування ядра, опція модуля, sysctl, прошивка).
• Мовчазний відкат. Система заявляє про успіх, але відкочується до повільнішого або менш безпечного режиму. Ви помічаєте це тільки після інциденту — або після першого рахунку.
• Дрейф версій та ABI. Порт відповідає заголовкам upstream, але не їхній поведінці; достатньо сумісний, щоб зібратися, але відмінний настільки, що ламає семантику.

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

І найгірша категорія — «документаційна коректність» без «операційної коректності». Якщо сторінка з функцією закінчується фразою «set enable=true», вітаємо — ви написали пресреліз, а не керівництво з експлуатації.

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

Жарт №1: Функція, що працює лише в лабораторії, називається «демо». У продакшні її називають «репетиція інциденту».

Пастка «портовано»: заяви про сумісність — не те саме, що заяви про продуктивність

Типове непорозуміння: «Підтримується» інтерпретується як «швидко», «безпечнo» або «еквівалентно». Вендори й внутрішні платформи часто мають більш вузьке зобов’язання: «не впаде відразу» або «працює з дефолтними налаштуваннями».

Для роботи зі сховищем і надійністю цього замало. Треба відповісти:

• Чи зберігає вона семантику надійності (fsync, бар’єри, скидання кешу) при втраті живлення?
• Чи коректно працює у режимі деградації (multipath failover, відновлення RAID, backfill об’єктного сховища)?
• Чи витримує вона SLOи по латентності під час компактації, GC, ресинхів та знімків?
• Чи надає вона спостережуваність (лічильники, tracepoint-и, логи), щоб ви могли довести, що вона працює?

Якщо ви не можете це довести під навантаженням — у вас не функція. У вас — думка.

Кілька фактів і історичний контекст, які варто пам’ятати

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

1. Сумісність POSIX завжди була спектром. Різні UNIX-форми історично «підтримували POSIX», але відрізнялися у крайових випадках — сигнали, семантика вводу/виводу, блокування файлів.
2. Реалізації NFS у Linux розвивалися нерівномірно між версіями. Функції на кшталт делегацій NFSv4 та idmapping довго існували, але були операційно крихкими, особливо в змішаних клієнт/сервер версіях.
3. Опції журналювання EXT4 стали полем сумісності. Режими на кшталт data=ordered, бар’єри й поведінка записів змінювалися з поліпшеннями ядра й коректністю скидання кешу пристрою.
4. Історії NVMe та SCSI multipath різні. dm-multipath був створений для поведінки ери SCSI; NVMe приніс ANA і рідні semantics multipath, і «має multipath» не означає, що воно переключається так, як ви очікуєте.
5. Флаги функцій ZFS створювали, щоб уникати пасток апгрейду пулу. Це добра система, але означає, що «ZFS доступний» не гарантує, що «цей пул сумісний усюди, куди ви плануєте його імпортувати».
6. Контейнери знову зробили видимими семантику файлових систем. Overlay та union mounts виявляють крайові випадки (rename, xattr, whiteouts), які багато застосунків не тестували поза CI.
7. glibc vs musl — це не лише розмір і ліцензія. Різниці в DNS-резолюванні, значеннях стеків потоків, локалі та кодах помилок можуть змінювати поведінку під час виконання без змін у коді.
8. Крипто-стеки мають давню традицію «компілюється нормально, а працює дивно». Між версіями OpenSSL, провайдерами, FIPS-режимами й ядром алгоритми можуть виглядати присутніми, але бути відключені політикою або без доступного прискорення.
9. Мережеві оффлоади неодноразово відправлялися з багами. TSO/GSO/GRO, checksum offload та сегментація можуть бути «підтримані» мережею, але містити баги в конкретному драйвері+прошивці.

Режими відмов: як «портовані» функції підводять у реальних системах

1) Конфігурація-но-оп: прапорець встановлено, нічого не змінюється

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

Приклади: увімкнення TRIM/discard у віртуальній машині, де гіпервізор його не пробросив; увімкнення асинхронного I/O у поєднанні libc/ядро, де код мовчки використовує синхронний I/O; увімкнення «шифрування», де є лише управління ключами, але шар шифрування відсутній або політикою відключений.

2) «Підтримується», але тільки на одному шляху виконання

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

3) Функція присутня, але семантика інша

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

Для сховищ семантика важить більше, ніж швидкість. Швидка файлова система, що брешe про надійність — це не «швидка». Це просто «мовчазно оптимістична».

4) Мовчазний відкат у «режим сумісності»

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

5) Прогалина в спостережуваності: ви не можете довести, що це працює

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

6) Різкий провал продуктивності під реальними робочими навантаженнями

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

Є перефразована ідея, часто приписувана В. Едварду Демінгу: Без даних ви — просто ще одна людина з думкою. В термінах опсів: без вимірювань ви — просто ще одна людина з pager’ом.

Жарт №2: Найшвидша система зберігання — та, що відкидає записи. Це також та, яку ваші аудитори запам’ятають.

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

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

Перший: доведіть узгодження (функція дійсно ввімкнена наскрізь?)

• Перевірте runtime-прапорці (не конфіг-файли): sysfs, procfs, інформацію про драйвер, опції монтування файлової системи.
• Перевірте версіоновані набори можливостей: флаги функцій ZFS, версії протоколу NFS, списки шифрів TLS, опції конфігурації ядра.
• Перевірте «іншу сторону»: сервер проти клієнта, гіпервізор проти гостьової ОС, контролер проти ініціатора.

Другий: спостерігайте поведінку (чи йде виконання по потрібному шляху?)

• Використовуйте лічильники й трасування: iostat, perf, bpftrace, zpool iostat, nfsstat, ethtool stats.
• Шукайте ознаки відкату: повідомлення в логах, узгоджені пониження протоколу, банери «using safe mode», попередження kernel dmesg.
• Вимірюйте розподіл латентності: p95/p99 показують обриви; середнє це приховує.

Третій: валідуйте семантику (чи робить вона те, що ви вважали?)

• Тести на надійність: перевірити поведінку fsync при симуляції втрати живлення складно, але можна валідувати команди flush, бар’єри й політику кешу.
• Тести режимів відмов: від’єднайте шлях, вбийте вузол, пошкодьте блок, заповніть диск. Якщо порт не поводиться під стресом — він не працює.
• Тести сумісності: імпорт/експорт пулів, монтування з змішаних клієнтів, апгрейд/даунгрейд компонентів.

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

Практичні завдання: 12+ команд, які покажуть, що реально підтримується

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

Завдання 1: Визначте реальне ядро та flavor збірки

cr0x@server:~$ uname -a
Linux server 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-01-23) x86_64 GNU/Linux

Що це означає: Версія ядра та збірка дистрибутива важливі, бо порти часто таргетять «Linux» загально, але залежать від конкретних бэпортів або конфігів.

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

Завдання 2: Перевірте конфіг ядра для нібито «підтримуваної» функції

cr0x@server:~$ zgrep -E 'DM_MULTIPATH|NVME_MULTIPATH|BTRFS_FS|OVERLAY_FS' /proc/config.gz
CONFIG_DM_MULTIPATH=m
CONFIG_NVME_MULTIPATH=y
CONFIG_BTRFS_FS=m
CONFIG_OVERLAY_FS=y

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

Рішення: Якщо потрібна опція відсутня, немає сенсу налаштовувати user space. Спочатку виправте ядро/модулі.

Завдання 3: Підтвердіть наявність модулів та їх параметри (runtime, не теорія)

cr0x@server:~$ lsmod | egrep 'nvme|dm_multipath|zfs|overlay'
nvme_fabrics           24576  0
nvme_core             200704  2 nvme_fabrics,nvme
overlay               155648  2

Що це означає: Якщо модуль не завантажено — функція не активна. Прямо і безжально.

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

Завдання 4: Перевірте опції монтування та реальний тип файлової системи

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /var/lib/postgresql
/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro,data=ordered

Що це означає: Багато «функцій» — це опції монтування (бар’єри, discard, noatime) і вони можуть бути відсутні або перевизначені.

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

Завдання 5: Перевірте, чи пристрій дійсно підтримує discard/TRIM

cr0x@server:~$ lsblk -D -o NAME,ROTA,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME        ROTA DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1        0      512B       2G         0
nvme0n1p2      0      512B       2G         0

Що це означає: Якщо DISC-MAX дорівнює 0B, discard не підтримується через цей стек. Це може трапитися з деякими RAID-контролерами, гіпервізорами або неправильно сконфігурованими пристроями.

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

Завдання 6: Підтвердіть експорт write cache та поведінку flush

cr0x@server:~$ sudo hdparm -W /dev/sda
/dev/sda:
 write-caching =  1 (on)

Що це означає: Увімкнений write cache не обов’язково поганий, але він змінює історію надійності. Головне питання — чи honor-яться flush-и аж до фізичного носія.

Рішення: Якщо ви не можете гарантувати захист кешу (BBU, PLP), треба ставитись до семантики fsync з підозрою та коригувати дизайн зберігання.

Завдання 7: Швидко виміряйте латентність I/O та насичення

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0-18-amd64 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.21    0.00    1.10    8.42    0.00   87.27

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
nvme0n1        120.0   980.0  4800.0 64000.0     0.0     0.0   92.1   14.3

Що це означає: Високий %util і зростання await вказують на насичення пристрою або чергування. Якщо ваш «портований» функціонал мав зменшити латентність — він цього не робить.

Рішення: Якщо пристрій насичено, припиніть звинувачувати застосунок. Виправте I/O-шлях, глибину черги, планувальник або провізіювання.

Завдання 8: Підтвердіть планувальник I/O та налаштування черг (поширений несуміст порту)

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

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

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

Завдання 9: Перевірте узгоджені TLS-можливості (крипто-порти люблять тихі пониження)

cr0x@server:~$ openssl version -a
OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023)
built on: Tue Oct 10 10:10:10 2023 UTC
platform: debian-amd64

Що це означає: Великі версії OpenSSL змінюють поведінку провайдерів. Те, що «підтримувалося» в 1.1.1, може потребувати конфігурації в 3.x.

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

Завдання 10: Підтвердіть можливості NFS клієнта/сервера

cr0x@server:~$ nfsstat -m
/var/lib/app from nfs01:/export/app
 Flags: rw,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.2.10

Що це означає: Ви бачите узгоджену версію NFS. Якщо ви думали, що на 4.2 з певними семантиками, а насправді — 4.1, ваша «функція» може бути відсутня.

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

Завдання 11: Валідація NVMe multipath та стану ANA

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:2f2a...
\
 +- nvme0 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live optimized
 +- nvme1 fc traddr=nn-0x500a098... host_traddr=nn-0x500a098... live non-optimized

Що це означає: Multipath «існує» лише коли шляхи видимі і їхні стани мають сенс. «Non-optimized» шляхи можуть бути у стані standby або використовуватися неправильно залежно від політики.

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

Завдання 12: Впіймайте тихі відкатування файлової системи в контейнерному сховищі

cr0x@server:~$ docker info | sed -n '/Storage Driver/,$p' | head -n 8
 Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
 userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd

Що це означає: Поведінка overlay залежить від можливостей бекенд-файлової системи. Якщо підтримка d_type відсутня, overlay може працювати некоректно. Якщо userxattr — false, певні функції безпеки/метаданих можуть бути недоступні.

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

Завдання 13: Флаги функцій ZFS та реальність сумісності

cr0x@server:~$ zpool get -H -o name,property,value ashift,autotrim,feature@async_destroy rpool
rpool	ashift	12
rpool	autotrim	off
rpool	feature@async_destroy	active

Що це означає: Флаги функцій ZFS явні. Пул можна імпортувати, але він може мати активні флаги, які старі порти не зможуть безпечно обробити.

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

Завдання 14: Перевірте runtime-попередження, що вказують на заглушки або вимкнені шляхи

cr0x@server:~$ dmesg -T | egrep -i 'fallback|disable|unsupported|unknown|deprecated' | tail -n 10
[Wed Jan 22 00:12:44 2026] nvme nvme0: missing or invalid ANA log, disabling ANA support
[Wed Jan 22 00:12:45 2026] overlayfs: upper fs does not support xattr, falling back to index=off

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

Рішення: Ставтеся до таких рядків як до вимог. Якщо функцію вимкнено, припиніть про неї проєктуватися.

Завдання 15: Підтвердіть виклики системних викликів та відмінності в поведінці (glibc/musl, seccomp)

cr0x@server:~$ strace -f -e trace=io_uring_setup,openat,fsync -o /tmp/trace.log ./app --once
cr0x@server:~$ tail -n 6 /tmp/trace.log
12345 io_uring_setup(256, {flags=0, sq_thread_cpu=0, sq_thread_idle=0}) = -1 EPERM (Operation not permitted)
12345 openat(AT_FDCWD, "/var/lib/app/data", O_RDONLY|O_CLOEXEC) = 3
12345 fsync(3) = 0

Що це означає: Ваш застосунок «підтримує io_uring», але в контейнері із seccomp або недостатніми привілеями він може бути заблокований і тихо відкотитися на старіший I/O.

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

Три міні-історії з корпоративного життя (анонімні, болісно реальні)

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

Команда платформи випустила новий «зашитий» базовий образ для внутрішніх сервісів. Його подавали як drop-in заміну: ті самі пакунки, трохи новіше ядро, менша площа атаки. План міграції був простим: збирати AMI, rolling deploy, стежити за дашбордами.

Один сервіс — write-heavy API з локальною чергою — почав показувати періодичні спайки латентності, що нагадували паузи GC. CPU нормальний. Пам’ять нормальна. Мережа нормальна. Але кожні кілька хвилин p99 підстрибував і пропускна здатність падала. Усі дивилися на трейси застосунку, бо, звісно, це має бути в додатку.

Це не додаток. Базовий образ змінив стек зберігання дуже тонко: опції монтування вже не включали discard, а підлеглий віртуальний диск усе одно не рекламував discard. Старий образ підтримував щотижневий trim; новий — ні. З часом SSD-пристрій почав поводитися як песимістичний архіваріус: він пам’ятав кожен запис і став мститися.

«Портована функція» була обіцянкою, що новий образ операційно еквівалентний. Так і було. Окрім нудної поведінки обслуговування, яка не була задокументована як вимога і тому не тестувалася. Виправлення було не героїчним: відновити виконання trim, валідувати end-to-end підтримку discard і додати явну перевірку в пайплайні образів, щоб збірки падали при зміні припущень про зберігання.

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

Команда зберігання мігрувала флот з iSCSI LUN на NVMe over Fabrics. Демонстрація від вендора була відмінна. Латентність покращилась у контрольованих тестах. Хтось помітив, що ядро має нативну підтримку NVMe multipath, і вирішив прибрати dm-multipath, щоб «зменшити оверхед». Чистіший стек, менше шарів.

За кілька тижнів з’явилися періодичні помилки під час технічного обслуговування fabric. Нічого катастрофічного — лише короткі затримки, що викликали таймаути вище по стеку. Навантаження було розподіленою базою даних. Розподілені бази чутливі емоційно: декілька секунд невизначеності I/O перетворюються на каскад змін лідерів, повторних спроб і компактацій. Все здавалося проблемою додатка, бо саме додаток кричав.

Корінь проблеми — припущення про паритет функцій: ядро мало NVMe multipath, але конкретне поєднання прошивки та поведінки fabric породжувало ANA-переходи, які порт обробляв некоректно. Система не була зламана постійно — лише достатньо, щоб отруїти хвостову латентність.

Виправлення полягало в тому, щоб відмовитися від елегантності на користь передбачуваності: відновити валідувану конфігурацію multipath, додати health checks, що стверджують коректність стану шляхів, і репетирувати відмови в staging з тією ж прошивкою. Урок: прибирати шари — не завжди спрощення в режимі відмов.

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

Середня компанія тримала приватний Kubernetes-кластер з CSI-драйвером для блочного сховища. Вони мали два внутрішні дистрибутиви: «стандартний Linux» і мінімальну ОС для хостів контейнерів. Мінімальна ОС була популярна: швидко грузиться і простіше закрити. Вона також мала звичку пропускати ядрові модулі, «які всі вважають наявними».

Перед тим як допускати її в продакшн, один SRE наполіг на «контракті можливостей» у вигляді тестової збірки. Це було не гламурно. Вона завантажувала вузол, приєднувала том, виконувала набір перевірок sysfs, валідувала опції монтування, робила fsync-стресс і потім примусово від’єднувала/заново приєднувала. Також перевіряла конкретні попередження ядра і відмовлялася продовжувати, якщо в dmesg з’являлися рядки про «fallback».

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

Практика, що їх врятувала, була прозаїчною: формалізувати припущення як тести. Вони не «довіряли порту». Вони тестували порт. Мінімальна ОС все ще використовувалася, але з чіткою міткою: без знімків, доки не співпадуть ядрові модулі й функції файлової системи. Ніхто не отримав pager, а CFO залишився щасливо неусвідомленим щодо того, як близько вони були до фінансування несподіваного фестивалю копіювання даних.

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

1) «Ми ввімкнули це, але продуктивність не змінилася»

Симптом: Перемкнули функцію (discard, стиснення, multipath, async I/O). Метрики залишилися незмінними.

Корінна причина: Функція не узгоджується наскрізь або вимкнена в runtime через відсутність можливості.

Виправлення: Валідуйте знизу вгору: підтримку пристрою (lsblk -D), попередження ядра (dmesg), опції монтування (findmnt) і статистику драйвера.

2) «Працює до перемикання, потім зависає»

Симптом: Нормальна латентність до відмови шляху або обслуговування; потім хвостова латентність вибухає.

Корінна причина: Часткова реалізація семантики failover, невірна політика шляхів або порт, що не обробляє перехідні стани коректно.

Виправлення: Репетируйте відмову навмисно. Перевіряйте стан multipath і його здоров’я. Віддавайте перевагу перевіреним, консервативним конфігураціям перед «чистим стеком», коли важлива надійність.

3) «Знімки є, але відновлення повільне»

Симптом: API знімків успішний; відновлення займає вічність і б’є по сховищу.

Корінна причина: Порт надає об’єкти знімків, але не має copy-on-write або нативної підтримки знімків; він відкатується на повне копіювання.

Виправлення: Перевірте реалізацію: можливості файлової системи, підтримку бекенду сховища та реальні I/O-шаблони відновлення. Обмежте використання знімків за типом бекенду.

4) «Шифрування ввімкнено, але CPU злітає вгору»

Симптом: Включення TLS або шифрування диска призводить до колапсу пропускної здатності.

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

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

5) «Контейнери почали падати з дивними помилками файлової системи»

Симптом: Помилки overlay, дивні відмови rename, проблеми з правами.

Корінна причина: Бекенд-файлова система не має необхідних можливостей (d_type, xattrs) або реалізація overlay у ядрі відрізняється від очікувань рантайму.

Виправлення: Перевірте передумови overlay і змініть бекенд або драйвер. Не запускайте overlay на «чому-небудь, що випадково змонтовано».

6) «Той самий застосунок, інший дистро — інша поведінка»

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

Корінна причина: Відмінності libc, поведінки резолвера, значень потокових стеків або змін sysctl ядра.

Виправлення: Розглядайте базовий образ і libc як частину API платформи. Зафіксуйте версії, запускайте тести сумісності і дифайте sysctl.

7) «Функція є, але ми не можемо її спостерігати»

Симптом: Немає метрик або логів для підтвердження поведінки; лише непряма інференція.

Корінна причина: Порт опустив лічильники/tracepoint-и або не підключив їх у вашу телеметрію.

Виправлення: Додайте явні вимоги до спостережуваності в acceptance-критерії. Якщо ви не можете це спостерігати — ви не можете це експлуатувати.

Контрольні списки / поетапний план: як безпечно релізити порти

Крок за кроком: побудуйте «контракт можливостей» для вашої платформи

1. Перелічіть незаперечні семантики для кожного робочого навантаження. Для баз даних: коректність fsync і латентність; для об’єктного сховища: надійність і поведінка під час відновлення; для стрімінгу: хвостова латентність під тиском назад.
2. Перекладіть семантику в перевірювані тести. «Підтримує discard» стає «DISC-MAX > 0 і опція монтування встановлена або періодичний trim верифікований». «Підтримка знімків» стає «відновлення не вимагає повного копіювання».
3. Явно документуйте передумови. Опції ядра, потрібні модулі, мінімальна прошивка і потрібні можливості файлової системи.
4. Створіть автоматизований набір валідації. Запускайте його при кожному новому ядрі, базовому образі та бекенді сховища. Падайте швидко, коли можливості дрейфують.
5. Включіть вправи з відмов. Від’єднайте шлях, перезавантажте вузол, заповніть диск до 95%, примусово ресинхронізуйте, прокачайте сертифікати. Виміряйте вплив на SLO.
6. Визначте політику відкатів. Якщо функцію неможливо узгодити, система має відмовитися запускатися, або працювати в деградованому режимі з гучними алертами?
7. Обмежуйте реліз за можливостями, а не за іменами хостів. «prod-storage-02» — не можливість. «discard підтримується end-to-end» — ось що має значення.
8. Ведіть матрицю сумісності. Не новомодна річ; таблиця: версії ядра, версії драйверів, прошивка, флаги функцій, відомі нюанси.

Операційний чеклист: перед тим як приймати «портований» як «готовий до продакшну»

• Чи можете ви довести, що функція узгоджується наскрізь (клієнт + сервер + ядро + пристрій)?
• Чи можете ви довести, що функція змінює поведінку під навантаженням (не лише стан конфігурації)?
• Чи є у вас принаймні один негативний тест, де функція відсутня і система гучно падає?
• Чи є у вас спостережуваність: лічильники, логи та чіткі дашборди, що показують здоров’я функції?
• Чи протестовано «потворний шлях»: failover, resync, повний диск, висока латентність, втрата пакетів?
• Чи безпечний відкат (флаги функцій пулу, даунгрейд протоколу, сумісність конфігів)?

Правила прийняття рішень (суб’єктивні, бо у вас мало часу)

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

Поширені питання

1) У чому різниця між «функція існує» і «функція працює»?

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

2) Чому порти виходять з заглушеними функціями?

Бо досягти паритету API часто простіше, ніж паритету семантики. Заглушки зменшують тертя інтеграції і дають час. Проблема починається, коли ніхто не маркує заглушку як заглушку.

3) Як виникають мовчазні відкатування?

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

4) Чи варті зусиль «матриці сумісності»?

Так, якщо ви тримаєте їх короткими і прив’язаними до acceptance-тестів. Цінність не в документі; цінність — у дисципліні знати, які комбінації протестовані, а які — надії на краще.

5) Який найшвидший спосіб дізнатися, чи справжня функція зберігання?

Перевірте можливості пристрою (sysfs/lsblk), перевірте попередження ядра (dmesg), а потім виміряйте поведінку (iostat латентність, тести відновлення/відмови). Якщо будь-який шар не погоджується — вважайте, що функція не реальна.

6) Як реагувати на заяви вендора «підтримується на Linux»?

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

7) Чи варто надавати перевагу меншим шарам (наприклад, прибрати dm-multipath)?

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

8) Якщо відсутня функція — це лише проблема продуктивності, а не коректності?

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

9) Як змусити команди припинити сперечатися про те, чи це додаток чи платформа?

Змушуйте платформу публікувати контракт можливостей з тестами й доказами, а сервіси — декларувати, які можливості їм потрібні. Тоді розбіжності стануть дифами і результатами тестів, а не нескінченними зустрічами.

Висновок: що зробити наступного тижня, а не в наступному кварталі

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

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

1. Створіть контракт можливостей для вашої платформи: кілька ключових функцій, від яких ви справді залежите (надійність, знімки, поведінка multipath, узгодження крипто, спостережуваність).
2. Автоматизуйте перевірки, показані вище, у CI для базових образів, ядер і збірок вузлів. Падайте швидко, коли передумови дрейфують.
3. Проведіть одну вправу з відмови для кожної критичної функції в staging: втрата шляху, перезавантаження вузла, ресинхронізація, відновлення знімку, інжекція високої латентності.
4. Зробіть відкат гучним: якщо система понижує можливості, алерт. Якщо вона не може надати потрібну функцію, відмовляйтеся запускатися.

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