Antennagate: коли тримання телефону стало заголовком

Що насправді було Antennagate (і чого не було)

Antennagate, простими словами, був колапсом радіо-продуктивності, спричиненим користувачем. Певні способи тримання iPhone 4 могли зменшувати
силу сигналу настільки, що обривалися дзвінки або падала швидкість передачі даних — особливо в умовах слабкого покриття. Поведінка була тісно
пов’язана з тим, як торкалися зовнішні антенні ділянки корпусу.

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

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

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

Факти та історичний контекст, які варто пам’ятати

Це не дрібниці. Це контекст того, чому інцидент вразив так сильно і що він змінив.

1. iPhone 4 використовував зовнішню нержавну стрічку як частину антенної системи. Гарно виглядало та економило місце, але було ризиковано щодо взаємодії з користувачем.
2. Ефект «смертельного захвату» був найпомітніший у зонах слабкого сигналу. Коли ви на межі покриття, кілька дБ — це різниця між «працює» і «ні».
3. Показники «смуг» — це відображення в UI, а не фізична величина. Різна прошивка може показувати різні смуги при однаковому RSSI; зміна мапінгу швидко змінює сприйняття.
4. Інші смартфони також показували ослаблення сигналу від руки. Різниця була в ступені, повторюваності та конкретній сегментації антени iPhone 4.
5. Історія вибухнула, бо її було легко показати на камеру. Інженери недооцінюють, наскільки руйнівними можуть бути «кроки відтворення», коли їх може виконати публіка.
6. Існувало просте фізичне тимчасове рішення: ізоляція антени чохлом/бампером. Виправлення не було екзотичним; воно буквально полягало в тому, щоб не давати шкірі створювати місток.
7. Варіативність ланцюга постачання має значення для RF. Невеликі зміни в діелектричних властивостях, зазорах при збірці або покриттях можуть змінити налаштування антени так, що крайові випадки посиляться.
8. Поведінка мережі оператора впливала на симптоми. Агресивний хендовер, керування потужністю по каналу та локальна навантаженість змінювали швидкість появи відмов.

RF надійність 101: чому рука може зіпсувати ваш день

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

Бюджет каналу — ваш SLO

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

У сценарії Antennagate рука користувача робила дві ворожі для надійності речі:

• Детюнінг: зсув ефективного резонансу антени так, що вона вже не підходила для призначеного діапазону.
• Поглинання/атенюація: перетворення енергії радіохвиль в тепло в тілі користувача (і введення додаткових втрат).

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

«Смуги» — не метрика; це продуктове рішення

Люди, що працюють з надійністю, люблять графіки. Споживачі отримують смуги. Смуги будуються з RSSI/RSRP/RSRQ і логіки продавця. Це абстракція UX,
і мапінг може змінитися з оновленням прошивки без поліпшення реального RF.

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

Жарт №1 (короткий, доречний)

RF‑інженери не вірять у привидів. Вони вірять у «немоделюване зв’язування», що те саме, але в таблиці Excel.

Режим відмови: детюнінг, ослаблення сигналу та проблема «мосту»

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

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

Чому це виявлялося як скидання дзвінків

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

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

Чому бампер‑чохол «вирішував» проблему

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

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

Аналіз прогалин у тестуванні: як це проскочило

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

Припущення №1: лабораторні фіксатори для хвату представляють справжні руки

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

Припущення №2: зони маргінального сигналу — це «крайові випадки»

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

Припущення №3: PR вирішить відтворюваний демо‑ефект

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

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

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

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

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

Перше: це запас лінку RF чи UI?

• Витягніть реальні метрики сигналу (RSSI/RSRP/RSRQ/SINR) з логів пристрою або режиму тестування.
• Корелюйте з обривами дзвінків, падінням пропускної здатності або втратою пакетів — не зі смугами.
• Якщо смуги змінюються, а SINR стабільний, можливо, проблема в мапінгу/порогах більше, ніж у RF.

Друге: це детюнінг/зчеплення антени чи поведінка мережі?

• Зробіть A/B‑тест у контрольованому RF‑середовищі (екранована коробка / симулятор базової станції, якщо є).
• Повторіть на кількох операторах або конфігураціях базових станцій, якщо можливо.
• Якщо проблема відтворюється в контрольованому середовищі, швидше за все це фізика пристрою/прошивка.

Третє: чи ізоляція або змінений хват усувають ефект?

• Додайте відому ізолюючу прошарку (чохол, стрічка в контрольованому експерименті) і перетестуйте.
• Якщо ізоляція відновлює дБ і стабільність, у вас режим відмови з чутливістю зв’язку/мосту.
• Тоді вирішіть: апаратний ревізіон, аксесуар як тимчасове рішення або прийняти і чітко повідомити (останній варіант).

Четверте: кількісно оцініть радіус ураження

• Який відсоток користувачів часто перебуває в маргінальному покритті?
• Як часто природно використовується «поганий хват»?
• Чи розширюють допуски виробництва розподіл (деякі пристрої значно гірші)?

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

Ви не можете ssh у базбенд телефону як у Linux‑сервер у продакшні, але можна побудувати дисциплінований робочий процес навколо
логів, метрик і контрольованих експериментів. Нижче — практичні завдання, які ви можете виконати в лабораторії або на фліті, де
є доступ до Linux‑тестових стендів, Wi‑Fi/SDR‑інструментів і телеметричних конвеєрів.

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

Завдання 1: Перевірте, що тестовий стенд не брешеться (шум по USB, проблеми хаба)

cr0x@server:~$ lsusb
Bus 002 Device 003: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 004: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 001 Device 005: ID 0cf3:e300 Qualcomm Atheros Communications

Значення: Підтвердьте, що ваші NIC і Wi‑Fi‑адаптери — це те, що ви очікуєте. Випадкові хаби та ненадійні адаптери створюють фантомні «RF‑проблеми».

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

Завдання 2: Перевірте статистику Wi‑Fi‑з’єднання як швидкий проксі для ефектів руки/чохла

cr0x@server:~$ iw dev wlan0 link
Connected to 3c:84:6a:12:34:56 (on wlan0)
	SSID: lab-ap
	freq: 5180
	RX: 124893 bytes (812 packets)
	TX: 90211 bytes (621 packets)
	signal: -67 dBm
	tx bitrate: 351.0 MBit/s VHT-MCS 7 80MHz short GI

Значення: Сигнал і бітрейт — негайні індикатори. Якщо «смертельний хват» падає сигнал на 15–25 дБ, ви побачите, як адаптація швидкості різко впаде.

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

Завдання 3: Захопіть базовий розподіл RSSI з часом

cr0x@server:~$ for i in {1..10}; do date +%T; iw dev wlan0 link | awk '/signal/ {print $2" "$3}'; sleep 1; done
14:02:11
-67 dBm
14:02:12
-68 dBm
14:02:13
-67 dBm
14:02:14
-67 dBm
14:02:15
-80 dBm
14:02:16
-81 dBm
14:02:17
-79 dBm
14:02:18
-68 dBm
14:02:19
-67 dBm
14:02:20
-67 dBm

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

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

Завдання 4: Виявити роумінг або цикли перепідключення

cr0x@server:~$ journalctl -u NetworkManager --since "10 minutes ago" | tail -n 20
Jan 21 14:01:58 labhost NetworkManager[1123]: wlan0: disconnected (reason 4)
Jan 21 14:01:58 labhost NetworkManager[1123]: wlan0: scanning for networks
Jan 21 14:02:00 labhost NetworkManager[1123]: wlan0: connected to lab-ap
Jan 21 14:02:05 labhost NetworkManager[1123]: wlan0: disconnected (reason 4)

Значення: Цикли відключення/підключення можуть маскуватися під «втрати сигналу». Коди причин допомагають розділити RF‑затухання від проблем аутентифікації.

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

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

cr0x@server:~$ iperf3 -c 10.0.0.10 -t 10 -R
Connecting to host 10.0.0.10, port 5201
Reverse mode, remote host 10.0.0.10 is sending
[  5]   0.00-10.00  sec   312 MBytes   262 Mbits/sec  receiver

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

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

Завдання 6: Слідкувати за втратою пакетів і джиттером під час зміни хвату

cr0x@server:~$ ping -i 0.2 -c 30 10.0.0.10
30 packets transmitted, 29 received, 3.33333% packet loss, time 5872ms
rtt min/avg/max/mdev = 1.921/7.842/98.331/18.402 ms

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

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

Завдання 7: Перевірте енергозбереження інтерфейсу (воно може імітувати слабкий RF)

cr0x@server:~$ iw dev wlan0 get power_save
Power save: on

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

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

Завдання 8: Вимкнути енергозбереження Wi‑Fi на час тесту

cr0x@server:~$ sudo iw dev wlan0 set power_save off

Значення: Прибирає змінну. Якщо симптоми зникають, ваша «RF‑проблема» була політикою енергозбереження.

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

Завдання 9: Перевірте регуляторну зону та план каналів (псує порівняння)

cr0x@server:~$ iw reg get
global
country US: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW

Значення: Різні домени змінюють дозволену потужність і канали. Порівнювати тести між стендами без уніфікації regdom — це погана практика.

Рішення: Узгодьте регуляторні налаштування перед тим, як порівнювати «Пристрій A гірший за Пристрій B».

Завдання 10: Перевірте тротлінг CPU на тестовому хості (вузьке місце пропускної здатності вдає, що це RF)

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave

Значення: Якщо ваша тестова кінцева точка тротлить, результати iperf будуть неправдиві. Ви звинуватите антену за поведінку CPU‑гувернера.

Рішення: Переключіть на performance governor під час тестів або використайте апаратний еталон.

Завдання 11: Підтвердити рівні ретраїв (високі retries = погана якість лінку)

cr0x@server:~$ ip -s link show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543  65432      0       12       0     1234
    TX:  bytes packets errors dropped carrier collsns
    8765432  54321      0      210       0       0

Значення: Відкинуті TX‑пакети можуть свідчити про ретраї або проблеми драйвера; при RF‑проблемах відкиди і ретраї зростають під час поганого зчеплення.

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

Завдання 12: Захопіть події бездротового інтерфейсу в ту секунду, коли виникає проблема

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Tue Jan 21 14:02:15 2026] wlan0: deauthenticating from 3c:84:6a:12:34:56 by local choice (reason=3)
[Tue Jan 21 14:02:17 2026] wlan0: authenticate with 3c:84:6a:12:34:56
[Tue Jan 21 14:02:18 2026] wlan0: associated

Значення: Якщо пристрій деавтентифікується, можливо, ви дивитесь на політику софта або поведінку AP, а не на чисте RF‑атенюацію.

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

Завдання 13: Переконайтесь, що RF‑середовище не перенасичене (2.4 GHz — поле бою)

cr0x@server:~$ sudo iw dev wlan0 scan | awk -F: '/SSID|signal|freq/ {print}'
	freq: 2412
	signal: -39.00 dBm
	SSID: lab-ap
	freq: 2412
	signal: -41.00 dBm
	SSID: neighbor-wifi
	freq: 2412
	signal: -45.00 dBm
	SSID: coffee-shop

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

Рішення: Перейдіть на 5 GHz/6 GHz, ізолюйте канали або тестуйте в екранованому просторі перш ніж оголошувати дефект апаратури.

Завдання 14: Відстежуйте затримки під навантаженням (RF‑проблеми часто проявляються як bufferbloat + ретраї)

cr0x@server:~$ iperf3 -c 10.0.0.10 -t 15 & ping -i 0.2 -c 40 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=2.1 ms
64 bytes from 10.0.0.10: icmp_seq=10 ttl=64 time=48.7 ms
64 bytes from 10.0.0.10: icmp_seq=20 ttl=64 time=97.3 ms
--- 10.0.0.10 ping statistics ---
40 packets transmitted, 40 received, 0% packet loss, time 7990ms
rtt min/avg/max/mdev = 1.9/32.4/101.8/29.7 ms

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

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

Завдання 15: Шукайте варіації виробництва, порівнюючи кілька одиниць

cr0x@server:~$ paste unitA.rssi unitB.rssi unitC.rssi | head
-66	-70	-67
-67	-71	-68
-79	-90	-80
-66	-71	-67

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

Рішення: Якщо варіативність висока, потрібні контроль виробництва та скринінг, а не лише прошивка.

Завдання 16: Підтвердьте, що ваше «виправлення» (ізоляція/чохол) дійсно відновлює запас

cr0x@server:~$ diff -u no-case.summary with-case.summary
--- no-case.summary	2026-01-21 14:10:00
+++ with-case.summary	2026-01-21 14:20:00
@@ -1,3 +1,3 @@
-min_signal_dbm=-91
-avg_throughput_mbps=42
-drop_events=3
+min_signal_dbm=-78
+avg_throughput_mbps=188
+drop_events=0

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

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

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

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

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

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

Корінь був незручно фізичним. Резинове покриття «міцного» сканера містило тонке провідне покриття для управління ESD.
У лабораторії пристрої тестували на столі з мінімальним контактом руки. На складі оператори міцно стискали пристрій під час сканування,
стискаючи овермолд і змінюючи зчеплення біля антенного входу. Він детюнився достатньо, щоб випасти зі стабільного MCS в проходах з високими перешкодами.

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

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

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

Інша команда гналася за часом роботи батареї. Їх пристрій був комунікатором, схожим на телефон, для полевих техніків, і скарги на батарею були реальними.
Хтось запропонував зменшити потужність передавання в «хорошому покритті» для економії енергії і тепла. Це добре пройшло в лабораторії та в центрі міста.
Вони випустили зміни за feature flag і почали поступове включення.

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

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

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

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

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

Постачальник мережевих приладів — уявіть невеликі роутери в торгівельних мережах — мав дисциплінований чекліст релізів, який дратував усіх.
Кожна апаратна ревізія, навіть «косметична», вимагала RF‑регресійні тести з кількома корпусами, кількома проксима хвату і найгіршим планом каналів.
Це додавало дні до графіку. Менеджери продукту бурчали. Інженери скрипіли зубами.

Одного кварталу індустріальний дизайн змінив постачальника пластичної смоли. Та сама механічна специфікація, той самий колір, дешевша та краща логістика.
Зміна виглядала безпечно. Але RF‑команда регресії виявила послідовне падіння продуктивності 5 GHz біля одного кута корпусу. Не катастрофічно —
просто достатньо, щоб не пройти їх внутрішній сценарій «склад/бекофіс».

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

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

Урок: нудний процес — регресійні тести, базові лінії, перевірка варіацій — не потрапляє в заголовки, бо він працює.

Жарт №2 (короткий, доречний)

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

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

1) «Смуги впали, отже антену зламали»

Симптом: UI показує драматичний спад смуг при торканні.

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

Виправлення: Корелюйте смуги з SINR/пропускною здатністю/рівнем обривів дзвінків; регулюйте мапінг лише після перевірки фізики. Не використовуйте UI як основну метрику.

2) «Тільки деякі користувачі — отже це випадково»

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

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

Виправлення: Тестуйте в контрольованих умовах низького запасу; побудуйте набір сценаріїв «хвіст 10%», а не демо «кращий 90%».

3) «Наші лабораторні тести пройшли; поле неправе»

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

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

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

4) «Чохол вирішив проблему, отже ми все зробили»

Симптом: Ізолюючий чохол знижує скарги.

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

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

5) «Ми через прошивку оновимо закони фізики»

Симптом: Команда пропонує лише софт‑зміни для проблеми з зчепленням.

Корінна причина: Плутанина між мапінгом UI та налагодженням радіостеку з радіаційною ефективністю та імпедансним несумісністю.

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

6) «Одна золота одиниця доводить, що дизайн в порядку»

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

Корінна причина: Варіація виробництва, відмінності у збірці або тихі ревізії.

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

7) «Нехай підтримка впорається»

Симптом: Інженери уникають публічних деталей; підтримка отримує скрипти.

Корінна причина: Розбіжність між інженерною правдою і клієнтським наративом.

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

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

Крок за кроком: розслідування інциденту «рука впливає на сигнал»

1. Зафіксуйте базовий стенд. Той самий AP, той самий канал, та сама потужність, та сама прошивка, відома кінцева точка для тестів пропускної здатності.
2. Визначте симптом, видимий користувачу. Скидання дзвінків? Нижча пропускна здатність? Вища затримка? Лише спад смуг у UI?
3. Зберіть реальні RF‑метрики. RSSI/RSRP/RSRQ/SINR у часі, вирівняні з подіями (зміни хвату, рух).
4. Відтворіть в умовах низького запасу. Додайте контрольоване затухання або відстань, щоб симулювати погане покриття.
5. Проведіть A/B хвати. Нормальний хват проти найгіршого випадку з повторюваними спробами; записуйте розподіли.
6. Спробуйте ізоляційне пом’якшення. Чохол/стрічка контрольовано. Якщо це суттєво допомагає, ви виявили чутливість зчеплення.
7. Тестуйте кілька одиниць. Шукайте варіації. Якщо підмножина значно гірша, підозрюйте допуски/збірку.
8. Відділіть «мапінг» від «фізики». Якщо смуги змінюються, але пропускна здатність/стабільність дзвінків — ні, розглядайте це як борг інструментації/UX.
9. Вирішіть стратегію пом’якшення. Термінове рішення для клієнтів, прошивка‑запобіжники, апаратний ревізіон або всі три.
10. Напишіть постмортем. Включіть припущення, що зламалося, відсутній тест і запобіжний контроль, який ви додасте.

Чекліст релізу: як не створити власний Antennagate

• Адвесаріальні тести людського зчеплення щонайменше в трьох реалістичних хватах і двох орієнтаціях.
• Тестування хвоста: перевірка поведінки в нижньому 10% запасу сигналу, а не в медіані.
• Тестування варіативності між одиницями та між виробничими партіями.
• Тестування взаємодії з аксесуарами: чохли, бампери, кріплення і док‑зарядки.
• План телеметрії: логування метрик лінку і лічильників відмов з дотриманням приватності.
• Готове клієнтське пом’якшення: чесний скрипт підтримки і чітке тимчасове рішення.

Чекліст комунікацій (бо PR — частина опсів)

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

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

1) Чи був Antennagate «реальним», чи це радше питання смуг у UI?

Реальний. Мапінг смуг відігравав роль у сприйнятті, але багато користувачів могли відтворити значне погіршення лінку і скидання дзвінків у слабкому покритті.
Розглядайте це як комбінований інцидент фізики + інструментації.

2) Чому це не зачепило всіх однаково?

Бо запас RF сильно варіюється. У сильному сигналі ви можете втратити багато і все одно працювати. У маргінальному сигналі невеликі втрати стають відмовами.
Крім того, люди тримають пристрої по-різному, а мультипопадання змінюється на кожному метрі.

3) Чи всі телефони втрачають сигнал при торканні?

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

4) Чому iPhone 4 був особливо чутливий?

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

5) Чи є чохол легітимним інженерним рішенням?

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

6) Який еквівалент Antennagate у програмних системах?

Будь‑яка відмова, де нормальна поведінка користувача стає тригером: хвилі повторів, масові одночасні звернення після пропаду кеша, або дія UI, що випадково DOSить API.
Шаблон — «ми не змоделювали домінантну реальну поведінку».

7) Як тестувати проактивно, якщо у вас немає дорогих RF‑лабораторій?

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

8) Якщо проблема в фізиці, чи може прошивка взагалі допомогти?

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

9) На що має звернути увагу постмортем для апаратного інциденту на кшталт цього?

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

10) Що одне команди мають припинити робити після вивчення цієї історії?

Припиніть називати хвилинні хвости «крайовими випадками». Хвости — це місце, куди йдуть репутації, бо саме там помічають користувачі.

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

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

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

1. Запишіть свої припущення щодо запасу лінку так само, як ви записуєте припущення SLO. Потім атакуйте їх.
2. Додайте адвесаріальні тести з людиною в циклі до вашого release gate, а не як доповнення.
3. Вимірюйте реальні метрики, а не проксі UI, і корелюйте їх із болем користувача (скидання, ретраї, колапс пропускної здатності).
4. Кількісно оцініть варіативність між одиницями і партіями; RF чутливий, і допуски — частина системи.
5. Плануйте пом’якшення як оператор: швидке тимчасове рішення зараз, надійний редизайн пізніше і чесні комунікації протягом усього процесу.

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