PDF管理协调的隐性成本
当多种分布式视角至关重要时，控制协调成本
Laura M.D. Maguire
一开始是502错误。几乎立刻，大量用户报告涌入了服务的社区Slack频道。
一位用户在上午 9:22 发帖 “收到 502 错误？” ，几分钟内，其他 40 位用户回复了“是”和“+1”的表情符号。
同样在上午 9:22，在运维频道中，值班工程师开启了一个事件，负责该服务的站点可靠性工程师已被呼叫。到上午 9:23，五名响应者正在检查日志和仪表板。
在上午 9:25——在最初的试探性问题表明可能存在问题不到两分钟后——第一个通知被推送给用户。 这旨在减缓来自 77,000 多用户社区的用户报告涌入。
在不到七分钟的时间内，响应者提出了关于问题性质的八个假设。 在同一时期，其中五个已被调查并被排除。
在事件发生的最初 10 分钟内，响应者已直接与社区频道中的 4,700 名用户取得联系，向三个依赖服务的支持团队开立了工单，并在 10 人组成的响应小组中进行了协调。
当 IT 系统高速且大规模运行时，各种不同的参与者都会参与其中。 当服务中断时，这一点会立即显现出来。 那些工作直接或间接依赖于系统功能的人，都会被迫参与进来，要么帮助解决问题，要么寻求更多信息，以便他们可以调整自己的目标和优先级，以适应降级（或缺失）的服务。
通常，由于服务的业务关键性质或四个 9 的服务级别协议，服务中断会触发对多个响应者的全面呼叫。 然而，这个核心小组只代表了所涉及角色的一小部分。 即使简单地看一下事件响应，也很明显，在这些系统中解决服务中断的性能，关键在于快速、顺畅地协调这些多个不同的参与者，如图 1 所示。
在这个集体中进行的联合活动发生在脚本化和非脚本化的努力中，例如识别中断、采取行动以保护系统免受进一步衰退、诊断问题的根源、确定潜在的解决方案、在代码推送之前交叉检查修复程序，以及一系列善后活动。
即使在相对较小规模的系统中，事件响应也可能不再侧重于服务中断的诊断和修复，而更多地侧重于管理多个响应者所需的能力、通过让更多参与者协助可能实现的潜在好处，以及利益相关者群体的需求。 这种协调会产生额外的需求。 例如，为了使他们的技能和经验对当前的事件流程有用，新来的响应者需要听取简报，并了解相对于活动顺序分配给他们的任务。
这样做需要大量的努力——特别是当中断的严重程度或响应者的数量增加或不确定性增加时。
在高风险的数字关键基础设施服务交付管理领域，诊断和修复中断的时间压力是巨大的。1 虽然资源可能随时可用，但当事件的节奏升级，并且阻止级联故障的努力占据了响应团队的所有注意力时，使用这些资源可能非常具有挑战性。
问题的关键在于：角色的协作互动和同步至关重要，12,13,15 但先前的研究表明，不良的协调设计会给从业人员带来 认知成本，具体而言，参与联合活动需要额外的脑力劳动和负荷。5,6 这在数字服务领域尤其会加剧，因为它发生在地理上分散的团队中。 本文使用来自关键数字服务的示例，探讨了协调成本的性质以及软件工程师在服务中断期间如何体验这些成本。 这些发现为控制事件响应中的协调成本的设计提供了新的方向。
协调的隐性成本
平稳运行所需的编排是费力的，7 尤其是在系统承受压力时。 但这些努力很难辨别，通常不会从该领域内预期的“专业实践”中分离出来。 这种编排的出现是因为“不断升级的异常可能会迅速超出单个响应者的资源。 有很多事情要做，而且必须快速果断地采取行动的压力很大。 “调集资源并有效地部署它们需要一系列与直接解决问题相关的但又不同的技能。 但为了有效，必须指导、跟踪和重定向这些资源。 这些活动本身就要求很高。”18
这种技能的集合在很大程度上被忽视并不奇怪。 专家从业人员熟练地管理这些协调需求，最大限度地降低了所涉及努力的可见性。19 只有当协调崩溃时，它才会走到前台。 活动同步困难、任务序列的平稳流程中断或明确旨在组织多方的对话，都是协调崩溃已经发生的证据示例。
值得将协调所需的编排与这些活动产生的成本区分开来。 招聘新资源参与事件响应就是一个例子——只是联合活动中的一个功能。 相关的管理成本包括
• 监控当前容量相对于不断变化的需求
• 确定所需的技能
• 确定谁可用
• 确定如何联系他们
• 联系他们
• 等待回复
• 调整当前工作以适应新的参与（等待，缓慢完成任务以帮助协调）
• 为参与做准备
— 预测需求
— 开发“紧急情况报告”或状态更新
— 授予对工具和协调渠道的访问权限/许可
— 生成共享工件（仪表板、屏幕截图）
• 处理访问问题（无法加入网络会议或音频建立问题）
这些管理成本看起来相对良性——它们是任何联合活动的隐含特征。 而这正是重点：在正常操作中，它们可能是 最小的负担，因此在显式设计中被认为不值得支持。 然而，在高节奏、时间紧迫和认知需求高的场景中，这些负担会增加到使已经负担过重的响应者超负荷的程度。 想想飞行最初几分钟的发动机动力损失或太空行走期间的意外事件——在这里，时间以秒为单位计算，认知工作中的任何额外摩擦都很重要。 现在想想关键数字服务的运行速度——微秒以单位计算，隐藏的协调成本可能会以以前未考虑的方式产生影响。 协调的认知成本在事件响应过程中很重要。 现在让我们考虑一下不良的协调设计如何影响负责系统可靠性的工程团队。
协调设计的必要性
高度技术化的系统操作越来越趋于非本地化。 对近乎完美的可靠性的需求以及这可能给值班工程师带来的倦怠感，催生了 24/7 系统管理的不同模型，以跨时区分配呼叫。 即使团队可能在地理位置上是同地办公的，中断也会发生在非工作时间，或者团队成员可能在旅行、开会或因其他原因无法进行面对面的互动时。 这意味着事件响应的设计应适应完全远程的联合活动。
对良好协调设计的需求超越了软件社区：越来越多的过去通常在地理上不分散的其他行业正在利用技术能力来分散其劳动力，以优化成本或可用人才（提供即时专业知识）。
当前的协调设计侧重于处理支持的结构，包括分诊方法，即经验不足的支持工程师在升级到专家之前使用运行手册或故障排除算法，或者通过“追随太阳”的地理分散的支持网络。 这些形式可以减少在系统崩溃时唤醒专家资源的需求，但这些配置并不能消除对协调设计的需求。 需求以可能升级情况的方式转移，从而加剧了事件的协调需求，因为其他利益相关者也参与进来。
让我们通过一个例子来了解这一点。 当异常产生呼叫值班人员的需求时，这些直接响应者开始聚集。 与此同时，其他对问题感兴趣的利益相关者也被吸引进来。 用户可能会开始涌入支持渠道和工单系统，试图确定服务是否降级或他们的系统是否不稳定，或者依赖的服务可能会遇到问题并开始索取信息。 这种协调“噪音”使得难以确定这些是否都是相同的问题、相关问题还是不相关问题。
由于诊断和保护活动需要大量的注意力，因此需要额外的资源来分流涌入的报告，并筛选传入的数据，以最大限度地减少数据过载。16 随着事件的进展以及对影响的担忧日益增长，升级到管理层会引入更多的参与者，因为高级管理人员开始迫切要求更多细节或要求恢复服务。 面临客户紧急请求的客户支持角色将寻求信息以传递下去。
尽管有大量参与方参与，但系统很少在设计时明确关注协调要求。 当他们这样做时，通常是为了：(1) 通过事件指挥官集中响应协调； (2) 设计过于规范的流程管理视角，未能考虑到协调的隐性认知工作； 或 (3) 依赖于未能完全支持事件响应发生的动态、非线性方式的工具。 这些方法不一定能像预期那样支持协调的认知工作。
支持协调的尝试
有些人会认为，协调设计对于在分布式系统（如 CDI（关键数字基础设施））中开发和部署技术至关重要。 但是，以流程驱动的协调设计——强调分布式任务而不是联合活动——将无法满足前面描述的需求。 流程驱动的行业最佳实践的一个例子，围绕服务中断期间的协调——借鉴自灾难和应急响应领域——是 ICS（事件指挥系统）。 该模型的中心是分配 IC（事件指挥官）并确保所有角色和团队都严格遵守共享的 ICS。 让我们看看这两个原则实际上是如何限制弹性事件响应实践的。
尝试 1：分配事件指挥官
IC 角色的目的是通过指导其他人的活动并承担及时决策的责任来管理相关方的协调要求。 在某些条件下（例如，在低节奏场景中，参与方很少或事件结果合理已知且可预测的情况下），这可能是一种合适的配置。 在这些情况下（或事件的这些阶段），认知和协调需求在没有协调设计的情况下是可以管理的。7,12,13 常规事件可以在没有过度压力的情况下处理。
然而，将情况升级到非常规或特殊情况的事件会急剧增加应对所需的认知活动，并且通常不会遵循可预测的路线。 随着需求的增长，事件指挥结构往往会成为工作负载和活动瓶颈，从而相对于级联问题的节奏减慢响应速度。20 在事件中和对事件进行工作迫使注意力分散在职位的“固有”角色上。 例如，IC 需要跟踪事件的详细信息，以便准备好预测并适应快速变化的条件，但是花费太多精力来准确评估情况会分散对跨角色管理协调的注意力。 相反，试图集中管理谁在何时做什么往往会落后于事件和挑战的步伐，从而使问题更难解决，联合活动更难同步。
这不是一个无关紧要的观点。 成为联合活动的有效编舞者需要当前的、准确的知识以及将注意力转移到编排进出事件的参与者及其不断变化的需求的能力。 此外，在响应期间，IC 维护组织纪律的行为实际上可能会破坏弹性实践的来源，而弹性实践有助于事件响应者应对不匹配的协调策略和事件的认知需求。
尝试 2：强制执行操作纪律以遵循 ICS
先前在软件方面的研究表明，应对工作负载需求的不同策略，例如放弃任务（称为卸载）、将工作推迟到以后或降低所执行工作的质量。2其他平衡工作负载和协调价值的尝试要求增加更多资源，但这也会带来成本。 在设计不良的系统中，处理需求所需的资源无法顺利投入使用，而不会扰乱正在进行的控制事件不利影响的工作。
这里存在一个悖论：您有可用的资源，但无法使其有用。 与此同时，他们变得有用的尝试会适得其反——进入音频桥或 ChatOps 频道的新响应者需要请求简报，而更新会中断活动流程。 这可能会推动在选定的响应者之间形成辅助频道，从而可以在其中不间断地进行诊断工作。 创建这个外围空间对于完成认知要求高的工作是必要的，但会让其他参与者与辅助频道中正在进行的进展脱节。
除非您曾处于此类事件的“火线”上，否则很容易低估这些情况中固有的紧张关系。 值得重申的是：协调研究中研究的系统通常是危及生命的或具有其他高风险的。 尽管协调很重要，但必须及时采取行动来应对异常情况，因为它们有可能导致故障。 当高昂的协调成本可能会破坏跟上异常情况不断变化的需求的能力时，对结果负责的人员必然会做出调整。 关键数字基础设施系统中的事件响应也不例外。 事实上，CDI 运行的速度和规模，加上通过技术连接的分布式团队的挑战，使得该领域特别容易受到过高协调成本的干扰。
在对重大事件和事后分析的观察中，创建与“官方”事件响应分开的不同频道中的子组的调整反复发生。9 通常，事后分析会误解这些对高昂协调成本的适应形式。 回顾性讨论将这些调整描述为违反 ICS 协议，因此导致努力阻止人们形成这些频道。 这种行为实际上是一种适应性策略，用于应对协调变得过于昂贵的情况。 与其强迫响应者承担巨大的注意力和工作负载成本，不如促进将各种工作线转移到子组，同时支持将进展或困难连接到更大的响应流程中。
紧急服务部门已开始认识到 ICS 的局限性，4 其他采用指挥和控制或分层方法的领域也开始转向更灵活的团队结构。10,11 当 ICS 等实践跨领域采用时，务必密切关注来自其他大型、多主体协调环境的批评和发现。 这样做，就有可能限制当一个环境的现实世界需求挑战从另一个环境导入的实践时，产生意想不到的不利影响。
关于事件响应中的人员如何在协调成本过高威胁到关键认知工作时进行调整的这些发现，是指导创新的重要设计种子来源。
尝试 3：使用技术来促进协调
计算机支持的协同工作 (CSCW) 术语是由 Irene Greif 和 Paul Cashman 在 1980 年代早期创造的，用于描述计算机介导跨人员和角色协调活动的新兴领域。3 从那时起，技术能力的进步、计算机在工作场所的普及以及自动化流程的激增巩固了 CSCW 的重要性，同时也使其变得多余，因为几乎所有形式的联合活动都已成为计算机介导的。
尽管如此，该领域仍有三个主要主题在 CDI 中特别受关注：协作软件平台的使用； 人与机器人之间联合活动的协调； 以及人机团队合作中互惠的性质。
协作软件平台
毫不奇怪，由于工作环境不断变化的需求以及劳动力的技术能力，软件工程推动了协作工作的工具和实践的创新和发展。 在线软件平台采用传统的离线活动，例如项目管理计划、问题跟踪、小组讨论和共享工作的谈判，并支持分布式网络中参与者的实时协作。
这些平台已从昂贵的、专有的文件共享形式转变为广泛可访问的、基于云的工具，这些工具可以快速地在正式和临时的分组中采用。 以这种方式降低协作的门槛降低了临时性、单一问题需求和早期探索性工作的协调成本。 这意味着可以更快地促进协作工作，并减少管理成本。 灵活的协调结构还提供了使其使用适应问题需求的能力。
在早期示例中展示的形成辅助频道以管理高昂协调成本的弹性，得益于可以轻松发送直接消息或启动新频道。 支持快速重新配置为更小的、临时的团队，可以在活动在不断变化的参与者群体中分布时实现平稳过渡。 这些属性的集合——适应不断变化的问题需求、资源的动态重新配置和平稳协调——在高风险工作中至关重要，并且是在许多领域中擅长分布式联合活动的团队的突出特征。
设计可以帮助实现这些能力的技术是控制协调成本的一种手段。 虽然许多平台优化了单一标准（快速重新配置）的协调成本，但 ChatOps 平台在与工具本身协调方面施加了惩罚。 例如，虽然 ChatOps 的实践允许可追溯性，可能支持使新响应者快速上手，但该工具的打包消息列表格式的设计很差，无法做到这一点。14 进入正在进行的事件的响应者必须滚动浏览文本列表，搜索仍在考虑中的相关调查线索、关键决策点和其他重要的上下文信息，以获得对当前情况的理解。
这些看似微不足道的设计方面非常重要。 回想一下，当时间以秒为单位计算且专家资源需求量很大时，高节奏操作中固有的紧张关系。 那些可能被吸引来参与服务中断响应工作的人员通常拥有通常稀缺的专业技能。 因此，他们可能要到后期阶段才被带入事件中，此时节奏或故障传播驱动着采取紧急行动的需求。 不良的设计使 ChatOps 几乎无用，因为它无法帮助人们理解正在演变且压力越来越大的情况。
跨人与机器协调联合活动
上一小节改变了控制协调成本的框架。 最初，协调成本指的是适应联合活动中固有的任务和交互的额外努力。 在人与人之间的协调中，交互成本由双方承担，并且可能会为了适应共享或长期目标而“投资”放松个人或短期目标。 联合工作将成本分摊到参与者身上。 前面的小节介绍了一个重要的区别：与工具和自动化交互会扭曲成本。 在人机团队合作中，有许多协调成本被忽视或因工具设计而加剧。
例如，为帮助异常响应的各种功能（例如监控或警报）而设置工具的初始努力可能是巨大的。 负责组装自己的堆栈的工程师花费大量精力：评估工具是否适合特定用途； 相对于团队的需求进行评估； 考虑理解其功能所需的技术能力； 学习它是如何工作的； 在添加新功能时维护准确的心理模型； 确定适当的配置； 执行维护以确保在需求变化时删除或更新旧配置； 容忍可能导致不必要警报的缺乏上下文敏感性； 为团队中的用户提供访问权限和许可； 构建安全措施以防止意外更改； 以及在集成新工具时进行更改和调整。 （清单可以继续列下去。） 这些都是与机器协调对人类同事产生成本的例子。 如果该工具是人类同事，那么您需要花费大量精力来确保它仍然是相关的团队成员可能会让您犹豫； 然而，这种根本的不对称性，即不适当地增加了人类团队成员的额外成本以弥补自动化的局限性，是当今人机团队的特征。6,7
跨人与人以及人与机器网络的团队合作动态的一个关键（且经常被忽视的）方面是，联合活动中的参与者在多大程度上考虑其他人的目标、工作负载和需求，并相应地调整他们的行动。
认识到互惠的动态
当技术旨在对抗过高的协调成本时，编排技术介导的联合活动可以为更大的互惠机会创造条件。17例如，对 NASA 太空飞船任务控制中心在关键事件期间的研究揭示了许多有效的联合活动模式。 特别值得关注的是，许多人加入了，超出了那些名义上负责的人。 介导控制室和后方房间通信的技术有助于使加入的人员快速上手，而不会给当前处理异常情况的人员带来负担。13 额外的人员提供了不同的视角，尤其是在每个飞行控制员随着异常情况的展开而越来越关注他或她的职责范围时。 “查看和收听”的能力已被广泛记录为平稳协调的好处。8,12
不难看出任务控制中心和 CDI 之间在服务中断期间利益相关者（其他响应者、用户、客户支持、管理层）数量快速升级方面的相似之处。 使完全分布式网络中的这种能力和其他联合活动能力成为可能，而不会增加额外负担的技术，为那些技能、经验和知识可能对事件有用，但尚未明确被吸引进来的人员提供了一种手段，让他们可以在需要时随时准备提供帮助。 了解事件进展的最新情况，但又不受特定职责的束缚，为通过新的视角重新构建问题提供了机会（Grayson，本期）。
在概述支持协调的这三种尝试时，很明显，技术既可以通过支持适应能力来降低协调成本，又可以通过对人类一方施加不对称负担来加剧高昂的协调成本。 在 CDI 环境中，技术可以快速开发和部署，除非工具被明确设计为支持协调，否则设计很容易为联合活动增加意想不到的成本。
结论
协调仍然是大型分布式工作系统不可或缺的一部分，但缺乏针对联合活动的协调设计继续为从业人员增加隐性认知成本。 这些努力和负担与在快节奏、不断演变的事件场景中完成异常响应的认知工作时，实现跨多方分组的平稳同步的额外工作有关。 回想一下开篇案例，其中不断升级的事件带来了多个不同的分布式视角，每个视角都对事件进展具有既得利益。
每个参与者对于直接和间接管理中断都是必要的，ChatOps 论坛使他们的参与成为可能。 然而，更仔细地检查许多案例后发现了一个悖论：平台本身既促进又阻碍了协调。 辅助频道的轻松形成使工程师能够通过在主要响应工作之外的灵活重新配置来适应，但打包消息列表结构的设计使新响应者难以快速上手。
一些被认为可以控制协调成本的常见策略包括采用事件指挥结构，特别是 IC 角色。 实际案例表明，使用协作软件平台和采用技术来帮助协调会暴露出认知工作的局限性和未被认识到的影响。 然而，所有这些领域都为在高节奏、多主体事件中顺利编排提供了机会，特别是通过支持在协调成本过高时适应的能力。
控制事件响应者认知成本的一些初步考虑因素包括：(1) 相对于事件的认知需求评估协调策略； (2) 认识到何时调整代表多种相互竞争的需求（协调和认知工作）之间的紧张关系，并寻求更好地理解它们，而不是单方面地消除它们； (3) 扩大视角，将联合认知系统（人机能力集成）作为分析单元进行研究； 以及 (4) 将联合活动视为在组织间和组织内边界之间实现互惠的机会。
随着系统规模的扩大、速度的提高以及可靠服务交付中断期间面临的问题的复杂性增加，控制协调成本将继续是一个重要问题。
参考文献
1. Allspaw, J. 2015. 压力下的权衡：解决互联网服务中断的团队的启发法和观察。 硕士论文，隆德大学； https://lup.lub.lu.se/student-papers/search/publication/8084520。
2. Grayson, M. R. 2018. 接近过载：复杂和自动化生产软件系统中异常的诊断和响应。 硕士论文，俄亥俄州立大学； https://etd.ohiolink.edu/pg_10?::NO:10:P10_ETD_SUBID:174511。
3. Grudin, J. 1994. 计算机支持的协同工作：历史和重点。 计算机 27(5), 19-26; https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/IEEEComputer1994.pdf。
4. Jensen, J., Waugh Jr., W. L. 2014. 美国在事件指挥系统方面的经验：我们认为我们知道的和我们需要更多了解的。 突发事件与危机管理杂志 22(1),5-17; 22(1), 5-17; https://onlinelibrary.wiley.com/doi/abs/10.1111/1468-5973.12034
5. Klein, G. 2006. 团队在检测问题方面的优势和局限性。 认知、技术与工作 8(4), 227-236; https://link.springer.com/content/pdf/10.1007%2Fs10111-005-0024-6.pdf。
6. Klein, G., Feltovich, P. J., Bradshaw, J. M., Woods, D. D. 2004. 联合活动中的共同基础和协调。 在组织模拟中，编辑：W. Rouse 和 K. Boff, 139-184。 纽约：Wiley; http://jeffreymbradshaw.net/publications/Common_Ground_Single.pdf。
7. Klein, G., Woods. D.D., Bradshaw, J., Hoffman, R.R., Feltovich, P.J. 2004. 使自动化成为联合人机活动中的“团队合作者”的十大挑战。 IEEE 智能系统 19(6), 91-95; https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1363742。
8. Luff, P., Heath, C., Greatbatch, D. 1992. 交互中的任务：协作活动中的纸质和屏幕文档。 在 计算机支持的协同工作会议论文集中，163-170; https://dl.acm.org/citation.cfm?id=143475。
9. Maguire, L.M. 2020，即将出版。 控制大规模分布式系统中协调的认知成本：寻找支持联合活动的编排模型。 论文，俄亥俄州立大学； https://www.researchgate.net/profile/Laura_Maguire5。
10. Nemeth, C. P. 2007. 工作中的团队：从大规模协调研究中吸取的教训。 认知、技术与工作 9(1), 1—4; https://link.springer.com/article/10.1007/s10111-006-0049-5。
11. O'Leary, R., Bingham, L. B. (编辑). 2009. 协作公共管理者：二十一世纪的新思路。 乔治城大学出版社; https://muse.jhu.edu/book/13036。
12. Patterson, E. S., Watts-Perotti, J., Woods, D. D. 1999. 语音环路作为航天飞机任务控制中的协调辅助工具。 计算机支持的协同工作 (CSCW) 8(4), 353-371; semanticscholar.org/...。
13. Patterson, E. S., Woods, D. D. 2001. 航天飞机任务控制中的换班、更新和随叫随到架构。 计算机支持的协同工作 (CSCW) 10(3-4), 317-346; https://link.springer.com/article/10.1023/A:1012705926828。
14. Potter, S. S., Woods, D.D. 1991. 事件驱动的时间线显示：超越人机智能系统交互中的消息列表。 在IEEE 系统、人与控制论国际会议论文集中； https://ieeexplore.ieee.org/abstract/document/169864。
15. Watts-Perotti, J., Woods, D. D. 2009. Cooperative advocacy: an approach for integrating diverse perspectives in anomaly response. Computer Supported Cooperative Work (CSCW) 18(2-3), 175-198; https://link.springer.com/article/10.1007/s10606-008-9085-4.
16. Woods, D.D. 1994. Cognitive demands and activities in dynamic fault management: abduction and disturbance management. In Human Factors of Alarm Design, ed. N. Stanton. London: Taylor & Francis, 63-92.
17. Woods, D.D. 2019. Essentials of resilience, revisited. In Handbook on Resilience of Socio-Technical Systems, eds. M. Ruth and S. G. Reisemann. Edward Elgar Publishing, 52-65; researchgate.net/....
18. Woods, D. D., ed. 2017. STELLA Report from the SNAFUcatchers Workshop on Coping with Complexity. SNAFU Catchers Consortium; http://stella.report/.
19. Woods, D.D., Hollnagel, E. 2006. Joint Cognitive Systems: Patterns in Cognitive Systems Engineering. Boca Raton, FL: CRC Press (Taylor & Francis).
20. Woods, D. D., Patterson, E. S. 2001. How unexpected events produce an escalation of cognitive and coordinative demands. In Stress, Workload, and Fatigue, eds. P.A. Hancock and P.A. Desmond. Mahwah, NJ: L. Erlbaum; http://csel.eng.ohio-state.edu/productions/laws/laws_mediapaper/2_4_escalation.pdf.
相关文章
服务可用性的计算
你的可用性取决于你所有依赖项的总和。
Ben Treynor, Mike Dahlin, Vivek Rau, Betsy Beyer
https://queue.org.cn/detail.cfm?id=3096459
系统管理中的协作
对于系统管理员来说，解决问题通常需要与他人协作。我们如何才能使其更有效？
Eben M. Haber, Eser Kandogan, Paul Maglio
https://queue.org.cn/detail.cfm?id=1898149
分布式开发经验教训
Michael Turnlund
如果可以避免，为什么要重蹈覆辙？
https://queue.org.cn/detail.cfm?id=966801
Laura M.D. Maguire 是俄亥俄州立大学认知系统工程实验室的研究员，研究高风险/高后果工作中的人类表现。她的研究兴趣在于弹性工程、协调以及在分布式工作团队和系统监管与控制形式中实现适应性能力。自 2017 年以来，她一直是 SNAFU Catchers Consortium 的研究员，并与大中型数字服务公司在事件响应实践、工具开发、设计和情境研究方面密切合作。Laura 拥有人类因素与系统安全硕士学位，目前正在俄亥俄州立大学攻读认知系统工程博士学位。她的研究借鉴了她在林业、石油和天然气、投资银行和行业协会的工作经验。作为一名野外滑雪者和高山攀岩者，她也对山区环境中的认知工作和弹性表现感兴趣，并对此进行了撰写。
版权 © 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 年首次引入，后来普及，是这些已证明的解决方案之一。
© 保留所有权利。