1. 故障应急总纲：Kafka故障分级体系、应急响应流程、故障复盘机制
做Kafka运维这些年，我最大的感触就是——故障不是会不会来的问题，而是什么时候来、来了你能不能扛住的问题。你想想看，一个集群几百个Broker，每天处理几万亿条消息，不出点事才奇怪。关键不在于不出事，而在于出事之后，你有没有一套能打的标准动作。
这一章，我就把咱们的故障应急总纲摊开来讲。说白了，就是三件事：故障怎么分级、出事了怎么响应、事后怎么复盘。这三板斧练好了，Kafka集群再出幺蛾子，你心里也有底。
核心原则：故障应急不是靠个人英雄主义，而是靠流程和机制。我见过太多团队，出事了全去群里@运维，结果越搞越乱。标准化，才是救命的。
1.1 故障分级体系：别把小事当大事，也别把大事当小事
我见过最典型的场景：一个Topic的ISR收缩了，值班同学半夜三点把整个SRE群拉起来开会。结果呢？其实就是某个Broker网络抖动，5分钟后自己恢复了。这就是分级没做好。
我个人习惯把Kafka故障分成四个等级，从P0到P3。这个分级不是拍脑袋定的，而是根据影响范围、数据丢失风险、服务可用性三个维度来评估。
| 等级 | 定义 | 典型场景 | 响应要求 |
|---|---|---|---|
| P0 灾难级 | 集群整体不可用，或核心业务数据持续丢失 | 全部Broker宕机、Controller选举失败、磁盘阵列损坏、核心Topic数据永久丢失 | 立即响应，5分钟内拉起应急群，15分钟内启动应急预案 |
| P1 严重级 | 部分分区不可用，或非核心业务数据丢失 | 单个Broker宕机、ISR收缩到0、部分分区Leader不可用、磁盘使用率超95% | 30分钟内响应，1小时内恢复或降级 |
| P2 一般级 | 集群功能正常，但性能下降或存在潜在风险 | 消费者Lag持续增长、网络延迟升高、磁盘IO等待时间过长、Controller频繁切换 | 4小时内响应，24小时内处理 |
| P3 告警级 | 不影响业务，但需要关注或计划处理 | 单台机器CPU/内存使用率过高、日志中出现WARN、未配置监控的Topic | 下一个工作日处理，或纳入运维工单 |
我的经验：P0和P1的界定，关键看数据是否已经丢失。如果只是不可用但数据还在，算P1；如果数据已经丢了或者正在丢，直接上P0。我曾经遇到过磁盘坏道导致数据文件损坏，当时就是按P0处理的——宁可过度响应，也不能让数据丢了没人管。
1.2 应急响应流程：别慌，按步骤来
出故障的时候，最怕的就是一群人围在一起瞎猜。我自己的团队有一套五步应急法，说白了就是：发现→定级→隔离→恢复→验证。每一步都有明确的责任人和动作。
第一步：发现与告警
没有监控，应急就是空谈。我个人建议至少覆盖以下指标：
- 集群层面：Controller状态、Broker存活数、ISR变化率、未同步分区数
- Topic层面：消息生产/消费速率、Lag、分区Leader分布
- 系统层面：磁盘使用率、IO等待、网络吞吐、GC暂停时间
嗯，这里要注意——告警阈值别设得太敏感。我见过有人把磁盘使用率告警设在80%，结果天天半夜被叫起来，最后大家直接无视告警了。我个人习惯：WARN设在85%，CRITICAL设在92%，留出足够的缓冲时间。
第二步：评估与定级
收到告警后，值班同学需要在5分钟内回答三个问题：
- 影响范围多大？——是整个集群还是单个Broker？是核心Topic还是边缘Topic？
- 数据安全吗？——有没有数据丢失？有没有数据不一致？
- 业务感知到了吗？——生产端报错了吗？消费端卡住了吗？
根据这三个问题的答案，对照上面的分级表，快速定级。定级之后，立刻在应急群里@对应的人，不要等。
第三步：隔离与止损
这一步的核心是先止血，再治病。不要一上来就想着怎么修，先保证业务不继续受损。
- 如果是Broker宕机，先确认Leader切换是否正常，如果切换失败，手动触发Preferred Leader Election
- 如果是磁盘满了，先清理日志或迁移数据，别急着扩容
- 如果是网络分区，先隔离异常节点，让集群恢复稳定
⚠️ 避坑指南：我曾经有一次，Broker磁盘满了，我直接上去删日志文件。结果删完之后，Kafka报错说文件不存在，整个分区挂了。后来才知道，Kafka的日志删除有自己的一套机制，不能手动乱删。正确的做法是：先调整保留策略，或者用kafka-log-dirs命令查看哪些分区占空间大，再针对性处理。
第四步：恢复与验证
止损之后，才是真正的恢复操作。恢复完成后，必须做功能验证：
- 生产端：用测试Producer发送消息，确认能正常写入
- 消费端：检查Consumer Lag是否在下降，确认消费正常
- 集群状态：用
kafka-broker-api-versions.sh和kafka-topics.sh --describe确认所有Broker和分区状态正常
第五步：持续监控
恢复之后别急着走。至少观察30分钟，确认指标稳定。我个人习惯在恢复后把监控告警阈值临时调低20%，这样能更早发现复发迹象。
1.3 故障复盘机制：别让同一个坑绊倒两次
故障复盘，说白了就是把事故变成经验。我见过很多团队，故障恢复了就散了，下次同样的故障再来一遍。这不行。
我自己的复盘流程分三步：
第一步：时间线还原
把故障从发生到恢复的整个过程，按时间线列出来。每个时间点要记录：发生了什么、谁做了什么、结果如何。这个时间线要精确到秒，因为很多时候，几秒钟的延迟就决定了故障的走向。
工具推荐：我个人习惯用Mermaid时序图或者在线时间线工具来画。不要用Excel，太慢了。复盘的时候，把时间线投到屏幕上，大家一起看，哪里慢了、哪里做错了，一目了然。
第二步：根因分析
不要只停留在表面原因。比如“Broker宕机了”，这不是根因。根因是“为什么Broker会宕机”？是内存泄漏？是磁盘故障？还是配置错误？
我推荐用5 Whys分析法。举个例子：
- 问题：消费者Lag持续增长
- Why 1：因为消费速度跟不上生产速度
- Why 2：因为消费者线程数不够
- Why 3：因为消费者配置的
max.poll.records太大，导致处理时间过长 - Why 4：因为上线前没有做压测，不知道这个配置不合理
- 根因：缺乏上线前的性能压测流程
你看，追到第四层，才找到真正需要改进的地方。
第三步：改进项跟踪
复盘不能只停留在文档里。每个复盘会必须产出3-5个可执行的改进项，并且指定负责人和截止日期。我自己的团队会用Jira或者飞书文档来跟踪，每周检查一次进度。
| 改进项 | 负责人 | 截止日期 | 状态 |
|---|---|---|---|
| 增加磁盘使用率告警到监控系统 | 张三 | 2024-03-10 | 已完成 |
| 优化消费者max.poll.records配置 | 李四 | 2024-03-15 | 进行中 |
| 编写Broker宕机应急预案文档 | 王五 | 2024-03-20 | 未开始 |
| 上线前增加压测流程 | 赵六 | 2024-04-01 | 未开始 |
我的习惯：复盘会不要开成批斗会。我见过有人把复盘会开成了“谁的责任大会”，结果大家都不敢说话了。复盘的核心是找系统的问题，不是找人的问题。记住：故障是系统的bug，不是人的bug。
1.4 总结：应急总纲的核心就三句话
好了，这一章的内容差不多就这些。我再用三句话总结一下：
- 分级要清晰：P0/P1/P2/P3，每个级别对应不同的响应力度，别把小事搞大，也别把大事拖小
- 流程要标准化：发现→定级→隔离→恢复→验证，每一步都有标准动作，别靠临场发挥
- 复盘要落地：时间线还原→根因分析→改进项跟踪，确保每个故障都变成团队的资产
这套总纲，是我在多个Kafka集群上摸爬滚打总结出来的。你拿去用，根据自己团队的实际情况调整。记住：没有完美的应急方案，只有不断迭代的应急方案。