出现问题时

一旦出了问题——而且早晚肯定会出问题——我们的黄金法则就是尽可能降低对客户造成的影响。

在出现问题时，我的第一反应就是解决问题。但事实证明，这并不是最高效的应对思路。

相反，即使只是小小的问题，最高效的办法其实是选择回滚。返回之前能够正常工作的状态，这样才能缩短客户无法正常使用服务的时间窗口。

也只有这样，我们才能安心查找错误并动手加以修复。

正如集群中的“故障”机器一样，在尝试判断机器出了什么问题之前，我们首先应该将其下线并标记为不可用。

我发现这确实是种反直觉的办法，而且我的本能总会把自己带离最佳解决途径。

我觉得正是这样的本能，逼迫我走上解决bug的漫长道路。有时候，引发问题的根源就是我编写的代码出了问题，而我会深入研究自己写下的第一行代码。这有点像深度优先搜索的过程。

如果最后证明是配置发生了变化，而我没能及时调整功能本身，我就会非常生气。因为这个错误太低级了，本不该发生。

从那时起，我的心得就是在深度优先搜索之前先来一轮广度优先搜索，暂时不触及顶级节点。我能利用自己手头的资源确认哪些问题？

· 机器还在运行吗？

· 安装的代码是否正确？

· 配置是否到位？

· 代码是否使用到特定配置，例如代码中的路由是否正确？

· 架构版本是否正确？

· 最后，再看代码内容。

我们原本以为是nginx在机器上没有正确安装。但事实证明，只是配置文件被设置为false。

当然，大多数情况下并不需要这么麻烦。有时候，单靠错误消息就足以帮我快速找到存在问题的代码。

当我找不出问题时，我会尝试分步对代码进行变更以查找可能的根源。变更的数量越少，找到真正问题的速度就越快。总之，请尽可能让推理过程变得有迹可循，太过跳跃只会错失线索。

我现在还记得自己曾花了一个多小时解决几个bug：问题在哪？一般都是我忘了检查的一些低级问题，例如设置路由、确保架构版本与服务版本匹配等等。这只能说明我对自己使用的技术堆栈还不够熟悉，因此需要通过犯错误的方式积累经验。最终，我可以单靠直觉就判断出为什么代码没能正常运行。