PDF异常响应期间假设探索的认知工作
审视我们如何应对意外情况
Marisa R. Grayson
如今，Web生产软件系统以前所未有的规模运行，需要广泛的自动化来开发和维护服务。这些系统被设计为定期适应动态负载，以避免网络部分过载的后果。随着软件系统规模的扩大和复杂性的增长，观察、建模和跟踪系统如何运行和发生故障变得更加困难。异常不可避免地会出现，对事件响应者提出挑战，要求他们识别和理解异常行为，以便计划和执行干预措施，以减轻或解决服务中断的威胁。 这就是异常响应1。
异常响应的认知工作已在能源系统、航天系统和外科麻醉管理中得到研究9,10。最近，它已被认为是管理Web生产软件系统的重要组成部分。Web 运维也为新的见解提供了潜力，因为原则上，纯数字系统中事件响应的所有数据都可用于支持详细分析。更重要的是，Web 运维的规模、自主能力和复杂性远远超出了先前研究的设置7,8。
来自Web软件公司的四个事件揭示了Web运维中发生事件时异常响应过程的重要方面，本文讨论了其中两个案例。详细检查的一个特定认知功能是假设生成和探索，考虑到晦涩的自动化对工程师构建他们管理的系统的一致模型的影响。每个案例都使用认知系统工程的技术和概念进行了分析9,10。这组案例为了解复杂Web运维系统事件管理中“线上”的认知工作提供了一个窗口（参见本期Richard Cook的“线上，线下”）。（参见Grayson，2018）。
认知工作的真实本质
回顾事件并确定哪里出了问题似乎很容易。困难在于理解实际发生了什么以及如何从中学习。后见之明偏见缩小了学习能力，因为它导致事后审查过度简化人们面临的情况，并忽略了真正的困难。然而，当Web请求失败且客户无法访问内容时，人们会问及什么是故障，驱动观察到的干扰的根本问题是什么，哪些干预措施可以减轻或解决正在经历的问题等等。
软件工程包括在高度动态的环境中进行意义构建，该环境具有广泛且有时令人费解的系统网络中的相互依赖性，这些系统大多隐藏在“线下”。问题会产生影响和干扰，这些影响和干扰会传播并出现在远离驱动行为的源头的地方——高度相互依赖的过程中的远距离效应6。观察和追踪多个自动化过程和子系统的行为是困难且模棱两可的。
参与解决事件的人员带来了关于不同组件、功能和子系统如何互连的心理模型，并在探索可能的解释时更新这些模型。理解和解决异常可能需要连接处理多个过去事件中获得的经验和知识。但是，关于系统如何工作的模型没有一个是完全相同或完整的，因此理解事件需要整合来自不同视角的信息和知识。假设探索和计划干预是跨分布式方的协作过程，这些分布式方可能遍布世界各地（参见本期Laura Maguire的“管理协调的隐性成本”）。
什么是异常响应和假设探索？
异常有多种形式，但响应异常的认知工作涉及一组基本的关键功能。异常具有两个特性：它是异常的和意外的，例如加载主页的响应时间异常缓慢，或在通常流量较低的午夜时段网络需求很高。将异常识别为观察到的系统行为与系统在该上下文中预期行为之间的差异，取决于观察者对系统正在做什么的模型。异常是需要解释的事件，因为当前的系统模型与观察到的情况不符。
换句话说，异常是生成和探索关于正在发生的事情的假设的触发器，如果假设为真，则可以解释异常行为9。随着问题在高度相互依赖的网络中传播，以及采取行动对抗异常行为，多个异常会随着时间的推移而累积。异常变成了一组不断展开的意外发现，并通过生成一组不断展开的候选假设来匹配，以便作为潜在的解释进行测试。
异常响应的认知工作涉及三个相互依赖的活动线：（1）异常识别，从业人员在其中收集和更新要解释的发现集；（2）假设探索，从业人员在其中生成、修订和测试可以解释发现的潜在解释；以及（3）响应管理或重新计划，从业人员在其中修改正在进行的计划，以维护系统完整性，减轻对关键目标的影响，并确定哪些干预措施可以解决问题。这些活动都是时间相关的，并且需要随着时间的推移，根据关于异常及其驱动源的证据的出现、采取的补救措施产生额外的令人惊讶的影响以及解决情况的压力而进行修订，即使不确定性持续存在。
给定一组要解释的发现，假设探索会生成和测试候选假设。有趣的是，研究表明，随着相互依赖规模的增加，假设探索的难度也会增加。在假设生成中，目标是扩大正在考虑的假设集，作为对发现模式的候选解释，并避免过早缩小范围。研究强烈表明，不同的视角——在正确的协作互动中——有助于生成更广泛的候选假设集。在假设探索进行期间，新的事件将会发生，这些事件可能会加强当前的工作假设，详细阐述当前的可能假设集，或推翻当前的工作假设。令人难以置信的自动化速度可以迅速改变信息格局，进一步使假设探索复杂化。
Web运维中的异常响应案例
此处讨论的研究基于从SNAFUcatchers Consortium（https://www.snafucatchers.com/about-us）开发的数据库中的更大案例语料库中抽取的四个案例，该联盟由行业领导者和研究人员组成，专注于理解人们如何在关键数字服务的运营中应对复杂性并产生弹性性能。事件的定义在不同的组织中有所不同，但大多数组织都捕捉到围绕服务损失或降级的情况（例如，Huang等人3）。相关方和公司特定详细信息在分析中被去标识化。
聊天记录文件是从事后记录中收集的，作为每个案例的主要数据来源。聊天记录来自IRC（Internet Relay Chat）或Slack，具体取决于当时使用的主要通信技术。聊天记录没有直接显示工程师在系统上的操作；它们确实记录了个人在线上表达的意图和计划，以响应异常以及跨越线的已记录信号11。此外，考虑到主要渠道中的书面更新，聊天操作证明了观察者隐含立场中异常的出现。数据记录通过与直接了解事件的个人进行的知识启发会话进行了补充。
分析使用了过程追踪方法5。经过多次迭代，通过应用基于异常响应和宏认知功能的认知工作的轻量级编码方案来分析通信日志4,6。重点是几个关键过程，包括（1）事件；（2）假设生成；（3）模型修订；（4）干预；和（5）立场2。这五个方面捕捉了工程师响应级联干扰的期望和沟通流程。
本文重点介绍假设生成和探索的结果。工程师沟通积极的理论，为诊断搜索提供方向，并通过来自多个视角的贡献来拓宽假设探索空间。假设空间的演变被标记并以图表形式布局（图1-3），其特征是添加或排除假设等活动；支持积极假设的发现；假设修改；重新审视过去的假设；心理模型更新；以及困惑和不确定性的点。
可视化假设探索空间
在案例的过程中，软件工程师提出了许多假设。异常的迹象和信号促使新想法的出现，并支持其他解释的演变或驳回。聊天频道实现了关于这些假设的公开交流，在一个理论上在事件期间任何时候都可供所有参与者使用的集体环境中。为每个案例布局了平行的认知路径，以显示所采取的不同行动模式和见解。
图表的顶部部分（如图1所示）描绘了共享环境中的不同假设。每个气泡都有证据和提出的结论的浓缩版本。假设探索空间（顶部部分）标有各种假设气泡，这些气泡由异常迹象（中间）以及共享的干预措施和结果（底部）支持。承诺线分隔了已采取行动的假设，尽管根据具体情况，这些假设可能已被证明是错误的或无关紧要的。假设是相互连接的，显示了随时间的推移既有分歧又有趋同。值得注意的是，一些假设最终被驳回（分钟15和50处的红色轮廓）或被认为与手头的问题无关（分钟50、60和70处的黑色轮廓）。承诺线标记了一个采取行动的点，通常是在不确定的情况下。
（点击查看图1）
每个图的中间部分通过异常迹象和信号的具体时刻来支持上部部分。每个标记表示自事件开始和异常状态以来的时间。底部部分显示了工程师在事件期间进行的干预措施和澄清问题。这些行动可能是诊断性的，也可能是治疗性的，具体取决于具体情况。
信号和干预措施都具有指向单个或多个假设的箭头，其对齐方式类似于“线上，线下”图中指向线上从业人员的表示，该图显示在Cook的文章中。假设在线上生成，并由表示线产生的异常和交互驱动。
接下来，让我们检查两个案例研究，其中调查和缓解的叙述以图形时间线表示形式显示。
广泛延迟的案例
背景：两个数据中心容纳运行网站所需的数据库和服务器。定期存储备份以在出现问题时保护数据，并将其分别保存在每个数据中心内。网络管道连接这两个数据中心，并将它们连接到软件工程师用来维护站点的终端。他们几乎不知道，看似合理的微小更改将产生广泛的后果。
当自动警报被触发时，一位搜索工程师正在值班。他和另一位工程师在黎明前的几个小时内召集了几个人在线诊断多个系统中的异常行为。搜索、memcache、监控图表和生产网站中普遍存在延迟增加、滞后和连接问题。网络连接问题是过载的驱动源，尽管搜索和运维工程师并没有立即意识到这一点。他们看到了网络退化的症状，但访问受限，无法追踪根本问题。他们的初步假设是试探性的，因为他们收集了更多信息。
如图2顶部部分所示，早期采取的行动是切换服务器组。假设探索空间（顶部部分）由工程师在聊天记录中记录的异常迹象（中间）以及共享的干预措施和结果（底部）支持。在本例中，假设最终收敛，超过了行动计划的相对界限。通常，一半的问题不会影响几乎相同的另一半。然而，这个假设很快就被放弃了，转而关注关于是什么驱动了广泛干扰的其他想法。
（点击查看图2）
图2的顶部部分显示了工程师的假设演变，因为他们从一个想法转向下一个想法。红色部分（时间轴中分钟15和50左右的深色轮廓假设）被证伪，黑色部分被认为与手头的问题无关。下面的两个部分分别记录了异常行为的实例和具有共享结果的干预措施。这两组都为事件过程中提出的不同假设提供了证据和背景。例如，30分钟过去了，关于驱动问题的几个假设形成。对搜索和memcache的几个连接错误导致一些工程师得出结论，memcache的性能正在引发其他问题。与此同时，其他工程师正在争论网络问题是否是减速的实际原因。
这些影响是广泛的，并且远离真实问题，没有明显的联系。最终，工程师们追踪到了问题的更深层来源，他们的结论得到了对所需指标具有更大访问权限的网络工程师的支持。他驳斥了memcache理论，并解释说系统内的网络流量异常高。瓶颈是数据中心之间传输备份的管道，该管道还承载着对站点其他主要功能至关重要的数据。这些影响表现为整体缓慢，因为几乎没有资源可以持续促进站点上除备份以外的其他功能。备份过程的波动足以允许某些带宽被其他区域使用，但总体而言，所有功能的延迟都非常高。系统其他部分需要通过同一路径访问服务器，这增加了管道的过载，从而有效地破坏了系统。
在数据中心之间传输网络数据的中继卡没有节流阀来防止其资源能力达到最大值。管道通常被超额订阅，这意味着如果满负荷使用，输入可能会多次超过路径的负荷。资源利用率通常远低于理论阈值，因此权衡风险以换取通过公共路由实现的更大可访问性。这种情况的物理类比是一根管道，通常只有少量水流过，现在一次性被洪水淹没。在这种情况下，其他功能缺乏带宽，无法适应资源的缺乏。
大约一个小时后，一位工程师回忆起最近对备份结构的更改，之后错误神秘地消失了。到此时，假设已经超过了承诺线，因为工程师们已经决定了行动方案。在本周早些时候，备份过程已更改为跨两个数据中心进行，而不是保留在每个数据中心内。本质上，服务器现在将数据发送到另一个数据中心的备份服务器，而不是发送到同一数据中心内的备份服务器。由于数据库备份通常每周发生一次，因此在启动本周的备份过程之前，系统的性能并未受到影响。来自网络工程师的新视角和证据消除了不确定性，从而明确评估了问题的根源，并为解决方案提供了行动方案——恢复到旧的备份方案，直到他们可以开发一个不会使系统过载的方案。
请求消失的案例
这种设置听起来可能很熟悉：一组服务器（包括数据库和API）由负载均衡器管理。顾名思义，负载均衡器动态地在它监管的服务器之间分配负载或请求，以避免任何特定资产过载。通常，此过程工作正常，没有干扰，但这次除外。
第一个警告信号来自一位产品工程师的自定义电子邮件警报，指出API服务器存在连接错误。这些错误是间歇性的，并且很难在多个人之间一致地重现。正常的警报阈值未被触发，因此产品工程师警示运维和基础设施中的其他知识渊博的工程师协助。典型的日志监控器中没有出现错误，这对于响应者来说似乎非常奇怪。他们确定连接未到达服务器，但无法支持他们关于问题所在位置的假设。有人回忆说，最近安装了一个分流接头，通过将少量流量转移到某些服务器来在将这些服务器添加到生产环境之前对其进行测试。
如图3所示，软件工程师决定尽早移除测试服务器，但这并没有解决问题。在本例中，共享的假设空间（顶部）具有几个不同的假设，其中一些假设已采取行动并最终合并。异常（中间）在整个事件中相当一致，而干预措施（底部）则处理质疑和遵循不同的调查方向。
（点击查看图3）
聊天中讨论了许多假设，参与者可以使用这些假设，尽管需要重新审视旧的想法并整合新的想法才能形成任何令人满意的结论。尽管参与者后来意识到某些假设是不正确的，但他们通过遵循几个调查路径发现的信息演变成其他假设。
最初的响应者对负载均衡器日志的访问权限有限，并且主要关注应用程序级组件，但没有取得太大成功。一位具有负载均衡器访问权限的网络工程师被召集来检查连接，并在有问题的同一服务器集群上找到了一个旧规则。在移除该规则和最近添加的分流规则后，工程师发现错误消失了。他们与实施分流规则的基础设施工程师一起确定，这些规则出乎意料地相互作用并重新激活了旧规则，该规则将请求定向到一个不再存在的服务器。
负载均衡器结构的基本假设是它不会将流量发送到无法处理流量的服务器。它通过运行状况检查来实现此目的，运行状况检查是一个简短的请求响应，用于验证服务器是否具有可用容量。然而，分流规则不自动进行此运行状况检查，并且可以将请求发送到可能不存在的服务器。此外，如果一组规则具有有效目标而另一组规则没有有效目标，则多个规则的交互可能会对该检查产生一定的影响。工程师很难估计丢弃的请求对其系统功能和最终用户体验的下游影响，因为转移的请求量非常小且监控不可见。
先前的测试规则未得到积极管理，并且留在机器上，对网络流量没有明显的直接影响。添加了一个正常的测试结构，该结构无意中重新激活了一个较旧的分流规则，该规则改为将流量发送到一个已停用的服务器。在此发现之后，对于为什么新规则与旧规则相互作用（当它们应该是独立的时）仍然存在困惑。在对效果没有很大把握的情况下，假设被付诸行动，例如完全移除分流规则。在负载均衡器上具有最大访问权限和可指导性的网络工程师也难以理解触发丢弃请求的黑洞的纠缠。最终，出现了一些理论作为看似僵尸规则的合理解释，尽管在没有进一步测试的情况下，没有达成明确的共识。
探索新的假设格局
每个案例中的工程师组以不同的方式探索了他们的假设空间，尽管两者在达到事件的“结论”时都面临共同的挑战。事件的真实性质在于日常运营的持续流动，而不是事后分析中捕获的短暂持续时间。尽管如此，捕获的案例确实显示了相关的模式，例如狭隘地和更广泛地探索。
第一个案例看到想法收敛于一个相当自信的行动计划。相比之下，第二个案例的工程师们早期就致力于假设，并且有许多不同的路径，但没有明确的解决方案。两者最初的响应都未能成功实现预期结果，但提供了更多信息来指导后续假设。每次对系统的探测和搜索都激发了新想法添加到集体假设空间。
这两个案例中的工程师都展示了解释数据和为模棱两可的信号提供背景信息的重要技能。底层自动化是不透明的，尤其是在执行高度自主的功能时，例如在负载均衡器中分配网络流量。然而，从源头远处出现的影响以高度可解释的方式呈现。每个案例都展示了工程师在事件过程中可观察到的一组不同的信号。相互依赖的不透明网络的另一个副作用是掩蔽，这掩盖了可能相关的自动化驱动功能。过载可能发生和浮出水面的路径的多样性是网络复杂性的症状，这需要更深入、更具信息性的调查措施。
假设探索因隐藏在可观察的监视器下方的相互作用效应而变得复杂。有限的可测量信号、掩蔽和奇怪的循环限制了人类响应者理解系统和采取适当纠正措施的能力。时间也影响了调查范围。最近的更改被优先考虑为当前问题的可能贡献者，即使证据可能支持其他解释。
追踪时间上不连续的更改要困难得多，例如一周前或长期选择留下的潜在影响，这些影响等待特定情况激活。追踪复杂软件系统中的异常的一个主要困难是系统不断变化的状态。每天都会发生数百次更新，长度各异，但它们的影响可能要到很久以后才会作为累积效应感受到。当前的警报平台通常提供本地化信息，这可以帮助支持重点假设，也可以缩小调查范围。这些案例中的响应者因缺乏对自动化底层动态的可观察性而受到阻碍。
本文中假设探索空间的追踪具体揭示了事件管理的意外模式：（1）线上存在多个已承诺的假设和干预措施；（2）在短时间内生成了许多假设；（3）在一个假设被承诺后，不断做出更多的行动和假设；以及（4）高度动态系统的opaque性和复杂性产生了远距离效应，这使得假设探索变得复杂。
系统和自主功能的复杂性促使调查人员协作并探索多个假设以响应异常。不同的视角扩展了所考虑的假设，并有益地拓宽了调查范围。工程师在聊天记录中频繁地明确评论相互更新彼此的心理模型；这一发现支持了Woods关于发现和填补理解差距的重要性的定理7。
假设演变的图表还证明了通过通信渠道的集体想法空间的影响。多个假设的早期分歧导致了一些试探性的行动承诺，以及排除了不相关的贡献。被丢弃的想法通常有助于其他路径获得朝着充分解释异常的总体收敛的动力。个人响应者的独特经验、技能组合和角色有助于解决复杂的挑战。
最终，分享想法和调查多个假设足以拓宽工程师对问题的看法，从而找到合理的解决方案。无论是证据的累积进展还是在找到正确的监控来源后的顿悟时刻，事件响应者都能够进行干预并保护软件系统的功能。高可靠性的持续开发和部署迫使工程师跟上变化的步伐并适应持续的挑战。他们的假设探索应得到他们每天使用的工具的支持，因为他们已经在解决最终用户甚至不知道的问题。
参考文献
1. Allspaw, J. 2015。压力下的权衡：解决互联网服务中断的团队的启发式方法和观察。硕士论文。瑞典隆德：隆德大学。
2. Chow, R., Christoffersen, K., Woods, D. D. 2000。支持分布式异常响应和重新计划的通信模型。在人类因素和人机工程学学会年会论文集 44 (1), 34-37。Sage 出版社。
3. Huang, P., Guo, C., Zhou, L., Lorch, J. R., Dang, Y., Chintalapati, M., Yao, R. 2017。灰色故障：云规模系统的阿喀琉斯之踵。在第16届操作系统热点主题研讨会论文集, 150-155。。
4. Klein, G., Ross, K. G., Moon, B. M., Klein, D. E., Hoffman, R. R., Hollnagel, E. 2003。宏认知。IEEE 智能系统 18(3), 81-85。
5. Woods, D. D. 1993。实验心理学实验室之外的认知研究的过程追踪方法。在行动中的决策制定：模型和方法，编辑。G. A. Klein, J. Orasanu, R. Calderwood, C. E. Zsambok, 228-251。韦斯特波特，CT：Ablex 出版社。
6. Woods, D. D. 1994。动态故障管理中的认知需求和活动：溯因推理和干扰管理。在报警设计中的人为因素，编辑。N. A. Stanton, 63-92。布里斯托尔，宾夕法尼亚州：Taylor & Francis。
7. Woods, D. D., 编辑。2017。STELLA：来自 SNAFUcatchers 关于应对复杂性研讨会的报告；https://snafucatchers.github.io。
8. Woods, D.D. 2018。战略敏捷性差距：组织如何在动荡的世界中缓慢而陈旧地适应。在高风险公司中的人和组织因素，编辑。F. Daniellou 和 R. Amalberti，法国图卢兹：工业安全文化基金会 (FONCSI)。
9. Woods, D. D., Hollnagel, E. 2006。异常响应。在联合认知系统：认知系统工程模式, 69-95。博卡拉顿：CRC/Taylor & Francis。
10. Woods, D. D., Hollnagel, E. 2006。自动化惊喜。在联合认知系统：认知系统工程模式, 113-142。博卡拉顿：CRC/Taylor & Francis。
11. Woods, D. D., Patterson, E. S., Roth, E. M. 2002。我们能永远摆脱数据过载吗？认知系统诊断。认知、技术与工作 4(1), 22-36。
相关文章
调试思维模式
理解学习策略的心理学可以带来有效的解决问题的技能。
Devon H. O'Dell
https://queue.org.cn/detail.cfm?id=3068754
搜索与查找
William A. Woods
为什么系统需要知识才能找到你真正想要的东西
https://queue.org.cn/detail.cfm?id=988405
用户界面设计师，时尚的奴隶
现状在界面设计中占主导地位，而有缺陷的剪切粘贴概念就是一个完美的例子。
Jef Raskin
https://queue.org.cn/detail.cfm?id=945161
Marisa R. Grayson 是 Mile Two, LLC 屡获殊荣的认知系统工程师。她拥有俄亥俄州立大学的硕士学位，并且是认知系统工程实验室和 SNAFU Catchers Consortium 的成员。她的经验从医疗保健、国防情报和分布式软件系统等多个领域的研究中汲取灵感。作为一名狂热的 UI 开发人员和游戏玩家，她设计了实用且可用的产品，展示了真实工作的叙事。
版权所有 © 2019，所有者/作者持有。出版权已许可给 。
最初发表于 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 年首次引入，并在后来得到普及，就是这些成熟的解决方案之一。
© 保留所有权利。