awesome-everything EN
↑ Обратно к восхождению

Наблюдаемость

RED и USE: тест с выбором ответа

Суть Синтез всего юнита в формате выбора ответа — триаж симптом против причины, saturation, агрегация гистограмм, cardinality и дисциплина уровней алертов.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 13 min

Шесть вопросов, проходящих сквозь весь юнит. Ни один не про заучивание определения — каждый отражает решение, которое вы принимаете прямо во время инцидента, когда пейджер орёт, а вам нужно выбрать правильный дашборд, правильный сигнал и правильный уровень алерта.

Цель

Убедитесь, что вы соединяете два чек-листа в единую дисциплину триажа: RED называет симптом со стороны клиента, USE находит причину со стороны ядра, а вспомогательные решения — saturation, агрегация гистограмм, cardinality, уровни алертов — служат этому ритму чтения.

Викторина

Пейджер срабатывает на checkout p99 (80 мс до 1.2 с). RED показывает: Rate стабилен, Errors ниже 0.1%, Duration p99 в 15 раз хуже. Каков правильный следующий шаг и почему?

Викторина

Один диск на 80% utilization с глубиной очереди I/O 50; другой на 95% utilization с глубиной очереди 1. Какой сигнал хуже и какое измерение USE это говорит?

Викторина

Utilization памяти узла умеренный, MemAvailable всё ещё показывает 500 МБ свободно, но воркер встаёт на минуты. Какой сигнал бы это поймал и почему дашборды free-RAM это пропускают?

Викторина

Команда считает p99 по всему флоту, усредняя предвычисленный p99 каждой реплики (Prometheus summaries). Почему это неверно и каков правильный метод?

Викторина

Чтобы перейти от скачка p99 в гистограмме к конкретному медленному запросу, инженер хочет добавить trace_id как label метрики. Что сломается и каково спроектированное решение?

Викторина

Проектируя алерты для сервиса, как сопоставить сигналы RED и USE с уровнями серьёзности и почему это разделение — сильнейший рычаг против усталости от алертов?

Итог

Сквозная линия юнита — одно дерево решений: RED называет симптом со стороны клиента (Rate, Errors, Duration), USE находит причину со стороны ядра (Utilization, Saturation, Errors), а saturation — глубина очереди, PSI — самое диагностичное измерение, потому что пользователь чувствует ожидающую работу, а не среднее busy-время. Вокруг этого ядра стоят вспомогательные дисциплины: Duration должен быть гистограммой, агрегированной через sum by (le) (никогда не усреднённым перцентилем); cardinality ограничивается тем, что в label идут только route/method/status_class, а мост к трейсам строится через exemplars; алерты пейджат на RED, предупреждают на USE. Каждый продакшен-сбой в юните сводится к одному пропущенному сигналу в этом дереве.

Продолжить восхождение ↑RED и USE: тест на свободное припоминание
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.