这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 SLO 分母应是有效技术尝试而不是页面浏览，成功需在阈值内达到可用功能通道。用户取消和拒绝单独报告，技术超时计为失败。
可观测性应回答故障发生在哪个阶段、影响多少会话和是否仍在扩大。事件字段使用白名单与低基数维度，用户内容、密钥和完整网络身份不进入遥测。
先把实现决策说清楚
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 设全局与关键区域双层目标，例如 99.9% 在 15 秒内；以 28 天滚动窗口和多窗口 burn-rate 告警观察预算消耗。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“连接 SLO 怎么定：成功率、时延和可恢复性要一起算”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 排除所有失败前离开的用户会美化结果；只看月末预算又让一次严重故障在长窗口中太晚告警。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
上线前怎样验证
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 用历史事件重算不同定义并人工标注样本，确认分母、终态和时限符合用户感受；演练 2% 故障的 burn 告警。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。