灰度期间的监控指标需覆盖异常与性能，不只是业务指标
别名: 灰度监控异常与性能 · 不只看业务指标 · canary telemetry
概念解释
灰度若只盯转化、GMV、日活，会在业务曲线还没动之前放过崩溃、超时、错误提交和不可恢复的状态。监控必须覆盖异常与性能，而不是只覆盖业务指标。异常包括未捕获错误、任务中断、权限失败、数据写坏；性能包括延迟分布、超时率和资源饱和，而不是平均值好看。业务指标是滞后且可被局部成功掩盖的；交互失败往往先出现在错误与速度上。判断点如果只读业务，门会在伤害已经发生时仍显示绿灯。
机制
业务指标对局部故障不敏感：1% 用户彻底做不成，全站转化可能看不出。即使用户改用旧路径或放弃，收入也可能暂时由其他入口顶住。错误率、崩溃、p95 延迟直接钉在受影响的会话上，是更早的信号。性能退化会改变策略——重试、连点、改设备——这些行为再传导到业务，已经晚了一拍。只看业务还会激励错误的修复：用运营补贴把转化拉回，而让超时留着。灰度窗口往往短于业务指标的稳定周期，用周活跃去门控以小时计的发布，时间尺度错配。
怎么研究
为每一阶段列三组指标：异常（错误、崩溃、任务中断）、性能（延迟分位、超时）、业务（转化等）。预先规定异常与性能的红线，业务只作辅助。对照发布前后及灰度内外的同期队列。SRE 的 SLI/SLO 思路可被 HCI 评估借用：把“关键任务可完成”定义成可监测事件，而不只是漏斗终点。质性工单应能在同一仪表盘上按严重度进入异常计数。不要在业务指标不显著时宣布体验通过。
边界
全新功能没有业务基线，更应把异常与性能当作主门，业务只作描述。有些体验伤害几乎不上报错误码（令人羞耻的文案、找不到入口），监控必须辅以定向跟访，不能声称仪表盘已覆盖全部体验。过度报警会让值守关掉告警，性能阈值需要按阶段校准。隐私约束可能禁止细粒度会话日志，需用聚合异常代替逐条重放。对离线或同步延迟高的客户端，性能信号会晚到，判断点窗口要跟着拉长。
怎么落地
- 发布仪表盘默认三栏：异常、性能、业务；判断点绑在前两栏。
- 为关键任务定义“开始—成功/失败/超时”事件，而不是只埋漏斗终点。
- 红线用分位数和计数，不用平均值；演练一次用注入错误看门是否亮。
- 业务回升但异常未降时，禁止升阶段。