《SRE google 运维解密》读书笔记 （二）
有效的故障排查手段
理论：
反复采用假设排除手段的过程：
不断提出一个造成系统问题的假设，进而针对这些假设进行测试和排除
常见的陷阱
- 关注的错误的系统现象，或者错误地理解了系统现象的含义。
- 不能正确的修改系统的配置信息，输入信息或者系统运行环境。
- 将问题过早的归结为极为不可能的因素，或者之前曾经发生过的问题
- 试图解决与当前问题相关的一些问题，却没有认识到只是巧合。
实践
故障报告
故障报告不鼓励直接汇报给具体的某个人，这样会导致压力集中在几个问题汇报人熟悉的团队成员。而不是质保人员。
需要保证每一个故障报告都有调查的历史和解决方案。
定位
大型问题，不要立即开始排查问题，尽快找到问题的根源。
正确的做法是，尽最大可能使系统回复。（同时尽量保存报错的现场供事后调查复盘）
检查
需要检查系统中每个组件的工作状态，以便了解系统是不是在正常工作。
理想情况下监控可以提供相应指标。
日志很重要，了解系统某个时间在干啥。
将日志结构化，可以保存更长时间
多级记录日志很重要，尤其可以动态调整日志级别
在日志系统中支持过滤条件
诊断
- 简化和缩略
- 对于大型系统，逐级查询问题过于耗时，尝试使用二分法。
- What 、Where 、Why
- 最后一次变更
- 变更是引起问题的最大来源
- 有针对性的诊断
测试和修复
- 理想的测试应该具有互斥性，一个测试可以推翻一组假设
- 先测试最可能的问题
- 某些测试可能带来误导性的结果
- 执行测试可能会带来副作用
神奇的负面结果
所谓负面结果，就是一项试验中不符合预期的结果- 负面结果不应该被忽略
- 负面结果需要被记录，供后来人查阅。
- 比如压测不通过的报告
- 工具和方法可能超越目前的试验，为未来的工作提供帮助
- 公布负面结果有利于挺升行业的数据驱动风气
- 公布结果
- 负面结果并不是失败
- 负面结果并非没有价值
- 良好设计的试验是有价值的，而不是有正向结果的试验才有价值
治愈
理想情况下，可能把错误原因减少到了一个。
下一步复现问题。
然后修复问题
如果一旦解决了某个问题，需要将如何定位问题，如何修复问题，如何防止问题再次发生。进行记录作为事后总结记录。
使故障排查更简单
- 增加系统的可观察性。为每个系统增加白盒监控和结构化日志
- 利用成熟的，观察性好的组件接口设计系统