如何排查系统故障-道

很早以前，程序员只需要写好自己那部分代码，并确保熟悉代码逻辑，以及代码中关联的部分外部系统如数据库就行了。

到了近几年，随着分布式系统如雨后春笋层出不穷，一个应用系统的依赖可谓相当多。比如一个典型的风控系统，背后可能会依赖kafka, hbase, hive, zookeeper, elasticsearch,mysql, flink等等。这些系统往往无法如设计之初所想的那样健壮，从概率的角度来讲，即便某个系统的故障率是0.5%，10个系统在一起其可用性也会降到95%。而保障每一个系统可用也成为了应用对外的SLA。

这里对系统排障做一些经验总结，提供大方向和思路，在排障过程中能起到灯塔的作用。即所谓的道，它并不会对实际排查问题起到帮助，但是能够提供不同的思路碰撞，在陷入死胡同时往往会有效果。

宏观vs微观

排障过程中，既要在宏观层面思考全局，又要跳到微观层面思考细节，有时需要在两种思路中反复跳跃。

举个例子，某个docker上部署了你的应用A，当你发现A疑似gc频繁可能内存不足时，你是在深度微观寻找该应用可能的问题；若你解决了内存问题，发现cpu

又比如，ES系统中某索引出现写入一条数据需要30s的情况，这时候是不是就一定可以认为该索引有问题，只需要去检查该索引就行了，如果这么考虑，实际上就是仅站在孤立微观的角度去看问题，实际上，可能是另一条错误使用的索引影响了该索引而已，这就是从孤立微观的现象抽象到整体统一的宏观角度。

时间vs空间

排障过程中，既要思考时间层面变化带来的影响，又要思考空间层面变化带来的影响。

所谓时间层面，即需要考虑故障开始的时间点，在时间线维度进行环比同比这样的时间层面上进行多维度的分析和比较。

比如，某天调用量大幅下降，故障与上一小时相比有什么变化（环比），与头一天同时段有什么变化（同比）。

然后，从有问题的时间去检查那个时刻是否有发布，是否有动态配置变更，是否有系统配置变更，是否有系统变更，是否有依赖系统变更，是否有硬件层面的变更，这些往往是重要的因素，在我过去的经验中，故障的开始往往伴随着变更。

所谓空间层面，即考虑故障的产生的范围，是在上游，下游还是本系统；如果是本系统，那么可能在本系统的A模块，B模块还是C模块；如果是本系统，是局部问题还是整体问题（某些节点故障还是所有节点故障）。即从大致范围划分来迅速寻找或圈定故障点，从而帮助我们更方便的查找原因。

比如，某flink系统，其上游是kafka，再上游是一个spark系统计算，其下游是另一个kafka，某天下游消费方突然发现没有数据了，此时应当如何从空间和范围界定的角度迅速缩小故障点？

又或者，某天某索引写入较慢，如何判断是整个索引故障，还是某台机器磁盘坏了？

白盒vs黑盒

排障过程中，既要考虑黑盒排障的方式，又要考虑白盒的方式。

白盒排障及熟悉系统架构，模块，代码，通过现象推断问题大致在哪，原因是什么？靠的是对内部细节的熟悉和深入理解。

黑盒排障则是从另一个维度，即将系统当做一个黑盒子，从各类外部现象如CPU，内存，磁盘，网络等推断故障原因。

以上仅仅是对排障的一些"道"的总结，主要目的是产生思维的碰撞，在茫茫大海中产生排障的思路，而真正的排障就需要有"术"和"器"的指导。