PDF揭示人类绩效在软件中的关键作用
现在是时候重新审视我们对面向互联网的软件系统的人性化方面的认识了。
David D. Woods 和 John Allspaw
在现代面向互联网的软件系统中，人是事件响应中必不可少的自适应能力的独特来源。《acm queue》本期文章旨在探讨人类绩效的形式，这些形式使得现代关键业务系统尽管规模庞大且复杂，但仍能保持稳健和弹性。
在本期四篇文章的第一篇中，Richard Cook 重新构建了这些面向互联网的系统的工作方式，他提出了富有洞察力的“线上/线下”框架，将人类绩效与软件工具连接起来。他将线上的人类绩效与线下的技术绩效联系起来。
然后，Marisa Grayson 考虑了线上的一项关键功能，通过研究异常响应的认知工作，特别是事件响应期间如何探索假设。
在她的文章中，Laura Maguire 扩展了线上框架，通过检查当事件威胁服务中断时，跨多个角色之间的协调是什么样的，特别是人们如何适应以控制这种协调的成本。
最后，J. Paul Reed 拓宽了视角，揭示了影响从事件中学习的方式的因素，这些方式可能是狭隘和被动的，也可能是广泛和主动的。广泛、主动的学习与时俱进，不断为自适应能力的来源充电，从而实现弹性的绩效。
所有文章都强调了一个观点，即事件是更新和修订组织产生和维持自适应能力的模型的机会，以便在系统增长并在新的规模上运行时处理令人惊讶的挑战。
虽然软件工程和运维社区专注于技术的复杂性是合理的，但人们如何完成他们的工作却很少受到关注。这是一个关键的差距，因为现代关键业务系统之所以能良好运行，是因为人们的自适应能力。更具体地说：如果没有人们彼此之间进行的认知工作，所有软件系统最终都会失败（有些是灾难性的！）。1
随着业务关键型软件系统变得更加成功，其复杂性必然会增加。这种复杂性使得这些系统本质上是混乱的，因此令人惊讶的事件是更大规模和速度提供服务能力的一部分（有关基本介绍，请参阅“弹性是一种动词”10）。无论过去的可靠性统计数据如何，事件都将继续带来需要弹性绩效的挑战。
弹性工程2,9的研究表明，人们通过以下方式产生弹性绩效：（1）进行异常响应的认知工作；（2）在威胁服务中断的事件期间协调联合活动；（3）利用从事件中吸取的教训，修订他们对系统实际 工作和故障方式的模型。尽管系统不断变化，但人们的弹性绩效弥补了系统的混乱性。
如果您认为系统之所以启动、运行和成功，是因为人们拥有的自适应能力，那么事件可以被重新定义为持续的机会，用于更新和修订心理模型，随着组织/技术/基础设施的变化、增长和扩展。4
人类绩效与软件工程
CDI（关键数字基础设施）包括工程师用于开发、更改、更新和运行软件以实现有价值的服务的设施。这包括创建企业为客户提供的价值所需的所有组件：技术堆栈、代码存储库、数据源以及用于测试、监控、部署和性能测量的各种工具，以及交付这些服务的各种方式。
Cook 在他的开篇文章中指出，仅关注技术的讨论 忽略了面向互联网的应用程序运营中实际发生的事情。Cook 文章中的图 1 揭示了线上进行的认知工作和联合活动，并将开发和运营的技术和工具放在线下。这里的“线”是表征线。没有人可以直接检查或影响线下运行的流程；所有理解和行动都通过表征来介导。
图表中的线上区域包括参与保持系统运行和扩展其功能的人员。他们是准备部署新代码、监控系统活动、重新架构系统等的人。这些人会问诸如以下问题：它现在在做什么？它为什么要这样做？它接下来要做什么？这种认知工作——观察、推断、预测、计划、干预等——是通过与表征而不是事物本身互动来完成的。有趣的是，一些表征（例如，仪表板）是由软件工程师和其他利益相关者设计（和为之设计）的。
请注意，所有线上参与者都对线下的内容有心理模型。这些模型因角色和经验以及个人观点和知识而异。请注意，参与者的心理模型是不同的。这是因为复杂、高度互连的系统的模型保真度存在普遍限制。8现代软件系统也是如此，事件响应研究证明了这一点；在事件期间或之后的验尸会议上，经常听到的一句话是：“我不知道它是那样工作的。”9
系统是混乱的
系统的开发和运行都使用有限的资源，并且在不断变化的环境中运行。 计划、程序、自动化和角色本质上是有限的；它们无法涵盖这些系统遇到的所有活动、事件和需求。系统在多种压力下运行，并且几乎总是在降级模式下运行。10
复杂系统的自适应能力在于人。正是人适应以应对不可避免的挑战、压力、权衡、资源稀缺和意外情况。 二战时期的一个俚语概括了系统的状态以及使事物运转的人们的接受程度：SNAFU（情况正常，一切都搞砸了）。 士兵们用这个词承认这是通常的状态，他们的工作是使有缺陷和难以驾驭的部件工作。如果 SNAFU 是正常的，那么 SNAFU 捕捉是必不可少的——弹性绩效取决于在标准计划之外适应的能力，而标准计划不可避免地会崩溃。
无论技术如何促进，SNAFU 捕捉都是一项根本的人类能力，对于在变化和意外的世界中生存至关重要。某些角色中的某些人为 SNAFU 捕捉提供了必要的自适应能力，尽管捕捉本身可能是局部的、远距离视角不可见的，甚至是在组织视野之外进行的。6
复杂系统中的意外是不可避免的。弹性工程增强了应对意外所需的自适应能力。具有自适应能力的系统随时准备适应。它在某种程度上准备好改变其当前的工作方式—其模型、计划、流程、行为—当它面对异常和意外时。8适应是修改计划以继续适应不断变化的情况的潜力。 NASA 休斯顿任务控制中心是这种能力的一个积极案例研究，特别是航天飞机任务控制器如何培养处理异常的技能，他们预计他们将要经历的下一个异常不太可能与他们过去练习或经历过的任何异常相匹配。7
基于 IT 的公司存在于一个充满压力的世界中，技术、竞争对手和利益相关者都在不断变化。他们的成功需要扩展和改造基础设施，以适应不断增长的需求并构建新产品。这些因素增加了复杂性（例如，必须应对涉及第三方软件依赖的事件响应）并产生令人惊讶的异常。1,9基于 IT 的公司、组织和政府知道他们会遇到异常，因此需要精通变化并随时准备适应。
异常响应
Marisa Grayson 和 Laura Maguire 的文章揭示了 IT 事件响应是异常响应的认知工作的一个例子。11
Grayson 专注于异常响应期间假设探索的一般功能。假设探索始于识别异常（即，观察到的内容与观察者的期望之间的差异）。这些期望来自观察者对系统的模型和操作的具体背景。在大型、互连且部分自治的系统中，异常识别尤其困难。当监控有关可能相关的事件的不断变化的数据流时，情境感知具有挑战性。对于许多面向互联网的业务系统来说，这是常态：数据流宽且快速流动；正常变异性很高；警报超载很常见；操作和观察以及技术都是高度分布式的。更糟糕的是，通常可用的表征需要长链的推断，而不是支持异常行为的直接可视化。
Grayson 的结果显示了从业者如何生成、修订和测试可能解释意外发现的潜在解释。她开发了一种基于线上/线下框架对假设探索进行图解和可视化的方法。
她的图表揭示了探索的典型流程，其中生成多个假设来解释异常，并且这组假设会随着时间的推移而变化。随着响应团队对情况评估达成一致，他们经常修订被认为是候选假设的内容以及他们在各种可能性中的相对信心。在她的研究中，Grayson 发现，有时一个被认为是已证实的假设后来会被新的证据推翻。
事后看来，人们关注解决事件的答案。然而，异常响应的质量与生成和考虑各种假设以及随着情况随时间变化而修订假设的能力直接相关——例如，当解决问题的干预措施最终产生额外的意外行为时。
控制联合活动中协调的成本
Maguire 通过检查人们如何适应以控制联合活动协调的成本来扩展线上发生的事情。
跨角色和视角的协调价值已得到充分证实。在太空任务运行中心等高风险世界中处理异常就是一个例子。7但对联合活动的研究也表明，协调成本可能会抵消让多人和自动化参与情境管理的好处。5早期的研究着眼于以物理控制室为基础的异常响应，响应人员在开放的工作空间中并置。
面向互联网的软件系统的管理方式不同，因为响应人员通常是物理分布的。人们通过 ChatOps 频道连接，无法相互观察。地理位置分散的团队的协调认知成本更高。Maguire 的文章描述了这如何既促进又限制了联合活动。例如，增长导致了第三方软件依赖，这需要在异常响应期间跨组织（和公司）边界进行协调。
在她的研究中，Maguire 提出了一个问题：在不确定性、风险和压力下进行异常响应时，从业者如何控制协调成本？她的结果基于对软件工程师在一系列事件响应案例中体验这些“成本”的研究。他们强调了传统协调角色和管理协调成本的方式的缺点（例如，事件指挥官、严格遵守程序（基于事件指挥系统）以及使用 IT 义肢（如机器人）的努力）。Maguire 的工作揭示了当协调成本变得更大时，人们如何适应。理解这些适应可以帮助设计有效的工具，改变角色，并构建组织框架，以增强联合活动并降低事件响应期间的协调成本。
学习是什么让事件响应有效
我们想象事件发生（和解决）的方式与它们实际 发生的方式之间存在显着差距。3J. Paul Reed 的最后一篇文章考虑了组织如何学习弥合这一差距。Reed 的研究强调了一个重要但通常不可见的线上工作驱动因素——人们如何捕捉过去事件的持久记忆，以及那些当时不在场或未参与处理事件的人员如何使用这些记忆。人们如何理解发生了什么？他们如何分享关于事件发生原因的归因？为什么有些事件比其他事件更能引起组织的关注？
组织通常保留有限的资源来研究导致（或接近）重大服务降级的事件。社会、组织和监管因素限制了从此类事件中学习的可能性。相比之下，关于弹性绩效和自适应能力的主动学习侧重于认知工作通常如何在所有困难、有限的资源、权衡和意外情况下顺利进行 。之前的报告中的数据和分析说明了深入检查事件响应的认知工作可能获得的潜在见解。2,9
结论
总而言之，本期中的四篇文章概述了表征线上正在发生的事情，尤其是在事件响应期间。这些活动对于构建、部署和修订现代信息技术至关重要，而我们的社会越来越依赖这些技术。理解人们如何检测异常、共同解决事件以及从这些经验中学习，对于未来拥有更具弹性的系统至关重要。
人类专业知识与现代系统的技术组件之间的密切关系无法进行线性分解。正如 Cook 所表明的那样，这里实际上只有一个系统——系统的运行和演变取决于对人们的适应能力有时会受到技术的促进，有时会受到技术的阻碍的认识。Grayson、Maguire 和 Reed 的文章演示了如何通过认知工作、联合活动和自适应能力的视角来看待事件，从而为这种人-技术系统如何真正工作提供了新的见解。事件是挑战，揭示了系统的工作方式与人们想象的不同。事件和事件后调查的经验提供了学习机会，突出了心理模型需要修订的地方。
然而，这些文章更进一步。它们共同强调了每个人关于面向互联网的软件系统的心理模型都需要进行重大修订。人类的认知、协作和适应性绩效对于软件工程和运营至关重要。随着提供关键服务所需的软件系统的规模和复杂性持续增加，线上发生的事情将仍然是所有关于增长、成功、不确定性和崩溃故事的核心。
理解、支持和维持线上能力需要所有利益相关者能够不断更新和修订他们对系统混乱但通常设法正常工作的模型的认识。这种持续重新审视系统真正工作方式的开放态度需要扩大从事件中学习的努力。这些文章提供了所有人都可以遵循的具体路径，以学习如何从事件中学习。
参考文献
1. Allspaw, J. 2016. 人为因素和人体工程学在网络工程和运营中的实践：驾驭关键但晦涩难懂的自动化海洋。见 人为因素和人体工程学实践，编辑：S. Shorrock 和 C. Williams，313-322。博卡拉顿，佛罗里达州：CRC Press (Taylor & Francis)。
2. Allspaw, J. 2015. 压力下的权衡：解决互联网服务中断的团队的启发式方法和观察。硕士论文。隆德，瑞典：隆德大学。
3. Allspaw, J. 2018. 我们想象的事件与事件的实际情况。PagerDuty Summit 2018。YouTube； https://www.youtube.com/watch?v=8DtzmV1jiyQ。
4. Allspaw, J., Cook, R. I. 2018. SRE 认知工作。见 寻求 SRE：关于大规模运行生产系统的对话，编辑：D. Blank-Edelman，441-465。奥莱利媒体。
5. Klein, G., Feltovich, P. J., Bradshaw, J. M., Woods, D. D. 2005. 联合活动中的共同基础和协调。见 组织模拟，编辑：W. Rouse 和 K. Boff，139-184。威利。
6. Perry, S. J., Wears, R. L. 2012. 地下适应：来自医疗保健的案例。认知、技术与工作 14(3), 253—60； doi.org/10.1007/s10111-011-0207-2。
7. Watts-Perotti, J., Woods, D. D. 2009. 合作倡导：在异常响应中整合不同观点的策略。计算机支持的协同工作：协同计算杂志 18(2), 175—98。
8. Woods, D. D. 2015. 弹性的四个概念及其对弹性工程的影响。可靠性工程与系统安全，141, 5-9；doi:10.1016/j.ress.2015.03.018。
9. Woods D. D. 2017. 来自 SNAFUcatchers 复杂性应对研讨会的 Stella 报告； https://snafucatchers.github.io/。
10. Woods, D. D. 2018. 弹性是一种动词。见 IRGC 弹性资源指南（第 2 卷）：复杂互连系统的弹性领域，编辑：B. D. Trump、M.-V. Florin 和 I. Linkov。洛桑，瑞士：EPFL 国际风险治理中心。 https://www.researchgate.net/publication/329035477_Resilience_is_a_Verb。
11. Woods, D.D., Hollnagel, E. 2006. 联合认知系统：认知系统工程中的模式。博卡拉顿，佛罗里达州：CRC Press (Taylor & Francis)。
David D. Woods，俄亥俄州立大学综合系统工程教授， 在过去 40 年中，几乎在所有高风险复杂环境中研究了人类与自动化和智能系统的协调。 自 2000-2003 年开始，作为对几起 NASA 事故的响应的一部分，他开发了关于脆弱系统的危险以及需要投资于维持弹性来源的弹性工程。 他的著作包括 人为错误背后 (1994/2010)、弹性工程：概念和戒律 (2006) 和 联合认知系统（基础，2005 年/模式，2006 年）。他是人为因素和人体工程学学会和弹性工程协会的前任主席。
John Allspaw 在软件系统工程和运营领域工作了 20 多年。John 的出版物包括 容量规划艺术 (2009) 和 Web 运营 (2010) 以及 DevOps 手册 的序言。 他 2009 年与 Paul Hammond 在 Velocity 上的演讲“每天 10+ 次部署：开发和运营合作”帮助启动了 DevOps 运动。John 曾担任 Etsy 的 CTO，并拥有隆德大学的人为因素和系统安全硕士学位。
版权 © 2019 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue 杂志第 17 卷，第 6 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑非加密哈希函数的评估标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多用于加密哈希的标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者普遍认为，良好的开发者体验可以提高软件交付效率和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的过程中，它容易受到时尚的支配，并且可能会忘记或忽略一些它面临的永恒问题的经过验证的解决方案。用例最早于 1986 年引入，并在后来普及，是这些经过验证的解决方案之一。
© 保留所有权利。