Архитектура бэкенда
Видеть систему: RED-метрики, хвост p99 и состояние breaker
Прошлый урок описал каскад, что ты мог рассказать постфактум — но инженер, проживающий его в 3 ночи, не видит этой истории. Он видит дашборд. И если дашборд показывает лишь «средняя латентность: 180ms, доля ошибок: 0.2%», он слеп, потому что каскад прячется ровно в местах, что среднее стирает. Средняя латентность остаётся спокойной, пока p99 тихо утраивается, потому что медленный хвост — малая доля запросов, утопленная в среднем. Пул в одном получении от пустоты, но «соединения: 47» без лимита в 50 рядом не говорит тебе ничего. Breaker хлопал открыто-закрыто четыре раза за последнюю минуту — единственный важнейший сигнал, что даунстрим падает — и он не появляется нигде, потому что никто не выпустил его как метрику. Каждый механизм, что ты построил в этом треке, имеет внутреннее состояние, что и есть раннее предупреждение, а бэкенд, что не выводит то состояние на поверхность, — бэкенд, что ты эксплуатируешь с закрытыми глазами. Прошлые уроки сделали систему; этот делает её видимой — потому что нельзя эксплуатировать, дебажить или выбраться из сбоя, что не видишь, а сложенные сбои прошлого урока невидимы ровно до того, как ты инструментируешь швы.
RED: три числа, что каждый сервис тебе должен
Начни с уровня запроса. Метод RED говорит, что каждый сервис должен выпускать три вещи, и вместе они отвечают «здоров ли этот сервис?» до того, как ты узнаешь что-либо о его внутренностях:
- Rate (частота) — запросов в секунду. Нагрузка, что сервис несёт.
- Errors (ошибки) — доля (или частота) запросов, что падают. Не только 5xx; всё, что вызывающий переживает как сбой, включая отказы breaker.
- Duration (длительность) — распределение времён ответа, не среднее. Здесь живёт хвост.
RED намеренно центрирован на запросе: он описывает, что вызывающий чувствует, что верный самый внешний вид. Под ним ты добавляешь сигналы уровня ресурсов — насыщение пула, loop, очереди — что объясняют, почему числа RED движутся.
Среднее лжёт; смотри перцентили
Важнейшая привычка, что учит этот урок: никогда не доверяй средней латентности. Среднее смешивает быстрые и медленные запросы в одно число, что не описывает ни один из них. Если 99 запросов берут 20ms, а один берёт 4 секунды, среднее ~60ms — число, что выглядит нормально и переживается никем. Метрика, что важна, — перцентиль: p50 (медиана, типичный запрос), p99 (медленный хвост, один запрос из сотни), p999 (редкая катастрофа). Хвост — не шум — он и есть сигнал, потому что каскад прошлого урока начинается как растущий p99 задолго до того, как среднее вообще сдвинется. Пул, начинающий насыщаться, даунстрим, начинающий замедляться, GC-пауза — все показываются в хвосте первыми. Смотри p99 — и видишь формирующийся каскад; смотри среднее — и видишь его лишь после коллапса.
У каждого механизма есть состояние, достойное выпуска
Механизмы трека — не просто код; каждый имеет внутреннее состояние, что опережающий индикатор, и задача — вывести его на поверхность:
- Пул — выпускай в использовании против лимита и время ожидания получения / глубину очереди. Насыщение (в использовании / лимит, приближающееся к 1.0) — раннейший признак каскада. «47 соединений» бессмысленно; «47 из 50, 200ms ожидание получения» — тревога.
- Event loop — выпускай лаг loop. Растущий лаг значит, что что-то блокирует loop, голодая каждый конкурентный запрос.
- Breaker — выпускай состояние и переходы (closed → open → half-open). Хлопающий breaker — яснейшее возможное заявление, что зависимость нездорова; это должна быть первоклассная метрика, не строка лога.
- Ретраи — выпускай частоту ретраев отдельно от частоты запросов. Частота ретраев, лезущая к частоте запросов, — формирующийся шторм.
- Shutdown — выпускай длительность дренажа и счёт форс-киллов. Дренажи, ползущие к grace period, предсказывают потерянную работу на следующем деплое.
Error budget: превращение телеметрии в решение
Наблюдаемость не только для дебага; она ведёт решение о выкатке. SLO (service level objective) ставит цель — скажем, 99.9% запросов успешны под 300ms. Зазор между той целью и 100% — error budget: сбои, что тебе позволено потратить. Когда бюджет здоров, ты катишь фичи быстро и берёшь риск. Когда телеметрия показывает, что бюджет почти потрачен, ты прекращаешь катить фичи и тратишь инженерию на надёжность вместо этого. Это превращает всю картину RED/перцентилей/насыщения из пассивных дашбордов в активный регулятор поведения команды — мост от «мы видим систему» к «здоровье системы контролирует, что мы делаем дальше».
Почему это работает
Почему настаивать на перцентилях и отвергать среднее так абсолютно — ведь средняя латентность какая-то полезная сводка того, как сервис поживает? Потому что среднее отвечает на вопрос, что никто не задаёт, и прячет тот, что важен. Никто не переживает «среднее»; каждый пользователь переживает свой собственный запрос, и распределение этих индивидуальных переживаний — весь смысл. Среднее схлопывает то распределение в одно число, что математически доминируется массой и структурно слепо к хвосту — а хвост там, где живёт каждый интересный сбой. Рассмотри арифметику: на масштабе p99 — не редкая диковинка. Пользователь, делающий 100 запросов, чтобы загрузить одну страницу, попадает на свой личный p99 почти на каждой загрузке — «один из сотни» медленный запрос — почти достоверность за сессию, так что p99 ближе к «переживанию активного пользователя», чем медиана. Хуже, среднее активно скрывает каскад: когда пул начинает насыщаться, горстка запросов становится медленной, пока остальные остаются быстрыми, так что хвост поднимается, пока среднее едва дёргается — к моменту, как растущее среднее заставит тебя обратить внимание, хвост уже был катастрофическим минутами. Есть и более глубокая структурная причина: распределения латентности в реальных системах не гауссовы, они тяжелохвостые и часто мультимодальные (быстрый путь и медленный путь, например попадание в кэш против промаха, доступный пул против ожидания пула), и для таких распределений среднее даже не осмысленная центральная тенденция — это артефакт, сидящий между двух горбов, не описывающий ни одного. Вот почему каждый механизм трека должен выпускать своё состояние как распределение или дискретное событие, никогда как среднее: усреднённое состояние breaker бессмысленно, усреднённая глубина очереди прячет пики, что вызывают потери, усреднённое время дренажа прячет деплой, что чуть не пролетел дедлайн. Принцип обобщается в правило операционной зрелости: мониторь переживание на хвосте, потому что хвост — и где пользователи чувствуют боль, и где система говорит тебе — раннее и яснее всего — что вот-вот сложит сбой.
| Сигнал | Что измеряет | Почему это раннее предупреждение |
|---|---|---|
| Rate | Запросов / секунда | Нагрузка, что объясняет остальную картину |
| Errors | Доля упавших запросов | Включает отказы breaker, не только 5xx |
| Duration (p99) | Латентность медленного хвоста | Каскад тут до сдвига среднего |
| Насыщение пула | в использовании / лимит, ожидание | Раннейший признак каскада через пул |
| Лаг loop | Задержка event loop | Что-то блокирует loop |
| Состояние breaker | closed / open / half-open | Яснейший сигнал, что зависимость падает |
| Error budget | Цель SLO против факта | Превращает телеметрию в решение катить/стоп |
Дашборд показывает среднюю латентность стабильно на 180ms и долю ошибок 0.2%, но пользователи жалуются, что приложение медленное. Какое слепое пятно вероятнее всего?
Почему error budget больше, чем просто дашборд — какое решение он ведёт?
Расставь, как бы ты инструментировал сервис от самого внешнего сигнала до решения о выкатке:
- 1 Выпускать RED на краю запроса: частота, ошибки и распределение длительности
- 2 Смотреть перцентильную латентность (p99/p999), никогда среднее, чтобы поймать медленный хвост
- 3 Добавить сигналы ресурсов — насыщение пула, лаг loop, состояние breaker — чтобы объяснить, почему RED движется
- 4 Определить SLO и отслеживать error budget, чтобы гейтить выкатку фич против надёжности
- 01Что такое метод RED и почему надо смотреть перцентили вместо средней латентности?
- 02Какое внутреннее состояние должен выпускать каждый механизм и как error budget превращает телеметрию в решение?
Каскад прошлого урока невидим в 3 ночи, если твой дашборд показывает лишь средние, так что этот урок делает систему видимой. RED — частота, ошибки, длительность — самый внешний, центрированный на вызывающем вид, и железное правило — смотреть распределение длительности, никогда среднее: каскад выходит на поверхность как растущий p99 задолго до того, как среднее дёрнется, потому что латентность тяжелохвостая и среднее описывает запрос, что никто не делает. Каждый механизм трека владеет внутренним состоянием, что опережающий индикатор и должно выпускаться как метрика: насыщение пула и ожидание получения, лаг event loop, переходы breaker, частота ретраев, длительность дренажа. И наблюдаемость не пассивна — SLO и его error budget превращают всю картину в регулятор: катить фичи, пока бюджет здоров, переключиться на работу над надёжностью, когда он почти потрачен. Теперь ты можешь и рассуждать о сложенных сбоях, и видеть их формирующимися. Следующий урок использует эту видимость под тяжелейшим условием — намеренной перегрузкой — где каждый механизм работает и как ручка контроля нагрузки, и вопрос в том, деградирует ли сервис грациозно или схлопывается.