3.3. 有效的故障排查手段
故障定位是一个可以自我学习，又可以传授的技能。
3.3.1. 理论
理论上，我们将故障排查过程定义为反复采用架设-排除手段的过程，针对某系统的一些观察结果和对该系统的运行机制的理论认知， 我们不断提出一个造成系统问题的假设，进而跟进这些假设进行测试和排除。
通用故障排查模型如下
故障报告 -> 定位
检查
诊断
测试修复 -> 治愈
造成低效的故障排查通常集中在定位、检查、诊断环节上，主要由于对系统不够了解而导致。 下面几种情况要注意。
关注了错误的系统现象，错误方向渐行渐远
不能正确修改系统配置信息，不能进行有效测试假设
将问题过早归类极为不可能的原因，隐藏问题细节，故障还会在此发生的的，更大故障。
有些是相关性的不等于因果关系。
我们现在知道了那些， 我们现在有啥假设， 这个假设需要哪些数据， 查找这些数据进行验证 。
3.3.2. 实践
3.3.2.1. 故障报告
每个系统故障都起源于一份故障报告，这样每个故障都有记录和解决方案。
3.3.2.2. 定位
先判定故障影响面，大型问题可能需要全员参与的紧急会议。
止损优先： 尽最大可能让系统恢复服务。 可以保留一些问题现场，方便后续进行问题分析。
3.3.2.3. 检查
检查组件等工作状态，确认整个系统是否在预期工作。 一般情况下，我们监控系统记录整个系统的监控指标，通过多个监控面板的相关性可以确定 问题根源。
检查日志
检查rpc调用trace信息。
3.3.2.4. 诊断
对系统设计的详细了解，在系统出现问题的时候可以快速提出合理猜想的主要帮助。 在乜有详细了解的情况下，这是一些通用方法。
简化和缩略： 链路比较长，可以二分法进行定位故障所属哪段。
什么 哪里 为什么： 什么是现象（延迟高） 为什么（ cpu高） 哪里（排序和正则）
最后变更： 快速找到所有变更，进行关联分析。错误率数据和部署阶段时间点进行match分析。
3.3.2.5. 测试和修复
有一些假设的可能原因列表，接下来就是找到具体那个原因导致才是真正的根因。
一个理想的测试应该是互斥的，执行了这个测试，可以排除一堆假设。
先测试最有可能的
3.3.3. 神奇的负面结果
负面结果是一项试验中预期结果没有出现，也就是试验没有成功。
3.3.3.1. 治愈
理想情况下，你已经将一系列可能的错误原因减少到一个，下一步就是证明就是这个问题根源。 当最终确定某个因素是问题根源后，应该将系统出错的部分，如何定位的，如何修复的，如何防止在此发生写下来。 就是事后报告。
3.3.4. 案例分析
3.3.5. 使故障简单
增加可观察性。 给每个组件增加百合指标和结构化日志。
利用成熟的，贯彻好的组件接口设计系统。