文档章节

复盘一次生产问题

o
 osc_a22drz29
发布于 2019/03/25 09:18
字数 1916
阅读 0
收藏 0

精选30+云产品,助力企业轻松上云!>>>

夜空

有整整 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,一起交流进步。

o
粉丝 0
博文 500
码字总数 0
作品 0
私信 提问
加载中
请先登录后再评论。
复盘一次生产问题

有整整 10 天木有更文了,这段时间确实比较忙。 有加我微信的朋友知道我上周末出去春游了,部门组织去了趟外伶仃岛,环境挺不错的,这段时间去的人也比较少,值得去玩。 今天讲讲上周末一次生...

LieBrother
2019/03/25
442
0
论“复盘”的重要性

昨天一场估计不足的强对流天气,让值班员们手忙脚乱,一会儿发预警、一会儿发天气快报、一会儿又发雨量统计。刚加入值班的年轻人面对这种天气状况更是不知如何应对,还好有许多有经验的预报首...

amuo
06/19
0
0
掘金者说-第11期-硬核之复盘管理

第一季-思想篇 [ ] 第1期 个人性格 [ ] 第2期 求知欲 [ ] 第3期 人和领导力对拓展性的影响 [ ] 第4期 [个人的经验](https://juejin.im/post/5e04...

掘金者说
02/27
8
0
故障复盘

故障的定义有很多种,一般都是根据业务来进行定义故障等级,对于大大小小的故障,你会采取什么样的态度? 是让故障飞一会儿呢?还是让故障再浪一浪。。。 在生产环境中,一般定义为工单,事件...

SRE运维实践
2018/05/08
0
0
由Redis的hGetAll函数所引发的一次服务宕机事件

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累。这篇博客,算作一个复盘和记录吧。。。 先来看看Redis的缓存淘汰算法思维导图: 说明:当实际占用的内存超过Redis配置的max...

osc_lt3ocv4d
2018/12/21
4
0

没有更多内容

加载失败,请刷新页面

加载更多

平时使用的Lszrz到底是什么协议?说说Xmodem/Ymodem/Zmodem

XMODEM, YMODEM, and ZMODEM 由于平时使用rz/sz较多,r/s好理解,一个send一个receive。但是由不太清楚z是什么意思,故有此文。 sx/rx, sb/rb (b=batch)和sz/rz分别实现了xmodem,ymodem和z...

独钓渔
今天
17
0
真正的强智能时代已经到来。道翰天琼认知智能机器人平台API大脑。

最近,我常说人工智能的寒冬快要来了,提醒业界要做好思想准备,但同时我也说:冬天来了,春天就不会远了…… 2019年6月我写了篇文章《深度学习的问题究竟在哪?》,说到深度学习的一个主要问...

jackli2020
今天
24
0
什么是控制型人格,控制型人格的筛查测试

一、 什么是控制性人格 拥有控制型人格的人,他们会尽力的隐藏自己的意图,但是又会使用很微妙的方式来利用周围人的弱点,进而占取便宜时,使他们能够得到自己想要的东西。这类人的控制欲非常...

蛤蟆丸子
今天
14
0
【Spring】Spring AOP 代理对象生成逻辑源码分析

1. spring aop案例(POJO注入) 1.0 被代理接口 TargetInterface /** * 被代理的接口 * @author Yang ZhiWei */public interface TargetInterface { void show(); String show......

ZeroneLove
今天
36
0
聊聊dubbo-go的gracefulShutdownFilter

序 本文主要研究一下dubbo-go的gracefulShutdownFilter gracefulShutdownFilter dubbo-go-v1.4.2/filter/filter_impl/graceful_shutdown_filter.go type gracefulShutdownFilter struct {......

go4it
今天
30
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部