Наблюдаемость
Observability-капстоун: free-recall-обзор
Retrieval бьёт перечитывание. Для каждого промпта восстановите полный ответ по памяти через весь трек, прежде чем открывать модельный ответ — именно усилие припоминания сплавляет отдельные юниты в одну ментальную модель.
Восстановить хребет главы, не подглядывая: debugging-воронку, как джойнятся три pillar’а, архитектуру OTel, рычаги sampling и стоимости, burn-rate-алертинг и арифметику ROI.
- 01Назовите пять слоёв debugging-воронки по порядку и скажите, что вывод каждого слоя подаёт в следующий.
- 02Как три pillar'а — метрики, логи, трейсы — плюс профили складываются в одну навигируемую поверхность, а не в четыре силоса?
- 03Опишите трёхслойную архитектуру OTel и чего в ней стоит смена backend.
- 04Почему tail sampling нужен в дополнение к head sampling и какова каноническая production-политика?
- 05Как работает multi-window burn-rate-алерт и почему он лучше статического порога по сырому error rate?
- 06Сформулируйте ROI-аргумент для observability как арифметику, а не слоган, и из чего измеряется каждый вход.
Если вы смогли восстановить каждый ответ по памяти, вы держите хребет главы: воронка сужает SLO → RED → trace → profile → git blame, каждый шаг продиктован предыдущим; три pillar’а плюс профили складываются через join по trace-id; OTel — это один SDK, один OTLP-формат, взаимозаменяемые backend’ы; tail sampling держит 100% важного и сбрасывает остальное; multi-window burn-rate-алертинг привязывает пейджи к потреблению бюджета; а расход оправдан измеримой арифметикой избегнутого outage. Observability — это не мониторинг; это субстрат, позволяющий деплоить без страха.