设想一个订单查询接口：数据库没有宕机，应用进程也都存活，但某个依赖开始超时。线程和连接逐渐排满，自动重试又增加了请求量。值班人员收到一批 CPU、连接数和错误日志告警，却还不知道用户是否能够完成查询。
值班团队需要从这批信号中确认用户影响，执行止损动作，并在复盘中消除复发条件。团队可以同时推进三项工作。新架构无法代替值班流程，监控数量也衡量不了用户是否恢复。
告警要指向用户正在做的事
进程仍在运行、机器负载正常，都无法证明用户可以查到订单。订单团队需要衡量用户能否在约定时间内获得正确结果，HTTP 200 只提供其中一条线索。
先定义有效请求的范围。健康探测、错误凭证、客户端主动取消是否进入分母，应按业务约定处理并单独观察。某些返回 200 的响应只包含降级空数据，对用户来说仍可能失败。这样的失败需要业务指标表达，不能靠 HTTP 状态码猜测。
例如，假设某个统计窗口有一百万次有效请求，可用性目标为 99.9%，则该窗口允许的不良请求预算为：
1,000,000 × (1 - 0.999) = 1,000
这只是请求型 SLO 的算例，不能直接换算为允许停机多少分钟。流量不均匀时，繁忙时段和凌晨同样长的故障消耗不同预算。
告警还应考虑问题是否正在持续。长窗口有助于判断影响规模，短窗口有助于判断当前是否仍在恶化。Google 的 SLO 告警方法讨论了这类组合，也指出低流量服务的比例信号容易失真。不能把示例阈值照搬成所有接口的验收线。
对于低频但重要的操作，错误次数、合成探测和用户反馈可能比单纯错误率更有用。探测要经过关键路径，又不能在生产制造真实支付等副作用。
值班手册要写清动作前提
故障发生后，值班人员要从手册中找到动作、适用条件和风险。“检查日志”无法指导下一步操作。
以依赖超时为例，可以准备这样一份动作表：
| 观察到的情况 | 可考虑的动作 | 执行前必须确认 |
|---|---|---|
| 可选推荐依赖变慢 | 暂停推荐调用，保留主流程 | 空推荐是否被客户端正确处理 |
| 最近发布后错误集中出现 | 回退应用版本 | 旧版本能否读取当前数据格式 |
| 单租户消耗大量资源 | 限制该租户的新请求 | 身份识别可靠，其他租户不会被误伤 |
| 查询负载拖累核心写入 | 暂停昂贵报表或缩短查询预算 | 核心用户旅程及拒绝响应有明确约定 |
动作应有负责人、观察窗口和退出条件。限制流量后如果错误减少，但核心业务完成量也跌到不可接受水平，不能仅凭错误率宣布恢复。应同时看成功完成量和被拒绝的工作量。
重试尤其容易制造次生故障。若一条调用链的三个层级都允许一次请求最多尝试三次，在全部失败且每层都重放的假设下，最底层可能收到最多 27 次尝试。这是最坏情形的算术示例，不是任何系统的测量结果。
掌握调用语义的单一层级负责重试，并限制总时间和次数，配合退避与抖动。写操作还需提供幂等保证。调用方遇到超时，只能确认自己没有按时取得结果，业务操作仍可能已经提交。
Amazon Builders' Library 的 超时、重试与抖动退避从调用方视角讨论了同一风险：重试会增加依赖负载，多层重试还会放大请求。团队需要把连接超时、请求超时和总重试预算分开设置，并通过调用链中的单一责任层控制重放。
降级同样不能越过正确性边界。商品推荐缺失可能可以接受，权限判断失败却不能退化为允许访问；库存来源不可用时，也不能伪造“库存充足”。每个降级分支都应由业务负责人确认。
复盘任务必须对应失效条件
服务恢复之后，复盘需要重建时间线：用户什么时候开始失败，告警什么时候触发，值班人员依据什么信息采取动作，哪个动作改变了局面。原始记录不全时，应标出未知区间，不能用回忆补成精确时间。
负责人无法验收“加强监控”“提高意识”“完善测试”。复盘任务应绑定具体失效条件。例如：
观察：
推荐依赖超时后，请求继续占用主流程并发名额。
整改：
为推荐路径设置独立并发上限和超时预算；
超限或超时时返回已约定的空推荐结构。
验收：
在受控环境模拟推荐依赖持续超时，
确认主流程满足约定 SLO，拒绝量和降级量可见，
恢复依赖后无需重启即可退出降级。
约束：
不得改变下单鉴权和库存校验行为。
这是一份演练定义，不是已经完成的演练记录。实现者、截止时间和证据位置需要在真实任务中补充。
长期整改也可以删除复杂度。团队若发现关键接口同步等待一项无需实时完成的工作，可以把它移出请求路径，减少原链路上的重试策略。改成异步后，团队还要处理可见延迟、补偿和积压。
不要承诺“架构免疫”。隔离故障域可以降低传播，副本可以应对部分节点故障，却不能自动防止错误配置、权限缺陷或同一软件版本的系统性问题。
小团队先守住一条关键旅程
资源有限的团队可以先选一条关键用户旅程，把检测、值班和止损串起来。值班人员需要知道谁接收告警、谁有操作权限，以及用哪些数据确认恢复。
如果大量告警都在重复提示同一类问题，优先修复这条故障路径。若事故处理时间主要花在寻找负责人和确认版本上，先补责任与发布记录。若回退因数据不兼容频繁失败，再安排迁移协议和兼容窗口。
衡量进展时，除故障数量外，还应看影响范围、恢复过程中的误操作、演练暴露的问题是否关闭。同一团队的事故样本往往很少，单个恢复时间下降不能证明体系成熟。保留每次判断所依据的记录，下次值班人员才能知道哪些动作已经验证，哪些仍然只是设想。