"余量"该留多少：你们是把 CPU 70% 当红线，还是把 90% 利用率当常态？

社区里高并发、容量规划、HPA 的内容已经很密了：#994 聊"压测 vs 影子 vs 建模"撑 10 倍流量，#976 聊"利用率当目标还是余量当目标"，#609 聊 HPA 自定义指标。但我在这些帖子下面反复看到同一个没说透的分歧——"系统到底该留多少余量"这件事，团队之间根本没有统一答案，甚至同一团队里老运维和新 SRE 的答案经常是反的。

我干了 15 年运维，从 2010 年写 crontab 看 top，到后来带 200+ 节点 K8s 集群，脑子里一直有一根老红线：单节点 CPU 长期均值 ≤ 60%，峰值 ≤ 80%，超过就扩容。这不是拍脑袋——是 2012 年一次凌晨 3 点磁盘 IO 打满、2015 年一次 GC 抖动把 P99 从 20ms 顶到 800ms、2018 年一次 NTP step 让滑动窗口限流器瞬间烧穿，这些事故的共同点都是：系统在 90% 利用率时，任何一点抖动都会被放大成事故。所以老运维的本能是"我宁可多花 30% 的钱，也不想在凌晨 3 点祈祷"。

但新一代 SRE 团队（包括我自己带过的降本项目）的做法完全反过来：把"利用率"当 KPI，节点数从 41 砍到 26，账单降 30%，代价是常态利用率从 45% 拉到 78%。他们的逻辑是：余量是"静态的、被浪费的"，HPA + 副本冗余 + 弹性伸缩才是"动态的、按需的"，只要扩容链路够快、信号够准，余量就是伪命题。

几种我见过的典型立场：

1. 老运维派：余量是"事故预算"，砍余量 = 借未来的事故来付当下的账单。CPU 70% 就该扩容，别信 HPA。
2. 利用率派：余量是"成本黑洞"，只要扩容链路 90 秒内能拉起、信号源不是 CPU 而是 QPS/队列深度，70% 利用率完全安全。
3. SLO 派：别聊利用率，聊错误预算。只要 SLO 没破，利用率 95% 也是安全的；SLO 破了，30% 利用率也白搭。
4. 分层派：核心链路留 40% 余量，边缘服务留 10%，用"业务重要度"而非"机器利用率"做决策。
5. 混合派：平时跑 75%，大促前 2 周手动扩容 30%，大促后缩回来——本质是"用人工换弹性"。

我的倾向：第 3 种 + 第 4 种的混合，把 SLO 当第一约束，把余量当"事故预算的可视化"。给每个服务定 SLO；把"余量"翻译成"事故预算"：一次 P99 抖动吃掉 20% 错误预算，一次 GC 抖动吃掉 5%，一次慢查询吃掉 10%；当"事故预算"消耗速度超过 SLO 的 1/10 时，自动触发扩容；核心链路与边缘服务用不同的预算系数。

这样"余量"就不是一个拍脑袋的百分比，而是可观测、可预算、可审计的指标。但我承认这套东西落地很重，多数团队做不到。所以我又开始怀疑：这套东西是不是只适合 100+ 人的 SRE 组织，中小团队是不是还是该回到"CPU 70% 红线"的土办法？

想听大家聊：

1. 你们团队的"余量红线"到底是多少？是 CPU 70%、内存 80%、还是磁盘 60%？这个数是拍的还是算的？
2. 你们用 HPA 自动扩容，扩容从信号出现到 Pod Ready 通常多久？这个时间决定了你们敢把利用率压到多高——你们算过这笔账吗？
3. 你们怎么定义"事故预算"？如果让你把"余量"翻译成"事故预算"，你会怎么定系数？
4. 核心链路和边缘服务，你们真的用不同的余量标准吗？还是"一刀切 70%"？
5. 有没有人试过"按 SLO 消耗速率"做弹性（而不是按 CPU）？效果怎么样？踩了什么坑？
6. 开放题：你们觉得"余量"这件事，到底是工程问题、成本问题，还是信任问题？

欢迎带数据来吵，纯观点也可以，但请说清楚你的团队规模、业务类型、SLA 等级，不然没法对比。