【稳定性】揭秘团队快速排查问题的三字经，你学会了吗？
背景
线上故障是技术成长中不可避免的一部分，我们从中能够吸取宝贵的教训并变得越来越有经验。然而，并非每个团队或技术同学都能以合理和科学的方式处理故障。基于日常实际工作经验和个人心得，我整理了一份团队遇到故障问题或者疑似问题快速排查的三字经清单及正确✅案例和错误❌案例。这份清单将帮助你在遇到问题时进行快速排查，无需担心在高压环境下忙中出错，遗漏关键步骤环节。掌握这份清单，你将能够更好地掌控现场，从而避免因疏忽而造成的损失。让我们面对故障时保持冷静，有条不紊地进行排查，不断提升我们的技术水平和问题解决能力。
三字经
备注：下面不是严格的顺序，需要根据实际情况调整可多路并行，比如清楚问题大概环节，先止血。如不清楚，报备分工，初步定位大概环节再快速止血。
在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级，恢复现场快速止血方案高于寻找故障原因等其他所有环节。
别慌张，先报备
先组会，明分工
描现象，非结论
先止血，再定位
看监控，看日志
找规律、先试验
看输入，看输出
留现场，时反馈
别慌张，先报备
1、在处理紧急事件（线上问题或者疑似问题）时，先把问题上报组内。
2、充分发挥团队的力量，通过集思广益的方式，可以更加快速地找到问题的根源，并采取相应的措施进行解决。
✅正例：
- 假设一个团队中一名成员遇到了一个业务或者其他团队研发反馈的线上问题。他首先将问题上报给了组内TL/架构
- 然后通过在线会议或即时通讯工具与团队成员分享问题的细节。团队成员们迅速展开讨论，集思广益，共同分析问题的原因和可能的解决方案。
- 经过大家的共同努力，最终找到了问题的根源，并成功解决了问题。这个过程中，团队成员们充分发挥了团队协作的力量，提高了解决问题的效率。
❌反例：
- 假设一个团队中一名成员遇到了一个业务或者其他团队研发反馈的线上问题。他没有将问题上报给组内，而是试图自己解决。 结果，这个问题没有得到及时的解决，反而加重影响了线上损失。
先组会，明分工
1、故障指挥官(问题发现人或者小组长/架构），有权召集相应的业务、产品、开发或其它必要资源，快速组织会议。
2、故障指挥官明确各角色职责，分工明确，这样可以有效地提高故障处理的效率。
✅正例：
- 故障指挥官（问题发现人或者TL/架构）有权召集相关的业务、产品、开发等团队成员，快速组织一个会议。在会议上，明确各成员的角色职责
- 如产品人员、开发人员、测试人员等，并分工明确。这样，每个人都能清楚地知道自己需要完成的任务，从而有效地提高故障处理的效率。
- 通过集思广益，团队成员们能够迅速找到问题的根源，并采取相应的措施进行解决。
❌反例：
- 故障指挥官（问题发现人或者TL/架构）没有及时召集相关的业务、产品、开发等团队成员开会。他试图自己解决问题，但由于缺乏专业的业务 知识和经验，问题没有得到及时的解决。同时，其他团队成员也因为不知道问题的严重性而没有给予足够的关注。这种情况下，故障指挥官需要 花费更多的时间和精力去协调各方资源，最终可能导致问题得不到有效解决，影响整个项目的进度。
描现象，非结论
1、让问题发现者描述发现的现象（时间、影响范围、影响程度），而不是判断的结论（因为判断的结论可能是错误的，这样会误导大家排查方向）
2、请大家避免在描述问题现象时，过多地表达自己的判断和看法，因为这可能会影响到大家的排查方向。我们需要保持客观和理性的态度，以便更好地分析问题。
3、同时，也请大家注意自己的思维方式，避免让自己的大脑成为别人思想的跑马场。在讨论问题时，我们可以提出自己的观点和建议，但请确保这些观点是基于事实和证据的，而不是个人的主观臆断。
✅正例：
假设在一个软件开发团队中，当遇到一个性能问题时，问题发现者描述了如下现象：
- 时间：2023年8月18日上午9点至10点之间，用户在使用过程中发现了明显的性能下降。
- 影响范围：影响到用户登录、数据查询等主要功能模块。
- 影响程度：由于性能下降，用户的请求响应时间明显增加，部分用户无法正常完成操作。
在这个例子中，问题发现者提供了具体的现象信息，使得团队成员能够迅速定位问题所在，并采取相应的措施进行优化和修复。
❌反例：
假设在一个软件开发团队中，当遇到一个性能问题时，问题发现者仅给出了自己的判断结论：
- 时间：2023年8月18日上午9点至10点之间。
- 影响范围：可能是数据库连接池的问题。
- 影响程度：很严重，导致大部分用户都无法正常使用系统。
在这个例子中，问题发现者没有提供具体的现象信息，而是仅仅给出了自己的判断结论。这可能会导致团队成员在排查问题时产生困惑， 无法准确地找到问题的根源。同时，由于判断结论可能是错误的，这也可能误导团队成员，导致他们在排查问题上浪费时间和精力。
先止血，再定位
1、在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级，恢复现场止血方案高于寻找故障原因。
2、快速止血：我们可以采用开关技术、回滚技术等手段，迅速恢复系统功能，避免服务中断。
3、日常应急预案：请大家提前制定好应急预案，包括关键业务的容灾策略、故障切换流程等，以便在发生故障时能够迅速启动预案，降低故障对业务的影响。
4、请大家在故障处理过程中，不要过于关注故障原因的寻找。虽然找到故障原因是解决问题的关键，但在紧急情况下，我们需要优先考虑如何快速止血，恢复业务。只有在确保业务稳定运行的前提下，我们才能有更多的时间和精力去深入分析故障原因，从根本上解决问题。
✅正例：
- 案例1：假设在一个软件开发团队中，当遇到一个系统故障时，问题发现者迅速采取了快速止血措施，恢复了系统功能。同时，团队成员在日常工作中 制定了详细的应急预案，使得在类似的故障发生时能够迅速启动预案，降低故障对业务的影响。在这个例子中，问题发现者和团队成员将恢复业务作为最高优先级， 迅速采取了快速止血措施，确保了系统的稳定性和可用性。同时，他们也注重日常应急预案的制定，为将来可能出现的故障做好了充分的准备。
- 案例2：在上线发布期间，如果开始报错，并且发布前一切正常？那什么也别管，先回滚再说，等恢复正常后再排查问题。
- 案例3：应用已经稳定运行很长一段时间，突然开始出现进程退出的现象？则很可能是内存泄露，可采用重启大法，重启部分机器后观察看看是否止血了。
❌反例：
- 假设在一个软件开发团队中，当遇到一个系统故障时，问题发现者花费了大量的时间去寻找故障原因，而忽略了快速止血和恢复业务的重要性。 同时，团队成员在日常工作中没有制定详细的应急预案，导致在类似的故障发生时，处理过程混乱，无法迅速恢复系统功能。在这个例子中，问题发现 者和团队成员过于关注故障原因的寻找，而忽视了快速止血和恢复业务的重要性。这导致了在故障发生时，处理过程效率低下，无法及时恢复系统功能， 给业务带来了较大的影响。
看监控，看日志：
1、收集和分析UMP性能指标、Logbook错误日志、MDC系统运行状态等信息，以便更准确地判断问题所在。
2、与相关团队进行沟通，共同分析问题原因，制定解决方案。在解决问题的过程中，要保持冷静和耐心，遵循故障处理的最佳实践，确保问题得到及时有效的解决。
✅正例：
- 假设在一个生产环境中，系统突然出现性能下降的问题。作为oncall人员，在接到问题报告后，首先通过各种监控工具收集系统运行状态和 性能指标等信息。然后，根据收集到的信息分析问题可能的原因，并与相关团队进行沟通和协作。最后，制定解决方案并进行实施， 成功解决了系统性能下降的问题，恢复了正常的生产环境。
❌反例：
- 假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为oncall员，在接到问题报告后，没有先定位大体方向，也没有通过监控工具收集相关信息进行分析。而是直接尝试修复问题，但由于缺乏准确的信息和分析，很难找到问题的根本原因，导致问题得不到有效解决，影响了业务的正常运行。
找规律、先试验
1、通过各种监控工具，如UMP（流量、tp99、可用率）和日志分析，我们可以查找规律并了解系统在上线前后的表现。比如，我们可以对比昨天、上周的日志数据，看看是否也存在类似的问题。同时，我们还可以监测UMP流量的变化，以判断系统是否受到异常的影响。
2、如果我们发现之前也存在类似的疑问点，那么这可能意味着问题与今天的上线无关。我们需要继续深入研究，找出根本原因。
3、对于每一个疑问点，我们应该按照优先级进行试验和验证。这样可以确保我们首先解决最关键的问题，避免影响系统的正常运行。
4、如果在试验过程中发现问题仍然存在，我们应该及时调整方案并重新进行试验。这样可以帮助我们更快速地找到问题的根源，并采取相应的措施进行修复。
5、在整个排查过程中，我们应该保持沟通和协作。如果遇到困难或不确定的情况，可以与其他团队成员交流，共同解决问题。
✅正例：
- 假设在一个生产环境中，系统突然出现性能下降的问题。作为oncall人员，通过各种监控工具收集了UMP和日志数据，并发现在昨天和上周也存在类似的问题。 同时，监测到UMP流量与之前相比没有明显变化。基于这些信息，运维人员可以初步判断问题与今天的上线无关，可能是由于其他原因导致的。 他们按照优先级进行试验和验证，最终发现问题是由于某个配置参数设置不正确导致的。通过调整配置并重新试验，问题得到了解决，系统性能恢复正常。
❌反例：
- 假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为oncall人员，没有经过详细的监控和分析，直接尝试修复问题。 然而，由于缺乏准确的信息和分析，问题得不到有效解决，甚至可能因为错误的操作而导致更严重的错误。这种情况下，oncall人员需要及时调整 方案并重新进行试验，以确保问题得到正确处理。
看输入，看输出
1、首先，确认需要比对的输入和输出参数。这些参数可能包括请求参数、响应数据等。确保你清楚地知道需要比对的内容。在比较过程中，注意观察参数值的差异。如果发现有差异，进一步分析可能的原因，例如参数传递错误、接口逻辑问题等。
2、如果发现问题是由于接口逻辑导致的，可以尝试某N台机器回滚到之前的版本，然后再次测试接口是否正常工作。如果问题仍然存在，可能需要进一步排查并修复代码。
3、根据比对的结果和排查的过程，总结经验教训，提出改进建议，以避免类似问题再次发生。
✅正例：
- 假设在一个生产环境中，系统突然出现性能下降的问题。作为运维人员，通过技术回滚某台机器或者引流比对，发现输入参数与预期不符，导致接口无法正确处理请求。 通过仔细排查，发现是由于一个配置参数错误导致的。修复该问题后，系统性能恢复正常，业务正常运行。
❌反例：
- 假设在一个生产环境中，系统突然出现故障，导致业务无法正常运行。作为运维人员，没有进行任何比对和排查，直接尝试修复问题。 然而，由于缺乏准确的信息和分析，问题得不到有效解决，甚至可能因为错误的操作而导致更严重的错误。这种情况下，运维人员需要及时 调整方案并重新进行试验，以确保问题得到正确处理。
留现场，时反馈
1、在进行故障排查和处理时，保留现状并记录已采取的措施和尝试过的解决方法是非常重要的（比如不要全部机器都重启，可保留1台现场机器）
2、详细地记录下来包括已采取的措施和尝试过的解决方法。
3、没有进展也是进展，也要及时反馈。
✅正例：
- 假设在一个生产环境中，系统突然出现性能下降的问题，值班运维人员保留了1台机器并且摘除了流量，其他机器分批重启了，快速止血恢复了现场， 同时安排其他人员去分析未重启的机器，Dump应用快照（常用的快照类型一般就是线程堆栈和堆内存映射）分析原因。
❌反例：
- 假设在一个生产环境中，系统突然出现性能下降的问题，值班运维人员直接把机器都重启了， 这样快速止血恢复了现场，但由于没有保留现场，导致现场关键信息丢失，可能无法继续排查根因
如果你发现我提供的信息有误或者有更加合适的清单，请随时指正并且联系我补充完善。非常感谢你的反馈和帮助！我将尽快进行修正并提供更准确的信息。
作者：京东物流 冯志文
来源：京东云开发者社区 自猿其说Tech 转载请注明来源
