背景

线上故障是技术成长中不可避免的一部分,我们从中能够吸取宝贵的教训并变得越来越有经验。然而,并非每个团队或技术同学都能以合理和科学的方式处理故障。基于日常实际工作经验和个人心得,我整理了一份团队遇到故障问题或者疑似问题快速排查的三字经清单及正确✅案例和错误❌案例。这份清单将帮助你在遇到问题时进行快速排查,无需担心在高压环境下忙中出错,遗漏关键步骤环节掌握这份清单,你将能够更好地掌控现场,从而避免因疏忽而造成的损失。让我们面对故障时保持冷静,有条不紊地进行排查,不断提升我们的技术水平和问题解决能力。

三字经

备注:下面不是严格的顺序,需要根据实际情况调整可多路并行,比如清楚问题大概环节,先止血。如不清楚,报备分工,初步定位大概环节再快速止血。

在故障处理过程中采取的所有手段和行动,一切以恢复业务为最高优先级,恢复现场快速止血方案高于寻找故障原因等其他所有环节。

别慌张,先报备

先组会,明分工

描现象,非结论

先止血,再定位

看监控,看日志

找规律、先试验

看输入,看输出

留现场,时反馈

别慌张,先报备

1、在处理紧急事件(线上问题或者疑似问题)时,先把问题上报组内

2、充分发挥团队的力量,通过集思广益的方式,可以更加快速地找到问题的根源,并采取相应的措施进行解决。

✅正例:

❌反例:

先组会,明分工

1、故障指挥官 (问题发现人或者小组长/架构),有权召集相应的业务、产品、开发或其它必要资源,快速组织会议。

2、故障指挥官明确各角色职责,分工明确,这样可以有效地提高故障处理的效率。

✅正例:

❌反例:

描现象,非结论

1*、让问题发现者描述发现的现象(时间、影响范围、影响程度),而不是判断的结论(因为判断的结论可能是错误的,这样会误导大家排查方向)*

2、请大家避免在描述问题现象时,过多地表达自己的判断和看法,因为这可能会影响到大家的排查方向。我们需要保持客观和理性的态度,以便更好地分析问题。

3、同时,也请大家注意自己的思维方式,避免让自己的大脑成为别人思想的跑马场。在讨论问题时,我们可以提出自己的观点和建议,但请确保这些观点是基于事实和证据的,而不是个人的主观臆断。

✅正例:

假设在一个软件开发团队中,当遇到一个性能问题时,问题发现者描述了如下现象:

在这个例子中,问题发现者提供了具体的现象信息,使得团队成员能够迅速定位问题所在,并采取相应的措施进行优化和修复。

❌反例:

假设在一个软件开发团队中,当遇到一个性能问题时,问题发现者仅给出了自己的判断结论:

在这个例子中,问题发现者没有提供具体的现象信息,而是仅仅给出了自己的判断结论。这可能会导致团队成员在排查问题时产生困惑, 无法准确地找到问题的根源。同时,由于判断结论可能是错误的,这也可能误导团队成员,导致他们在排查问题上浪费时间和精力。

先止血,再定位

1、在故障处理过程中采取的所有手段和行动,一切以恢复业务为最高优先级,恢复现场止血方案高于寻找故障原因

2、快速止血:我们可以采用开关技术、回滚技术等手段,迅速恢复系统功能,避免服务中断。

3、日常应急预案:请大家提前制定好应急预案,包括关键业务的容灾策略、故障切换流程等,以便在发生故障时能够迅速启动预案,降低故障对业务的影响。

4、请大家在故障处理过程中,不要过于关注故障原因的寻找。虽然找到故障原因是解决问题的关键,但在紧急情况下,我们需要优先考虑如何快速止血,恢复业务。只有在确保业务稳定运行的前提下,我们才能有更多的时间和精力去深入分析故障原因,从根本上解决问题。

✅正例:

❌反例:

看监控,看日志:

1、收集和分析 UMP 性能指标、Logbook 错误日志、MDC 系统运行状态等信息,以便更准确地判断问题所在。

2、与相关团队进行沟通,共同分析问题原因,制定解决方案。在解决问题的过程中,要保持冷静和耐心,遵循故障处理的最佳实践,确保问题得到及时有效的解决。

✅正例:

❌反例:

找规律、先试验

1、通过各种监控工具,如 UMP(流量、tp99、可用率)和日志分析,我们可以查找规律并了解系统在上线前后的表现。比如,我们可以对比昨天、上周的日志数据,看看是否也存在类似的问题。同时,我们还可以监测 UMP 流量的变化,以判断系统是否受到异常的影响

2、如果我们发现之前也存在类似的疑问点,那么这可能意味着问题与今天的上线无关。我们需要继续深入研究,找出根本原因。

3、对于每一个疑问点,我们应该按照优先级进行试验和验证。这样可以确保我们首先解决最关键的问题,避免影响系统的正常运行。

4、如果在试验过程中发现问题仍然存在,我们应该及时调整方案并重新进行试验。这样可以帮助我们更快速地找到问题的根源,并采取相应的措施进行修复。

5、在整个排查过程中,我们应该保持沟通和协作。如果遇到困难或不确定的情况,可以与其他团队成员交流,共同解决问题。

✅正例:

❌反例:

看输入,看输出

1、首先,确认需要比对的输入和输出参数。这些参数可能包括请求参数、响应数据等。确保你清楚地知道需要比对的内容。在比较过程中,注意观察参数值的差异。如果发现有差异,进一步分析可能的原因,例如参数传递错误、接口逻辑问题等。

2、如果发现问题是由于接口逻辑导致的,可以尝试某 N 台机器回滚到之前的版本,然后再次测试接口是否正常工作。如果问题仍然存在,可能需要进一步排查并修复代码。

3、根据比对的结果和排查的过程,总结经验教训,提出改进建议,以避免类似问题再次发生。

✅正例:

❌反例:

留现场,时反馈

1、在进行故障排查和处理时,保留现状并记录已采取的措施和尝试过的解决方法是非常重要的(比如不要全部机器都重启,可保留 1 台现场机器)

2、详细地记录下来包括已采取的措施和尝试过的解决方法。

3、没有进展也是进展,也要及时反馈。

✅正例:

❌反例:

如果你发现我提供的信息有误或者有更加合适的清单,请随时指正并且联系我补充完善。非常感谢你的反馈和帮助!我将尽快进行修正并提供更准确的信息。

作者:京东物流 冯志文

来源:京东云开发者社区  自猿其说 Tech 转载请注明来源


↙↙↙阅读原文可查看相关链接,并与作者交流