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、P99RED回答的是用户体验好不好。服务出问题通常先在错误率或延迟上体现。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 告警疲劳是真正的危险告警太多比太少更危险。当一个人每天收到几百条告警他会开始忽略所有告警包括真正重要的那条。这就是告警疲劳。前面每篇都提到告警不能只匹配某个状态比如不能只匹配phasePending、不能一次重启就告警。原因就在这噪声告警会淹没真问题。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、改探针、调QoSRunbook把这次的处理过程沉淀成Runbook下次更快行动项如果只是下次注意等于没有。要具体到给X服务配PDB负责人A,本周内。4.4 区分事实和推断复盘里要像排障一样区分已确认的事实和推断。前面反复强调的不把相关性写成因果“单一指标不能定根因”,在复盘里同样适用。一份好的复盘经得起追问:每个结论背后的证据是什么。五、C级生产化重建案例一次告警太晚的复盘5.1 先说明哪些是真的哪些是重建的下面不是作者声称亲历的具体事故而是根据监控告警机制和复盘方法构造的生产化重建用于演示复盘怎么做。内容证据属性RED、USE、SLO、错误预算和告警降噪的方法SRE通行方法与Kubernetes监控机制一次因告警太晚导致故障扩大的复盘机制一致的重建场景时间线、影响描述、指标数值为讲解构造的说明性信息只监控资源没监控用户症状导致发现晚模拟根因不是某次事故原始记录所有内容按合理机制编排但不是某次真实事故的原始记录读者不能把下面的时间或数值引用为真实数据。5.2 复盘一次发现太晚的服务降级故障时间线说明性重建相对时间事件T00某依赖开始变慢核心接口延迟和错误率缓慢上升T15分用户开始反馈变慢客服转告T20分值班才介入此时错误已持续20分钟T35分定位到依赖问题并降级恢复影响基于事实不夸大核心接口一段时间内成功率下降、延迟升高具体数值以监控为准这里不编造精确的用户数和金额。为什么发现晚根因分析监控体系里只配了USE视角的资源告警CPU、内存核心接口的错误率和延迟这种RED症状指标虽然有仪表盘但没有配成告警。所以资源没到阈值时没有任何告警直到用户反馈才发现。只监控了资源利用率没对用户症状告警 依赖变慢不体现在本服务的CPU内存上 RED的错误率延迟只在看板里没配告警 于是靠用户反馈发现晚了约20分钟 告警设计缺陷导致发现晚放大了影响这不是排障能力问题是监控告警设计问题。5.3 行动项回流到闭环行动项类型说明给核心接口的错误率和P99延迟配SLO告警告警症状告警而非只有资源告警定义核心链路SLO和错误预算SLO让多好算好可量化依赖变慢时本服务的降级预案写成RunbookRunbook下次更快恢复复盘同类服务是否也只有资源告警监控举一反三每条都有明确内容落地后能让发现晚这个问题不再重演。这就是复盘的价值不是记录一次事故而是让系统变得更能自我发现问题。5.4 这个案例说明什么前十四篇的排障能力解决的是发现问题后怎么查。但这个案例的问题出在太晚才发现。再强的排障能力也补偿不了监控告警设计的缺陷。所以稳定性是个闭环缺一环都不行。六、把整个专栏收敛成闭环回顾整个专栏它其实就是这个闭环的展开闭环环节对应专栏内容排障方法第01篇方法论、第02篇kubectl工具箱具体排障第03到13篇各类故障升级与变更第14篇集群升级监控告警复盘本篇证据原则贯穿全专栏区分事实与推断、单变量验证、不把相关当因果如果说前面十四篇教的是怎么查,这一篇想说的是:最好的排障是不用排障。通过监控让问题可见、告警及时准确、复盘持续改进,让系统越来越少出问题、出了也能更快发现和恢复。排障能力是底线,稳定性闭环才是目标。七、稳定性闭环检查清单监控 [ ] 核心服务有没有RED请求量、错误率、延迟 [ ] 关键资源有没有USE利用率、饱和度、错误 [ ] 前面各类故障有没有对应的监控指标 SLO [ ] 核心链路有没有定义SLO和错误预算 [ ] SLO是否基于用户体验而非资源指标 告警 [ ] 是不是对用户症状告警而不是对每个原因告警 [ ] 每条会叫醒人的告警是否可执行、有Runbook [ ] 是否避免了告警疲劳噪声告警降级或删除 [ ] 正常等待、短暂抖动是否被排除避免误告警 复盘 [ ] 复盘是否对事不对人 [ ] 是否有时间线、影响、根因、行动项 [ ] 行动项是否具体、有负责人、有截止时间 [ ] 行动项是否回流到监控、告警和系统设计 [ ] 是否区分了事实和推断八、常见误区误区1监控指标堆一堆却没重点用RED和USE抓重点而不是什么都监控。误区2给资源利用率定SLOSLO应基于用户体验资源是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. 排障能力强还需要这些吗需要。发现晚、告警缺失再强的排障也补偿不了稳定性是闭环。小结稳定性是闭环监控、告警、排障、复盘、改进回流缺一不可。RED看服务的请求量错误率延迟USE看资源的利用率饱和度错误。SLO基于用户体验定错误预算平衡稳定和迭代。告警对用户症状而非每个原因避免告警疲劳每条要可执行。复盘对事不对人要有时间线、根因和具体行动项。行动项回流到监控、告警和系统设计才让故障变成改进。复盘和排障一样要区分事实和推断。排障能力是底线闭环是目标最好的排障是不用排障。专栏结语到这里Kubernetes生产运维实战专栏的十六篇就全部写完了。从排障方法论、各类具体故障到升级、监控和复盘串起来是一句话从现象到证据到根因用方法而不是运气解决问题再用闭环让问题越来越少。希望这个专栏不只是一份排障手册而是一种工作方式遇到问题先分层、先取证、先区分事实和推断再动手解决之后补监控、补预防、做复盘。这样无论遇到没见过的新问题也有一套稳定的方法去面对。感谢一路看到这里。参考资料Kubernetes官方文档Monitoring in KubernetesKubernetes官方文档Metrics For Kubernetes System ComponentsKubernetes官方文档Logging ArchitectureKubernetes官方文档Resource metrics pipelineKubernetes官方文档ObservabilityPrometheus官方文档Alerting RulesPrometheus官方文档AlertmanagerGrafana LabsThe RED MethodGoogle SRE Book: Service Level ObjectivesGoogle SRE Book: Postmortem Culture注第9、10项为Google SRE Book的SLO与故障复盘章节是SRE方法的权威来源国内网络访问Google站点可能不稳定可搜索对应中译或镜像阅读。 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、P99RED回答的是用户体验好不好。服务出问题通常先在错误率或延迟上体现。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 告警疲劳是真正的危险告警太多比太少更危险。当一个人每天收到几百条告警他会开始忽略所有告警包括真正重要的那条。这就是告警疲劳。前面每篇都提到告警不能只匹配某个状态比如不能只匹配phasePending、不能一次重启就告警。原因就在这噪声告警会淹没真问题。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、改探针、调QoSRunbook把这次的处理过程沉淀成Runbook下次更快行动项如果只是下次注意等于没有。要具体到给X服务配PDB负责人A,本周内。4.4 区分事实和推断复盘里要像排障一样区分已确认的事实和推断。前面反复强调的不把相关性写成因果“单一指标不能定根因”,在复盘里同样适用。一份好的复盘经得起追问:每个结论背后的证据是什么。五、C级生产化重建案例一次告警太晚的复盘5.1 先说明哪些是真的哪些是重建的下面不是作者声称亲历的具体事故而是根据监控告警机制和复盘方法构造的生产化重建用于演示复盘怎么做。内容证据属性RED、USE、SLO、错误预算和告警降噪的方法SRE通行方法与Kubernetes监控机制一次因告警太晚导致故障扩大的复盘机制一致的重建场景时间线、影响描述、指标数值为讲解构造的说明性信息只监控资源没监控用户症状导致发现晚模拟根因不是某次事故原始记录所有内容按合理机制编排但不是某次真实事故的原始记录读者不能把下面的时间或数值引用为真实数据。5.2 复盘一次发现太晚的服务降级故障时间线说明性重建相对时间事件T00某依赖开始变慢核心接口延迟和错误率缓慢上升T15分用户开始反馈变慢客服转告T20分值班才介入此时错误已持续20分钟T35分定位到依赖问题并降级恢复影响基于事实不夸大核心接口一段时间内成功率下降、延迟升高具体数值以监控为准这里不编造精确的用户数和金额。为什么发现晚根因分析监控体系里只配了USE视角的资源告警CPU、内存核心接口的错误率和延迟这种RED症状指标虽然有仪表盘但没有配成告警。所以资源没到阈值时没有任何告警直到用户反馈才发现。只监控了资源利用率没对用户症状告警 依赖变慢不体现在本服务的CPU内存上 RED的错误率延迟只在看板里没配告警 于是靠用户反馈发现晚了约20分钟 告警设计缺陷导致发现晚放大了影响这不是排障能力问题是监控告警设计问题。5.3 行动项回流到闭环行动项类型说明给核心接口的错误率和P99延迟配SLO告警告警症状告警而非只有资源告警定义核心链路SLO和错误预算SLO让多好算好可量化依赖变慢时本服务的降级预案写成RunbookRunbook下次更快恢复复盘同类服务是否也只有资源告警监控举一反三每条都有明确内容落地后能让发现晚这个问题不再重演。这就是复盘的价值不是记录一次事故而是让系统变得更能自我发现问题。5.4 这个案例说明什么前十四篇的排障能力解决的是发现问题后怎么查。但这个案例的问题出在太晚才发现。再强的排障能力也补偿不了监控告警设计的缺陷。所以稳定性是个闭环缺一环都不行。六、把整个专栏收敛成闭环回顾整个专栏它其实就是这个闭环的展开闭环环节对应专栏内容排障方法第01篇方法论、第02篇kubectl工具箱具体排障第03到13篇各类故障升级与变更第14篇集群升级监控告警复盘本篇证据原则贯穿全专栏区分事实与推断、单变量验证、不把相关当因果如果说前面十四篇教的是怎么查,这一篇想说的是:最好的排障是不用排障。通过监控让问题可见、告警及时准确、复盘持续改进,让系统越来越少出问题、出了也能更快发现和恢复。排障能力是底线,稳定性闭环才是目标。七、稳定性闭环检查清单监控 [ ] 核心服务有没有RED请求量、错误率、延迟 [ ] 关键资源有没有USE利用率、饱和度、错误 [ ] 前面各类故障有没有对应的监控指标 SLO [ ] 核心链路有没有定义SLO和错误预算 [ ] SLO是否基于用户体验而非资源指标 告警 [ ] 是不是对用户症状告警而不是对每个原因告警 [ ] 每条会叫醒人的告警是否可执行、有Runbook [ ] 是否避免了告警疲劳噪声告警降级或删除 [ ] 正常等待、短暂抖动是否被排除避免误告警 复盘 [ ] 复盘是否对事不对人 [ ] 是否有时间线、影响、根因、行动项 [ ] 行动项是否具体、有负责人、有截止时间 [ ] 行动项是否回流到监控、告警和系统设计 [ ] 是否区分了事实和推断八、常见误区误区1监控指标堆一堆却没重点用RED和USE抓重点而不是什么都监控。误区2给资源利用率定SLOSLO应基于用户体验资源是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. 排障能力强还需要这些吗需要。发现晚、告警缺失再强的排障也补偿不了稳定性是闭环。小结稳定性是闭环监控、告警、排障、复盘、改进回流缺一不可。RED看服务的请求量错误率延迟USE看资源的利用率饱和度错误。SLO基于用户体验定错误预算平衡稳定和迭代。告警对用户症状而非每个原因避免告警疲劳每条要可执行。复盘对事不对人要有时间线、根因和具体行动项。行动项回流到监控、告警和系统设计才让故障变成改进。复盘和排障一样要区分事实和推断。排障能力是底线闭环是目标最好的排障是不用排障。专栏结语到这里Kubernetes生产运维实战专栏的十六篇就全部写完了。从排障方法论、各类具体故障到升级、监控和复盘串起来是一句话从现象到证据到根因用方法而不是运气解决问题再用闭环让问题越来越少。希望这个专栏不只是一份排障手册而是一种工作方式遇到问题先分层、先取证、先区分事实和推断再动手解决之后补监控、补预防、做复盘。这样无论遇到没见过的新问题也有一套稳定的方法去面对。感谢一路看到这里。参考资料Kubernetes官方文档Monitoring in KubernetesKubernetes官方文档Metrics For Kubernetes System ComponentsKubernetes官方文档Logging ArchitectureKubernetes官方文档Resource metrics pipelineKubernetes官方文档ObservabilityPrometheus官方文档Alerting RulesPrometheus官方文档AlertmanagerGrafana LabsThe RED MethodGoogle SRE Book: Service Level ObjectivesGoogle SRE Book: Postmortem Culture注第9、10项为Google SRE Book的SLO与故障复盘章节是SRE方法的权威来源国内网络访问Google站点可能不稳定可搜索对应中译或镜像阅读。