可观测性为什么要包含业务指标？
简化版
技术指标只能说明系统是否忙或报错，业务指标才能说明用户目标是否完成。应把下单成功率、支付转化、履约时长等与服务指标关联，但监控口径不能替代财务账本或权威业务数据。
详细版
从关键用户旅程选计数器、比率和时延，明确分子、分母、事件时间、去重规则、维度与 owner。业务指标通过稳定事件或权威状态生成，并与 release、region、channel 等低基数维度关联。
告警优先基于用户影响和消耗速率，技术指标用于定位。数据延迟、补录和撤销要有口径，仪表盘展示新鲜度；最终营收、余额等仍以交易账本和对账为准。
完整版教学
一、技术正常不等于业务正常
HTTP 200 可能返回“库存不足”，支付接口低延迟也可能因路由错误导致无人付款。只看 CPU 和错误率，会漏掉业务语义层故障。
记忆钩子：技术指标回答机器怎样，业务指标回答用户有没有办成事。
二、从旅程定义指标
checkout_conversion = paid_orders / checkout_started
payment_success_rate = successful_payments / valid_payment_attempts必须定义“有效尝试”是否排除用户取消、风控拒绝和重复请求，否则团队会对同名指标得到不同结论。
三、指标类型与用途
| 类型 | 示例 | 用途 |
|---|---|---|
| 数量 | 每分钟订单数 | 流量变化 |
| 比率 | 支付成功率 | 结果质量 |
| 时长 | 下单到发货 P95 | 流程效率 |
| 存量 | 未履约订单 | 风险积压 |
总金额等可加指标必须考虑币种、退款与重复，不能直接把浮点金额当 Counter 累加。
四、维度与基数
按 region、channel、release 分解可定位问题，但 userId、orderId 会造成高基数。单订单排查应进入日志/Trace，通过 exemplar 或受控链接关联，而非做指标标签。
例如 10 个 region×20 个 channel×50 个 release 已可能产生 10000 个序列，新增维度前要估算组合规模。
五、事件时间与一致性
支付成功可能晚到、撤销或补录。指标要区分 occurredAt 和 processedAt，实时看板允许修正；日报则从权威账本重算。仪表盘展示数据延迟，避免把采集断流误判成订单骤降。
业务监控是近实时信号，不自动具备会计准确性。
六、告警与责任
以“10 分钟支付成功率低于基线且有效样本超过 1000”为例，比单纯订单数下降更能排除低流量噪声。告警关联 owner、Runbook、依赖指标和发布标记。
阈值应按业务周期和区域基线调整，并用历史事件回放验证误报、漏报。
业务口径变更必须版本化并标注生效时间；将新旧公式直接拼成一条长期曲线，会制造不存在的趋势突变。
看板应同时展示分母和绝对量，避免低样本下一个失败把成功率误读成大规模事故。
七、常见误区与追问
- 误区：HTTP 成功率就是业务成功率。 业务拒绝可能仍返回 200。
- 误区：业务指标可以直接当财务报表。 实时采集可能重复、延迟和修正。
- 误区：维度越细越容易定位。 高基数会让成本与查询失控。
- 误区：订单数下降一定是系统故障。 也可能是周期、活动或流量变化。
- 追问：如何处理迟到事件？ 按事件时间修正窗口，并由离线权威数据校准。
- 追问：指标 owner 是谁？ 业务与技术共同定义，明确唯一维护责任。
- 追问：如何连接技术原因？ release/region 维度加日志、Trace 和依赖看板下钻。
八、加强记忆
业务指标按“用户旅程—明确口径—稳定事件—受控维度—新鲜度—权威对账”建设。它负责发现用户影响，技术遥测负责定位原因；实时看板允许迟到修正但不冒充账本，告警同时考虑比率、样本量和业务周期。