Software Architect · 模块 15
可靠的系统不承诺什么都不会坏。它限制损失、快速恢复，并且对自己的状态保持诚实。
SLO · error budget · graceful degradation · recovery
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 出现延迟时，用户操作不能被它卡住。
可靠性不是用幻灯片证明的——是用一次事故或一次演练证明的。
例子：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 是什么时候？