排查
是不是这次更新的锅？先看方向
昨天还好好的，今天不行了。诚实的答案不是「大概是更新」， 而是先看哪件事先发生。
方向很重要
发生在更新之后的故障，是典型的「更新之后出的问题」； 发生在更新之前的，就不能怪它——不管这有多诱人。 在把责任归给任何东西之前，先把两个时间戳并排放在一起。 这一步通常就能消掉很大一部分错误归因，两个方向上都一样。
「正常」必须是明确的正面确认
诊断报「正常」这件事本身有个陷阱：如果「正常」的意思是我们没发现问题， 那么一条从没运行过的规则，看起来就和一台健康的机器一模一样。三种状态应当是：
- 正常——我们查过，明确确认没问题，而不是「没有数据」。
- 留意——值得看一眼，但不算缺陷。
- 警告——一个具体的问题。
把「正常」定义为正面确认，才能避免「什么都没查」被读成「一切健康」。
只读快照，不读活状态
结论应当来自一份冻结的快照——里面是所有规则被允许读取的东西。 如果规则在运行过程中还能去读活状态，答案就会取决于分析跑到一半时变了什么； 而同一台机器可以在几分钟内给出两个不同的结论，中间什么都没发生。
两个很细的计数错误
- 同一条警告用两种语言记录下来，是一个问题，不是两个。 按稳定的类别归组，否则一份双语的日志看起来像麻烦翻倍。
- 解析不出来的名字算未知，绝不猜。错误的归因比空的归因更糟， 因为它会把你引到错的地方去找。
实际怎么办
- 在动手修之前，先记下问题开始的确切时间——之后的每个动作都会毁掉证据。
- 拿它去和更新记录比，而不是和你对更新的记忆比。
- 如果问题早于更新，就别再想着回滚了，去看看别的：一根线、一个扩展坞、一台显示器、一次系统小版本更新。
诚实的边界
- 时间戳只能给事情排序，不能证明因果——更新之后的故障，也可能来自一根恰好在那时候松掉的线。
- 快照让结论可复现，不等于正确。阈值设错的规则，会把同一个错误答案完美地复现出来。