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

Tl;dr: У наступній публікації детально описано, як ми вимірюємо ефективність клієнтів у різних продуктах і багатофункціональних командах Coinbase.

Леонардо Зіззамія, старший інженер-програміст

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

У 2022 році Coinbase тепер має інженерів, які працюють над багатьма пропозиціями продуктів і чотирма платформами: React Web, React Native, Server Side Rendering і Chrome Extension. Продуктивність усіх чотирьох платформ раніше ніколи не була стандартизована, тому нам потрібно було розглянути кілька аспектів: відсутність достатньої кількості повних даних для деяких платформ, втрату ефективності, коли неможливо визначити можливості продуктивності, і послідовне визначення пріоритетів у всіх командах.

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

Розширення Google Web Vitals

Спільнота веб-розробників має Основні веб-значення стандарт для вимірювання продуктивності клієнтів, який ми прийняли та активно використовуємо в Coinbase.

Важливі показники розрізняються за пороговими значеннями, які класифікують кожне вимірювання продуктивності як «добре»,«потребує покращення", Або"бідні".

Нижче наведено один із прикладів того, де може бути порогове значення для одного з веб-показників, час до першого байта.

Щоб класифікувати загальну продуктивність клієнтського продукту, Coinbase дотримується найкращих практик і використовує значення 85-го процентиля всіх вимірювань для цієї сторінки чи екрана. Іншими словами, якщо хоча б 85% вимірювань на сайті зустріти "добре», сайт класифікується як такий, що має «добру» ефективність за цим показником. Цей показник на 10 пунктів вищий, ніж Стандарт Google Web Vitals, що дає нам достатню пропускну здатність для виправлення потенційних регресій.

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

Сьогодні ми представляємо інноваційний внутрішній показник, який ми називаємо Загальний час блокування навігації (NTBT). NTBT вимірює проміжок часу, протягом якого програмі може бути заблоковано обробку коду протягом 2-секундного вікна після переходу користувача зі сторінки A на сторінку B. Показник NTBT – це сума часу блокування для всіх довгих завдань у вікні 2 секунди після цей метод викликається.

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

Ще один спосіб корисного використання Perfume.js полягає в тому, що ми можемо збагачувати всі показники інформацією API Navigator, щоб розрізняти досвід низького та високого рівня.

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

Показники ефективності Coinbase

Окрім створення веб-додатків, ми створюємо мобільні додатки React Native і служби, які надають їхні дані. Ми повторно використали найкращі практики Web Vitals і створили нові показники для обслуговування програм React Native і наших серверних служб. Разом ми називаємо їх «Показники ефективності», і вони дають нам цілісне уявлення про показники продуктивності всіх наших додатків, починаючи від низхідних (браузер і програми) і закінчуючи вищими (серверні служби).

Як видно на діаграмі нижче, показники ефективності розподіляються наскрізно, від низхідних до вихідних.

Створення React Native Vitals

Оцінюючи продуктивність для React Native, ми розробили початкові Vitals Відтворення програми завершено та Загальний час блокування навігації.

• Відтворення програми завершено (ARC): Вимірює кількість часу, необхідного для переходу від запуску програми до повного відтворення вмісту користувачеві без індикаторів завантаження. Добрий поріг 5s базується на вказівках від Спільнота Android офіційне дослідження.
• Загальний час блокування навігації (NTBT): Вимірює проміжок часу, протягом якого програмі може бути заблоковано обробку коду протягом 2-секундного вікна після переходу користувача з екрана A на екран B.

Для NTBT ми використали наявні знання про загальний час блокування з Web Vitals, щоб визначити порогове значення для мобільних пристроїв. Враховуючи, що хороший TBT в Інтернеті становить 200 мс, і ми очікуємо, що для мобільних пристроїв знадобиться більше часу, ми подвоїли стандарт із Інтернету, щоб отримати 400 мс для мобільних пристроїв.

У наступному відео показано, як розробник продукту може виявляти довготривалі завдання, вимірювати загальний час блокування під час навігації між сторінками та додаткові вимірювання NTBT.

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

Подібно до досвіду Інтернету, Coinbase створила власну бібліотеку React Native Core Vitals для вимірювання цієї ефективності з метою відкритих джерел наше відкриття повернеться спільноті в найближчі квартали.

Створення базових показників

Як ми це зробили Сайт і React Native Vitals, ми розширили стандарт Vitals до серверних служб, включаючи GraphQL і Backend Services.

Два показники, які ми спочатку створили:

• Час відгуку GraphQL (GRT): Час у дорозі для GraphQL послуга для обслуговування запиту.
• Час відгуку висхідного каналу (URT): Час у дорозі для Шлюз API для обслуговування серверної служби.

Щоб визначити хорошу оцінку для відображення серверної затримки, ми врахували кілька моментів:

1. З точки зору користувача, відчувається час реакції системи негайно, коли менше 1 с.
2. Ми також маємо взяти до уваги, що вартість мережі може варіюватися від 50 до 500 мс, залежно від регіону, з якого користувач отримує доступ до нашого продукту.
3. Виходячи з пунктів 1 і 2, затримка GraphQL не повинна перевищувати 500 мс, тобто вихідні служби повинні відповідати менше ніж за 300 мс, оскільки запити GraphQL мають чекати найповільнішої кінцевої точки.
4. Тому ми дійшли висновку, що поріг для оцінки GRT Good становить 500 мс, а оцінки URT Good — 300 мс.

Для Backend Vitals ми прагнемо принаймні 99 відсотків вимірювань для кожного зареєстрованого запиту відповідати порогу «Добре».

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

Прилади для Базові показники складається з трьох основних частин. По-перше, ми використовуємо нашу внутрішню аналітичну бібліотеку для визначення метаданих, таких як продукт, платформа та сторінки. Потім ми поширюємо цю інформацію в наші API і, зрештою, розміщуємо показники продуктивності разом із метаданими Web або React Native.

Можливість виявлення та визначення пріоритетів показників ефективності

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

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

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

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

Квартальне та річне планування

Performance Vitals ідеально підходять для планування KR, оскільки вони вимірюють оцінку від 0 до 100 і їх можна легко зберігати більше року. Загальна мова для всіх KR також полегшує створення спільних цілей для команд у всій організації.

Кілька прикладів того, як ви можете сформулювати свої KR:

• [Year KR] Досягніть NTBT Good Score у 90% порівняно з 70% у мобільному додатку Coinbase.
• [Квартал KR] Підвищити LCP Good Score з 70% до 85% у мережі Coinbase.

Вгору Далі

Performance Vitals повертаються до пошуку спільної мови, будь то стандартизація фільтрів, встановлення квартальних KR чи уніфікація системи оцінки. Від невеликої команди, яка працює над регресією API, до великих ініціатив, очолюваних кількома організаціями, спілкування однією мовою допомагає визначити пріоритети для всіх типів продуктів.

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