Наблюдаемость должна отвечать «что увидел клиент?»
CPU, memory и request latency нужны, но live-инцидент часто начинается при зелёной инфраструктуре: очередь медленно отстаёт, snapshot не обновился после reconnect, correction не дошёл до cache. Поэтому верхний уровень observability стоит строить вокруг состояния продукта — freshness, version continuity, suspend reason и успешное восстановление пути.
SLI связывает симптом с точкой измерения
Фраза «freshness плохая» бесполезна без определения. Где стоит clock? Что является authoritative timestamp? Какая версия считается опубликованной? Хороший SLI воспроизводим другим инженером и не меняет смысл от dashboard к dashboard. Если есть несколько временных шкал — provider time, ingest time, publish time — их лучше хранить отдельно.
Tracing нужен для границ, а не для красивого waterfall
Асинхронные системы ломают привычную цепочку HTTP spans. Context должен переживать queue, worker и fan-out, а рядом остаются предметные event/version identifiers. Тогда trace помогает найти задержку конкретного состояния, а не просто показывает набор быстрых сервисов без связи с пользователем.
Synthetic проверяет независимый путь
Внутренняя метрика может не заметить stale cache на edge. Synthetic сценарий открывает live-центр, проверяет version/freshness и отдельно тестирует reconnect. Его ценность в независимости: если ingest метрики зелёные, а synthetic падает, расследование смещается ближе к delivery/client.
Incident response требует guardrails и reconciliation
Во время крупного live-события важно заранее знать, кто принимает решение о деградации, какие действия безопасно выполнять и чем доказывается восстановление. Replay, provider failover или rollback не заканчиваются фактом запуска команды. Нужны exit criteria: backlog закрыт, state reconciled, пользовательский путь снова видит актуальную версию.
Error budget — механизм приоритета
SLO без реакции остаётся графиком. Error budget полезен, когда заранее связан с решением: ограничить рискованные изменения, усилить reliability work или остановить rollout. Числовые границы определяются реальными требованиями и измерениями; универсального значения для live betting не существует.
Смежные досье: архитектурные границы live-систем, карта инфраструктуры и runbook восстановления backlog.