复盘一次生产问题

夜空

有整整 10 天木有更文了，这段时间确实比较忙。

有加我微信的朋友知道我上周末出去春游了，部门组织去了趟外伶仃岛，环境挺不错的，这段时间去的人也比较少，值得去玩。

今天讲讲上周末一次生产问题的复盘。

1 事情经过

周日中午从外伶仃岛回来就直奔公司，因为生产出了些问题。问题是这样的：HBase 的一些节点挂了，导致一些数据丢失。丢失数据的客户来授信或者借款，都会卡件。在确定数据短时间没法恢复时，就决定从系统的层面去解决这个问题。这时我咨询了 2 位老员工，这些数据虽然是规则的入参数据，但是规则可能没用这些数据去做决策，能否先跟规则的同事确认这些数据是否有使用，如果没有，就可以先暂停这些数据的获取，减少影响面，再来细致的分析数据。得到的回复都是这些数据很早前就上线了，肯定有在用。这时只能分析系统数据，恰巧丢失的数据是原始数据，不是加工数据，原始数据不做规则入参，所以就简单的修改了获取数据源的代码。

在测试同事进行简单回归测试时，发现了一个奇怪的现象，旧数据被覆盖，检查了各种 SQL 配置，没有发现问题，因为以前也有很多模型和规则入参都是这样配置的，接着就陷入历史问题的 debug 中，还是没有发现问题所在，到了晚上快 11 点，有同事联系了规则同事，才发现卡件的数据他们并没有在借款的规则中使用，也就是可以通过关闭获取数据源来解决借款卡件问题，作罢，先解决数据卡件问题，后面再细致分析历史问题，搞完回到家 1 点半。

2 复盘

这周也是持续在跟进这个生产历史问题，最终发现是系统框架的 Bug，在数据处理的时候，私有的数据被公共的数据覆盖导致的。这段时间也一直在思考这次生产问题，从马后炮来说，其实可以很快就把卡件问题解决，但是其中却经历了整整 10 个小时的折腾，肯定是有原因的，通过这篇文章复盘一下。

2.1 惯性思维

从维基百科上看这个定义：惯性思维（Inertial thinking）指人习惯性地因循以前的思路思考问题，仿佛物体运动的惯性。惯性思维常会造成思考事情时有些盲点，且缺少创新或改变的可能性。

上面的过程发现了 2 处惯性思维。

1. 一处是同事们因为经历了整个系统的开发过程，所以直接否定了确认规则是否有在使用丢失的数据的方案；而我因为没有经历前程的开发，算是一个旁观者去看待这个问题，所以才有这个想法先确定数据有没在使用。这里的惯性思维是：因为数据很早前就上线了，当时就在使用，所以现在数据还在使用。
2. 另外一处则是我对待生产出现的历史问题，一直在通过检查业务代码和 SQL 配置去尝试解决这个问题，因为以前也是这样使用的，以前没出现问题。这里的惯性思维是：以前这样使用没问题，这一次有问题应该是业务代码或者 SQL 配置有问题。

这里都是因为以前做过某些事情是没错的，导致在遇到相同问题的时候会去把以前没错的做法当成是正确答案，而其实没错不等于正确，以前没错的做法只是参考答案，不是正确答案，这里就涉及到思维问题，如果当成参考答案，那么思维是发散的，这个参考答案觉得不对则可以再找其他参考答案或者去发现其他解决方案；如果当成正确答案，那么思维是僵化的，会把这个正确答案一直往里套，就会走不出来。

理解了上面这点，那有什么可以去摆脱惯性思维呢？下面这两点不确定是不是对的，但是是我通过思考，决定接下来要尝试去执行的。

1. 告诉自己，这是惯性思维。《正念的奇迹》书中讲过洗碗、吃橘子的案例，都是去感受洗碗、去感受吃橘子的感觉。有健身的朋友也会知道，健身肌肉酸痛的时候，去感受那个感觉。让自己去清晰的正面对待惯性思维，而不是去埋怨自己怎么又陷入惯性思维，正面对待它，然后告诉自己，这是惯性思维，这个参考答案是错的，找另一个答案。
2. 空杯状态。如果没有好的参考答案，放空自己，根据眼前看到的事情，按正常的解决思路去解决。

2.2 明确轻重缓急

当时最紧要的事情是解决生产卡件的问题。在解决的过程中，却发现了一个历史遗留的 Bug，这时卡件的问题代码已经验证通过了，应该直接就上生产，解决当前的燃眉之急，再解决历史遗留的 Bug。现实是一直去把心思放到历史遗留的 Bug 中，导致延迟了很久才把 hotfix 上线。

明确轻重缓急很重要，不仅在特殊紧急的情况，在平时工作中也是一样重要，每天要做的事情很多，要学会先做什么，后做什么。解决这个问题，可以采用四象限工作法，什么是四象限工作法？看下图。

四象限工作法

<span style="font-size:0.8em;">（注：这里的象限划分和数学上的有些差别，数学上三、四象限和图上是相反的，这里是按照事情的重要紧急程度排序）</span>

每件工作用 2 个维度去衡量，分别是重要性和紧急度。按照这 2 个维度进行分析后落位到各个象限，然后根据象限的顺序去执行，比如上面遇到的卡件以及历史 Bug 问题，卡件这个是放在一象限，历史 Bug 是放在二象限，所以应该分开解决，解决好了卡件问题之后，再去解决历史 Bug。当时有这个意识的话，在验证卡件 hotfix 代码没问题后，就可以直接上线了，后续再分析历史 Bug。

3 总结

经过这次事情，让自己静下心来思考，思考哪些地方做错了，思考犯错的本质，思考如何去避免再犯同样的错，思考怎么去用实际的行动改进。犯错不可怕，可怕的是一错再错。嗯，这一刻，我又成长了。希望我的复盘也能给你一些启示。

推荐阅读：

行为型模式：观察者模式
行为型模式：迭代器模式
行为型模式：策略模式

欢迎关注公众号：LieBrother，一起交流进步。