系统设计和故障诊断是工程师的两个核心能力，而在分布式系统领域，后者来得更重要。衡量一个工程师能否Cover住一个分布式系统（比如RocketMQ、Kafka、Storm、Spark、Flink等），就是看其能否快速诊断出各种故障，以降低甚至避免损失。
那什么才是故障诊断的核心技能呢？
知识体系重要，但还不够
一般人会觉得知识体系是最重要的。查不出来问题，是因为知识不够。
知识体系固然重要，但其实并不是最重要的。
刚进入阿里时，曾经查过一个超时的Case。看代码、抓包、堆栈等各种措施都用了，还是看不出端倪，看起来都是正常的。查了两三个小时无果，最后找别人帮忙，一查发现是GC导致的。
GC这个知识点，其实我并不是不知道，只是没往这方面想。
同样的Case，在组内最近也出现了，同学都写了好几年的Java，GC的算法都能说得头头是道，但遇到这个问题，查了几天也没定位到真实原因。
这充分说明，即使知识体系并没有明显的漏洞，却不代表，你有能力快速排查出故障。
思维惯性是最大的障碍
一般来说，超时，大部分情况是网络抖动导致的，还有就是锁竞争导致的。
这些是高可能性原因。
思维的惯性，就是快速调取高可能性的原因进行确认。
思维惯性的弊端就是，一旦高可能性原因不是真正原因时，会陷入打圈圈的状态，排查难以有进展。
对低可能性的关注，是思维突破的第一步。
有地图也有搜索方法
排查问题，有的时候就像找东西，东西肯定就在屋子里，但如果不掌握有效的办法，即使每天在屋子里走来走去，却不一定找得到想要的东西。
关于找东西，有一个经典的打捞军舰的故事。
军方知道，军舰沉没的大概范围，不算小，也不算大，但多次搜索无果。
后来，有个数学家给支了一招。
把地图画成一个个小方块，根据已有的信息，标出每个方块有沉船的概率。
每次搜索，都固定搜索某1个或几个方块，并根据搜索情况，更新每个方块的概率。
大意就是，如果一个方块，被仔细搜查了，一无所获，那么沉船在此处的概率就下降。下次，就应该重点排查其它方块。
这个搜索方法还被理论化了，就是贝叶斯搜索理论。
贝叶斯搜索理论
假定失踪物位于某区域的概率是 p，在此处能搜索成功的概率是 q。如果搜索此处后未能找到失踪物，根据贝叶斯定理，失踪物位于此处的概率被更新为
对其它区域，如果其原本失踪物在其处的概率是 r，那么这一概率将被更新为
如果运用贝叶斯搜索理论来进行软件故障排查，需要准备以下3件事：
- 画一个图，表示所有可能的原因；
- 根据已有经验或者信息，给出每个原因的初始概率；
- 根据已有经验或者信息，给出排除每个原因的概率
比如，对于一个成熟的中间件服务，粗粒度的原因图如下（颜色越深，表示出问题的概率越大）：
粗粒度图
一个成熟的中间件服务，其服务端操作系统和JVM都是经过精心调优过的，出问题的概率极小。而客户端，由于开发者水平良莠不齐，且通常不会进行针对性调优，其应用自身和JVM，都是问题高发地。
一个经验丰富的工程师，或者常年运维某个系统服务的工程师，其能力主要体现在步骤2，也即能根据用户反馈的初始信息（比如报错等）就能大概率知道什么原因导致。
一个基础知识扎实全面的工程师，其能力主要体现在步骤1和步骤3，对于任何的系统软件服务，能画出较为详细的原因图，同时知晓排查每个原因的可靠手段。
贝叶斯搜索的启示
最重要的启示是，如果一个方向排查无果，就应该换个方向。
知识体系的主要帮助是，提高q，也即一个东西在此处，而你又恰好排查到此处，被你查出来的概率是比较高的。
但仅此不够的，如果问题不在此处，你又死活不放手，还觉得可能是自己的知识体系不够导致的，就容易陷入打圈圈的境地。
因此说，知识体系固然重要，但还不够。
最重要的是，思维的转变。
不要钻牛角尖，全局排查，不断更新概率地图，给你足够的时间，你就应该能查出来自己领域内的任何问题。
参考资料：
Bayesian Search Theory
网友评论