# 15. 可靠性

如何用 SLO、error budget、graceful degradation、incident response 和 recovery 来思考系统对故障的抵抗力。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-15-reliability

---

## 1. 核心思想

Reliability 是一种带有明确目标的、可被管理的服务质量——不是对代码运气的祈祷。

### SLO 把可靠性翻译成产品语言

> "火车应该跑得好"无法验证。"99% 的火车在 5 分钟延迟内到达"则可以测量。

SLA 是对客户的承诺。SLO 是内部目标。SLI 是可测量的指标：availability、latency、error rate、freshness。Error budget 告诉你在一个周期内可以容忍多少失败。

架构师用 SLO 来选择 trade-offs：error budget 在燃烧时，团队降低 release 风险；预算充裕时，可以加快实验节奏。

### 故障应该是一种预期场景

> 制定疏散计划不是因为希望发生火灾，而是因为它有可能发生。

可靠性来自工程上的设计：timeouts、retries、bulkheads、rate limits、circuit breakers、backups、restore drills、health checks、runbooks 与 incident response。Prevention 重要，detection、mitigation、recovery 同样重要。

系统必须以受控的方式降级：recommendation engine 挂掉时，checkout 仍要可用；analytics 出现延迟时，用户操作不能被它卡住。

## 2. 例子与反例

可靠性不是用幻灯片证明的——是用一次事故或一次演练证明的。

### 例子：search 的 graceful degradation

> 如果机场显示屏熄灭了，工作人员仍然得有一份备用航班清单。

Search service 不可用。Product page 依然能打开，目录展示热门商品作为 fallback，UI 诚实地告诉用户搜索暂时受限。Alert 通知到 on-call，runbook 描述了如何检查索引和 rollback。

用户看到的是一个功能在降级——而不是整个产品倒下。

### 反例：只有 backup 没有 restore

> 如果没人知道备用钥匙是哪扇门的，它就毫无用处。

团队声称 backup 已经配置。但 restore 从未验证过，RPO 与 RTO 没人知道，访问 backup 的权限只在一个人手里，恢复流程也没文档化。

Backup 只是 reliability 的一半。真正的保障在一次成功的 restore drill 之后才存在。

#### 自检

- 哪些 SLI 真正反映了用户体验？- 关键数据的 RPO 和 RTO 是多少？- 依赖出故障时哪些功能还能继续运行？- 上一次验证 restore 是什么时候？

下一模块：[安全](./software-architect-16-security)。