Google Glass: коли майбутнє в публічному просторі здавалося незручним

Що насправді намагався стати Glass (і чому це було важливо)

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

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

Момент, коли ви підключаєте обчислення до обличчя, змінює обмеження дизайну:

• Затримка — це емоція. Якщо голосова команда додає ще секунду, це вже не «повільно», це «ми виглядаємо смішно, коли я розмовляю сам із собою».
• Витрата батареї стає політикою. Коли пристрій сідає посеред зміни, це не просто незручність — це зупинка процесу.
• Приватність — не функція; це шлюз для розгортання. Ви можете мати найкращу архітектуру безпеки у світі й все одно опинитися вигнанцем з бару.
• Обсервабельність обмежена. Не можна поставити 200МБ агента й назвати це моніторингом. Ваш бюджет логів вимірюється міліватами.

Отже, так — Glass був продуктом. Але також це була рання спроба того, що тепер називають «edge computing з людиною в циклі». А люди, як відомо, відмовляються поводитися як вузли Kubernetes.

Цікаві факти й контекст, які можна використати на зустрічах

Короткі, конкретні пункти контексту, що триматимуть розмови в реальності:

1. Проект Glass став публічним у 2012 році з демонстрацією стрибка з парашутом, яка зробила майбутнє беззусильним — бо трюки добре приховують операційні обмеження.
2. Екземпляри Explorer Edition коштували $1,500, що позиціонувало Glass як набір для розробників, але культурно він сприймався як споживчий продукт з відповідною пильністю.
3. «Glasshole» увійшло в лексикон як ярлик соціального тертя камер на обличчі — шкода бренду, яку не виправить жодне оновлення.
4. Ранні Glass сильно покладалися на Bluetooth-тетеринг до телефону для підключення, що означало, що фактично ви працювали як двопристроєва розподілена система.
5. Початкове обладнання використовувало маленький призмовий дисплей, який вкидав інформацію в периферійне бачення — блискуче для швидких поглядів, незручно для тривалого читання.
6. Батарея була частою скаргою, особливо під час використання камери; захоплення відео — найбільш стресове навантаження для тепла й енергії.
7. Google завершив споживчу програму Explorer у 2015 році, що багато хто трактував як «продукт зазнав поразки», але базові сценарії використання не зникли.
8. Glass повернувся як корпоративний продукт (Glass Enterprise Edition) для логістики, польового обслуговування та виробництва — там, де незручності терпіли, якщо вони економлять хвилини.
9. Багато закладів забороняли Glass або просили зняти; публічна політика стала залежністю на час виконання.

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

Чому майбутнє виглядало незручно в публічному просторі: «операції» соціального прийняття

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

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

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

Оптика приватності переважає інженерію приватності

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

Операційно це важливо, бо крива впровадження стає недетермінованою. Ви не можете планувати потужність флоту, якщо місцеві менеджери імпровізують політики: «Ніякого Glass на нарадах», «Тільки у складі», «Не біля клієнтів», «Звісно, не в туалетах, навіщо про це згадувати?» Пристрій стає магнітом для політик.

Ілюзія «завжди ввімкнено» й пастка надійності

Носимі пристрої рекламують «завжди доступний». Користувач чує: «Він не підведе мене». А пристрій чує: «Успіхів у цьому».

Розумні окуляри майже завжди обмежені:

• Ємністю батареї (малий форм-фактор)
• Тепловим обмеженням (поблизу шкіри людини)
• Мережею з перемінною якістю (рух, перешкоди, роумінг)
• Невизначеністю вводу (голос, рух голови, тачпад)

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

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

Несумісність: оптимізм розробника проти толерантності публіки

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

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

Системний погляд: батарея, тепло, мережа та людський I/O

Якщо ви хочете зрозуміти Glass, не починайте з AR. Почніть з обмежень. Стек — це переговори між фізикою й поведінкою.

Батарея: найменш поблажливий SLO

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

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

• фонова програма, що утримує wake lock
• радіо, застрягле в режимі високої потужності через слабкий сигнал
• контур із жорстким циклом, що повторно надсилає невдале завантаження
• термальне тротлінг, що подовжує активний час для тієї самої роботи

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

Тепло: прихований регулятор

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

Мережа: роумінг — це режим відмови, не функція

Роумінг між AP на папері простий. У реальних будівлях це місце загибелі сесій.

Носимі пристрої епохи Glass покладалися на тетеринг до телефону або прості Wi‑Fi стеки. Це вводить багатоступеневі відмови: батарея телефону, фонові обмеження ОС телефону, якість Bluetooth-зв’язку і captive portal у Wi‑Fi. Ваш «вихід програми» може насправді бути бурею перепідключень Bluetooth у чиїйсь кишені.

Людський I/O: ваш інтерфейс — це канал інцидентів

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

Отже, сприймайте UX як частину опсів. Поганий UX генерує операційне навантаження так само, як багатий клієнт генерує «thundering herds».

Одна цитата про надійність, яку варто мати на стіні

Надія не є стратегією. — Gene Kranz

Це тут застосовується жорстко: сподіватися, що користувачі «просто заряджатимуть», «знайдуть кращий Wi‑Fi» або «використовуватимуть у відповідних місцях» — не операційний план.

Три корпоративні міні-історії з фронту носимих пристроїв

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

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

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

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

Нарешті хтось поставив банальне питання: «Яка сила сигналу там, де це падає?» Зіставивши відключення зі типами локацій, вони виявили справжнього винуватця: RF-мертві зони й баги роумінгу AP на кількох клієнтських майданчиках. Виправлення не було «більше бекенду». Це був режим локального кешування з явною офлайн-поведінкою і правило: не намагатися вести пряму трансляцію нижче порога сигналу; переходити на збереження й пересилання пізніше.

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

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

Логістична фірма хотіла швидшого зчитування штрихкодів на окулярах. Команда оптимізувала агресивно: тримати прев’ю камери «гарячим», попередньо завантажувати ML-модель і запускати постійну автофокусування. Демонстрація була прекрасною. Затримка сканування впала. Люди аплодували. Хтось написав «game changer» у презентацію — надійний предиктор майбутнього болю.

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

Оператори також помітили новий клас відмов: пристрої не витримували зміну без підзарядки посеред дня, тож працівники почали підключати їх до випадкових USB-портів. Деякі порти були лише для заряджання, деякі були за зачиненими шафами, деякі — на ПК, які запускали незвідані оновлення. Оптимізація опосередковано збільшила вектор атаки й навантаження на підтримку.

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

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

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

Група промислового обслуговування розгорнула окуляри на кількох заводах. Керівництво хотіло швидкості, але один досвідчений ops-лідер наполіг на нудному розгортанні: інвентаризація кожного пристрою, уніфіковані збірки ОС і поетапні оновлення. Ніякої героїки. Просто дисципліна.

Вони створили три кільця: лабораторія, пілот, широке розгортання. Кожне оновлення — ОС, політика MDM, їхній додаток — мало відстоюватися тиждень у лабораторії, потім тиждень у пілоті перед широким розгортанням. Також вони збирали метрики здоров’я пристрою (цикл батареї, кількість крашів, піки температури) в центральну панель.

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

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

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

Експлуатація розумних окулярів — це експлуатація флоту плюс налагодження мобільних пристроїв плюс мережева реальність. Нижче наведені практичні завдання, які ви можете виконати вже сьогодні, використовуючи стандартні інструменти Linux і Android Debug Bridge (ADB). Мета не в тому, щоб прикидатися хакером. Мета — швидко й аргументовано приймати рішення на основі доказів.

Завдання 1: Перевірити, чи пристрій доступний через ADB (USB)

cr0x@server:~$ adb devices
List of devices attached
8a3f21d2	device

Що означає вивід: Ідентифікатор пристрою відображається як device, а не unauthorized чи порожній.

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

Завдання 2: Зняти базову ідентифікацію пристрою (OS/build)

cr0x@server:~$ adb shell getprop ro.build.fingerprint
google/glass_enterprise/glass:10/QP1A.190711.020/6789012:user/release-keys

Що це означає: Точний відбиток збірки ОС для кореляції.

Рішення: Якщо інциденти корелюють із конкретним fingerprint, зупиніть розгортання й ізолюйте.

Завдання 3: Перевірити вільне сховище (шторм логів любить повні диски)

cr0x@server:~$ adb shell df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/block/dm-0  24G   22G  1.8G  93% /data

Що це означає: /data майже заповнений; додатки можуть падати, оновлення — зазнати невдач, бази даних — пошкодитися.

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

Завдання 4: Визначити топ-споживачів CPU (попередник тротлінгу)

cr0x@server:~$ adb shell top -b -n 1 | head -n 12
Tasks: 279 total,   2 running, 277 sleeping,   0 stopped,   0 zombie
%Cpu(s): 38.0 us,  8.0 sy,  0.0 ni, 54.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER         PR  NI  VIRT  RES  SHR S[%CPU] %MEM     TIME+ ARGS
 3124 u0_a133      10 -10 2.1G  188M  92M R 28.5  3.2   0:43.12 com.company.assist
  987 system       20   0  132M   34M  18M S  6.2  0.6   2:10.44 surfaceflinger

Що це означає: Ваш додаток спалює CPU. Навантаження surfaceflinger вказує на важке рендеринг UI.

Рішення: Якщо CPU високий у стані «idle», шукайте wake locks, цикли прев’ю камери або stormи повторів.

Завдання 5: Перевірити тепловий статус і сигнали тротлінгу

cr0x@server:~$ adb shell dumpsys thermalservice | head -n 20
IsStatusOverride: false
Thermal Status: 2
Temperature{mValue=41.5, mType=CPU, mName=cpu-0, mStatus=2}
Temperature{mValue=39.0, mType=SKIN, mName=skin, mStatus=1}

Що це означає: Підігрітий CPU; тепловий статус вказує на середній ризик тротлінгу.

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

Завдання 6: Снімок здоров’я батареї (знайти винуватців wake lock)

cr0x@server:~$ adb shell dumpsys batterystats --charged | head -n 25
Battery Statistics (Charged):
  Estimated power use (mAh):
    Capacity: 780, Computed drain: 612, actual drain: 590
  Per-app estimated power use (mAh):
    com.company.assist: 210
    com.android.systemui: 68

Що це означає: Ваш додаток — великий споживач енергії.

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

Завдання 7: Перевірити wake locks (класична помилка «завжди ввімкнено»)

cr0x@server:~$ adb shell dumpsys power | sed -n '1,120p'
Power Manager State:
  mWakefulness=Awake
  Wake Locks: size=2
  * WakeLock{c11a2b1 held=true flags=0x1 tag="com.company.assist:stream" uid=10133}
  * WakeLock{a84f21d held=false flags=0x1 tag="AudioMix" uid=1041}

Що це означає: Ваш додаток утримує wake lock з тегом stream.

Рішення: Якщо wake lock тримається поза активним використанням, виправте життєвий цикл; інакше ваш SLO по батареї — ілюзія.

Завдання 8: Перевірити стан мережевого інтерфейсу й IP-адресацію

cr0x@server:~$ adb shell ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 3000
    inet 10.42.18.77/24 brd 10.42.18.255 scope global wlan0

Що це означає: Wi‑Fi увімкнений з IP; базовий L3-зв’язок можливий.

Рішення: Якщо немає IP, налагодьте DHCP, captive portal або MDM Wi‑Fi профілі перед тим, як чіпати код додатка.

Завдання 9: Заміряти втрати пакетів/затримки до вашого API (з пристрою)

cr0x@server:~$ adb shell ping -c 5 api.internal
PING api.internal (10.42.50.12): 56 data bytes
64 bytes from 10.42.50.12: icmp_seq=0 ttl=63 time=18.4 ms
64 bytes from 10.42.50.12: icmp_seq=1 ttl=63 time=220.1 ms
64 bytes from 10.42.50.12: icmp_seq=2 ttl=63 time=19.2 ms
64 bytes from 10.42.50.12: icmp_seq=3 ttl=63 time=21.0 ms
64 bytes from 10.42.50.12: icmp_seq=4 ttl=63 time=19.1 ms

--- api.internal ping statistics ---
5 packets transmitted, 5 received, 0% packet loss
round-trip min/avg/max = 18.4/59.5/220.1 ms

Що це означає: Втрат немає, але джиттер високий; максимальна RTT — користувацько-видима «паузa».

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

Завдання 10: Перевірити розв’язання DNS (поширено в заблокованих мережах)

cr0x@server:~$ adb shell getprop net.dns1
10.42.0.2

Що це означає: Пристрій має налаштований DNS-рекурсор.

Рішення: Якщо DNS пустий або вказує на captive portal, виправте Wi‑Fi провізіювання і припущення про split-horizon DNS.

Завдання 11: Завантажити логи за конкретне вікно крашу

cr0x@server:~$ adb logcat -d -t 200 | tail -n 30
01-21 10:14:22.884  3124  3180 E AssistStream: upload failed: java.net.SocketTimeoutException
01-21 10:14:22.886  3124  3180 W AssistStream: retrying in 0ms
01-21 10:14:22.901  3124  3180 E AssistStream: upload failed: java.net.SocketTimeoutException
01-21 10:14:22.902  3124  3180 W AssistStream: retrying in 0ms

Що це означає: Цикл повторів з 0ms бекофом — це баг, що плавить радіо.

Рішення: Додайте експоненційний backoff з джиттером і circuit breaker; також обмежте кількість паралельних завантажень.

Завдання 12: Підтвердити, чи пристрій роумить між AP

cr0x@server:~$ adb shell dumpsys wifi | sed -n '1,140p'
Wi-Fi is enabled
Current network: "CorpWiFi" WPA2
RSSI: -76
BSSID: 8c:3b:ad:11:22:33
Supplicant state: COMPLETED
Roam count: 9

Що це означає: Слабкий сигнал і частий роумінг; ідеальний рецепт для падіння стрімів.

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

Завдання 13: Перевірити TLS-хендшейк і ланцюг сертифікатів із опс-боксу

cr0x@server:~$ openssl s_client -connect api.internal:443 -servername api.internal -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Peer certificate: CN = api.internal
Verification: OK

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

Рішення: Якщо перевірка падає лише на пристроях — шукайте відсутні проміжні сертифікати, застарілі сховища довіри або MITM від captive portal.

Завдання 14: Швидко перевірити насичення серверної сторони (CPU, пам’ять, диск I/O)

cr0x@server:~$ uptime
 10:22:51 up 41 days,  6:13,  3 users,  load average: 6.42, 6.81, 6.77

Що це означає: Навантаження підвищене; не доказ CPU-сатурації, але підказка.

Рішення: Якщо навантаження росте разом із сесіями носимих пристроїв, перевіряйте I/O wait і пул потоків; не додайте поди на автопілоті.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  1      0 245312  82240 731204    0    0  1240  2110 3810 6120 32  9 44 15  0
 4  2      0 241800  82244 731010    0    0  1420  2380 3992 6450 28 10 43 19  0

Що це означає: wa (I/O wait) нетривіальний; сховище або мережеві диски можуть бути вузьким місцем.

Рішення: Якщо I/O wait високий — дослідіть затримки диска й глибину черг перед масштабуванням обчислень.

Завдання 15: Помітити тиск на диск на сервері (нудний вбивця)

cr0x@server:~$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  200G  192G  8.0G  97% /var

Що це означає: Логи, завантаження або кеші заповнюють /var.

Рішення: Якщо ви вище 90–95% — обертайте логи, перемістіть кеши й увімкніть алерти. Повні диски створюють «випадкові» збої, які насправді дуже передбачувані.

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

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

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

Перше: вирішіть, де вузьке місце — пристрій, мережа чи бекенд

1. Знімок стану пристрою: топ-споживачі CPU, тепловий статус, вільне сховище, витрата батареї по додатках.
2. Мережева реальність: RSSI, кількість роумінгів, джиттер ping, коректність DNS.
3. Насичення бекенду: рівні помилок, затримки, черги, використання диска, I/O wait.

Правило: Якщо пристрій гарячий, має мало місця або утримує wake locks, не витрачайте час на звинувачення мережі спочатку.

Друге: ідентифікуйте режим відмови (retry storm, throttle або hard crash)

• Retry storm: логи показують щільні цикли, таймаути, миттєві повтори, часті перепідключення.
• Throttle: thermalservice показує ріст статусу; CPU виглядає «нормальним», але інтерфейс смикається; падіння кадрів при камері.
• Hard crash: tombstone-файли, фатальні виключення, ANR-трейси; часто спричинені браком пам’яті або тиском на сховище.

Третє: застосуйте найменше безпечне пом’якшення

Пом’якшення повинно зменшувати навантаження, а не збільшувати його.

• Відключити або деградувати: знизити бітрейт відео, призупинити завантаження при поганому RSSI, зменшити частоту прев’ю камери, відкласти ML-інференс.
• Backoff і обмеження: експоненційний backoff з джиттером, максимум повторів, circuit breaker, ідемпотентні кінцеві точки.
• Зупинити кровотечу: призупинити розгортання, відкотити збірки, карантинувати зміну політики.

Четверте: виправте корінну причину з охоронними механізмами

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

• бюджети енергії для кожного робочого процесу
• теплові пороги, що викликають плавну деградацію
• офлайн-поведінка «за замовчуванням» з чітким UX
• мережеві ворота якості (не намагайтеся стрімити при поганому RF)
• кільця оновлень і прив’язування збірок

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

1) «Живучість батареї жахлива, навіть коли я не користуюся»

Симптоми: Пристрій сідає посеред зміни; теплий у стані «idle»; графіки використання звинувачують ваш додаток.

Корінна причина: Wake locks, гарячий конвеєр камери, агресивні повтори або безперервне сканування/ML.

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

2) «Стріми обриваються випадково»

Симптоми: Відеодзвінки зависають; петлі перепідключення; скарги прив’язані до певних кімнат чи поверхів.

Корінна причина: Роумінг, слабкий RSSI, captive portals, нестабільність tethering через Bluetooth або band steering на AP.

Виправлення: Обмежте живе стрімування в залежності від якості мережі; підтримуйте відновлювані сесії; налаштуйте Wi‑Fi; віддавайте перевагу store-and-forward у мертвих зонах.

3) «Додаток повільний, але бекенд в нормі»

Симптоми: Серверна латентність нормальна; користувачі відчувають лаг; пристрій здається «липким».

Корінна причина: Тепловий тротлінг, блокування UI-потоку або CPU, зайнятий фоновою роботою.

Виправлення: Профайлитьте на пристрої; зменшіть частоту кадрів; винесіть роботу з UI-потоку; додайте поведінку, що враховує тепло; зменшіть вартість прев’ю камери.

4) «Після оновлення все стало дивним»

Симптоми: Кількість звернень у підтримку зросла; непослідовна поведінка; страждає лише частина пристроїв.

Корінна причина: Часткове розгортання, змішані збірки ОС, дрейф політик або регресія в стеку радіо/дозволів.

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

5) «Пристрій підключений до Wi‑Fi, але нічого не працює»

Симптоми: Іконка Wi‑Fi є; додаток таймаутить; DNS не працює; веб-переглядачі показують сторінки входу.

Корінна причина: Captive portal, заблокований DNS, вимоги проксі або правила файрволу, що ламають TLS.

Виправлення: Виявляйте captive portal; налаштуйте корпоративний Wi‑Fi належним чином (802.1X, де потрібно); дозволяйте необхідні кінцеві точки; уникайте крихких припущень про відкритий інтернет.

6) «Користувачі не користуються функцією, яку ми побудували»

Симптоми: Телекеметрія показує низьку залученість; навчання не допомагає; функція технічно відточена.

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

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

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

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

1. Виберіть правильний сценарій використання. Якщо цінність вимагає постійного запису в публічних місцях — очікуйте політичного тертя. Починайте в контрольованих середовищах (склад, польовий сервіс, виробництво).
2. Визначте SLO, що відповідають реальності. Включіть виживання батареї за зміну, відсоток успішних перепідключень, час до першого кадру і завершення офлайн-завдань — не лише uptime API.
3. Проектуйте «офлайн за замовчуванням». Store-and-forward, відновлювані завантаження і явний зворотний зв’язок користувачу при поганій мережі.
4. Реалізуйте мережеві ворота якості. Не намагайтеся стрімити високим бітрейтом нижче порога сигналу; деградуйте плавно.
5. Інструментуйте енергію й теплові показники. Захоплюйте витрату батареї по робочих процесах, переходи теплового статусу й завантаження CPU у стані «idle».
6. Побудуйте кільця оновлень. Lab → pilot → broad. Фіксуйте збірки. Відкат має бути рутинною дією, а не героїчною.
7. Ідентичність флоту й гігієна політик. Реєструйте пристрої, вимагайте коди доступу, керуйте сертифікатами й уніфікуйте Wi‑Fi профілі.
8. Бюджет логів і ротація. Обмежуйте логи на пристрої, обертайте серверні логи й сигналізуйте про використання диска. Обсервабельність не повинна «вбивати» пристрій.
9. Безпека з урахуванням ергономіки. MFA, що вимагає вводити довгі коди на дисплеї біля обличчя — не «безпечно», це «не використовується». Використовуйте ідентичність, прив’язану до пристрою, і короткі потоки повторної аутентифікації.
10. Навчайте щодо поведінки, а не фіч. Навчайте, коли не користуватися, як сигналізувати про запис і як поводитися в чутливих зонах.
11. Плануйте зарядку, як плануєте запчастини. Уніфікуйте зарядні пристрої, маркуйте порти, уникайте випадкового USB-заряджання й розглядайте станції зарядки як інфраструктуру.
12. Проводьте game days. Симулюйте captive portal, бурі роумінгу і деградацію бекенду. Підтвердіть, що пристрій деградує плавно.

Чек-лист: перед пілотом

• Всі пристрої зареєстровані, інвентаризовані й промарковані
• Єдиний fingerprint ОС усього флоту
• Wi‑Fi профілі протестовані в реальних локаціях (включно з мертвими зонами)
• Офлайн-режим протестований і повідомлений користувачам
• Backoff/circuit breaker перевірені (немає 0ms retry loops)
• Телеметрія тепла й батареї увімкнена з панелями
• Політика приватності задокументована для середовища (правила запису)
• План відкату відрепетируваний

Чек-лист: що логувати (і що ні)

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

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

Чи був Google Glass «попереду свого часу» чи просто поганою ідеєю?

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

Чому публічна реакція мала таке технічне значення?

Бо вона зменшила реальне використання, що позбавило продукт природних зворотних зв’язків і нормалізувало політики «не використовувати тут». Це фактично простою для основного контексту, де Glass був потрібен.

Яка була найбільша операційна проблема для розумних окулярів?

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

Чому тетеринг до телефону — така проблема?

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

Як корпоративні впровадження уникали проблеми «незручності в публіці»?

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

Яка перша метрика, яку б ви додали для флоту на кшталт Glass?

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

Як уникнути retry storms на носимих пристроях?

Експоненційний backoff з джиттером, жорсткий ліміт на повтори, circuit breaker і ідемпотентні кінцеві точки на сервері. Потім тестуйте це при втраті пакетів і роумінгу — а не тільки на ідеальному Wi‑Fi.

Який типовий сигнал, що ви тротлите через тепло?

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

Яку пораду ви дали б перед початком розробки софту для розумних окулярів?

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

Google Glass «провалився», чи просто змінив ринок?

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

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

Google Glass нагадує, що майбутнє не блокують фантазії. Його блокують батареї, тепло, роумінг і те, що людям не подобається відчуття запису. Якщо ви відправляєте носимі пристрої — або будь-який edge-пристрій, що живе в людському просторі — сприймайте «незручність» як сигнал продуктивності, а не як маркетингову проблему.

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

1. Напишіть SLO, що включають виживання батареї й завершення офлайн-завдань.
2. Додайте термальну й енергетичну телеметрію, пов’язану з робочими процесами.
3. Аудитуйте поведінку клієнта щодо повторів; знищіть 0ms retry цикли.
4. Змініть мапу RF-мертвих зон і спроектуйте явні офлайн/низькосигнальні режими.
5. Впровадьте кільця оновлень і фіксацію збірок перед масштабуванням флоту.
6. Документуйте правила приватності для середовищ, в яких працюєте — і забезпечуйте їх UX-ом, а не надією.

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