如何处理陌生系统的线上故障

TL;DR

常在河边走,哪有不湿鞋.线上故障,从一开始的设计、编码、测试种种环节,里面有很大一部分的精力都是要放在避免线上故障的.最终项目顺利上线、你好我好大家好.但是总会有一些预想之外的事情发生,这个时候,如何快速的定位问题,以最小的代价解决问题成了关键. 很多时候,对于自己设计、参与的系统这种排查问题还算简单.毕竟大多数时候,一说故障,大致出现的原因也就清晰了.但是有时不得不要处理一些陌生系统的故障.这个时候该怎么做?国庆前后先后处理了两次这类线上故障.记录下来.

范围

第一时间应该有相应的熟悉业务的同事明确故障的范围和可能的影响.确定涉及的模块和系统.确定各系统之间的交互关系.明确是那种原因导致的,是否最近有变更或者业务上发生了什么变化导致的.这些都明确以后,就能确定如下的内容了:

• 故障的范围
• 故障最终解决的标准
• 确定涉及的模块和功能
• 确认是性能还是业务的问题

根据故障的范围和影响的规模可以明确应该回退版保系统的稳定,还是为了要保业务,必须将故障解决调.

时间就是生命

这种情况下为了快速解决问题,就要求所有参与的人员能够高度集中,各项事项的推进都应该快速完成.减少故障时间,缩小故障范围是首要目标.软件开发中有句话,你要吃自己的狗屎……项目人员如果连自己的系统也不熟悉、指望一个外人来处理.不会有太好的结果的.日常中就应该熟悉自己的项目.这句话可能是废话,但是真正做到的人很少.不理所应当的事情真正的做了才是关键.

拒绝想当然

由于陌生的系统这个前提,在看代码排查问题的时候,最好做一个假设,就是每一行、每一个函数都可能是潜在有问题的.避免出现想当然的情况.另外对于项目成员告诉的情况也要保持怀疑的态度,通过代码求证.避免限入他们之前的思维陷阱里面.

这两次里面由于都是完全陌生的系统,都需要相关的研发人员介绍业务和实现.开始一听都听正常的……但是实际看代码的时候,一个是理解的偏差,另外一个就是熟悉程度导致更大的偏差.

多听项目人员的讲解,在代码中求证.不要陷入他们的思维逻辑中,毕竟是第三方,要能够跳出来看到问题.

技术过硬

这个没什么可说的,提的方案要能够快速落地,能够以最小的修改解决问题.不引入新的问题.重构、逻辑思考的能力很重要

总结

没有讲应该用什么样的功能来排查故障,更多讲了一些代码之外的事情.对于故障的解决,不仅仅是技术能力的问题,是一项对个人整体能力的考验.