别慌张，先报备

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、根据比对的结果和排查的过程，总结经验教训，提出改进建议，以避免类似问题再次发生。

✅正例：

❌反例：