一次线上故障发生时，人们最自然的反应是寻找答案：哪个提交引入了问题，哪个服务正在超时，哪一行代码需要修复。但在复杂系统中，过早追逐答案经常让排查进入一条更窄的路。
调试首先是一种观察。它要求我们暂时搁置解释，明确已经知道什么、还不知道什么，以及下一次观测怎样缩小不确定性。
从现象而不是猜测开始
好的问题描述应当只包含可以被验证的信息。例如，“接口变慢了”不是一个足够明确的现象，而下面这些信息可以构成排查的起点：
- 延迟从什么时候开始变化
- 哪些请求受到影响
- P50、P95 和 P99 是否同时变化
- 错误率与吞吐量是否发生关联变化
这些事实不会直接给出根因，却会限制合理解释的范围。
建立最小观测闭环
每次排查动作都应回答一个具体问题。一个简单的闭环由三部分构成：
- 提出能够被证伪的假设
- 选择成本最低且信息量足够的观测
- 根据结果保留或排除假设
假设：数据库连接池已经耗尽
观测：连接等待时间与活动连接数
结果：等待时间正常，排除该假设这里的重要部分不是猜对，而是每一步都能减少未知。
保留排查路径
故障结束后，最值得留下的通常不只是最终修复。记录被排除的方向、关键指标和判断依据，可以帮助未来的维护者理解系统的真实边界。
一份有价值的故障记录，应当让没有参与现场的人重建当时的推理过程。
答案会过期，观察和验证的方法更容易被迁移到下一个问题中。