作为《空中浩劫》的忠实观众，我常常能看到飞行员在遇到各种险情时，只要还有时间和精力，就一定会拿起手边的操作手册（新机型应该已经电子化了）按指引逐条查找来尝试找到问题的标准解决方式。这份手册就是本文的主题，即 SOP （标准作业程序）。

虽然在航空业中，要么飞行员能够依靠 SOP 化险为夷，要么调查人员也常常会证明按照 SOP 操作很可能就能避免事故，但在互联网行业，SOP 虽常常被人提及和编纂，却很少能发挥出很大的作用，这又是什么原因呢？

翻译代码与滞后性

在航空、医疗等行业，SOP 的制定者是飞机或器械的研发产品团队，而阅读者则是具体的使用者，也就是说其中包含了一种较强的供需关系且两者是独立的。而在互联网领域，除去基础组件面向全公司提供的 SOP 符合这一性质，在业务团队中， SOP 的制定者与使用者却常常是同一批人。

而在制定故障处理 SOP 的编写目标时，很多团队希望这份手册能包含业务内所有逻辑的故障应对方案。这其实是种非常理想化的想法，原因就在于再简单的业务接口，其内部涉及的逻辑也至少是乘以十计的，这也就导致越细致的 SOP 就越相当于对代码的翻译。

与之类似的是理想化的单测覆盖率尤其是 TDD 模式的单测，业务运行不依赖单测，但单测与业务逻辑是强绑定的，修改业务逻辑就要协同修改单测。但故障 SOP 又与单测不完全相同，文字总结甚至系统化的 Wiki 没有 CI Pipeline 的限制，研发对代码进行修改时很难被强制要求更新 SOP ，时间一长，很容易就会出现类似于技术文档的滞后性。

正如稳定性手段一般，过期的故障处理 SOP 不仅很难帮助你，反而更有可能会害了你！

故障处理SOP的积极意义

虽然故障处理 SOP 有着很大的局限性，但在互联网和软件领域，它仍具有一定的积极意义：

  1. 加强版新人培训：只要给足团队新成员时间，理解业务、做好需求对于大部分人来说都不是问题。但故障的处理是需要经验的，此前工作经历再丰富的新人，面对一个复杂存量系统的故障时也会显得手足无措。

  2. 减少次生灾害：很多次生故障的产生都是由于操作人员处理故障时的慌乱导致的，而有了 SOP ，处理者在如禁用机器、调整路由策略等常规操作上更有底气，配合和其他成员的交叉检查即可在很大程度上避免次生故障的发生。

  3. 处理思路补位：好的故障处理 SOP 不会仅仅包含处理步骤，而会结合过往的事故，给出系统中常见故障的现象和处理思路，这对故障处理者是至关重要的。就像考试时我们有时会出现提笔忘字的情况，给处理者一份答案提示，便能为他的故障处理策略制定提供很大的帮助。

如何制订一份有点用的SOP

从上文可以看出，故障处理 SOP 并不是毫无用处，但也不可能覆盖所有问题。那么一份『有点用』的故障处理 SOP 应该具有哪些特点呢？

便于搜索

我看过很多公司和部门的故障预案，大多是在自己的 Wiki 系统中建立树状目录，而 SOP 内容则全部位于子节点页面中。

这样的文档布局看似非常清晰，很适合向 leader 作为『成果』汇报，但对使用这份手册的人来说则是灾难性的：一边是影响线上的故障，一边是使用深度搜索或广度搜索遍历各个子节点查找某个 SOP 是否能为自己提供帮助，这样的 SOP 到底是在帮助处理者还是在拖慢处理者呢？

因此编写最终面向故障处理者的 SOP 时，要么做到将内容平铺到同一份文档中，要么提供全文搜索功能，让慌乱的处理者不会因为需要查阅结构复杂的 SOP 而变得崩溃。

思路比手段更重要

故障处理 SOP 告诉我这样做，可这么做是对的吗？ 按照 SOP 的步骤执行到一半，怎么现象和 SOP 说的不一样？

对于常规故障，像机器禁用等简单操作按照步骤逐步执行无可厚非。但我们知道，严重的故障很少是单个问题直接触发的，却往往是某个数据或逻辑有问题成为故障的根本原因，而更多的直接原因则常常是多个其他流程或系统由于各类问题产生故障或稳定性手段失效。这仍然与航空事故非常相似，《空中浩劫》中的 NTSB 调查员常挂在嘴边的也是类似的话。

而在复杂故障下，简单的步骤教程是没有意义的，因为阅读者根本无法决定应该选择哪个步骤指南来解决问题。所以好的故障处理 SOP 不仅要包含常见的操作步骤指南，更应该包含故障的处理思路，这些思路应该从各种历史故障或系统薄弱点出发，至少给出以下内容：

  • 故障特征：这份 SOP 适用于什么现象？
  • 处理原则：故障千千万万，处理原则却常常寥寥无几，给出原则，让阅读者在建议步骤无效时仍能找到排查和处理的思考出发点。
  • 建议处理步骤：与常见 SOP 中的步骤描述类似，但这类步骤应该是建议性而非强制性的，同时也要讲清使用的上下文，简明扼要地向阅读者说明『这么做故障就有可能会恢复』。

勤于故障演练

『勤能补拙』在故障处理领域并不是『鸡汤』，与其指望帮助有限的故障处理 SOP ，更有效的是通过无损或低损的故障演练来训练故障处理者的情绪控制能力、思考方式和操作熟练度，并为处理真实故障积累经验。不过虽然『混沌工程』的理念已经被提出多年，但很多公司的故障演练仍然是在过家家。对于大部分公司和团队来说，故障演练的有效落地仍然有很长的一段路需要走。