弹性（也可叫韧性），也就是实时适应不断变化的条件的能力，是专家级水平的标志。
弹性工程研究的结果揭示并概括了人类在处理复杂、变化的环境时采用的种种模式。
这些研究可以指导软件工程师及其组织有效地组织团队和处理任务。
弹性、适应性的专长的五个特征包括及早识别不断变化的条件、快速调整一个人的心理模型、准确地重新规划、重新配置可用资源以及回顾过去并总结经验。
可以通过各种软件界面设计技术、改变工作实践和开展培训来支持这些特征。
随着软件开发人员在职业生涯中不断前进，他们会积累深厚的技术系统知识，并熟练掌握特定的软件服务、组件或语言。然而，随着工程师进入更高级的职位，如高级工程师、架构师或高级技术主管角色，他们知识的应用范围也会发生变化。在高级职位上，角色的知识和经验通常会应用于整个系统。这种专业知识越来越多地被要求处理新颖或非结构化的问题，或设计复杂问题的创新解决方案。这意味着他们要考虑软件和团队的相互依赖性，认识到连锁效应及其影响，并利用自己的人际关系为新计划或发展中的局面带来适当的关注和资源。在本文中，我将讨论几种策略，以帮助你作为组织高级成员来扮演好自己的角色。
现代软件工程需要许多核心能力来应对快速和大规模构建和运行系统时的复杂性，并适应不断变化的局势。弹性工程提供了几个概念，与适应不可避免的压力、限制和意外相关。
弹性的概念在很多专业领域中有着多种描述方式。它曾被用来描述心理、经济和社会属性，但主要应用在生态学，被用来描述生物和生态系统的适应性特征。多年来，我们对弹性的理解发生了变化。在软件领域，对弹性最有影响力的描述可能来自安全研究员 David Woods 和优雅扩展理论。他将其定义为“当意外事件挑战系统边界时，系统扩展其适应力的能力”。
这意味着一个组织不仅仅是在“反弹”或成功地保护自己免受干扰。相比之下，它可以引入一种新的能力来做出反应。就像福布斯在其关于业务转型的文章中指出的那样，在疫情期间，商业航空公司通过将航线改为货运航班来应对旅行需求下降，或者失去旅客的酒店开始为在家工作的人们提供每日房价优惠，为远程工作提供安全、高效的场所。
同样，这种弹性视角对软件工程很有帮助，因为“意外”是大规模、持续部署环境中日常运营的一项核心特征。系统设计的一个核心方面是提供更具弹性和更可靠的服务交付能力，这就需要为意外事件预先设计、规划和培训处理能力。
研究人员研究了一些高要求工作中的绩效表现，例如以 1800 英里 / 小时的速度驾驶战斗机接近地面、地震后迅速关闭核电站或对处于困境的婴儿进行心脏直视手术，并已经锁定了很多重要的人类感知、推理和反应能力，这些能力使人们能够快速、适当地对特定事件做出反应。
即使经过充分的准备和培训，意外事件也会让人们很难甚至不可能遵循剧本或工作流程。再加上时间压力，和难以判断正在发生哪些事情以及这些事情可能以多快的速度失败，局面就会变得难以管理。
人们被迫适应这类突发状况。他们必须在情况恶化时迅速找到一种新方法来处理这种情况，以防止故障的影响蔓延。成功的适应过程通常被称赞为“快速思考”，在本文中，我们将探讨软件事故期间快速思考，或者叫“弹性表现”的基础。
快速思考的理论基础来自对很多高后果工作环境的研究。当应用于软件运维时，它可以增强弹性表现并尽可能减少中断和停机时间。在这个语境下，这些研究结果被改编为针对个人工程师及其组织的行动策略。它们是：
识别细微变化的事件以提供早期评估和行动
实时调节用以调整行动策略的心智模型
随着条件的变化实时重新规划
重新配置可用的技术和人力资源
审查绩效以进行持续学习
这五种能力结合起来可以快速准确地应对意外事件并快速行动，而不会带来破坏。
及早识别问题、了解不断变化的情况或意识到我们需要修改自己对情况的理解，都是实现良好弹性的关键。早期检测的好处在于它带来了：
更多的行动可能性，因为情况还没有发展到难以应对的程度
在需要采取行动之前有机会收集更多信息
招募额外资源来帮助应对局面的能力
由于缺乏数据或可用数据难以获取，早期检测并不总是可行的。但是，工程师可以不断校准自己对系统在不同条件下运行机制的理解，并快速注意到哪怕是非常细微的变化，从而更早地发现问题。以下是软件工程师在日常工作中实现这一目标的三种实用方法：
校准变量：一种方法是通过定期（而不仅仅是在出现问题时）监控不同的运行条件来熟悉什么样的系统行为符合预期或属于意外。主动监控的实践有助于校准变量，比如说搞清楚什么情况下用量激增意味着出现了问题，而不是因为某个时区的用户开始大量使用某个服务。
扩展有关变化的知识：另一种策略是养成阅读事件报告，和查看仪表板在最早出现问题迹象时的样子的习惯，以便更好地注意到异常事件。
鼓励知识转移：最后，另一种有助于早期检测的轻量级校准技术是，每当同事提到了险些发生事故或他们主动避免停机的经历时，就问“你注意到了什么，让你认为有问题？”他们对这些间接经验的解释和你的阐释可以加强塑造一套更为复杂的，应对有记录行为和非记录行为的心智模型。
心智模型是系统行为的内部表示。所有软件工程师都会构建关于系统如何运行和失败的心智模型。心智模型通常包括很多有关关系、相互依赖性和交互性的信息，以便进行推理。它们还可以帮助预测系统对不同干预措施的反应。
对于软件工程师来说，这意味着在思考层面上筛选可能的解决方案、问题和交互，以确定最合理的行动。什么是“合理的”取决于如何根据当前和预期的未来条件、目标、优先级和可用资源评估行动。换句话说就是模拟演算“不同的选择将如何影响期望的结果”。经过良好校准的心智模型可以帮助工程师有效地模拟，并做好准备来评估每种选择的利弊以及可能涉及的风险。
但心智模型可能是错误的，而且往往是错误的。正如《人为错误背后》中所述，心智模型是局部的、不完整的和有缺陷的。这并不是对工程师的批评。相反，它承认了大型软件系统的复杂性和变化性。没有一个人会拥有完整和最新的系统知识。没有人能完美地理解现代软件系统的所有依赖关系和交互。大多数软件系统都太大、变化太多、太快，以至于任何人的知识都无法一直保持准确。
知识不够准确不是问题。问题在于你不知道自己的知识是否准确。这意味着工程师必须不断更新自己的模型。一种弹性策略方法是培养一种持续认知，不断反思自己对局势的理解是不是已经过时了。作为研究“工程师如何应对事件”的研究人员，我总是会寻找那些可以看出响应者的心理模型有多准确的线索。换句话说，他们对情况或系统的了解或信念是否正确？这也意味着模型需要不断更新。高绩效团队可以快速识别他们何时出错，并迅速找到数据来更新他们对情况的理解。持续修订的一些方法包括：
指出不确定性和模糊性：帮助团队注意到他们的心智模型何时不再正确，或者不一样了，一种技巧是提出问题要求对方澄清，例如“当你说这个查询语法错误时，你是什么意思？”这是一个简单而直接的问题，我的研究表明，这个问题并不常见。明确地询问问题为其他人创造了机会来揭示他们的想法，并让所有相关人员确保他们有相同的理解。这在情况迅速变化时尤其重要。团队可以开发一些确保模型一致性的简便方法，以避免扰乱事件响应流程。
养成明确陈述假设和信念的习惯，以便周围的人可以跟踪推理过程并快速识别不正确的假设或错误的信念。这看起来很简单，但是当你开始这样做时，你会意识到你对自己或他人的不准确或错误的心智模型有多“放任不管”，因为那些问题看起来很小，似乎不值得修订，或者时间压力阻止我们去修订。初级工程师可能不敢对已经讨论过的部署提出澄清问题，或者因为害怕出错而不愿谈论他们对回滚更改风险的理解。高级工程师可能没有意识到他们的心智模型存在缺陷，或者可能不想公开指出错误的知识。
学会接受错误：软件工程师必须接受他们的心智模型会出错这一事实。组织需要将“犯错”的做法正常化。这种转变意味着围绕模型更新的那些过程（例如提出看似显而易见的问题）成为合作中被接受和常见的部分。事后学习评估或结对编程是深入了解各方的心智模型和假设，了解他们如何思考技术在不同条件下工作、交互和表现机制的绝佳机会。
应对服务中断的软件工程师在大多数情况下都会下意识地想出解决方案并采取行动。研究人员 Gary Klein、Roberta Calderwood 和 Anne Clinton-Cirocco 研究 了各个领域的专家从业者。结果表明，异常识别、信息综合和采取行动是人类认知中紧密耦合的一组过程。感知和行动的循环是一个持续的反馈循环，这意味着人类会根据不断变化的可用信息不断重新规划。随着时间压力的增长，重新规划变得越来越棘手，部分原因是协调方面的需求。
例如，在日常工作的情况下重新规划（比如在冲刺规划会议中），并决定为什么要优先考虑某一个功能而不是另一个功能。在这种情况下，人们有时间仔细考虑改变工作顺序或优先级的影响。此时人们可以联系受决策影响的所有利益方，并获取他们对计划可能如何影响他们自身的意见。这种情况下重新组织工作流程相对容易，对每个人的干扰都较少。
与此形成鲜明对比的是，在严重程度较高的事件中，关键的、广泛使用的内部项目管理工具可能会丢失数据。事件响应团队认为数据丢失的影响可能仅局限在组织的一部分。虽然他们有恢复这些数据的可能性，但这意味着服务将再停运一天，影响更多用户。这时候一个团队要与一个重要客户举行重要会议，需要在下一个小时内恢复服务。这意味着响应人员必须在时间紧迫的情况下确定受影响用户的爆炸半径、数据丢失的程度以及对这些团队的影响。时间压力让任何类型的脑力或协调工作都更具挑战性，在信息有限的情况下重新规划可能会产生重大后果，因为人们可能无法获得所需的观点，从而给所有相关人员带来更多压力，并迫使优先事项发生意外变化或做出不良权衡。
在最近一项关于高严重程度事件期间权衡决策的 研究 中，我的同事 Courtney Nash 和我发现，重新规划的成功决策案例不可避免地是“跨界的”。重大中断通常需要组织中许多不同角色和级别的参与。这意味着，了解每个角色的不同目标和优先事项是做到快速重新规划，同时不让任何人的目标被牺牲的关键所在。或者，当目标和工作需要改变时，这样做的影响对于重新规划过程来说会更清楚。这些发现和其他来自弹性文献的研究成果为弹性化地重新规划方法提供了重要的策略：
创造拓宽视角的机会：强调隐性感知和信念的那些正式或非正式讨论，可以影响参与者在事件或工作规划期间采取行动的方式和时间。他们可以利用这些信息来修订不准确的心智模型，调整政策和实践，并帮助组织确定出更好的团队结构、升级模式和其他支持工作流程的方法。更好地了解目标和优先事项以及它们如何根据不同的需求发生变化，有助于在重新规划期间确定出优先事项。应对恶化条件的一个关键步骤是评估当前情况下可实现的目标，并找出哪些目标可能需要牺牲或放宽以维持运营。
当人们有空闲能力来处理意外情况时，意外很少发生。相反，组织会想尽办法用尽任何可用的人员以及任何可用的专业知识、权限或预算。灵活有效地使用给定资源的组织，即使在具有挑战性的情况下也可以有效地解决和协调问题。这种事情可以很简单，例如部署一个可以被多数人访问的通信平台，不需要特殊权限、代码或专门下载的应用程序，允许任何可以提供帮助的人无缝加入这项工作。它也可能更复杂，例如发展出一个促进相邻角色交叉培训的组织。
或者组织可以举行全公司参与的游戏日，以便有效地让来自多个团队的工程师共同应对重大中断，因为他们有共同点——他们彼此了解，对他们日常应对的系统的不同部分有一定的了解，并且可以依靠他们共同的经验来准确预测谁可能具备执行复杂任务的适当技能。就像你可能在网络配置中添加、删除或移动资源一样，人员和软件的动态重新配置策略可以将专业知识和能力转移到所需的地方，同时尽可能减少让其他领域性能下降的影响，从而有助于提高弹性。软件组织中关于重新配置的弹性策略包括：
培养跨界意识：当人们准确了解组织内相邻团队或主要计划的目标、优先事项和正在进行的工作的当前状态时，重新配置的方法让组织可以更有效地共享资源。针对复杂协调需求的研究表明，当各方对局面和决策背景有一个合理校准的共享心理模型时，实时重新配置的结果会更好。这使每个参与者能够快速有效地运用他们的知识，以支持协作交叉检查方法（本质上是根据不同观点审查新想法），并允许跨团队或组织进行互惠（能够提供帮助或放宽限制）。
保持系统中一定程度的松弛：现代组织专注于消除浪费和精益运营。但在事故发生之前被认为是低效或多余的部分，事后看来往往被认为是关键的，或至少是必要的。在我研究过的许多事故中，工程师即使不在值班，也会主动参与响应，从而减少平均修复时间（MTTR）。这种额外的能力在评估维护系统的实际要求时通常不会被承认或考虑，但它仍然至关重要。这是由工程师之间的专业素养和礼仪而实现的。负责应对具有挑战性的事故或处理影响大众的中断事件的压力是非常大的。我见过其他工程师在哄孩子睡觉或度假时也会加入进来提供帮助的例子。倦怠、离职和角色转换是不可避免的。维持一个比最佳效率稍差一些的团队，可以让团队通过增加沟通、建立和保持共同点以及交叉培训新技能来提高团队的适应力。
我们所想的工作完成方式与实际的完成方式之间存在差异。人们应该学习一种评估技能，其专注于已经发生的事情本身，而不是事情发生后展现了哪些事实，这样有助于展示系统在不同条件下的行为方式以及组织和团队在实践中的运作方式。讨论导致故障的因素、隐藏或意外的相互依赖关系以及其他技术细节时，还应包括有关组织压力、约束或有助于（或阻碍）响应的实践细节。即使“小事”也是如此，例如工程师在休息日为什么会注意到 CPU 使用率激增，或者为什么营销实习生是唯一知道工程团队在关键功能发布前一天计划进行重大更新的那个人。当事后评估范围扩大到事件的社会和技术方面的影响时，团队就可以解决软件和组织层面的不良因素，从而在未来实现更具弹性的响应。
一些通过持续学习支持更好的弹性能力的策略包括：
保持谦逊：如前所述，不准确或不完整的心理模型是大型分布式软件系统操作中无法避免的事实。倾听和提出澄清问题有助于创造很多微学习机会来更新错误的心理模型（包括你自己的！）
不要假设每个人都有一样的认知：在可能的情况下，总是从经验最少的那个人对特定问题、交互或情况的理解开始讨论，然后从那里开始，在审查过程中添加技术细节和背景。这就为所有人提供了共同的理解基础，并有助于找出那些被普遍认同但错误的假设或信念。
让学习成果广泛传播：重要的是，组织可以通过创建易于共享，可读和可访问的工件（包括文档、录音和可视化）来扩展学习成果，这些工件允许公开提问和回答问题以促进知识共享文化，并且可供整个组织的多方，甚至非工程角色来使用。“讲述事件故事”的叙述方法引人入胜，有助于读者理解为什么某些行动或决定在当时是有意义的。这是一个微妙但非平凡的框架。它鼓励读者好奇，促进同理心，而不是妄下判断。
与其他所有关键的绩效驱动因素一样，弹性能力也是需要投资的。不愿或无法投资系统性方法的组织可以通过尽可能利用重新修订、重新识别、重新规划、重新配置和重新审查的活动、互动和实践类型，以较小而可重复的方式重新分配资源以实现弹性绩效。通过这样的做法，我们可以让软件团队在不确定、时间紧迫和压力巨大的条件下更有效地协调和协作，以改善运营成果。
Laura Maguire 的研究重点是现代工作之所以具有挑战性的原因。她特别感兴趣的是支持需要应对复杂性、管理多个相互竞争的目标、应对不确定性以及处理人机团队的时间压力的工作。她是一位国际主题演讲者、STEM 女性的导师和倡导者。Laura 热爱学习，喜欢与世界各地和各个领域的同事和观众分享知识，以增进对日常工作的理解。
Adaptive Responses to Resiliently Handle Hard Problems in Software Operations (https://www.infoq.com/articles/adaptive-responses-resilience-software-operations/)
声明：本文由 InfoQ 翻译，未经许可禁止转载。