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. 使故障简单
增加可观察性。 给每个组件增加百合指标和结构化日志。
利用成熟的,贯彻好的组件接口设计系统。