Наблюдаемость
RED и USE: построить дашборд и провести триаж инцидента
Читать про триаж RED+USE — не то же самое, что запускать его под нагрузкой. Инструментируйте реальный сервис так, как сделал бы senior-инженер, постройте слоистый дашборд, намеренно сломайте его и докажите, что умеете назвать симптом по RED и причину по USE — со скриншотами и числами на каждом шаге.
Превратите ментальную модель юнита в работающий стек наблюдаемости и триаж, который можно защитить: ограниченные метрики RED, USE плюс PSI для хостов, единый слоистый дашборд, разделение алертов, пейджащее на симптомы, и задокументированный разбор инцидента RED-сначала / USE-вторым.
Инструментируйте небольшой HTTP-сервис корректным RED, подключите USE и PSI для его хостов, соберите один слоистый дашборд RED-над-USE, затем вызовите инцидент и проведите триаж RED-сначала / USE-вторым — доказывая каждый вывод панелью, запросом или числом.
- Скриншот слоистого дашборда со всеми тремя заполненными рядами под нагрузкой, p99 вычислен через histogram_quantile с sum by (le).
- Короткий аудит cardinality: перечислите каждый label на метриках RED, его ограниченный набор значений и итоговое число серий — и подтвердите, что нет неограниченного или несущего PII label.
- Два письменных разбора триажа, по одному на вызванный инцидент, каждый называет, какой сигнал RED двинулся, какой сигнал USE/PSI его объяснил и в каком порядке вы их читали — с опорой на захваченные панели.
- Доказательство, что разделение алертов работает: алерт RED спейджил на видимый пользователю инцидент, а сигнал USE/PSI остался на канале предупреждений (или сработал там), а не на page-канале.
- Добавьте on-call runbook: ритм чтения RED-сначала / USE-вторым, четыре ресурса USE с их метрикой saturation, таблицу серьёзности алертов и чек-лист для подтверждения ложного срабатывания.
- Добавьте exemplars в гистограмму длительности и продемонстрируйте клик по скачку p99 для прыжка прямо в трейс медленного запроса.
- Добавьте sidecar service mesh (Envoy/Linkerd) и сравните его авто-RED с RED, эмитируемым приложением — найдите случай, который sidecar не видит (напр. 200, вернувший неверные данные).
- Добавьте async- или очередной путь и инструментируйте его сигнал Saturation (consumer lag / глубина-очереди-в-секундах), показав бэклог, который один Duration упустил бы.
Это цикл, который вы запускаете на каждом реальном инциденте: инструментируйте RED ограниченными label, подключите USE плюс PSI для нижележащих ресурсов, поместите их на один слоистый дашборд с общей осью времени, пейджите на симптом и предупреждайте на причину, затем проведите триаж RED-сначала, чтобы назвать, что почувствовал пользователь, и USE-вторым, чтобы найти почему. Сделав это раз на сервисе, который вы сломали нарочно — со скриншотами, аудитом cardinality и двумя письменными разборами — вы превращаете дисциплину в рефлекс для продакшен-версии.