Blog.4 故障排查

测试提Bug的基本要素，主要包括：

1. 指望获得的结果
2. 实际获得的结果
3. 如何重现问题

生产环境出了故障，固然也脱离不开这3个要点。只不过相对重现问题会略微复杂。毕竟，故障老是咱们意外以外的状况。

根据Bug发生的现象，咱们会提出不少假设，而后进行逐步排除。

当问题发生时，最应想到的是：系统最近是否有过改动。很大几率上，一个正常工做的服务会一直维持工做，直到某种外力出现。若是确实是新功能上线致使的，能够结合具体状况，考虑是否回滚到老版本。但有些时候，回滚可能还会引起二次问题，须要特别注意。

接下来：

继续保存冷静，简要评估问题的严重程度，及时给外部做出反馈。这里的反馈特别重要，不只可让你们了解故障的进展状况，并且，你们还可能提供很是有价值的建议。

接下来：

仔细分析故障发生的现象，不要忽略错误日志的任何细节。这个过程当中，日志显得尤其重要。一个好的日志记录，必须能还原或推断出当时故障的现场。日志信息主要包括：上下文信息、报错信息。

固然，有时候故障会涉及多个微服务，最好能有一个trace_id，用来跟踪故障的发生过程，以及具体是微服务中的哪台服务器发生的故障。

接下来：

若是没法绝对肯定故障的缘由，咱们须要复现Bug，也就是前文提到的逐个排除。这开发过程当中，追加剧要服务的测试用例很是重要，可能会节约好多宝贵的时间。

但也存在难点，好比一些伪相关的缘由误导咱们的判断。故障通常都有连锁反应，有时候会很难分辨问题的主次。

Go开发排查问题

Q1

服务发生panic时，结合日志中打印的堆栈信息，能够很容易定位到出错的代码，并做出不少可能的推测。而后，结合具体的上下文信息，能很快复现问题。整个过程当中，日志是问题排查的关键。

日志必须包含panic的堆栈信息，最好有链路的trace_id信息。若是在开发过程当中，有对应的Test就更好了。

Q2

对于接口响应慢的状况，能够依靠pprof工具进行诊断。其中，最可能的是调用外部服务慢，好比经典的MySQL慢查询。

若是排除了外部依赖的问题，那极可能是程序代码自身问题。经过pprof的各类信息展现，也能很快定位。

珍惜Bug

不要放过任何Bug，对Bug的处理过程要作好梳理、总结。下面是总结的模版：

-- 细节
-- 灾难响应
-- 过后总结
    -- 作的好的地方
    -- 作的很差的地方