针对，troubleshooting，遵循以上十条真理

译者前言

Troubleshooting 即故障排查检修，这绝对不是一项简单的任务，不同技术体系之间天差地别，这个问题可有统一答案？因为具体的技术终将过时，所以本文不谈任何具体的技术细节，而是针对 troubleshooting 提出十条方。本文原：Steve Mushero

1. 故障无法避免

啊，你的服务又挂了，很不幸。

更不幸的是，因为负载高、业务复杂，它挂掉是常事。

它以一种不能被 “自动扩容”“加容器”“重启” 等手段轻易 “解决” 的方式挂掉，花里胡哨的调度此时也起不到作用。当然我不是说这些方法没用，毕竟它们各有各的场景。

有时候，你面对一个故障，5 分钟就能定位原因，但作为 “老兵” 的你一定懂得这背后需要多少经验积累和努力，常言道 “功夫都在戏外” 如果你恰好用了微服务（micro-service）无（server-less）无限可分割（infinitely-divisible）无处不在的松散连接组件（loosely-connected pieces and parts）之类的新玩意，修复起来就更难了。

何解？具体技术早晚会过时，而方则具备长久生命力。唯有 “道”指方才是应对复杂的指路明灯。

2. 对一切建模

要能说出每个部件在模型中的位置，它们如何交互、如何配置。条件允许的话，连它的行为也要弄清楚。

拿到并看懂逻辑架构图，有必要的话，物理架构图、网络架构图也一样。搞清楚不同尺度上的分层、分组。

3. 可知则尽知

尽你所能，弄清楚所有的配置和状态。

这确实很难，看懂仓库里的代码、配置文件、.env、基础结构即代码（infrastructure-as-code systems）只是毛毛雨，更不要说运行时动态的部分。但不管你喜不喜欢，真正运行着的就是一切真相的源头。

4. 谁动了环境？

最近有什么被动过？由谁？何时？操作对象是什么？效果是什么？谁登过？谁 push 过代码？改了什么配置？诸如此类。

哪些行为发生了变化。例如谁的延迟发生了变化，相关部分的动力学【1】变化，错误率是否有变化，哪些资源负载或可用性发生了变化？哪些变化重要呢？

5. 请专家

直接或间接地应用知识和经验，了解事物之间的关系、依赖，尤其是动力学及与之关联的失效模式2动用一切资源去找最懂行的人，问朋友同事、在论坛社区发帖、在社交网络提问、在 IRC 或列表提问…如果专家是“鬼魂”那就“作法招魂”3到现场指导是最好的、实在不行就远程。条件允许的话，使用可用的专家或规则引擎，这些都是被编码过的专业知识。

6. 提问要清晰准确

提问前请务必再三观察和思考，虽然给专家的信息永远是片面的，但错误的提问神仙难救，而某些低风险的、清晰而准确的提问，则连人脑都不需要，可以直接被规则引擎快速地自动解答，这就是提问质量的差距。

7. 局部小规模实验

可对做微小的改动或调整，观察其影响。

这招非常好用，尤其是使用排除法时、探究组件之间的关系、验证某些东西不生效的猜想时。

8. 提前做排除

别浪费时间在明显错误的方向上，它会吞噬掉大量的时间和精力，注意力被转移，资源被浪费，不要等到最后才懊悔没早点排除错误选项。问题 “是” 什么固然重要，但永远别忽视问题 “不是” 什么，要持续不断地根据逻辑和经验做排除。

9. 小心求证

排查到最后可能以自相矛盾的结论收尾，某些部分似是而非，最终问题无解。用马克 · 吐温的话说：“麻烦的不是未知，而是你深信不疑，却发现事实并非如此”

所以在排查过程中要乐于不断和自己的基本假设、基本事实与真相，因为似是而非的部分往往埋藏在其中。

10. 寻求慰藉

排查问题是困难的，时间和工具永远都不够，并且总是伴随着巨大压力。时常停下来，重新思考和审视已知的一切，观察它们如何连接与相互影响，真相经常以这样匪夷所思的方式被发现…

故障无法避免，遵循以上十条真理，答案终将到来。

注解：

1 Dynamics 即动力学，这里理解为需要分辨指标中谁是因，谁是果，以及影响程度。对指标的解读是关键。

2 Failure Modes 即失效模式，详见百科

本文相关词条概念解析：

提问

提问（askaquestion）是一个汉语词语，也是一个动作。