生产问题复盘报告.pdfVIP

生产问题复盘报告

1事情经过

周日中午从外伶仃岛回来就直奔公司，因为生产出了些问题。问

题是这样的：HBase的一些节点挂了，导致一些数据丢失。丢失数据

的客户来授信或者借款，都会卡件。在确定数据短时间没法恢复时，

就决定从系统的层面去解决这个问题。这时我咨询了2位老员工，

这些数据虽然是规则的入参数据，但是规则可能没用这些数据去做决

策，能否先跟规则的同事确认这些数据是否有使用，如果没有，就可

以先暂停这些数据的获取，减少影响面，再来细致的分析数据。得到

的回复都是这些数据很早前就上线了，肯定有在用。这时只能分析系

统数据，恰巧丢失的数据是原始数据，不是加工数据，原始数据不做

规则入参，所以就简单的修改了获取数据源的代码。

在测试同事进行简单回归测试时，发现了一个奇怪的现象，旧数

据被覆盖，检查了各种SQL配置，没有发现问题，因为以前也有很

多模型和规则入参都是这样配置的，接着就陷入历史问题的debug

中，还是没有发现问题所在，到了晚上快11点，有同事联系了规则

同事，才发现卡件的数据他们并没有在借款的规则中使用，也就是可

以通过关闭获取数据源来解决借款卡件问题，作罢，先解决数据卡件

问题，后面再细致分析历史问题，搞完回到家1点半。

2复盘

这周也是持续在跟进这个生产历史问题，最终发现是系统框架的

Bug，在数据处理的时候，私有的数据被公共的数据覆盖导致的。这

段时间也一直在思考这次生产问题，从马后炮来说，其实可以很快就

把卡件问题解决，但是其中却经历了整整10个小时的折腾，肯定是

有原因的，通过这篇文章复盘一下。

2.1惯性思维

从维基百科上看这个定义：惯性思维（Inertialthinking）指

人习惯性地因循以前的思路思考问题，仿佛物体运动的惯性。惯性思

维常会造成思考事情时有些盲点，且缺少创新或改变的可能性。

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

一处是同事们因为经历了整个系统的开发过程，所以直接否定了

确认规则是否有在使用丢失的数据的方案；而我因为没有经历前程的

开发，算是一个旁观者去看待这个问题，所以才有这个想法先确定数

据有没在使用。这里的惯性思维是：因为数据很早前就上线了，当时

就在使用，所以现在数据还在使用。

另外一处则是我对待生产出现的历史问题，一直在通过检查业务

代码和SQL配置去尝试解决这个问题，因为以前也是这样使用的，

以前没出现问题。这里的惯性思维是：以前这样使用没问题，这一次

有问题应该是业务代码或者SQL配置有问题。

这里都是因为以前做过某些事情是没错的，导致在遇到相同问题

的时候会去把以前没错的做法当成是正确答案，而其实没错不等于正

确，以前没错的做法只是参考答案，不是正确答案，这里就涉及到思

维问题，如果当成参考答案，那么思维是发散的，这个参考答案觉得

不对则可以再找其他参考答案或者去发现其他解决方案；如果当成正

确答案，那么思维是僵化的，会把这个正确答案一直往里套，就会走

不出来。

理解了上面这点，那有什么可以去摆脱惯性思维呢？下面这两点

不确定是不是对的，但是是我通过思考，决定接下来要尝试去执行的。

告诉自己，这是惯性思维。《正念的奇迹》书中讲过洗碗、吃橘

子的案例，都是去感受洗碗、去感受吃橘子的感觉。有健身的朋友也

会知道，健身肌肉酸痛的时候，去感受那个感觉。让自己去清晰的正

面对待惯性思维，而不是去埋怨自己怎么又陷入惯性思维，正面对待

它，然后告诉自己，这是惯性思维，这个参考答案是错的，找另一个

答案。

空杯状态。如果没有好的参考答案，放空自己，根据眼前看到的

事情，按正常的解决思路去解决。

2.2明确轻重缓急

当时最紧要的事情是解决生产卡件的问题。在解决的过程中，却

发现了一个历史遗留的Bug，这时卡件的问题代码已经验证通过了，

应该直接就上生产，解决当前的燃眉之急，再解决历史遗留的Bug。

现实是一直去把心思放到历史遗留的Bug中，导致延迟了很久才把

hotfix上线。

明确轻重缓急很重要，不仅在特殊紧急的情况，在平时工作中也

是一样重要，每天要做的事情很多，要学会先做什么，后做什么。解

决这个问题，可以采用四象限工作法，什么是四象限工