SRE 中的软件工程

一句话

你以为 SRE 写软件是为了少干点活，其实是为了让「运维」这件事第一次有了能复利的产出物。本章是全书唯一一章不讲怎么运维，而讲运维团队怎么造产品：以 Google 内部的容量规划工具 Auxon 为案例，论证把「人手拍出资源数字」换成意图式容量规划（intent-based capacity planning）——工程师声明约束与目标，求解器算出分配方案。

Glossary · 术语表

坐标

本章在全书第 III 部分「实践（Practices）」的中段：上承 Ch17「为可靠性做测试」，下启 Ch19–20 的前后端负载均衡。它在结构上是个异类——前后左右都在讲「怎么把线上顶住」，只有它在讲「SRE 团队怎么产出软件」。真正与它咬合的是 Ch5「消除杂务」与 Ch1 那条 50% 上限：本章相当于回答「省下的那 50% 拿去干嘛」。

这章要解决什么

传统容量规划是一条四步循环：收集需求预测 → 制定分配计划 → 评审签字 → 部署配置资源。它的产物是一张具体到数字的大表：「服务 Foo 在集群 X 要 50 核、Y 要 30 核」。

问题在于，这张表存的是结论，不是推理过程。一旦任何输入变动——预测上调、某批机器交付延期、某个依赖服务变重、某个发布推迟一个季度——整张表都得重算一遍，而算它靠的是电子表格加一圈跨团队对齐，一次迭代动辄数天到数周。书里把这个毛病叫脆弱（brittle）：不是慢，是每次变动的成本都等于从头再来一次。

后果有两个方向。一是计划做完就过期，团队索性按最坏情况超配，钱烧在闲置机器上；二是工作量随服务数线性增长——量级上，一个中等服务铺在几十个集群、依赖十几个下游，人工要维护的格子就是几百上千个，再乘服务数。这恰好逐字命中 toil 的定义。

核心内容，讲透

意图式容量规划：把「要多少」换成「为什么要」

核心概念是意图（intent）：驱动这个计划成立的需求与约束本身，而不是它算出来的数字。传统计划相当于只交付二进制、扔掉源码；意图式交付源码，二进制随时可重新编译。书里用一道阶梯说明「意图化」是连续光谱，不是开关：

这张阶梯的判断很实在：第 ③ 级是甜点——抽象到足以让机器接手，又具体到能真的求解。第 ④ 级听起来最美，但「五个九」要翻译成「多少核、摆在哪」中间缺的环节太多，本章明确把它列为尚不可行的方向。这也是全章最值得带走的一条判据：把意图抬高到「目标 + 冗余」那一层就停，别追求一句话解决所有问题。

意图由三样东西构成

光说「声明意图」是空话，本章把它拆成三个必须提供的输入，缺一个系统就转不起来：

• 依赖（dependencies）：Foo 每秒多 1000 次请求，会给下游 Bar、Baz 分别压上多少。没有依赖图，你只能逐个服务各自规划，链路上的放大效应就会被漏掉——前端涨 20%，某个被反复调用的底层服务可能涨 60%。
• 性能指标（performance metrics）：把需求翻译成资源的汇率，形如「每 1000 QPS 需要 2.5 核 + 4 GB」。本章强调这个系数应当由压测或线上实测自动产出，而不是让人填一个拍脑袋的数——它是整条链路的放大器，错 30% 就全局错 30%。
• 优先级（prioritization）：资源不够时先保谁。这一条最常被跳过，也最致命：没有优先级，求解器只能回你一句「无解」，而你真正想知道的是「牺牲哪个还能过」。

Auxon 怎么算：把容量规划变成一道优化题

Auxon 是 Google SRE 自己写的容量规划工具，本章拿它作全章唯一的案例。它的形状是一条标准的「编译 + 求解」流水线：

• 输入：意图配置（用一门专门的配置语言写）、按服务的需求预测、资源供给（现有机器 + 已订购待交付的机器）、资源定价（不同集群、不同机型的相对成本）、性能数据。
• 配置语言引擎：把人写的意图编译成一组形式化的约束与变量。
• 求解器：一道混合整数规划问题——在满足全部约束的前提下让总成本最小。写成记号大致是 minimize Σ price·alloc，受约束于「每个集群的用量不超过供给」「每个服务的份数 ≥ 需求所需 + 2」这类不等式；alloc 必须取整数，因为副本数不能是 2.7 个。这句话的白话版是：把所有硬性要求写成不等式，再挂一个「越便宜越好」的目标，让求解器在巨大的可能空间里搜一个最优摆法。
• 输出：分配计划——每个服务在每个集群占多少资源。

为什么这样设计？关键在两个性质。第一，输入变了只需重跑，人不必重算，一次迭代从数周压到分钟级。第二，无解时求解器能指出是哪条约束卡住——这比一张算不出来的表格有用得多，它把「资源不够」这个模糊结论变成了「A 区的 N+2 和当前供给互斥」这种可谈判的事实。

诚实的代价：MIP 是 NP 难问题，规模一大就没法保证在可接受时间内求到全局最优，因此实际使用中要接受近似解、按区域分解问题。本章对此不回避——容量规划本来就是在不确定的预测上做决策，一个快速得到的近似解，胜过一个精确但过期的答案。

为什么非得 SRE 自己写

本章的另一半主张是组织层面的：这类软件应当由 SRE 团队自己产出。理由不是「没人帮我们写」，而是三条结构性优势——SRE 既是开发者又是用户，反馈回路最短；他们手上握着外部工具厂商拿不到的生产环境领域知识（真实的依赖、真实的失效模式、真实的采购约束）；而且工程产出让团队价值不再随服务数线性堆人。

顺带解决人的问题：一条正经的软件工程产出线，给了 SRE 不靠转岗的成长路径。但本章同时给了硬约束：不要降低标准——这些软件在替生产做资源决策，必须按产品级要求做（设计文档、测试、明确的负责人与支持承诺），而不是「内部工具随便写写」。

关键权衡与选型

最容易搞混的一组概念，先钉死：自动扩缩（autoscaling）不是容量规划。自动扩缩在分钟级对已有机器做再分配，容量规划在季度级决定「要不要买、买多少、摆哪里」。前者解决不了「机器还没到货」，后者也追不上午高峰。两者是不同时间尺度上的两件事，谁也替代不了谁。

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

这套思想今天到处都是，只是换了名字。Kubernetes 的声明式 API（你写期望状态，控制器负责收敛）、Terraform 的期望状态模型、各家云的预留实例规划器，骨子里都是「交条件、别交步骤」；区别只在于 Auxon 把目标函数显式写成「总成本最小」，并真的塞了个数学求解器进去。

面试里的用法很具体：被问「你怎么做容量规划」，先反问意图在哪一层——「按去年峰值乘 1.5」和「声明 N+2 让系统自己算」，背后是完全不同的组织成熟度；再把「自动扩缩 ≠ 容量规划」讲清楚，基本就赢了一半。

易错点与争议

• 最常见的误解：把意图式当成自动扩缩的高级版。 不是。它们的时间尺度差了五个数量级，解决的也是不同问题——一个管「现在多开几个」，一个管「三个月后有没有机器可开」。
• 以为上了求解器人就闲了。 恰恰相反，人的活从「填表」变成了「把约束写对」，而后者更难。求解器只会严格优化你写下来的目标：你没写进约束的东西，它一定会替你省掉——忘了写 N+2，它就给你 N。
• 换算系数是被低估的单点。 「每 1000 QPS 要 2.5 核」错 30%，整个舰队的规划就错 30%，而且错得非常安静——所以本章坚持它必须自动测出来。
• 最优解不等于可解释的解。 MIP 给出的分配往往人看不懂「为什么是这样」，出事时排障、向上解释都更费劲——本章没充分展开的真实代价。
• 时代局限。 2016 年的 Auxon 面对的是自建数据中心 + 长采购周期。云时代按需扩容一度让这个问题显得过时；但 GPU / TPU 配额重新变成稀缺品、需要提前数月预订之后，「意图 + 求解器」这套东西又原样回来了，只是换了资源类型。
• 可复现性的争议。 Auxon 从未开源，本章也没给出足以复现的细节（配置语言语法、求解器的规模处理都只是点到）。外部团队能带走的是思想与那道意图阶梯，不是实现——按「案例研究」而非「实现指南」来读。

要点