可观测性从问题和用户影响开始：接口正常但订单不完成

网关 200 率 99.99%，订单完成率却降到 90%——组件全部健康，业务没有推进。本页定义可观测性的目的、四类信号的分工与 ID 关联规则，先回答"用户是否受影响"，再谈工具。分位与聚合的正确口径见分位、延迟和正确的聚合；告警如何从遥测语义推出见从遥测语义到可操作告警。

可观测性回答什么问题

可观测性是通过输出信号推断系统内部状态的能力。遥测数量多不等于可观测性好；信号应能回答用户是否受影响、影响范围、哪个不变量失守和如何验证修复。用户旅程是跨服务的业务动作。请求成功率和 HTTP 延迟应与业务完成率、处理新鲜度、待办年龄和账务差异联合观察，避免组件都健康而流程没有推进。

RED 关注请求率、错误和持续时间；USE 关注资源利用、饱和与错误。它们是查找视角，不是完整的产品指标或告警策略。

Metrics、Logs、Traces 的职责

Metrics 适合趋势、聚合和告警，要求标签基数可控。Histogram 以桶累积样本分布，可聚合近似分位；summary 一类本地分位通常难跨实例合并。桶边界和时间窗口决定能回答的问题。Logs 提供离散事件上下文。结构化字段便于查询，但高基数字段、敏感信息和高流量会增加索引与存储成本。日志必须限制凭证、token、个人信息和业务载荷泄漏。

Traces 表示一次分布式操作的因果树。span context 的传播要跨 HTTP、消息和异步任务；重试应能在 trace 中区分，消息消费需要关联生产上下文或链接。trace 是采样过的调试证据，不是完整业务账本。OpenTelemetry 统一 API、SDK、语义约定与传输协议，不替代后端存储、保留、安全或告警决策。采样、批处理和 exporter 自身故障也会让遥测不完整。

从"接口正常但订单不完成"开始排查

教学故障：网关200率99.99%，订单完成率却降至90%。网关只测到受理，异步队列因某租户毒消息停止前进。先定义用户结果的分子/分母和截止时间，再从任务年龄、状态迁移和恢复数定位，而不是扩大一屏CPU指标。Google SRE监控原则提供面向症状的出发点，以下工作流为本题设计。

为一次逻辑订单串联request_id、business_id、event_id与attempt。trace展示一次尝试，业务单可能跨多次trace；仅按trace查会遗漏重试和补偿。日志记录状态前后、版本与错误类别，指标表达总体趋势，追踪提供耗时与依赖关系，业务账本提供持久结果；四者不能互相替代。

带数判断影响范围

10万次受理中2万尚未到期限、7000已失败、3000过期仍未完成、7万及时完成，则按已到期8万计算及时完成87.5%，不是按已完成7万计算100%。把待完成全部排除会系统性美化指标。还需按租户/区域/工作类型分层，避免大流量健康租户掩盖小租户全损。

方案A在每次请求记录全部payload和所有维度，定位细但成本与隐私风险高；方案B有限指标维度、受控结构化日志及基于错误/延迟采样，成本可控但需说明缺样本时如何回到账本。选择由诊断问题、保留期和预算决定，不能只以采样率高低评价可观测性。

验证和交付

构造成功、永久等待、晚完成和重复事件四种任务，手工得到分子分母后对照查询。暂停一个worker，端到端探针应发现业务无法前进，而不仅看进程存活；恢复后验证积压年龄下降及已受损任务单独记录，不改写历史SLO。这些验证可在隔离环境执行，本轮未运行，步骤与预期按上文保留。

产物为问题—信号—动作对应表、ID关联规则、缺采集告警与隐私字段清单。不能用"接入了某厂商平台"代替这些具体证据。

影响面筛诊单：全局达标可能掩盖全损小租户

本页前面用 87.5% 与 100% 的对比说明了分母口径，但真实事故里更危险的是"全局达标、局部全损"。把影响面按租户、区域、工作类型三个维度分层，是事故开始时第一张要填的单子。

反例算例：已到期 80,000 个任务，其中大租户 79,600 个全部按时，小租户 400 个全部超时。全局按时率 (79,600+0)/80,000=99.5%，高于 99% 目标；小租户按时率 0/400=0%。若只盯全局 SLI，这个事故不会触发任何告警，而小租户已经在完全失败的状态。分摊到流量加权：一个小租户占 0.5% 流量时，它全损只拉低全局 0.5 个百分点。这正是本页开头"接口正常但订单不完成"在分层维度上的版本。

筛诊单要按固定顺序填，避免东看一屏西看一屏：先按租户列已到期数与按时数（找出全损租户）、再按区域列（找出单区归零）、再按工作类型（导出/通知/结算分开）。每一行都记分母、分子与截止时刻；没有截止时刻的行不入账。填完再决定是全局事故还是分层事故——这决定止损动作的范围：全局限流会误伤健康租户，按租户隔离才是正确动作。

执行 python3 labs/observability_models.py layered_impact：模型把 400 个小租户任务全部标坏，预期输出 due=80000、global_on_time=0.995、big_tenant=1.0、small_tenant=0.0、verdict_global=PASS、verdict_small=FAIL。脚本只做算术，不接监控；接入与采集归 U64 与 U24，本票只负责口径。

两个合理选择：A 只维护全局 SLI，告警少、运维简单，但小租户全损会被平均掉；B 全局 SLI 加有限分层（按套餐、区域、工作类型），告警与看板都分层，成本是维度维护与可能的告警噪声。本例选 B，并规定分层维度必须是有限枚举——按用户 ID 分层会撞上高基数问题（见本主题第 2 篇）。

架构师变化条件

把完成定义从"订单提交"改为"订单送达并签收"：SLI 链路延伸到第三方物流，需要对方事件补齐签到与账本口径，缺第三方回执的批次单列。若多租户共享队列，毒消息隔离要精确到租户维度的队列年龄告警。当 trace 采样率从 100% 降到 1%，诊断路径改走"指标→结构化日志→账本"，关联规则要预先演练而不是事故当天现找。每次变化重画问题—信号—动作表。

闭卷验收

本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。