《互联网产品的服务端架构·规模化与架构演进》附录 A 规模化指标

规模化讨论里，最容易吵架的不是方案，而是数字。本附录把卷四用到的指标集中成表，供评审与复盘时直接引用。

每条指标都按「分子 / 分母 / 窗口 / 采集」四要素写。缺一项，数字就只能当参考，不能当判据。

容量与利用率

容量指标回答「还能不能撑住」，利用率回答「撑得是否浪费」。

容量水位不是越高越好。70% 意味着还有 30% 余量，也意味着一次突发就可能打满；50% 更安全，但成本更高。哪一个合适，取决于扩容速度与突发概率。

CPU 利用率要区分「平均」与「峰值」。平均 40%、峰值 95% 的系统，比平均 60%、峰值 70% 的系统更危险。判断容量时看峰值，判断成本时看平均。

内存利用率要小心缓存。缓存把内存吃到 90% 是正常设计，不是故障；但如果没有回收策略，一次冷启动就可能 OOM。

爆炸半径

爆炸半径衡量「一次故障最多影响多少人」，是单元化与隔离的核心指标。

「单点依赖数」需要人工梳理，不能只看监控。数据库主库、配置中心、鉴权服务、支付渠道，任何一个没有冗余，都是单点。

故障影响面要用演练验证，不能只靠架构图。架构图上画了三个单元，实际路由可能把 80% 用户放在一个单元里。

SLO 与错误预算

SLO 指标必须有明确的口径，否则无法跨团队比较。

成功请求的定义要写清：5xx 算失败，4xx 是否算失败，超时算不算，降级返回算不算。口径不同，同一个系统的可用性能差出两个数量级。

错误预算烧完不等于必须停止发布，但必须有明确的处置规则：是冻结发布、只允许修复，还是需要架构评审。规则要事前写，不能临时争论。

多窗口燃烧率比单窗口更稳。1 小时燃烧率能快速发现急性故障，6 小时燃烧率能发现慢性失血，两者结合可以减少误报与漏报。

成本与单位经济

成本指标要能落到「每单位业务量」，否则无法判断优化是否有意义。

月总成本包括计算、存储、带宽、数据库、中间件与人力分摊。只算机器费用，会低估真实成本；把人力全摊进去，又会掩盖资源浪费。建议分两层看：资源成本与全成本。

成本优化要先看结构，再看单价。存储占 60% 时，优化计算单价意义不大；带宽占 50% 时，先看回源与缓存命中率。

闲置资源要有明确定义：连续 14 天 CPU 峰值低于 10%、无流量、无告警关联，才算闲置。定义太松会误删，太严则回收不了。

分片与数据倾斜

分片系统的健康度，主要看倾斜与热点。

倾斜度要按数据量与 QPS 分别看。数据倾斜影响存储与备份，QPS 倾斜影响延迟与可用性，两者的解法不同。

分片键一旦上线就很难改。评估分片键时，至少看三个维度：分布是否均匀、查询是否带分片键、未来是否会长出跨片事务。

发布与研发效能

发布效能指标用于判断「团队能不能独立演进」。

发布频率高不等于效能高。如果每次发布都要三个团队配合，频率高只是把协调成本摊薄到每次发布里。

变更失败率要区分「回滚」与「故障」。回滚是正常操作，不一定算失败；导致用户可见故障的发布才算。

回滚时长比平均恢复时间更能反映发布系统的成熟度。回滚需要 30 分钟的系统，即使故障少，风险也高。

平台与组织

平台类指标最容易自说自话，必须同时看采纳与成本。

采纳率的分母经常被悄悄改小。目标服务数应该在上线前冻结，否则「接入 20 个服务、目标也是 20 个」可以得到 100% 的采纳率。

平台覆盖率比服务数更能说明问题：接了平台但流量都走旁路，等于没接。

技术债利息是估算值，必须标注估算方法与假设。把它写成「实测」会误导决策。

采样与聚合

规模化系统的指标几乎都经过采样与聚合，采样方式会改变结论。

「P99 延迟」在采样系统里尤其危险。头部采样会把所有慢请求都记下来，算出看起来合理的分位；随机采样在小流量时，P99 可能只由几十个请求决定。

分位不能直接平均。三个节点各自的 P99 取平均，不等于全局 P99。要合并分位，必须用直方图或 t-digest 之类的结构，并在报表里注明算法。

计数器要处理重启。服务重启后计数器归零，如果直接做差分，会出现负值或尖峰。常见做法是用单调递增的时间戳或重启标记过滤。

告警阈值怎么定

阈值不是拍脑袋，也不是照抄别家。一个可用的阈值至少经过三步。

第一步：看历史分布。 取最近 28 天的同一时段数据，算出 P50、P95、P99。阈值通常设在 P99 附近，而不是平均值。

第二步：看告警成本。 误报一次要花多少人力？漏报一次影响多少用户？两者不对称时，阈值要偏向成本高的一侧。

第三步：看可行动性。 告警响起后，值班同学能做什么？如果只能「观察一下」，这个告警就不该存在。

容量告警要留出扩容时间。如果扩容需要 20 分钟，85% 才告警就太晚，应在 70% 预警。

成本告警看趋势，不看绝对值。日环比突增往往比「本月已花 80% 预算」更早发现问题。

一次口径事故

「回声」曾有一次关于「支付成功率下降」的告警。支付团队看到 92%，比平时低 3 个百分点，紧急排查了两小时，最后发现是口径问题。

原来，支付成功率的分子来自支付库的「成功」状态，分母来自网关的「发起支付」请求。那天网关做了一次重试策略调整，同一笔支付会发起两次请求，分母涨了 8%，分子没变。成功率自然下降。

这次事故之后，团队做了三件事：

• 分子分母统一从支付库取，按支付单号去重。
• 报表里增加「重试率」指标，重试异常时能提前发现。
• 口径变更必须走评审，变更记录写进指标字典。

口径事故的代价往往比真实故障更高，因为它消耗的是团队对数据的信任。真实故障修完就结束，口径事故会让人在很长时间里怀疑每一个数字。

指标字典模板

一个可用的指标条目至少包含以下字段：

「排除」是最容易被漏掉的一栏。测试订单、刷单、内部流量如果不排除，小体量业务的指标会剧烈波动。

指标字典应该与数据模型放在一起，最好能从字典生成查询。手写 SQL 与文档各维护一份，迟早分叉。

趋势与基线

单点数字没有意义，趋势才有。看趋势时要固定三件事：口径、窗口、采样方式。任何一项变了，趋势就断了。

基线建议取「过去 4 个同周几的同一时段」，而不是「昨天」。周内波动、活动周期、版本发布都会影响数字，同周几对比能过滤掉一部分。

对于有明显季节性的业务，基线要按季节调整。电商的大促月、教育的开学季、游戏的假期，都会让「正常水平」发生偏移。

趋势异常时，先排除口径与采集问题，再怀疑系统。顺序反了，会在错误的方向上排查很久。

指标评审清单

给一个指标做评审时，按顺序问：

• 分子与分母是否来自同一数据源、同一时间口径？
• 窗口是自然日、滚动 28 天，还是自定义？
• 去重键是什么？用户、订单、请求还是设备？
• 排除了哪些数据？测试账号、内部流量、风控拦截？
• 谁负责这个指标？口径变更由谁批准？
• 这个指标变好时，会不会让另一个指标变差？
• 指标异常时，第一动作是什么？

七个问题里有一个答不上来，这个指标就不适合作为考核或告警依据，只能作为参考。

常见误读

• 把平均值当容量。 峰值才是容量判据。
• 把可用性当体验。 请求成功但延迟 5 秒，用户仍然会走。
• 把成本当财务问题。 成本结构反映的是架构选择。
• 把采纳率当成功。 接了平台但没用起来，是负收益。
• 把发布频率当效能。 没有回滚能力的频繁发布，只是频繁冒险。
• 把倾斜度当数据问题。 倾斜往往来自分片键设计，不是数据本身。
• 把估算当实测。 技术债利息、闲置成本、平台收益，都要标注估算。

这些误读的共同点是：指标本身没错，错在用它回答它回答不了的问题。评审时先确认「这个指标能回答什么」，再讨论数值高低。

怎么用这份附录

• 做容量规划：看「容量与利用率」「爆炸半径」两节。
• 做稳定性评审：看「SLO 与错误预算」一节。
• 做成本优化：看「成本与单位经济」「分片与数据倾斜」两节。
• 做平台复盘：看「发布与研发效能」「平台与组织」两节。

每次使用前，先把自己的口径写下来，再和表里的定义对照。口径对齐之后，数字才有讨论价值。