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