目录
-
故障描述
-
处理经过
-
原因分析
-
故障总结
中午11:40
?
吃饭完回来
故障描述?
kafka 某topic 增加分区致业务数据掉坑
处理经过
| 时间 | 处理同学 | 动作 |
| 11:40 | 小O | 群里问小D kafka的topic能不能扩分区 |
| 11:41 | 小D | 回复yes，业务不影响 |
| 11:50 | 小O | 将某topic分区由4个改为8个 |
| 11:51 | 小O | 开开心心吃饭去了，吃完回来就午睡了 |
| 11:55? | 小D | 发现有问题，但是小O午睡了 |
| 14:00 - 16:00 | 小D小O | 重启服务 |
原因分析
原因就是傻白甜：
新分区扩容后，consumer并不能自动的获取新的分区数。而producer可以自动获取新的分区。于是数据被写入了新的分区，但是没人消费。
本来重启服务就可以解决问题，但是往往祸不单行，屋漏偏逢连夜雨。服务重启过程中遭遇其它问题，故障时间加长了2小时。
充分说明了软件开发是魔幻的，如果一个程序能够正常运行，千万不要动它。
故障总结
很小的一个事故，但是暴露了很多问题：
-
小O在吃饭前进行操作，且没有持续观察业务指标
-
小D虽然及时发现了问题，但是没有持续跟踪小O来解决
教训：
-
站在运维的角度，不要相信研发的鬼话。
-
站在研发的角度，不要对自己的系统过于自信，即使很细小的变更，往往藏着安全风险，不能掉以轻心
记录那些年我们一起处理过的故障～
微信公众号：小O小D
?