不同于可靠性，弹性建设你应该这样做

在依赖软件的企业中，改善结果的方法通常比较狭隘，只是专注于减少他们所经历的事件。在这种方法的背后，有一个隐含（几乎没有说出来）的假设：事件是临时畸变，与“正常”工作无关。通常，事件被视为令人恼火的干扰因素。二十多年来，弹性工程领域一直致力于把这个方法反过来——通过理解是什么让事件如此少见（相对于它们何时及怎样才不会发生），以及如此轻微（相对于它们可能变得多糟），并有意增强使这种情况成为可能的因素。

本文将对这种认知转变的多个方面进行探讨。

以备不时之需

弹性是指人们为适应无法预期或预见的情况所进行的活动、准备和能力投资。这不是我定义的：它是以 20 多年来弹性工程社区对意外、复杂和模棱两可的不确定情况的适应性的研究为基础发展而来的。

我知道，这个定义显得繁琐冗长。弹性的另一种描述方式是指出这个概念的根本：适应能力。这个词在生物学、生态学、环境科学甚至气候变化领域都有着很长的历史。弹性工程社区认识到，这个概念也适用于人力和组织层面。

适应能力可以定义为“未来遇到影响当前计划的情况（条件、信息、目标或难度变化）时的适应能力”。请注意，这里强调的是适应潜力，而非适应本身，是指在需要适应之前进行的投资。

Richard Cook 和 David Woods（该领域的先行者）称这种状态为"准备（poised）”适应。这是指已有的专业知识、资源和条件，使人们有可能针对事件作出响应。

弹性并非可靠性的升级

我同事 David 博士曾写过一篇文章，探讨可靠性与弹性之间的差异：

问题在于，可靠性假设未来会和过去一样。这个假设是站不住脚的，因为这个世界有两个事情是不可避免的：资源是有限的，而事物是变化的。

换句话说，最好将可靠性理解为一种概率，即许多相同事物中的一个在特定时间内发生故障的可能性。可靠性是通过测试或观察已知具有标准（和精确）尺寸和行为的事物集而得出的。使用可靠性数据进行预测时，会（错误地）假设未来看起来与过去一样。

与之相关的一个概念是健壮性，这是指我们用来处理已知故障模式的所有过程、机制或自动化方法。与使用可靠性数据进行预测相反，它会预测未来可能出现的特定故障，并采取相应的对策来减轻故障或减少其影响。我们可以围绕我们可以预测的故障模式来构建健壮性，但世界的变化方式经常会出乎我们的意料——以一种无法预测的方式。

弹性是指人们在应对突发事件时现有的可供使用的人员技能和能力，以及系统（人员和技术作为一个整体来运作）预测和适应突发事件的相关能力。

弹性隐于视野范围内

弹性工程社区中有一句著名的反向格言，即墨菲定律——“任何可能出错的事情都会出错”——是错的。可能出错的事情几乎永远不会出错，但我们往往忽略了这一点。

从事现代工作的人（不仅仅是软件工程师）根据他们所处的环境不断地适应他们正在做的事情。他们在做大多数事情时都能避免问题，几乎任何时候都是如此。当事情确实“偏离轨道”，出现需要处理或纠正的问题时，由于具备所需的专业知识，所以他们能够适应这类情况。Seeing the invisible: Perceptual-cognitive aspects of expertise（由 Klein G. A. 和 Hoffman R. R. 在 2020 年发表）一文中描述的决策研究表明，虽然专业知识是在时间紧迫和后果严重的事件（如事件响应）中发挥作用，但专业知识来自于日常工作中应对各种不断变化的情况的经验。它们是“隐藏的”，因为专家做普通工作的速度和轻松程度与工作的复杂程度形成了鲜明的对比。Woods 和 Hollnagel 将此称为流畅性法则（Law of Fluency）：

“适应良好”的认知工作发生时，会掩盖解决需求和平衡两难境地的难度。

换句话说：随着获得的专业知识越来越多，在面对不确定性和意外时就会更加熟练和自如，他们因此也就不太能意识到自己处理这些挑战时所运用的技能。这就是为什么不少新手观察者会说，专家“让事情看起来很容易”。

除了这种随着专业知识的增长而变得越来越“无形”的现象之外，还有许多人们参与支持弹性实现的活动，仅被从业者视为是“良好的实践”。

同行代码审查就是这种活动的一个例子。从表面上看，我们可以把评审同事编写的代码看作是帮助特定代码的变更人员建立信心的一种方式（通过同事的评论和建议），让他们相信修改后的代码将按照预期的方式运行。再深入一点看，我们还可以看到评审人员可以获得的好处：他们不仅有机会了解他们同事所关注的新功能或功能变化，而且还可以了解其他人对代码库的理解，他们正在使用的语言，或许可以应用于他们自己项目的特定技术，以及无数其他小而实在的好处。从这个角度来看，同行代码审查的常规实践可以对参与者应对意外情况的方式产生重大影响。与未参与代码审查的事件响应者相比，参与代码审查的事件响应者具有明显的优势。

适应能力来自专业知识的增加

为了增强（并维持）适应能力，我们首先需要仔细研究是什么使人们能够像在组织中那样针对事件做出响应——他们依赖于哪些实践、条件和资源。事件的结果往往比事件本身更糟糕。看一看，人们具体做了哪些事情来防止它们变得更糟。他们怎么知道发生了什么？他们怎么知道在这种情况下该怎么做？一旦你确定了这些适应能力的来源，你就可以：a）增强它们；b）保证它们未来不会遭到破坏。

下面是一些例子：

• 新员工影子值班。当新员工第一次承担值班职责时，他们会跟随一个有经验的人。这为他们提供了一个机会，让他们可以了解自己可能会遇到什么情况，以及老员工在这些情况下会怎么做。这也给了老员工一个机会向新员工解释和描述他们正在做什么、如何做以及为什么那样做。这种做法很容易遭到破坏，尤其是在经济紧缩的情况下：如果只“需要”一名工程师，为什么要支付两名值班工程师的工资呢？

• 跨代码库和日志的可见性。许多公司都采用的一个策略（有时是未言明的）是，允许所有工程师访问组织使用的所有代码库。在尝试诊断或纠正意外行为时，这种可访问性可以帮助工程师探索和理解可能起作用的机制。这是另一个可以说明适应能力关键来源的例子，尽管采用这种策略的公司通常不会意识到这一点；它只是被视为“我们做事的方式”。因此不难想象，以合规或安全考虑的名义，这种所有工程师可以访问所有库的策略会被清除或显著缩减。

弹性的基础是适应能力

在组织范围内的共享

分享适应能力意味着首先要主动理解：

• 是什么让其他“相邻”单位（团队、小组等）的工作变得困难，

• 是什么让他们善于处理意外

• 寻找灵活的方法来了解他们处理意外的能力。

只有这样，当需要邻居支持的情况出现时，团队之间才能相互帮助。这就是所谓的互惠。

这实际是如何发生的呢？投入时间和精力来了解其他团队的目标，以及他们通常面临的限制。在软件团队中，这种情况可能出现的一种方式是，鼓励工程师短暂地到其他团队“轮岗”工作一段时间。

关于如何共享适应能力，最好又最具体的研究是 Richard Cook 博士和 Beth Long 博士在《应用人体工程学》杂志上发表的文章“构建并完善可在响应技术事件时共享的适应能力：弹性工程案例”。他们对组织方法的研究主要有两个发现：

1. 从其他单位借用适应能力的能力是弹性系统的一个标志；

2. 对适应能力共享的刻意调整是某些弹性工程形式的一项特征。

这篇研究论文有一个通俗版本“事件响应中的适应能力”，其中描述了一项由从业者主导的工作，该工作创造了一种新方法，用于处理特别困难的事件。在某些条件下，事件响应人员可以通过灵活、有效的方式“借用”后备队的专业知识。这个后备队由一小群拥有不同事件经验的终身志愿者组成。将他们的专业知识运用到非常严重且难以解决的情况中，意味着事件会得到更有效的处理。这个志愿者支持小组的成员指出，虽然这个想法是由实际操作的工程师提出的，但公司的领导认识到了它的价值，并提供了支持和组织保障，以便它能够扩展演进。

任何形式的成功都倾向于在诸如新市场和客户、用例、功能、伙伴关系和集成等方面带来增长。这种增长伴随着技术系统、组织边界、涉众等各方面复杂性的增加。额外增加的复杂性会导致新的意外行为，而组织需要适应这些行为以保持活力。换句话说：成功意味着成长，成长意味着复杂，而复杂意味着意外。

共享适应能力可以创造条件，使组织能够不断取得成功。

在适应能力共享方面的投资回报是，可以保证组织持续获得成功，并使组织的工作保持一定的弹性。

培养事件响应技能就是

积累专业知识（不只是经验）

对于事件响应，人们能做的最好的事情是：a）立即意识到发生了什么；b）立即知道该怎么做。最重要的是要增加人们的专业知识，为这两件事提供支持。其他通常被认为是技能的东西都是次要的。

例如，类似于“与涉众进行清晰的沟通”这样的指导非常常见。表面上看，这是一个相当合理的建议。当发生的事情不清楚或模棱两可时（通常发生在事件开始时），在报告时说“我们不知道发生了什么，因此我们不确定需要多长时间才能解决”，涉众通常不会认为这是“清晰”的沟通。然而，在很多情况下，这就是现实。还要注意，努力沟通“发生了什么”和“什么时候”会解决问题，会分散人们在解决问题上的注意力。这是一个无法解决的困境。Laura Maguire 博士的博士论文研究了这种困境及与之相关的现象。她还写了一篇文章总结她的发现，相关内容可以查看 InfoQ 的这篇报道。

那么，哪些活动能够有效地培养应对突发事件的技能呢？从实际对事件做出响应的人的角度来理解已经发生的事件的“繁琐细节”！是什么让它变得困难或令人困惑？当不知道发生了什么时，他们到底做了什么？有什么他们知道（别人不知道）的东西影响了他们解决问题的方式吗？这些都是富有成效的方向。

寻找现有的弹性资源

看看你正在经历的事件（或者称为“对计划执行带来挑战的意外”），看看是什么让处理这些情况成为可能。

人们看的是什么？遥测信息吗？日志吗？他们怎么知道要找什么？他们怎么知道去哪里找？他们是否会去查看代码库或日志中由其他人负责的部分？如果他们向别人求助：他们怎么知道该向谁求助，或者如何联系他们？

其中许多活动都需要首先获得他们所依赖的数据；他们有这样的渠道。这看起来是如此的普通，以至于很难说其很重要，将来，可能很容易就可以找个理由把这种访问给禁止了。

当承受着时间压力解决可能导致事情出错的问题时，人们会使用他们认为需要的任何东西。通常情况下，人们实际做的事情并没有得到足够的关注。当然，除非他们的行为首先被看成了问题的起因，或是使现有的问题变得更糟。

换句话说：当人们犯错时，他们的行为会被密切关注。而当人们解决问题时，他们的行为却很少被仔细观察（如果有的话）。

弹性工程强调，后者比前者更重要。

原文链接：

https://www.infoq.com/articles/adapt-surprises-software-reliant-businesses/