造成低效的故障排查过程的原因通常集中在定位（triage）、检查和诊断环节上，主要由于对系统不够了解而导致。
常见陷阱： （a）关注了错误的系统现象，或者错误地理解了系统现象的含义。这样会在错误的方向上浪费时间。 （b）不能正确修改系统的配置信息、输入信息或者系统运行环境，造成不能安全和有效地测试假设。 （c）将问题过早地归结为极为不可能的因素（例如认为是宇宙射线造成数据变化，虽然有可能发生，但是并不应该在解决问题初期做这个假设），或者念念不忘之前曾经发生过的系统问题，认为一旦发生过一次，就有可能再次发生。 （d）试图解决与当前系统问题相关的一些问题，却没有认识到这些其实只是巧合，或者这些问题其实是由于当前系统的问题造成的。（比如发现数据库压力大的情况下，环境温度也有所上升，于是试图解决环境温度问题。） 故障排除实践： （a）故障报告： （b）定位：尽最大可能先让系统恢复服务。 （c）检查： 日志：在日志中支持多级记录是很重要的，尤其是可以在线动态调整日志级别。这项功能可以让你在不重启进程的情况下详细检查某些或者全部操作，同时这项功能还允许当系统正常运行时，将系统日志级别还原。 （d）诊断： （e）测试和修复： （f）治愈 问题分解（Divide & Conquer）是一个非常有用的通用解决方案。在一个多层系统中，整套系统需要多层组件共同协作完成。最好的办法通常是从系统的一端开始，逐个检查每一个组件，直到系统最底层。这样的策略非常适用于数据处理流水线。在大型系统中，逐个检查可能太慢了，可以采用对分法（bisection）将系统分为两部分，确认问题所在再重复进行。 “负面结果”指预期没有达成： （a）负面结果不应该被忽略，或者被轻视 （b）一项试验中出现的负面结果是确凿的 （c）工具和方法可能超越目前的试验，为未来的工作提供帮助 （d）公布负面结果有助于提升整个行业的数据驱动风气 （e）公布结果 有很多方法可以简化和加速故障排查过程。可能最基本的是： （a）增加可观察性。在实现之初就给每个组件增加白盒监控指标和结构化日志。 （b）利用成熟的、观察性好的组件接口设计系统。
