某地区依赖服务不可用时，如何验证 SaaS 产品的降级与恢复？ | 全球代理

降级测试要回答两个问题：核心功能是否仍可用，用户是否知道下一步该做什么。先标出哪些依赖挂了会影响核心路径，再在授权环境里模拟超时、5xx 和 DNS 失败。每模拟一种，逐项检查四件事：提示文案、重试次数、恢复后的状态、告警是否触发。降级是否按预期生效，最终要看发布后的地区错误率和回滚记录。有些问题只在特定地区的出口上出现，可在受控条件下切换出口复测。测试地区可用全球代理 IP 产品页规划；网络连接异常可参考连接超时、TLS 握手和代理出口稳定性记录。可以按依赖、故障注入、用户提示、恢复验证四层逐步检查。

盘点依赖与核心业务流程

先把依赖列出来，按“挂了会不会阻断核心路径”分两类。登录、支付、数据读写这类属于核心路径的依赖，挂了必须有降级或明确的阻断提示；统计这类非核心能力可以静默降级；推荐、富文本编辑能不能静默处理，要看它是否承载核心流程、失败会不会丢数据，涉及草稿保存或内容丢失的应给明确提示。

每一类依赖再标四个值：超时时间、重试次数、降级方式、告警阈值。这四个值决定测试的预期，没有它们就只能凭感觉判断“体验好不好”。

在授权环境模拟超时、5xx 和 DNS 故障

模拟只在自己可控的测试环境做，不动生产。三种失败方式分别对应三类故障：超时对应慢依赖，5xx 对应服务不可用，DNS 失败对应解析或网络配置问题。

模拟时只改一个依赖，其他依赖保持正常。同时改两个，出了问题也说不清是哪个触发的降级。模拟“某地区依赖不可用”之前，先确认这条依赖请求是浏览器发出的，还是服务端发出的：如果依赖由服务端发起，切换客户端出口根本不在那条链路上，测到的只是客户端到 SaaS 的一段。这类场景要在授权测试环境里用 mock、故障注入或受控网络策略，按目标地区或部署单元选择请求，分别注入超时、5xx、DNS 失败，并保留一组正常对照。仅换出口不等于已经注入依赖故障。

检查降级提示、重试上限和失败状态

用户可见的部分有三项要查：

• 提示文案：说清“哪个功能暂时不可用”，不要只写“系统繁忙”。
• 下一步：给一个用户能做的动作，比如稍后重试、改用备用方式或联系客服。
• 可恢复性：区分“稍后重试”和“暂时无法恢复”，别让用户反复点。

重试要测上限。若待测链路包含代理出口的请求重试，可参考代理请求的超时、重试和故障转移设计，但它不能替代 SaaS 依赖自身的重试与补偿验证。重试三次和重试三十次，对用户和后端的压力完全不同；超过上限后应该有明确的失败态，而不是一直转圈。

验证服务恢复、数据状态和告警

撤销故障注入、确认依赖本身恢复健康，只是这一步的起点，不是结论。按下面五步走完再宣布恢复：

1. 开关状态：观察降级开关、熔断器和限流是否自动解除，是否还有地区被锁在降级分支上。
2. 新请求：恢复后新发起的请求应走完整链路，结果与故障前基线一致。
3. 遗留请求：故障期间被拒绝、排队或超时的请求，要单独确认最终状态——是已失败、已补偿，还是仍在队列里。
4. 数据核对：对订单、扣款、消息投递、任务状态逐项对账，只对确认未完成的操作按幂等规则补做，不要把“有状态操作”整类重放一遍，那样会造出重复扣款。
5. 告警与指标：确认告警已解除、通知发到了正确的值班人、恢复后的错误率和延迟回到基线。

记录三组时间：故障开始、依赖解除、各项功能恢复完成；并写明每一步的预期状态与实际状态。没有这组记录，下次同类故障无法判断是恢复得慢，还是根本没恢复。

记录用户可见结果和系统指标

记录以用户视角为主，工程指标为辅。同一次模拟，要有“用户看到了什么”和“系统记了什么”两份证据。

> 表格中的阈值、用例编号和结果如无测试记录支持，均应视为演示样例；实际验收标准以项目需求、历史基线或团队约定为准。

“期望降级”一列来自设计文档，不是来自这次的实际表现，否则缺失的降级会被当成正常。

FAQ

恢复后要不要补数据？

先看这类操作在故障期间是否留下了未完成记录：订单、扣款、消息投递这类有状态操作要逐条核对并做幂等补偿；纯展示类不需要。补偿规则应在设计阶段就写进方案，测试时验证它是否真的被执行。

依赖恢复了，用户还在报错，先查什么？

先看降级状态是否解除，再查缓存是不是还挂着旧结果。

模拟故障会触发真实告警吗？

会。先通知值班人，或改到测试告警通道里演练。

只降级不报警行不行？

不行。静默降级最难发现，核心路径必须有告警。