Читання довгого хвоста
Латентність живе на кривій, не на числі
Середня латентність приховує те, що переживають користувачі. Реальні сервіси виробляють розподіл: криву, яка показує, скільки запитів тривало як довго.
Три точки на цій кривій мають більшість операційного значення:
- p50 (медіана): середина розподілу. Половина запитів закінчується швидше, половина повільніше. Описує типовий досвід.
- p99: 99-й процентиль. Лише 1% запитів тривало довше. Описує найгірший досвід для типових користувачів.
- p99.9: лише 0,1% запитів тривало довше. Описує найгірший досвід для активних користувачів, які часто звертаються до сервісу.
Геометричне розуміння: розподіли латентності майже завжди мають довгий правий хвіст. Крива швидко піднімається до піку біля медіани, потім повільно падає вправо, часто з малим піком далеко від середнього. Цей пік представляє найповільніших користувачів: тих, хто пише сердиті квитки.
Чому середні величини вводять в оману: сервіс з медіаною 50 мс і p99 5000 мс має розрив у 100 разів між типовим і хвостовим досвідом. Середнє арифметичне може становити 100 мс, повністю приховуючи катастрофу. Середнє арифметичне — це проекція однієї точки 2D форми: майже вся інформація форми зникає.
Проблема множення процентилів: запит, який звертається до 10 сервісів бекенду, кожний з p99 100 мс, має p99 приблизно 600 мс (не 100 мс). Повільні хвости множуються. Ось чому книга SRE попереджує: «Остерігайтеся найповільнішого з N». Коли N зростає, ваша латентність хвоста швидко деградує.
Математика хвостової латентності
Сервіс A має потік запитів, що розгалужується на 5 бекенд-сервісів паралельно й чекає на всі відповіді. Кожний бекенд має p99 латентність 100 мс.
Витрата бюджету як нахил
Побудова графіка бюджету в часі
Бюджет помилок побудований на 2D осях (час на x, залишок бюджету на y) розкриває здоров'я сервісу з першого погляду. Форма кривої витрати несе ту саму інформацію, що й десять окремих панелей.
Три еталонні форми:
- Здоровий лінійний спад: бюджет падає прямою лінією пропорційно минулому часу. На 14-й день 28-денного вікна мало залишитися половина бюджету. Це SLO-ціль, зроблена видимою.
- Швидке спалювання: крутий спад вниз. Вказує на активну проблему надійності. Якщо нахил досить крутий, бюджет вичерпується до скидання вікна, активуючи політику бюджету помилок.
- Вилікована крива: плоский або зростаючий сегмент. Сервіс працює краще, ніж його SLO. Залишок бюджету з часом росте, відкриваючи місце для ризикованих запусків.
Коефіцієнт спалювання — це нахил лінії витрати, нормалізований: коефіцієнт спалювання 1 означає витрату бюджету точно в тому ж темпі, що й час (ідеально вирівняно з SLO). Коефіцієнт спалювання 10 означає витрату в 10 разів швидше, ніж дозволено: весь місячний бюджет вичерпався б протягом 2,8 днів при такій швидкості.
Багатовіконне оповіщення з багатьма коефіцієнтами спалювання: робоча книга Google SRE рекомендує оповіщення про комбіновані умови, такі як «коефіцієнт спалювання понад 14,4 за останню годину І понад 14,4 за останні 5 хвилин». Геометрія: постійний крутий нахил, не просто короткий викид. Ця форма відфільтровує короткочасні імпульси, захоплюючи справжні загрози витрати.
Читання коефіцієнта спалювання
SLO вашої команди становить 99,9% протягом 28 днів. На 7-й день ви вже використали 60% вашого бюджету помилок. Поточний коефіцієнт спалювання за останні 24 години становить 8.
Сервіси як спрямований граф
Виробництво як DAG
Сучасні сервіси працюють як граф залежностей. Кожний сервіс — це вузол. Кожний виклик від сервісу A до сервісу B — це спрямована дуга від A до B. Повна картина утворює спрямований граф (іноді DAG, іноді з циклами через асинхронні повторні спроби).
Критичні геометричні властивості:
- Out-degree: скільки сервісів залежить вузол. Більший out-degree означає більше режимів відмови вище за потоком. Сервіс, який залежить від 12 бекендів, відмовляється, якщо один з 12 відмовляється.
- In-degree (fan-in): скільки сервісів залежить від цього вузла. Більший in-degree означає, що одна відмова тут каскадно розповсюджується широко. База даних з 30 залежними сервісами має найбільший радіус вибуху.
- Betweenness centrality: скільки найкоротших шляхів проходить через вузол. Вузли з високою betweenness — це вузькі місця. Сервіси аутентифікації та основні API зазвичай мають високий результат.
- Сильно пов'язані компоненти: групи сервісів, які утворюють цикли. Якщо A викликає B і B викликає A, у вас є цикл. Цикли ускладнюють відновлення після відмови: запуск обох сервісів вимагає, щоб інший уже працював.
Радіус вибуху — це геометрична концепція, яка спрямовує інвестиції в надійність. Радіус вибуху відмови — це підграф залежних сервісів, які вона впливає. Інженерія надійності сильно інвестує в вузли з найбільшим радіусом вибуху. Найдешевший спосіб покращити загальну надійність системи — часто додати резервну копію або витончене деградування на вузлах з найвищим betweenness.
Міркування про радіус вибуху
Сервіс споживача залежить від: AuthService, UserDB, ProductCatalog, PaymentGateway, RecommendationEngine, EmailService, AnalyticsService. AuthService має 47 інших сервісів, які від нього залежать. EmailService має 3 інших сервіси. RecommendationEngine має 2 інші сервіси.
Інформаційна геометрія панелі
Піксель — це реальна нерухомість
Панель — це 2D поверхня з обмеженою площею. Кожний піксель, виділений одному сигналу, — це піксель, не виділений іншому. Дизайн панелі — це геометрична задача: розташуйте найбільш релевантну для прийняття рішень інформацію в найменшій візуальній площі, зберігаючи просторові зв'язки, які допомагають розпізнаванню.
Шаблони читання: западні читачі сканують F-подібно (верхній лівий кут спочатку, потім впоперек, потім вниз). Найважливіший сигнал належить у верхньому лівому куту. Нижній правий кут отримує найменше уваги.
Групування Gestalt: сигнали від того самого сервісу належать до однієї візуальної групи. Латентність, трафік, помилки й насичення одного сервісу належать до сітки 2x2, не розкидані по екрану. Візуальна близькість кодує логічний взаємозв'язок.
Кодування кольором: червоний для помилок, жовтий для насичення, зелений для здорових діапазонів. Вибір кольорів — це умовності, не випадковість. Їх інверсія коштує когнітивного навантаження на кожен погляд під час інцидентів.
Y-осі масштабування: граф, масштабований 0-100%, виглядає спокійно навіть при подвоєнні трафіку. Граф з автоматичним масштабуванням до останніх значень виглядає тривожно при звичайних варіаціях. Обидва вибори мають відповідне використання; вибір геометричний, не косметичний.
Щільність інформації: занадто мало сигналів залишають команду сліпою до того, що не так. Занадто багато ховають сигнал у шумі. Дизайнер Едвард Туфте запропонував коефіцієнт data-ink: максимізуйте співвідношення чорнила, що передає інформацію, до чорнила, яке прикрашає. Мінімалізм у стилі sparkline переважає захаращені віджети з першого погляду.
Дизайн для першого погляду
Ваша команда дизайнує одну основну панель для сервісу, який має 8 критичних SLI на 4 залежностях бекенду. Панель повинна відповідити на перше запитання дежурного інженера о 3 ранку менш ніж за 5 секунд: «Щось горить, & якщо так, де?»
Геометрія SRE: підсумок
Форми, які запускають виробництво
Ви пройшли через чотири геометричні структури, які запускають SRE практики:
- Розподіли латентності як криві довгого хвоста, де точки процентилів несуть більше істини, ніж середні величини
- Конуси бюджету помилок, де нахил витрати розкриває здоров'я сервісу краще, ніж залишок числа
- Графи залежностей сервісів, де радіус вибуху й центральність спрямовують інвестиції в надійність
- Макети панелей як 2D нерухомість, де виділення пікселів — це геометрична задача з операційними наслідками
Геометричне мислення розділяє SRE від загальної операційної роботи. Операційний інженер читає цифри. SRE читає форми. Форми кодують інформацію, яку жодне окреме число не може захопити: нахил коефіцієнта спалювання, товстість хвоста, центральність вузла, gestalt панелі панелі.
Супутній урок по SRE охоплював практики. Цей урок охоплював геометрію під ними. Разом вони утворюють візуальні й концептуальні підтримки сучасної інженерії надійності.