为可靠性做测试

一句话

你以为测试是为了找出 bug，这一章的主张更锋利：测试是 SRE 用来「量化信心」的工具，它真正改变的不是 bug 的数量，而是 bug 的修复代价。原文开篇即说，SRE 的一项核心职责是量化对所维护系统的信心；而可靠性是平均无故障时间（MTTF）与平均修复时间（MTTR）的函数。测试的经济学就落在 MTTR 那一边——被测试卡在发布之前的 bug，修复时间近似为零。

Glossary · 术语表

坐标

本章属全书 Part III「实践」，紧跟第 15 章「事后复盘文化」那一组故障处理之后，上承第 3 章「拥抱风险」的错误预算与第 8 章「发布工程」，下启第 19–22 章的负载均衡与过载防线、第 27 章的发布协调。它对应现实里的那条链路：CI 流水线 → 灰度发布 → 黑盒探测——今天被叫作渐进式交付（progressive delivery）与合成监控（synthetic monitoring）。

这章要解决什么

SRE 要回答一个每天都被问的问题：「这个版本能上吗？」过去的可靠性可以靠监控历史数据说清楚，未来的可靠性却只能靠预测。而预测要成立，前提是系统没变——可系统天天在变。这一章给出的解法是：测试就是在变化发生时，证明「哪些地方仍然等价」的机制；每一个在改动前后都通过的测试，就消掉一块不确定性。

不解决会怎样？两种极端都见过。一种是不敢发：每次上线拉全组人手动验，节奏掉到一月一次，功能积压成巨型变更、出事更难定位。另一种是盲发：推上去盯监控，让用户当探测器——线上一个 bug 的完整代价是「告警 → 定位 → 回滚 → 复盘」，动辄几小时；而同一个 bug 被 CI 拦下，代价只是一次红色构建加一次提交。

核心内容，讲透

一、测试的本质：把 bug 挪到 MTTR 最低的那一格

原文有一个说法值得抄下来：当一个系统级测试正好抓到了「监控本来会抓到的那个问题」，这次推送就能被直接卡住，bug 根本到不了生产——这种 bug 的 MTTR 是零，靠拦住一次发布来修复它，既快又省事。

这句话把测试从「质量活动」重新定义成经济活动：你不是在消灭 bug（消灭不完），而是在决定它被发现的位置，位置决定代价。

二、传统测试：单元 → 集成 → 系统

第一类测试在未部署的二进制上跑，喂的是构造好的已知数据。三层：

• 单元测试：测一个最小单位，毫秒级，数量最多，是整座金字塔的底。
• 集成测试：把组装起来的组件放一起跑，用依赖注入把真实数据库、真实下游换成假的，从而在几秒内跑完本该跨进程的逻辑。
• 系统测试：在一套完整但尚未部署的系统上跑，又分三种——冒烟测试（smoke test）只验最简单也最关键的行为，先跑它，挂了后面就不必跑；性能测试盯住延迟与资源占用随版本悄悄漂移；回归测试把每个修过的 bug 固化成一条用例。

回归测试有一条极具操作性的判据：发现 bug 时，先写一个能稳定复现它的测试，再动手修。它顺带回答了「接手一个没有测试的老项目该从哪下手」——不必先补全量覆盖，从每一个你修过的 bug 开始攒。

三、生产测试：配置、压力、金丝雀

第二类测试跑在已经部署的系统上，因为有些事情只有生产环境才有。

• 配置测试（configuration test）：把线上实际生效的配置与版本库里应该生效的配置做比对，不一致就报警。它之所以要单列，是因为配置是事故的高发源头，却往往根本不在 CI 里——今天 Terraform 的 plan 与漂移检测（drift detection）就是它的当代形态。
• 压力测试（stress test）：主动找边界。数据库写到多满开始拒写？QPS 压到多少开始过载？剩多少空闲磁盘才触发告警？不测你就不知道边界在哪，只能等线上告诉你——而线上告诉你的方式通常是一次事故。
• 金丝雀（canary）：把新版本先发给一小撮服务器，让它在真实流量里「烘焙」一段时间再放大。

关于金丝雀，原书给了一句最常被忽略的话：它其实不是测试，而是「有组织的用户验收」。配置测试与压力测试是在确定性的软件上确认某个条件成立；金丝雀则更即兴——它只把待测代码暴露给一小片不可预测的真实流量，因此并不完美，也不总能抓到新引入的故障。把它当最后一道保险可以，当成「验过了」不行。

四、探针：测试与监控都够不着的那一格

把前面的东西摆成一张两维表，会看到一个常被漏掉的格子。传统测试 = 已知输入 × 未部署的二进制；监控 = 未知的真实流量 × 已部署的二进制。那么「已知输入 × 已部署的二进制」归谁管？——归探针。

原书点破了这块空白的成因：发布测试跑的那套组合，往往是「集成好的服务 + 一个前端 + 一个假后端」；而探针跑的是「发布二进制 + 负载均衡前端 + 真正可扩展的持久化后端」。换句话说，生产里真正在跑的那个组合，此前从未被完整测过。Google 用一个叫 Prober 的工具补这一格：它对目标跑一次协议级检查、报告成功或失败，还能校验响应负载本身（比如 HTTP 返回的 HTML 内容是否符合预期），并把提取出的值导出成时序指标。

探针的代价也要说清：它对生产发的是真实请求，要处理写入副作用（通常用专门的测试账号与可回收数据）、配额消耗，以及「探针自己挂了算谁的」——它的告警必须能区分「服务坏了」和「探针坏了」。

五、大规模下的三件麻烦事

① SRE 自己写的工具也是软件。排空集群流量、批量重启、回收数据、调配额——这些工具的爆炸半径往往比业务代码还大，却常常一行测试都没有。原书给了一条很利落的判据：测试的充分程度，决定了这个工具多久可以对生产用一次。没测过的工具就只能在人盯着的窗口里手动跑；测充分了才配得上自动化。

② 灾难恢复工具怎么测？它天然只在最糟的时刻被用到，没法等真出事再验。原书的做法很巧：很多灾难恢复工具可以被设计成离线运行，算出一个「等价于把服务干净地停掉」的检查点状态，再把这个状态推给现有的、非灾难场景下的校验工具去检查。把一次灾难变成一份可以离线校验的快照——这是全章最值得抄走的一招。

③ 速度就是可用性。测试跑得越久，从签入到拿到反馈的时延越长，工程师就越倾向于绕过它。而不稳定测试是更隐蔽的毒：工程师真正想知道的是「我这段代码是不是有没预料到的竞态」，如果测试本身时红时绿，这个信号就被噪声淹没了——一个偶发失败的测试比没有测试更糟，它会训练整个团队无视红灯。

最后，这三件事被同一个控制回路串起来：MTBF 随测试变好而上升，开发者就被鼓励发得更快；新 bug 出现，发布速度又被压回去。落到实践就是错误预算——SLO 还有余量就继续发，预算烧完就停发、把资源投回测试与稳定性。

关键权衡与选型

表 1 · 七种检查各守哪一段（抓什么 / 漏什么）

表 2 · 钱该往哪边投：先看你的 MTTR

两边不是二选一，而是同一个方程的两侧：可靠性是 MTTF 与 MTTR 的函数，你可以从任一侧买到它。真正的错误是两侧都不投，然后指望运气。

为什么重要 / 落到真实系统

今天几乎所有「现代交付」的做法，都能在这一章里找到原型：CI 上的分层测试对应 Bazel / GitHub Actions 那套流水线；配置测试对应 Terraform 的 plan 与漂移检测；金丝雀对应 Spinnaker、Argo Rollouts、Flagger 的渐进式发布；探针对应 Prometheus 的 blackbox_exporter、Datadog Synthetics 与各家的拨测。读懂这一章，等于拿到了这些工具「为什么长成这样」的说明书——也是被问到「你怎么保证一次发布是安全的」时，能从 MTTR 讲起而不是背工具名的底气。

易错点与争议

• 把金丝雀当测试：最常见的误解，而且原书自己就先点破了——它只是有组织的用户验收，抓不全新引入的故障。
• 拿覆盖率当安全感：覆盖率衡量的是代码被执行过，不是行为被断言过；而配置、依赖版本、部署拓扑这些最容易出事的东西，压根不进覆盖率的统计口径。
• 忘了测 SRE 自己的工具：爆炸半径最大的那部分代码，常常正是没有测试的那部分。判据回到原书：测得不够，就别让它自动跑。
• 容忍不稳定测试：它的伤害是复利的——先是被重跑，然后被加进忽略名单，最后整条红色信号都没人看了。
• 时代局限：本章 2016 年成书，当时既没有成熟的自动金丝雀判读（Kayenta 2018 才开源），也没有服务网格级的精细切流和 OpenTelemetry 这样的统一探测层。今天「渐进式交付」已经把金丝雀工程化到了本章没预见的程度。
• 一个有力的反方，其实是同一枚硬币：持续交付一派会说「与其砸钱做更长的测试套件，不如把 MTTR 压到几分钟」。听着像反对，实则正是本章的论证方向——可靠性是 MTTF 与 MTTR 的函数，两侧都能买；真正的分歧只在你的系统能不能秒级回滚。

要点