共计 4850 个字符，预计需要花费 13 分钟才能阅读完成。
背景
线上故障是技术成长中不可避免的一部分，咱们从中可能汲取贵重的教训并变得越来越有教训。然而，并非每个团队或技术同学都能以正当和迷信的形式解决故障 。基于日常理论工作教训和集体心得，我整顿了一份团队遇到故障问题或者疑似问题疾速排查的三字经清单及正确✅案例和谬误❌案例。这份清单将帮忙你在遇到问题时进行疾速排查， 无需放心在低压环境下忙中出错，脱漏关键步骤环节 。 把握这份清单，你将可能更好地掌控现场，从而防止因忽略而造成的损失。让咱们面对故障时放弃沉着，井井有条地进行排查，一直晋升咱们的技术水平和问题解决能力。
三字经
备注：上面不是严格的程序，须要依据理论状况调整可多路并行，比方分明问题大略环节，先止血。如不分明，报备分工，初步定位大略环节再疾速止血。
在故障处理过程中采取的所有伎俩和口头，所有以复原业务为最高优先级，复原现场疾速止血计划高于寻找故障起因等其余所有环节。
别慌乱，先报备
先组会，明分工
描景象，非论断
先止血，再定位
看监控，看日志
找法则、先试验
看输出，看输入
留现场，时反馈
别慌乱，先报备
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 转载请注明起源
