Як виявилася проблема

Трекер помилок пісочниці видав одне яскраве повідомлення: «undefined is not an object». Заголовок вказував на просту друкарську помилку в JavaScript, тому команда шукала неіснуючий шлях у коді. Коли вони перевірили сирі метадані, то побачили, що 89 % цих інцидентів насправді були тайм-аутами мережі. Панель керування взяла першу помилку, що надійшла, і використала її для назви всієї групи, маскуючи справжній тип збою.

Урок 1 — Заголовки на панелях керування можуть вводити в оману

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

Урок 2 — Значення-заповнювачі (placeholders) — це не вимірювання

Щоб не завантажувати важке середовище виконання (runtime) для користувачів із повільним інтернетом, код звертався до Network Information API та зчитував властивість downlink, яка показує швидкість у мегабітах на секунду. Під час першого візиту Chrome часто повертає значення-заповнювач замість реального вимірювання. Логіка сприйняла цей заповнювач як швидке з'єднання і пропустила оптимізацію, фактично заблокувавши саме тих користувачів, яким вона мала допомогти.

Сприймайте будь-яке значення за замовчуванням або контрольне значення (sentinel value) як «немає даних». Заповнювач має запускати стратегію відкату (fallback), а не інтерпретуватися як реальний показник швидкості.

Урок 3 — Мережеві умови змінюються, тому один знімок стану ненадійний

Після вирішення проблеми з downlink команда перейшла на перевірку effectiveType, яка класифікує з'єднання як «4g», «3g» тощо. Швидкий лабораторний тест пройшов успішно, але той самий тест, запущений за мить, завершився невдачею. Мобільні з'єднання нестабільні: користувач може мати швидке 4G одну секунду і переключитися на повільніше 3G наступної. Перевірка з'єднання лише під час завантаження сторінки — це лотерея.

Правильний підхід полягає в тому, щоб підписатися на подію change об'єкта Network Information і реагувати на будь-яку зміну пропускної здатності, а не приймати одноразове рішення.

Що змінила команда

  • Двохстадійне завантаження — Тепер середовище виконання починається з крихітного файлу завантаження (bootstrap). Якщо з'єднання визначено як повільне, bootstrap завантажує решту середовища малими частинами, що зменшує ризик повного переривання.
  • Живий моніторинг — Замість одноразового зчитування downlink, код тепер слухає події change і на льоту коригує стратегію завантаження.
  • Стабільний вибір джерела — Раніше система змінювала CDN прямо під час завантаження, якщо з'являвся швидший вузол. На повільному з'єднанні це призводило до перезапуску завантаження з нуля, що лише погіршувало проблему. Нова логіка фіксує джерело на весь час завантаження.
  • Відкладений запис у кеш — Важкі операції з кешем, які виконувалися до того, як додаток ставав доступним, тепер відкладаються до моменту запуску середовища виконання, звільняючи пропускну здатність для критично важливого завантаження.

Ширші наслідки

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

На що звернути увагу далі

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