Наблюдаемость
Observability-капстоун: синтез с множественным выбором
Суть Синтез-MCQ через весь observability-трек — порядок воронки, join по trace-id, tail sampling, стоимость cardinality, MTTD vs MTTR и ROI.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, которые заставляют связать весь трек воедино — три pillar’а, OTel, RED/USE, SLO-бюджеты, trace propagation, профилирование. Каждый — это решение, которое вы принимаете посреди инцидента или на design-review, а не определение для пересказа.
Цель
Убедиться, что вы собираете главу в одну систему: воронку, которая ведёт MTTR, trace-id, который джойнит четыре сигнала, рычаги sampling и cardinality, удерживающие счёт, и арифметику, оправдывающую расход.
Викторина
Completed
On-call получает пейдж 'checkout SLO burn 14x'. RED показывает рост p99 Duration, Rate и Errors ровные. Какой следующий шаг воронки правильный и почему именно он?
Heads-up Профилю нужна цель — сервис и в идеале trace-id — прежде чем он полезен. Прыжок к профилю до трейса пропускает шаг, который говорит, какой сервис и span профилировать.
Heads-up Errors ровные; это latency-инцидент, а не error-инцидент. Логи — последний рубеж воронки для точечного поиска событий, а не второй шаг.
Heads-up Причина ещё не локализована. Слепой откат может вернуть несвязанное изменение и оставить latency на месте; воронка сперва локализует, потом резолвит.
Викторина
Completed
Запрос замедляется. RED Duration это показывает, трейс показывает, что inventory.lookup владеет 1.3s, профиль показывает, что CPU съел json.Marshal, а логи держат деталь ошибки. Какое единственное свойство заставляет все четыре сигнала отвечать на один запрос про ЭТОТ request?
Heads-up Timestamp + service name — это ровно та ручная корреляция, которую заменяет trace-id. Clock skew и конкурентные запросы делают join только по времени неоднозначным; trace-id — точный ключ.
Heads-up Со-локация сигналов в одном backend помогает UX, но не создаёт join. Tempo, Loki, Prometheus и Pyroscope — отдельные хранилища, но всё равно джойнятся, потому что каждая строка несёт один trace-id.
Heads-up Semantic conventions делают кросс-сервисные дашборды согласованными, но per-request join между ТИПАМИ сигналов — это именно trace-id; conventions про ключи атрибутов, а не про идентичность запроса.
Викторина
Completed
Команда делает head sampling трейсов на 5% в SDK, чтобы срезать стоимость. Во время инцидента они не могут найти трейсы для падающих запросов. Что пошло не так и что чинит проблему?
Heads-up Head sampling вероятностный в начале трейса и не знает итогового исхода — он не может предпочтительно держать errors, которые ещё не видел. Это внутреннее ограничение, а не misconfiguration.
Heads-up Трейсы — ровно тот per-request причинный сигнал, который нужен в инциденте. Проблема в стратегии sampling, а не в сигнале.
Heads-up 100% head sampling убивает цель по стоимости — вы храните каждый baseline-трейс вечно. Tail sampling держит 100% важного и сбрасывает 90%+ скучного baseline, давая и стоимость, и покрытие.
Викторина
Completed
Счёт за observability удвоился за неделю без изменения трафика. Одна команда добавила user_id как label метрики и начала логировать полные тела запросов на INFO. Какие два разных failure mode это и какой сигнал бьёт каждый?
Heads-up Ни одна не трогает трейсы. user_id бьёт по cardinality метрик; тела запросов — по содержимому логов и compliance. Tail sampling не адресует ни ту, ни другую.
Heads-up Tiering управляет тем, как долго данные живут, а не их шириной или PII-содержимым. Неограниченный label всё равно взрывает series в первый же день; tiering не останавливает утечку.
Heads-up Шифрование at-rest не мешает авторизованному запросу (или атакующему с доступом) прочитать PII. Оба риска реальны и задокументированы — Datadog 2021 (cardinality) и Slack 2022 (PII в логах).
Викторина
Completed
Две команды делят идентичный тулинг. Команда A детектит outage за 30s и резолвит за 20min; команда B детектит за 8min и резолвит за 12min. При одинаковой severity, чьи пользователи страдают меньше суммарно и что это говорит о том, куда инвестировать?
Heads-up MTTR сам по себе игнорирует окно отказа до детекта. Пользователи B поглотили 8 минут неотмеченного отказа до того, как часы вообще пошли; суммарный impact примерно MTTD + MTTR на затронутый запрос.
Heads-up Impact не симметричен по двум фазам — во время задержки детекта отказ полностью живой и не митигирован. 30s MTTD с 20min MTTR всё равно подставило пользователей под куда меньшую часть опасного окна, чем 8min недетекта.
Heads-up Тулинг идентичен по условию; вся разница — в форме MTTD vs MTTR, а это вопрос процесса и алертинга, не вопрос вендора.
Викторина
Completed
CFO спрашивает, почему observability стоит $150k/год. Орг прогоняет ~30 инцидентов/год, каждый теперь резолвится на ~25 min быстрее baseline до инструментирования, при примерно $5k/min revenue-экспозиции. Какой ответ сильнейший?
Heads-up Индустриальный стандарт — не бизнес-кейс. Защитимый ответ — измеримая избегнутая стоимость outage, выведенная из вашей собственной истории инцидентов.
Heads-up Верно, но не количественное обоснование — именно такой ответ режут в downturn. Привяжите расход к защищённому revenue или снижению риска.
Heads-up SLA — downstream от observability; бизнес-аргумент — арифметика избегнутой стоимости, и она вычислима из MTTR-логов, числа инцидентов и rate выручки.
Итог
Глава собирается в одну систему. Воронка (SLO burn → RED → trace → profile → git blame) ведёт диагностику, и каждый шаг продиктован предыдущим. Trace-id, пробрасываемый W3C traceparent, — это то, что заставляет четыре сигнала отвечать на один per-request запрос. Cost-дисциплина — это три независимых рычага: cardinality-лимиты, tail sampling, tiered retention, каждый бьёт по своему сигналу. MTTD обычно перевешивает MTTR для user impact, потому что окно детекта полностью не митигировано. А расход оправдан арифметикой: избегнутая стоимость outage из реальных MTTR-дельт, обычно 10–30x. Каждый ответ здесь — drill-down из этих сквозных линий.