Kubernetes生产运维15：排障不该靠运气，怎么用监控、告警和复盘把稳定性沉淀下来

Kubernetes生产运维15：排障不该靠运气，怎么用监控、告警和复盘把稳定性沉淀下来

写在前面

这是本专栏的最后一篇。前面十四篇讲的都是"出了问题怎么查"：Pod Pending、CrashLoopBackOff、OOM、Service、DNS、Ingress、存储、节点、探针、资源、权限、升级。

但如果每次都靠出事后救火，人会越来越累，问题会反复发生。真正的稳定性不是排障能力，而是一个闭环：

监控让问题可见
→ 告警在合适的时候叫醒合适的人
→ 排障定位并恢复（前十四篇）
→ 复盘把这次故障变成改进
→ 改进回流到监控、告警和系统设计
→ 同类问题不再发生或更快被发现

这一篇讲怎么建立这个闭环：用什么方法监控、SLO怎么定、告警怎么才不吵、复盘怎么做才有用。它把前面所有排障经验收敛成一个可持续的体系。

本文按照SRE通行方法和Kubernetes官方监控机制整理。由于当前没有连接可验证的实验集群，示例指标和输出均为说明性重建，不是生产原始记录。SLO阈值、告警规则要结合自身业务和容量确定，本文给的是方法和起点，不是可照抄的具体数值。

一、监控什么：RED和USE两种视角

监控最怕的是装了一堆指标却不知道该看哪个。RED和USE是两个互补的框架，帮你抓重点。

1.1 RED：从服务视角看

RED针对每个服务，看三个指标：

• Rate（请求量）：每秒请求数
• Errors（错误率）：失败请求的比例
• Duration（延迟）：请求耗时，看P50、P95、P99

RED回答的是"用户体验好不好"。服务出问题，通常先在错误率或延迟上体现。

1.2 USE：从资源视角看

USE针对每个资源（CPU、内存、磁盘、网络），看三个指标：

• Utilization（利用率）：资源用了多少
• Saturation（饱和度）：排队等待的程度，如CPU限流、内存压力
• Errors（错误）：资源层面的错误

USE回答的是"资源够不够、有没有瓶颈"。前面讲的OOM、CPU限流、磁盘压力，都属于USE视角。

1.3 两者配合

• 用户报慢或报错，先看RED定位是哪个服务
• 再用USE看这个服务依赖的资源有没有瓶颈
• RED是症状，USE常是原因

在Kubernetes里，RED来自应用和网关指标，USE来自节点和容器指标（如前面用过的工作集内存、CPU限流、节点压力）。

二、SLO：定义"多好才算好"

2.1 为什么需要SLO

没有SLO，“稳定"是个说不清的词。SLO（服务等级目标）把它量化：比如"99.9%的请求在300毫秒内成功返回”。有了SLO，才能判断当前是不是够好、该不该投入改进。

几个概念：

• SLI：服务等级指标，实际测量值，如成功率、延迟
• SLO：目标，如成功率≥99.9%
• 错误预算：1减去SLO，即允许的不完美。99.9%的SLO意味着有0.1%的错误预算

2.2 错误预算怎么用

错误预算是个很实用的概念：

• 预算还充足：可以更激进地发布、升级、做变更
• 预算快用完：放慢变更、优先做稳定性，别再冒险

它把"要稳定还是要快"这个永恒矛盾变成了可量化的决策，而不是拍脑袋吵架。

2.3 SLO要基于用户体验

SLO应该反映用户真正在乎的东西，通常是核心链路的成功率和延迟，而不是"CPU利用率低于80%"这种资源指标。资源指标是USE的事，SLO是面向用户的。

一个常见错误是给什么都定SLO，结果没有重点。先给核心业务链路定，其他慢慢来。

三、告警：少而准，叫醒该叫醒的人

3.1 告警疲劳是真正的危险

告警太多比太少更危险。当一个人每天收到几百条告警，他会开始忽略所有告警，包括真正重要的那条。这就是告警疲劳。

前面每篇都提到"告警不能只匹配某个状态"，比如不能只匹配phase=Pending、不能一次重启就告警。原因就在这：噪声告警会淹没真问题。

3.2 告症状，而不是告原因

好的告警原则：对用户可感知的症状告警，而不是对每个可能的原因告警。

• 症状告警：错误率超过SLO、延迟P99恶化、核心接口不可用
• 原因告警：某个Pod重启了、某个节点CPU高了

原因层面的东西太多、太容易抖动，适合放进仪表盘供排查时看，而不是都变成会叫醒人的告警。当症状告警响了，再用原因层面的指标去定位（这正是前十四篇做的事）。

3.3 告警要可执行

每条会叫醒人的告警都应该：

• 对应一个真实的、需要人介入的问题
• 有明确的处理指引（Runbook链接）
• 分级：紧急的才叫醒人，次要的进工单或看板

如果一条告警响了大家都不知道要干嘛，或者响了也不用管，它就该被删掉或降级。

3.4 结合前面的排障经验降噪

前面各篇的降噪原则汇总起来就是：

• Pending：区分正常等待（WaitForFirstConsumer、SchedulingGated）和真正调度不上
• 重启：按重启速率和持续时间告警，不是一次重启就告警
• OOM：区分周期尖峰和持续泄漏
• 节点NotReady：区分短暂抖动和持续不可恢复
• 集体重启：这种模式反而要专门告警

四、故障复盘：让每次故障都变成改进

4.1 复盘的目的是改进，不是追责

Postmortem（故障复盘）最重要的原则是对事不对人（blameless）。如果复盘变成追责大会，大家就会隐瞒信息、推卸责任，真正的根因反而查不清。

对事不对人不是不追究,而是把注意力放在"系统为什么允许这个错误发生、怎么让它下次不发生",而不是"谁按错了按钮"。人会犯错是常态,好的系统应该能容错。

4.2 一份复盘该有什么

• 故障时间线：什么时候发生、什么时候发现、什么时候恢复，关键动作的时间点
• 影响：影响了什么、多大范围、多久（基于事实，不夸大）
• 根因：用前面的排障方法定位到的真正原因，而不是表面现象
• 止损和恢复过程：做了什么让它恢复
• 行动项：具体的、有负责人、有截止时间的改进，这是复盘最有价值的部分

4.3 行动项要落到闭环上

复盘的行动项应该回流到这个闭环的各环节：

• 监控：这次故障有没有对应的监控？没有就补
• 告警：有没有提前告警？告警是不是太晚或太吵？
• 系统设计：能不能从设计上避免？比如加PDB、改探针、调QoS
• Runbook：把这次的处理过程沉淀成Runbook，下次更快

行动项如果只是"下次注意"，等于没有。要具体到"给X服务配PDB，负责人A,本周内"。

4.4 区分事实和推断

复盘里要像排障一样区分已确认的事实和推断。前面反复强调的"不把相关性写成因果"“单一指标不能定根因”,在复盘里同样适用。一份好的复盘经得起追问:每个结论背后的证据是什么。

五、C级生产化重建案例：一次告警太晚的复盘

5.1 先说明哪些是真的，哪些是重建的

下面不是作者声称亲历的具体事故，而是根据监控告警机制和复盘方法构造的生产化重建，用于演示复盘怎么做。

所有内容按合理机制编排，但不是某次真实事故的原始记录，读者不能把下面的时间或数值引用为真实数据。

5.2 复盘：一次发现太晚的服务降级

故障时间线（说明性重建）：

影响（基于事实，不夸大）： 核心接口一段时间内成功率下降、延迟升高，具体数值以监控为准，这里不编造精确的用户数和金额。

为什么发现晚（根因分析）：

监控体系里只配了USE视角的资源告警（CPU、内存），核心接口的错误率和延迟这种RED症状指标虽然有仪表盘，但没有配成告警。所以资源没到阈值时，没有任何告警，直到用户反馈才发现。

只监控了资源利用率，没对用户症状告警
+ 依赖变慢不体现在本服务的CPU内存上
+ RED的错误率延迟只在看板里，没配告警
+ 于是靠用户反馈发现，晚了约20分钟
= 告警设计缺陷导致发现晚，放大了影响

这不是排障能力问题，是监控告警设计问题。

5.3 行动项（回流到闭环）

每条都有明确内容，落地后能让"发现晚"这个问题不再重演。这就是复盘的价值：不是记录一次事故，而是让系统变得更能自我发现问题。

5.4 这个案例说明什么

前十四篇的排障能力，解决的是"发现问题后怎么查"。但这个案例的问题出在"太晚才发现"。再强的排障能力，也补偿不了监控告警设计的缺陷。所以稳定性是个闭环，缺一环都不行。

六、把整个专栏收敛成闭环

回顾整个专栏，它其实就是这个闭环的展开：

如果说前面十四篇教的是"怎么查",这一篇想说的是:最好的排障是不用排障。通过监控让问题可见、告警及时准确、复盘持续改进,让系统越来越少出问题、出了也能更快发现和恢复。

排障能力是底线,稳定性闭环才是目标。

七、稳定性闭环检查清单

监控
[ ] 核心服务有没有RED（请求量、错误率、延迟）
[ ] 关键资源有没有USE（利用率、饱和度、错误）
[ ] 前面各类故障有没有对应的监控指标

SLO
[ ] 核心链路有没有定义SLO和错误预算
[ ] SLO是否基于用户体验而非资源指标

告警
[ ] 是不是对用户症状告警，而不是对每个原因告警
[ ] 每条会叫醒人的告警是否可执行、有Runbook
[ ] 是否避免了告警疲劳（噪声告警降级或删除）
[ ] 正常等待、短暂抖动是否被排除，避免误告警

复盘
[ ] 复盘是否对事不对人
[ ] 是否有时间线、影响、根因、行动项
[ ] 行动项是否具体、有负责人、有截止时间
[ ] 行动项是否回流到监控、告警和系统设计
[ ] 是否区分了事实和推断

八、常见误区

误区1：监控指标堆一堆却没重点

用RED和USE抓重点，而不是什么都监控。

误区2：给资源利用率定SLO

SLO应基于用户体验，资源是USE的事。

误区3：对每个原因都告警

原因太多太抖，应对用户症状告警，原因放看板供排查。

误区4：告警越多越安全

告警疲劳会让人忽略真问题，少而准更安全。

误区5：复盘变成追责

会导致隐瞒，应对事不对人。

误区6：复盘行动项是"下次注意"

要具体、有负责人、有截止时间。

误区7：以为排障能力强就够了

发现晚、告警缺失，再强的排障也补偿不了。

误区8：复盘不区分事实和推断

和排障一样，不能把相关当因果、单指标定根因。

九、面试怎么说

60秒版本

我把稳定性看成一个闭环：监控让问题可见、告警及时叫醒人、排障定位恢复、复盘持续改进、改进回流到系统。监控我用RED看服务的请求量错误率延迟、USE看资源的利用率饱和度错误。SLO基于用户体验定，配错误预算来平衡稳定和迭代。告警的核心原则是对用户症状告警而不是对每个原因告警，避免告警疲劳，每条告警都要可执行。复盘对事不对人，要有时间线、根因和具体行动项，行动项回流到监控告警和设计。排障能力是底线，但最好的排障是通过这个闭环让系统少出问题、快发现。

3分钟场景版本

举个复盘的例子。一次核心接口变慢，靠用户反馈才发现，已经影响了二十分钟。复盘时我们对事不对人，先拉时间线：依赖什么时候开始变慢、什么时候用户反馈、什么时候介入恢复。根因不是排障不力，而是监控告警设计缺陷：我们只配了CPU内存这些资源告警，而依赖变慢不体现在本服务的资源上，核心接口的错误率和延迟只在看板里没配告警，所以资源没超阈值时没人被叫醒。这是典型的只有USE没有RED告警。行动项很具体：给核心接口配错误率和P99延迟的SLO告警、定义核心链路SLO和错误预算、把降级预案写成Runbook、排查其他服务是否也只有资源告警，每条都有负责人和截止时间。这次复盘的价值不是记录事故，而是让系统下次能自己更早发现同类问题。这也是我理解的稳定性：排障是底线，闭环是目标，最好的排障是不用排障。

十、延伸问答

1. RED和USE什么关系

RED从服务视角看用户体验，USE从资源视角看瓶颈，RED是症状USE常是原因，配合使用。

2. SLO该怎么定

基于用户体验的核心指标，如成功率和延迟，先给核心链路定，不要给什么都定。

3. 错误预算有什么用

把稳定和迭代的矛盾量化：预算足可以激进变更，预算紧就放慢做稳定性。

4. 为什么告警太多危险

告警疲劳会让人忽略所有告警包括真问题，少而准更安全。

5. 告症状还是告原因

对用户可感知的症状告警，原因太多太抖，放看板供排查。

6. 复盘为什么要对事不对人

追责会导致隐瞒，查不清根因，应聚焦系统怎么改进。

7. 复盘行动项怎么才有用

具体、有负责人、有截止时间，并回流到监控告警和系统设计。

8. 排障能力强还需要这些吗

需要。发现晚、告警缺失，再强的排障也补偿不了，稳定性是闭环。

小结

专栏结语

到这里，Kubernetes生产运维实战专栏的十六篇就全部写完了。从排障方法论、各类具体故障，到升级、监控和复盘，串起来是一句话：从现象到证据到根因，用方法而不是运气解决问题，再用闭环让问题越来越少。

希望这个专栏不只是一份排障手册，而是一种工作方式：遇到问题先分层、先取证、先区分事实和推断，再动手；解决之后补监控、补预防、做复盘。这样无论遇到没见过的新问题，也有一套稳定的方法去面对。

感谢一路看到这里。

参考资料

注：第9、10项为Google SRE Book的SLO与故障复盘章节，是SRE方法的权威来源；国内网络访问Google站点可能不稳定，可搜索对应中译或镜像阅读。