复盘一次生产问题-低调大师

复盘一次生产问题

2019-03-25 716

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

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

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

1 事情经过

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

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

2 复盘

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

2.1 惯性思维

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

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

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

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

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

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

2.2 明确轻重缓急

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

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

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

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

3 总结

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

扩展spring cache 支持缓存多租户及其自动过期

spring cache 的概念 Spring 支持基于注释（annotation）的缓存（cache）技术，它本质上不是一个具体的缓存实现方案（例如 EHCache 或者 OSCache），而是一个对缓存使用的抽象，通过在既有代码中添加少量它定义的各种 annotation，即能够达到缓存方法的返回对象的效果。 @Cacheable 使用效果 ,更具 cacheName(value) + 请求入参（key）组成保存redis中的key public class PigxClientDetailsService extends JdbcClientDetailsService { @Cacheable(value = SecurityConstants.CLIENT_DETAILS_KEY, key = "#clientId") public ClientDetails loadClientByClientId(String clientId) { return super.loadClientByClientId(clientId); } }} 多租户下缓存问题分析默认情况 A...

2019-03-25

872

“一颗老鼠屎，坏了一锅粥，代码也是如此。” 在我们的项目中，也许在刚开始开发的时候，大家都会遵从一些规范来实施，但是当业务进度催的紧，或者人员变动，随着时间的迁移，项目不断的迭代以后，这时的代码可能就会出现一些“坏味道”了。 “坏味道”代码的出现可能不会影响我们的业务逻辑，大家自然也就比较容易忽视掉了，但是这如同是给我们代码埋下的定时炸弹，当爆炸的那天，需要我们背锅处理的时候，就会后悔当初为何不去解决这些问题呢？下面我们来看一下有哪些“坏味道”代码可以提前处理的吧。 1、多此一举型代码。 if(a > b){ return true;}else{returnfalse;} 也许一些经验不那么老道的开发会觉得这段代码没问题呀，可以跑得通，确实，在逻辑上是没问题的，但是有更简洁明了的写法为何不用？if() 里面的条件是boolean ，然后我们的返回值也是boolean，所以可以改写成 returna>b; 2、瞎命名型代码。 int a;Stringwzbt;// 文章标题Stringfastdi;//fastdi快递。。中西结合... 以上只是不规范命名的实例的冰山一...

2019-03-25

622

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。