Порожні обіцянки в продакшні: як продукти з пресрелізів ламають реальні системи

Що таке vaporware насправді (і чого це не стосується)

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

Існує різниця між:

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

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

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

Жарт #1 (короткий, доречний): Дорожня карта — єдиний артефакт у технологіях, що стає менш точним, чим більш кольорова вона.

Чому це продовжує траплятися в корпоративному IT

Vaporware — це не просто «маркетинг, що робить маркетинг». Це рівновага, створена резонансами мотивацій:

1) Оголошення дешевші за доставку

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

2) Покупці часто купують наративи, а не можливості

Процеси закупівель заохочують порівнянність. Постачальники відповідають коробками з галочками. Галочки заохочують гучні заяви. І раптом «multi-region active-active, zero RPO» стоїть поруч із «підтримує SNMP». Реальність не така акуратна.

3) Технічні команди тягнуть у передобов’язання

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

4) Корпоративний імунітет слабкий проти оптимізму

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

5) Інтеграція — місце, де обіцянки вмирають

Більшість заяв vaporware не неможливі ізольовано. Вони неможливі в поєднанні з усім іншим, що продукт уже робить: шифрування, снапшоти, реплікація, квоти, мультиорендне розмежування, телеметрія, відповідність записів і «працює з нашим identity provider».

Історичні факти та контекст, які реально допомагають

Трохи контексту корисно, бо vaporware повторює шаблони. Ось конкретні моменти, які варто пам’ятати (не ностальгія, а практичне розпізнавання):

1. Термін «vaporware» поширився на початку 1980-х у пресі про персональні комп’ютери, коли постачальники попередньо оголошували продукти, щоб стримати конкурентів.
2. Передані анонси стали конкурентною зброєю, коли розповсюдження і оновлення програм були повільними; захоплення уваги важило так само, як і доставка.
3. У 1990-х у корпоративній сфері нормалізували продаж «майбутніх» функцій: великі контракти домовлялися на основі дорожніх карт, а не лише поточних можливостей.
4. Антимонопольна увага іноді підвищувала обережність постачальників щодо попередніх оголошень, але не усувала практику; формулювання стали обачнішими.
5. Епоха хмари відродила vaporware в новій формі: «регіон незабаром», «preview сервісу» та «список очікування», які використовують в архітектурах ще до GA.
6. Постачальники сховищ історично перебільшували показники dedupe та стиснення, бо робочі навантаження різні, а синтетичні бенчмарки роблять легкі обіцянки.
7. «Міграція без простою» — повторювана заява десятиліть; реальні міграції обмежені поведінкою додатків, а не лише каналізацією зберігання.
8. Безпекові дорожні карти часто — гаряча зона vapor: «незмінні бекапи», «air-gapped відновлення», «захист від рансому» часто приходять неповними або операційно крихкими.
9. Відкриті стандарти використовували як маркетинговий щит: «S3-совместимий» і «Kubernetes-native» можуть означати дуже різні рівні сумісності.

Зверніть увагу на тему: vaporware процвітає там, де перевірити складно. Якщо ви не можете швидко протестувати — вас швидше продадуть історією.

Операційні режими відмов: як vaporware ламає системи

Режим відмови A: Архітектура залежить від незапущених примітивів

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

Патерн діагностики: «тимчасове рішення» стає постійним і набуває зубів: cron-завдання, крихкі скрипти, ручні кроки, винятки в аудитах і механізми відкату, що нагадують Rube Goldberg.

Режим відмови B: «Бета» трактують як підтримувану функцію

Бета — це не етап зрілості; це етап відповідальності. Постачальники часто кажуть «обмежена підтримка». На практиці це означає: обмежений on-call, мала терміновість виправлення багів і документація, написана «в дорозі».

Режим відмови C: Нефункціональні вимоги відкидаються

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

Режим відмови D: Інтеграційний борг переходить прямо в операції

Коли постачальник каже «інтегрується з вашою екосистемою», ваша екосистема завжди більша, ніж він має на увазі. Identity, мережа, DNS, проксі, аудит, тікетинг, бекап, моніторинг, розподіл витрат. Різниця стає вашим glue-кодом. Glue-код стає вашим пейджером.

Режим відмови E: Закупівля прив’язує вас до функцій до їх появи

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

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

Одна цитата, бо вона витримує аудити й бюджетні наради. Ідея Кіма (Gene Kim) часто виражається так; я перефразовую, щоб залишатися чесним:

Парафраз ідеї (Gene Kim): Надійність — це не функція, яку додають пізніше; це властивість, яку проектують і підтримують у системі від самого початку.

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

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

По-перше: підтвердьте, що справді розгорнуто

• Перевірте версії, увімкнені модулі, стан ліцензії та feature flags. Половина інцидентів із vaporware — це «він є, але не у вашому SKU/регіоні/збірці».
• Переконайтеся, що ви не читаєте маркетингові доки, запущені на минулому прошиванні.

По-друге: ідентифікуйте домінантний симптом

• Латентність (особливо хвостова) зазвичай означає контенцію, черги або синхронні записи.
• Обмеження пропускної здатності часто вказують на один вузький вузол: NIC bonding, зайняте ядро, глибина черги, один шлюзовий вузол.
• Аномалії консистентності зазвичай означають кешуючі шари або семантику реплікації слабшу, ніж ви припускали.
• Провали відкату часто означають, що запобігання split-brain працює — ціною доступності — або ваші залежності не включені.

По-третє: протестуйте шлях даних в ізоляції

• Зробіть бенчмарк локального диска проти мережевого зберігання та об’єктного шлюзу.
• Вимірюйте за допомогою інструментів, що показують IOPS, розподіл латентності та використання CPU.
• Завжди фіксуйте команду, вивід і деталі середовища. Інакше ви сперечаєтеся на атмосферу.

По-четверте: зіставте «обіцяне» з поведінкою, що спостерігається

• «Незмінність» означає, що ви не повинні мати змогу видалити чи перезаписати об’єкти/блоки протягом періоду збереження — навіть як адміністратор.
• «Active-active» означає два незалежні шляхи запису без прихованого первинного вузла.
• «Zero RPO» означає, що ви можете вбити сайт під час запису і все одно мати запис, зафіксований в іншому місці з визначеними семантиками.

По-п’яте: вирішіть швидко — фікс, тимчасове рішення чи відкат

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

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

Це реальні завдання, які можна виконати під час due diligence, POC або інциденту. Кожне містить: команду, що означає вивід, і рішення. Вони орієнтовані на Linux, бо продакшн зазвичай там.

Завдання 1: Підтвердити ядро й базові OS-налаштування (уникнути фантомних проблем продуктивності)

cr0x@server:~$ uname -a
Linux app01 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Значення виводу: Версія ядра впливає на NVMe, TCP стеки, io_uring і поведінку файлових систем. «Постачальник тестував на 5.4» важливо, якщо у вас 6.5.

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

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

cr0x@server:~$ cat /etc/vendor-storage/version
VendorStorageOS 3.2.1-build.4587

Значення виводу: Ви запускаєте конкретну збірку; «3.2» на слайдах — не номер збірки.

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

Завдання 3: Перевірити стан ліцензії чи прав доступу (функції можуть зникати тут)

cr0x@server:~$ vendorctl license show
License: ENTERPRISE
Features:
  replication: enabled
  immutable-snapshots: disabled
  s3-gateway: enabled
  kms-integration: enabled

Значення виводу: Функція не «відсутня», вона вимкнена ліцензією. Це також вважається «недоступною» для вас.

Рішення: Або оновіть права як частину контракту, або проектуйте, припускаючи, що функція не існує.

Завдання 4: Перевірити DNS і маршрути до уявних «мульти-регіональних» endpoint’ів

cr0x@server:~$ dig +short storage-global.example.internal
10.40.12.10

Значення виводу: «Глобальний endpoint» резолвиться в одну IP. Це не глобально; це один VIP у плащі.

Рішення: Якщо HA покладається на failover на основі DNS, вимагайте протестованих часів відновлення та поведінки кешування або переходьте на anycast/load-balancer, яким керуєте ви.

Завдання 5: Спостерігати мережевий шлях і MTU-проблеми (латентність, що маскується під зберігання)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens160           UP             00:50:56:aa:bb:cc
ens192           UP             00:50:56:dd:ee:ff

Значення виводу: Інтерфейси підняті. Це не доводить jumbo frames або offloads, але дає базу.

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

Завдання 6: Перевірити втрату пакетів у мережі зберігання

cr0x@server:~$ ping -c 20 -i 0.2 10.40.12.10
PING 10.40.12.10 (10.40.12.10) 56(84) bytes of data.
64 bytes from 10.40.12.10: icmp_seq=1 ttl=63 time=0.421 ms
64 bytes from 10.40.12.10: icmp_seq=2 ttl=63 time=0.389 ms
...
--- 10.40.12.10 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3811ms
rtt min/avg/max/mdev = 0.362/0.401/0.463/0.024 ms

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

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

Завдання 7: Підтвердити опції монтування (sync/async і atime можуть бути тихими вбивцями)

cr0x@server:~$ mount | grep /mnt/data
10.40.12.10:/vol0 on /mnt/data type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

Значення виводу: Версія NFS і rsize/wsize впливають на пропускну здатність; «relatime» зменшує метадані записів.

Рішення: Якщо постачальник обіцяв продуктивність на NFSv4.2, а у вас 4.1 — узгодьте спочатку. Якщо бачите «sync», де чекали async, перегляньте очікування по латентності.

Завдання 8: Швидко виміряти розподіл латентності файлової системи за допомогою fio (не тільки середні)

cr0x@server:~$ fio --name=randread --directory=/mnt/data --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=2G --time_based --runtime=60 --group_reporting
randread: (groupid=0, jobs=4): err= 0: pid=3121: Mon Jan 22 10:12:01 2026
  read: IOPS=52.1k, BW=203MiB/s (213MB/s)(12.0GiB/60s)
    slat (nsec): min=740, max=190k, avg=3200.1, stdev=4100.8
    clat (usec): min=85, max=21000, avg=510.4, stdev=980.2
     lat (usec): min=90, max=21010, avg=514.0, stdev=982.0
    clat percentiles (usec):
     |  50.00th=[  320],  90.00th=[  910],  99.00th=[ 4500],  99.90th=[14000]

Значення виводу: Медіана виглядає нормально, але 99.9% на 14мс може зламати вашу базу. Хвостова латентність — це правда; середні — заспокійливий засіб.

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

Завдання 9: Перевірити поведінку discard/TRIM (для thin-provisioning це критично)

cr0x@server:~$ lsblk -D
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0

Значення виводу: DISC-GRAN і DISC-MAX показують можливості discard. Якщо цього немає — історія thin-provisioning може бути фантазією.

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

Завдання 10: Перевірити стан реплікації і лаг (дорожня карта «майже в реальному часі» vs реальність)

cr0x@server:~$ vendorctl replication status
Pair: dc1-vol0 -> dc2-vol0
Mode: async
Last snapshot sent: 2026-01-22T10:10:12Z
Lag: 00:07:41
Queue: 1822 ops
State: healthy

Значення виводу: Асинхронна реплікація з лагом 7хв41с — не «zero RPO», не «синхронна» і не «миттєвий failover». Вона все ще може бути корисною — просто не для тієї історії, яку вам продали.

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

Завдання 11: Перевірити «незмінний снапшот» спробою видалення

cr0x@server:~$ vendorctl snapshot delete --volume vol0 --snapshot snap-2026-01-22
ERROR: snapshot is locked by retention policy until 2026-02-22T00:00:00Z

Значення виводу: Ось як виглядає незмінність: система відмовляється видаляти і каже, чому.

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

Завдання 12: Перевірити реальні коефіцієнти зменшення даних на реальних даних (не математикою постачальника)

cr0x@server:~$ vendorctl stats datareduction --volume vol0
Logical used: 12.4TiB
Physical used: 9.8TiB
Reduction ratio: 1.27:1
Dedupe: 1.05:1
Compression: 1.21:1

Значення виводу: Ваші дані зменшуються 1.27:1, а не 5:1. Це нормально. Заявки постачальника часто ґрунтуються на VDI-клонах або синтетичних даних.

Рішення: Планування ємності має використовувати виміряні коефіцієнти з запасом. Якщо бізнес-кейс вимагав 4:1 — бізнес-кейс був vapor.

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

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0-14-generic (app01) 	01/22/2026 	_x86_64_	(16 CPU)

10:14:03 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:14:04 AM  all   62.11    0.00   18.44    1.21    0.00    0.88    0.00    0.00    0.00   17.36
10:14:04 AM   3   96.00    0.00    3.00    0.00    0.00    1.00    0.00    0.00    0.00    0.00

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

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

Завдання 14: Підтвердити queue depth і латентність пристрою для блочного зберігання

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0-14-generic (app01) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          58.12    0.00   17.90    2.44    0.00   21.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1        820.0  52480.0     0.0   0.00    0.62    64.00   210.0  26880.0     0.0   0.00    1.10   128.00   0.35  68.00

Значення виводу: r_await/w_await показують латентність; %util вказує на насичення. Високий await при низькому util часто вказує на upstream (мережа, масив) латентність.

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

Завдання 15: Перевірити, що «S3-совместимість» справді підтримує потрібні заголовки/функції

cr0x@server:~$ aws --endpoint-url http://10.40.12.20:9000 s3api put-object --bucket backups --key test.txt --body /etc/hostname
{
    "ETag": "\"9b74c9897bac770ffc029102a200c5de\""
}

Значення виводу: Базовий PUT працює. Це не означає, що версіювання, object lock або мультипарт-поведінка відповідають вашим інструментам.

Рішення: Якщо вам потрібен object lock/retention, а це недоступно або несумісно з вашим софтом для бекапів — не приймайте «S3-совместимість» як заміну вимог.

Завдання 16: Протестувати механіку failover, а не тільки «status: ready»

cr0x@server:~$ vendorctl cluster failover --to-site dc2 --dry-run
Dry-run result:
  Will stop services on: dc1-gw1, dc1-gw2
  Will promote volumes: vol0, vol1
  Will update VIP: 10.40.12.10 -> 10.60.12.10
  Blocking issues:
    - quorum device unreachable
    - 2 clients have active locks on vol0
Exit code: 2

Значення виводу: Система каже, що failover зараз не пройде і чому. Це золото.

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

Жарт #2 (короткий, доречний): Ніщо так не говорить «висока доступність», як функція, що з’являється відразу після ретро по відмові.

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

Коротка історія 1: Відмова через неправильне припущення

Компанія була посеред міграції зі старого SAN на «cloud-native storage platform», яку продавали як active-active між двома дата-центрами. Слайди були приголомшливі: подвійні записи, автоматичний failover, zero RPO. Команда архітекторів спроєктувала новий рівень бази даних навколо ідеї, що будь-який вузол може писати в будь-який сайт, тож вікна обслуговування майже не знадобляться.

Під час POC інженер постачальника провів демонстрацію, де він відключив комутатор і UI залишився зелений. Усі аплодували. Ніхто не запитав, який робочий профіль був, чи були записи синхронними, або де саме лежав commit point.

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

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

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

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

Інша організація купила all-flash масив, у якого в наступному релізі обіцяли «inline compression без штрафу по продуктивності». CFO полюбив історію про ємність. Інженери — ідею вмістити більше даних у тих самих стійках. План полягав у тому, щоб увімкнути стиснення по всьому масиву, щойно вийде нова версія.

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

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

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

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

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

Глобальна компанія оцінювала нову платформу бекапу, яка обіцяла «незмінні бекапи з миттєвим відновленням» на S3-совместимому об’єктному сховищі. Постачальник робив акцент на готовності до рансому: air-gapped, locked, unstoppable. Security готові були підписати.

Керівник SRE наполягнув на нудній вимозі: скрипт прийняття, який би запускався щонічно в POC середовищі. Не раз. Щонічно. Він мав створювати бекап, намагатися видалити, перезаписати, скоротити термін збереження, а потім відновити в sandbox VM. Кожен запуск мав видавати логи, коди виходу і просте підсумкове pass/fail.

Через два тижні нічний запуск почав падати: поведінка «object lock» стала непослідовною після невеликого оновлення. Іноді видалення провалювалося (добре). Іноді видалення вдавалося (дуже погано). Постачальник спочатку списував на «неправильну конфігурацію». Скрипт зробив проблему відтворюваною і незаперечною.

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

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

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

1) «Функція є в продукті», але вона відсутня у вашому середовищі

Симптоми: UI показує недоступні налаштування; CLI повертає «unknown command»; в документації є згадка, але ваша збірка не містить.

Коренева причина: SKU/ліцензія, обмеження регіону або функція існує лише в новішій збірці, ніж та, що розгорнута.

Виправлення: Розглядайте доступність як артефакт розгортання: перевіряйте версію + стан ліцензії в POC; включіть у контракт, що доставка охоплює ваш SKU і ваші регіони.

2) «Active-active» поводиться як active-passive під навантаженням

Симптоми: Шлюзові вузли одного сайту гарячі; при failover зникають сесії; латентність записів зростає при навантаженні обох сайтів.

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

Виправлення: Вимагайте явної семантики: де commit point, що підтверджується коли і що відбувається при розділенні мережі. Тестуйте шляхом створення розриву, а не тільки вимкнення живлення.

3) Заявлення про продуктивність руйнується під реальними навантаженнями

Симптоми: Бенчмарки показують високий IOPS, але додаток відчувається повільним; 99.9p латентність жахлива; пропускна здатність раптово плато.

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

Виправлення: Бенчмарк з fio профілями, що відповідають вашому додатку. Порівнюйте хвостову латентність і використання CPU. Відмовтеся підписуватися на «up to» заяви.

4) «Незмінні» бекапи можуть видалити ті, хто має права

Симптоми: Роль адміністратора може прибрати утримання, видалити снапшоти або змінити конфігурацію object lock ретроактивно.

Коренева причина: Незмінність реалізована як політика, а не як примус; або примус застосований некоректно за обсягом.

Виправлення: Перевіряйте руйнівними тестами. Вимагайте розділення обов’язків: окремий security principal для змін політик зберігання та журнали аудиту, які можна експортувати поза платформою.

5) Інструменти міграції обіцяні, але простій реальний

Симптоми: «Жива міграція» працює для спокійних томів, але падає для зайнятих баз даних; cutover вимагає зупинки додатка довше, ніж планувалося.

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

Виправлення: Проводьте репетиції міграції з продакшн-подібним навантаженням. Вимірюйте dirty rates, плануйте поетапні cutover та прийміть, що деякі міграції потребують вікон обслуговування.

6) Спостережуваність — після думки

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

Коренева причина: Постачальник випустив основний функціонал, але без операційних інструментів; або метрики існують, але не експортуються.

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

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

Покроковий план: оцінювати «пресрелізні» функції, щоб не попектися

1. Опишіть вимогу як спостережувану поведінку. Наприклад: «Після втрати сайту записи продовжуються протягом X секунд, і жодні підтверджені транзакції не втрачаються.» Не «active-active».
2. Явно перераховуйте нефункціональні вимоги. Експорт метрик, журнали аудиту, RBAC, оновлення, відкат, очікування щодо відповіді підтримки.
3. Вимагайте матрицю підтримки та політику життєвого циклу. Версії ОС, ядра, гіпервізори, прошивки.
4. Перетворюйте кожну заяву на acceptance тест. Якщо не можна протестувати — не можна довіряти.
5. Проводьте POC з інжекцією продакшн-подібних відмов. Розриви лінків, вбивство вузлів, заповнення дисків, ротація ключів, протермінування сертифікатів.
6. Бенчмаркуйте ваші IO-патерни. Хвостова латентність, змішані read/write, реалістичні розміри датасетів, незагрітні кеші.
7. Перевіряйте операційні процедури. Процедура оновлення, відновлення, створення користувачів, ескалація інцидентів.
8. Угоджуйте контракти по доставці, а не намірам. Прив’язуйте виплати або продовження до протестованих можливостей, а не до слайдів дорожньої карти.
9. Розробіть стратегію виходу з дня №1. Формати експорту даних, інструменти міграції, період подвійних записів.
10. Залишайте резервну архітектуру життєздатною. Не видаляйте стару платформу, поки нова не пройшла місяці нудних тестів.

Контрольний список для рішення: коли йти геть

• Постачальник не може точно сформулювати семантику (RPO/RTO, модель консистентності, поведінка commit).
• Функція вимагає «професійних сервісів» для того, щоб бути використаною.
• Телеметрія й аудитність відсутні або доступні лише у пропрієтарній формі.
• POC вимагає нереалістичних умов (спеціальне обладнання, приватні збірки, ручні налаштування), яких не буде в продакшні.
• Постачальник відмовляється записати критерії доставки в письмовому вигляді.

Контрольний список у контракті: припинити платити за пар

• Критерії прийнятності: письмові тести і визначення pass/fail для ключових функцій.
• Терміни доставки з ремедіями: сервісні кредити, право розірвання або відкладені платежі.
• Зобов’язання підтримки: терміни відповіді, шляхи ескалації, on-call покриття, графіки патчів.
• Права на оновлення: гарантія, що ви маєте право на версію, яка містить обіцяні функції.
• Портативність даних: можливість експорту даних у стандартних форматах без каральних зборів.

FAQ

1) Чи завжди vaporware має злі наміри?

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

2) У чому різниця між «preview» і vaporware?

Preview може бути легітимним, якщо він придатний, тестований і має чіткі обмеження. Він стає vaporware, коли на вас тиснуть покладатися на нього, ніби це GA.

3) Як відстояти свою позицію, не виглядаючи затримкою?

Попросіть спостережувані поведінки й acceptance тести. Ви не сперечаєтесь; ви визначаєте, що означає «готово» для продакшну.

4) Що робити, якщо керівництво вже підписало контракт на основі дорожньої карти?

Перенаправте розмову на обмеження ризиків: ізолюйте залежність, спроєктуйте fallback і вимагайте поправок, прив’язаних до протестованої доставки.

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

Крос-регіональна консистентність, «міграції без простою», незмінність від рансому, прозора multi-cloud і функції продуктивності з обіцянкою «без накладних витрат».

6) Як правильно тестувати «active-active»?

Тестуйте мережеві розриви, а не тільки відмови вузлів. Примушуйте split-сценарії, перевіряйте семантику commit і вимірюйте поведінку клієнта під failover.

7) Чому бенчмарки постачальника рідко співпадають з нашою реальністю?

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

8) Чи може open source бути vaporware також?

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

9) Який найбезпечніший спосіб прийняти нову платформу з невизначеними функціями?

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

10) Якщо постачальник каже «це в дорожній карті», що питати далі?

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

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

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

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

1. Перетворіть п’ять головних заяв постачальників у acceptance тести, які можна запускати за вимогою та за розкладом.
2. Рефакторіть вимоги у спостережувані поведінки (RPO/RTO, хвостові латентності, семантика відмов) і припиніть купувати прикметники.
3. Запровадьте правило «без залежностей від дорожньої карти» для фундаментальної архітектури. Якщо не випущено й не протестовано — це не залежність.
4. Зробіть телеметрію пропускним критерієм: якщо не можете виміряти — не можете керувати.
5. Угоджуйте доставку письмово, включно з ремедіями. Оптимізм не піддається виконанню; контракти — піддаються.

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