《SRE google 运维解密》读书笔记 （二）

有效的故障排查手段

理论：

反复采用假设排除手段的过程： 不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除

常见的陷阱

• 关注错误的系统现象，或者错误地理解了系统现象的含义。
• 不能正确修改系统的配置信息，输入信息或者系统运行环境。
• 将问题过早的归结为极为不可能的因素，或者之前曾经发生德国的问题
• 试图解决与当前问题相关的一些问题，却没有认识到只是巧合。

实践

故障报告

故障报告不鼓励直接汇报给具体的某个人，这样会导致压力集中在几个问题汇报人熟悉的团队成员。而不是质保人员。 需要保证每一个故障报告都有调查的历史和解决方案。

定位

大型问题，不要立即开始排查问题，尽快找到问题的根源。

正确的做法是，尽最大可能使系统回复。（同时尽量保存报错的现场供事后调查复盘）

检查

需要检查系统中每个组件的工作状态，以便了解系统是不是在正常工作。

理想情况下监控可以提供相应指标。

日志很重要，了解系统某个时间在干啥。

将日志结构化，可以保存更长时间 多级记录日志很重要，尤其可以动态调整日志级别 在日志系统中支持过滤条件

诊断

• 简化和缩略
• 对于大型系统，逐级查询问题过于耗时，尝试使用二分法。
• What 、Where 、Why
• 最后一次变更
• 变更是引起问题的最大来源
• 有针对性的诊断

测试和修复

• 理想的测试应该具有互斥性，一个测试可以推翻一组假设
• 先测试最可能的问题
• 某些测试可能带来误导性的结果
• 执行测试可能会带来副作用

神奇的负面结果 所谓负面结果，就是一项试验中不符合预期的结果

• 负面结果不应该被忽略
• 负面结果需要被记录，供后来人查阅。
• 比如压测不通过的报告
• 工具和方法可能超越目前的试验，为未来的工作提供帮助
• 公布负面结果有利于挺升行业的数据驱动风气
• 公布结果
• 负面结果并不是失败
• 负面结果并非没有价值
• 良好设计的试验是有价值的，而不是有正向结果的试验才有价值

治愈

理想情况下，可能把错误原因减少到了一个。 下一步复现问题。 然后修复问题

如果一旦解决了某个问题，需要将如何定位问题，如何修复问题，如何防止问题再次发生。进行记录作为事后总结记录。

使故障排查更简单

• 增加系统的可观察性。为每个系统增加白盒监控和结构化日志
• 利用成熟的，观察性好的组件接口设计系统