下载本文的PDF版本 PDF

线上之下

面向互联网系统的韧性依赖于表示线以上的内容。

理查德·I·库克,医学博士

在线上表示层之上工作的人员不断构建和更新他们对线下内容的模型。这项活动对于面向互联网系统的韧性至关重要,并且是适应性能力的主要来源。

 

想象一下,所有参与维护您的网络企业正常运行的人员突然停止工作。该系统还能按预期功能运行多久?几乎每个人都认识到,企业软件系统的“维护和保养”需要或多或少的持续关注。需要干预的问题定期出现——对于许多企业来说,每周几次;对于其他企业来说,每天几次。

公开场合,公司通常将这些事件描述为偶发且轻微的——在系统上等同于感冒或流感,很容易在家中或在医生诊所治疗。然而,即使是粗略地了解一下内部情况,也会发现情况更像是重症监护室:持续监控,为管理相关资源而进行的精心斗争,以及由轮班工作的全天候专家团队进行的多次干预。这些系统远非健康强壮,而是脆弱且常常非常脆弱的组合,它们之所以能够勉强运行,仅仅是因为它们周围的人了解它们的工作原理、它们如何失效、可能发生什么以及如何处理。

正在发生什么?

技术软件/硬件组件与制造、修改和维修它们的人员之间亲密且持续的关系既引人注目又令人沮丧。基于互联网的企业所拥有的卓越影响力和能力源于将人类和机器不可分割地联系到一个不断变化、非确定性的、完全分布式的系统中。

他们对这些位如何以及为何如此组装的普遍和特定知识,使这些人有能力构建、维护和扩展企业技术。这些位不断变化,绝对需要调整和刷新知识、期望和计划。跟上这种变化是一项艰巨的任务,但这并非不可能——仅仅是勉强可能——原因如下:

1. 干预故障的人员通常与最初构建这些东西的人员相同。 诊断人员和维修人员通常与设计、编写、调试和安装现在发生故障的软件和硬件的人员相同。他们参与了产生和排列这些人为因素的复杂性、依赖性和假设。即使他们没有参与,他们也经常与其他人一起工作和互动,并在此过程中了解了谁做出了贡献以及谁是这些领域的专家。这使得该社区与其他操作员社区(例如,飞行员、护士)区分开来。

2. 干预人员可以前所未有地访问组件的内部结构。 修复人员可以查看源代码、询问进程以及近乎实时地查看活动统计摘要。在其他任何领域,都没有如此多的细节可用于排除故障。诚然,大量可访问的材料也是一个挑战:可能难以找到有意义的因果关系线索,并将其追溯到源头。同样,集体通常是关键资源——有人知道事物在哪里以及如何连接和依赖,因此处理正在发生的事件的工作通常包括弄清楚什么是相关的以及谁的专业知识与模式匹配的工作。

3. 持续的故障不断地将注意力转移到他们理解不完整或不准确的地方。 存在持续不断的异常情况需要引起注意。由此产生的参与会产生对当前重要的脆弱性、局限性和反常性的洞察力。异常是指向问题表现出来的区域,Beth Long 称之为“爆炸点”。这些也是进一步探索可能获得回报的领域。这是有价值的信息,尤其因为持续的变化会移动故障的位置。这也是为什么事件的纵向集合很少被证明有用的原因:过去的表现并不能保证未来的回报。

4. 存在一个独特的实践社区,具有自己的精神。从事这项工作的人们形成了 Jean Lave 和 Etienne Wenger 称之为实践社区的组织。3 这是一个复杂的网络,其特点是同时共享知识、分配责任和激发行动的沟通和流程。该网络具有一些显着特征。新人一直在加入,他们融入社区导致其成员重新审视旧有的基础。由于如此多的学习发生在工作中和真实而非模拟的环境中,因此它具有行会的性质。由于相关人员经常更换工作,因此行会随着时间的推移和跨公司界限而扩展。这产生了专业知识在整个行业的扩散,并同时创建了一个桥接公司界限的关系网。

进入该网络的障碍很低。目前还没有正式的培训过程,也没有类似领域(例如,医学)的权威认证。这促进了社区的快速发展,同时也造成了招聘实践中的不确定性(例如,代码编写练习)。

这个实践社区似乎有一种独特的 精神,非常强调保持系统正常运行并防御故障、损坏或中断。该社区既重视技术专业知识,也重视在压力下运作的能力;社区成员资格取决于是否成功度过困难和苛刻的局面。同样,威胁事件期间工作的集体性质鼓励合作和支持。正如 Lave 和 Wenger 对其他实践社区所观察到的那样,此处的掌握是通过“合法的边缘参与”获得的。

5. 这项工作要求很高,并且随着时间的推移仍然具有挑战性。保持企业持续运营和发展需要该团体提供的专业知识和奉献精神。尽管技术爱好者预测人员在系统中的作用会逐渐减弱,但没有迹象表明这种情况正在发生。故障之间的间隔非常短,补救故障所需的措施变化多端,只有齐心协力、积极主动地补充网络并刷新其知识才有可能取得成功。

 

表示线

所有这些特征都是环境的产物,同时也是环境的推动因素。它们在很大程度上出现是因为技术人为因素发展迅速,但更重要的是因为人为因素无法直接观察或操纵。计算只能通过合成的表示来检测其过程。同样,它也只能通过表示来操纵。

图 1 显示了一个面向互联网的系统。水平线包括人们在线以上工作时可用的所有表示,包括所有显示器、屏幕和其他输出设备,以及键盘和其他输入设备。这条线以下是技术人为因素:代码库、IDE、测试套件、编译器、CI/CD(持续集成/持续交付)管道组件以及计算能力本身,包括技术堆栈和服务。表示线以上是人员、组织和流程,它们塑造、指导和恢复位于该线下方的技术人为因素。

Above the Line, Below the Line

在线以上工作的人员通常使用具体、现实的语言来描述线下的内容。然而,令人惊讶的是,线下没有任何东西可以直接看到或作用于。构成表示线的显示器、键盘和鼠标是线下存在任何东西的唯一有形证据。

对线下所有事物的理解都是由布鲁诺·拉图尔和史蒂夫·伍尔加提出的意义上构建的2 我们对线下事物的“了解”——我们能够了解什么——取决于从屏幕和显示器上出现的表示中得出的推论。这些推论借鉴了我们的心智模型——那些经过多年发展和完善,然后通过近期事件进行修改、更新、完善和聚焦的模型。我们对事物如何运作、将要发生什么、可能发生什么、哪些途径是开放的以及危险在哪里的理解都包含在这些模型中。

 

启示

立即显而易见的是,没有任何个人的心智模型能够做到全面。范围和变化率确保任何完整的模型都将过时,而任何新的模型都将不完整。大卫·伍兹在所谓的伍兹定理中清楚地说明了这一点:4

 

随着系统复杂性的增加,任何单个代理自身对该系统模型的准确性都会迅速降低。

 

1. 这是一个复杂的系统;它总是在变化。组件的组成和排列使得系统的行为是非确定性的。线上和线下都在进行持续且通常是实质性的变化。无法捕获其状态,也无法重现给定状态。所有系统模型都是近似值。不可能预料到系统可能崩溃的所有方式或防范所有意外情况。

线上和线下的复杂程度相似。随着线下复杂性的增加,线上的复杂性也随之增加。

2. 协作是必要的;协作是例行的。 许多偶发性活动——特别是超出处理轻微异常的故障排除和修复——无法由单个人完成,需要协作。尽管偶尔事件的需求可能与第一个遇到它的人的知识和能力非常匹配,但大多数事件的工作可能需要几个人(或许多人)的共同行动。这些事件考验着结合、测试和修改心智模型的能力。这可以在事件对话和事件后审查中看到。

3. 协调协作努力具有挑战性。发挥专业知识并协调专业知识应用的工作非常重要,并且通常在严重的时间和后果压力下进行。一个蓬勃发展的兴趣领域是将各种方法应用于识别和吸引人们参与解决问题,生成富有成效的并行行动线程,将这些线程重新组合在一起,以及评估和做出决策。许多组织正在开发支持工具、管理流程和培训来满足这一需求。特别是,控制这些并行和联合活动的协调成本仍然是一个持续的挑战。

对于某些事件,故障排除和维修在线上和线下都是高度本地化的。当线下组件与线上个人或团队之间存在一对一映射时,协调工作可能很小。对于其他事件,故障排除和维修可能很费力,因为异常的表征远离其来源——事实上,如此之远,以至于不清楚谁的知识可能有用。

这些事件通常与角色和职能相对明确且任务分配是主要关注点的领域中的事件截然不同。关键数字服务中协作解决问题的协调是深入研究的主题,也是许多方法和工具的目标,但这仍然是一个棘手的问题。

4. 线上和线下都可能发生类似的故障和失效。跨表示线的混响倾向于塑造线下(特别是功能边界)的结构,使其类似于线上结构,反之亦然。由于线上结构和功能与线下结构和功能并行,因此可以预期可能发生的机能障碍形式也会并行。两者都是分布式系统。这表明,特定的线路故障形式(例如,对分区的敏感性、CAP [一致性、可用性、分区容错],甚至饱和或级联故障的可能性)也将在某种程度上在线上发现。

5. 这是一个系统,而不是两个。表示线似乎是一个方便的边界,分隔了两个“系统”,即线下的技术系统和线上的人工系统。线上和线下的互惠因果关系使得这种观点站不住脚。人们不断地与线下的技术互动;他们构建、修改、指导和响应它们。但这些技术以多种方式影响着这些人,而与这些技术的经验会在线上产生变化。这些互动将线上和线下焊接在一起。没有被表示障碍分隔的两个系统;只有一个系统。

20 世纪 70 年代围绕人机交互提出了类似的论点。将计算机和操作员视为独立实体的努力崩溃了,取而代之的是将人和计算机描述为一个“系统”。大规模分布式计算以及类似的分布式编程和操作方法正在更大范围内复制这种经验。

 

事件发生在线上

事件是“一组在时间上受限的,与不良系统行为相关的活动”。1 将某组活动描述为事件的决定是由线上人员做出的判断。因此,事件从有人说它开始时开始,到有人说它结束时结束。与对线下事物的理解一样,事件是构建的

结论

对线下结构和功能的知识和理解不断变化。需要近乎持续的努力来校准和刷新对存在于此的工作原理、依赖关系、局限性和能力的理解。在这种动态情况下,任何个人或团体都永远无法了解系统状态。相反,个人和团体必须对部分、零碎的心智模型感到满意,如果这些模型要有用,就需要或多或少的不断更新和调整。

 

参考文献

1. Allspaw, J., Cook, R.I. 2018. SRE 认知工作。在 Seeking SRE: Conversations About Running Production Systems at Scale, ed. D. Blank-Edelman. O'Reilly Media, 441-465.

2. Latour, B., Woolgar, S. 1979. Laboratory Life: The Construction of Scientific Facts. Beverly Hills: Sage Publications.

3. Lave, J., Wenger, E. 1991. Situated Learning: Legitimate Peripheral Participation. Cambridge: Cambridge University Press.

4. Woods, D.D. 2017. Stella: Report from the SNAFUcatchers Workshop on Coping with Complexity. The Ohio State University; https://snafucatchers.github.io/.

 

相关文章

持续交付听起来很棒,但它在这里可行吗?
这不是魔法,它只是需要在各个层面持续不断的日常改进。
Jez Humble
https://queue.org.cn/detail.cfm?id=3190610

操作系统访问控制可扩展性的十年
移动和嵌入式设备的开源安全基础
Robert N. M. Watson
https://queue.org.cn/detail.cfm?id=2430732

网络的新角色
面向应用程序的网络可以帮助弥合企业之间的差距。
Taf Anthias 和 Krishna Sankar
https://queue.org.cn/detail.cfm?id=1142069

 

理查德·I·库克医学博士是一位国际公认的复杂系统安全、事故和韧性专家。他拥有 30 年的经验,包括在医学、交通运输、制造业和信息技术领域的工作。他最常被引用的出版物是“复杂系统如何失效”和“走向稳固:系统动力学和患者安全后果模型”。他在俄亥俄州立大学任职,并且是 Adaptive Capacity Labs 的负责人。他住在芝加哥。

版权 © 2019 由所有者/作者持有。出版权已授权给 。

acmqueue

最初发表于 Queue vol. 17, no. 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 年首次引入,后来普及,是那些行之有效的解决方案之一。





© 保留所有权利。

© . All rights reserved.