PDF超越“修复式”跑步机
高绩效组织中事故后分析产物的使用
J. Paul Reed
在科技行业的所有特质中，自我反思和历史内省并不名列前茅。正如行业传奇人物艾伦·凯 (Alan Kay) 曾经说过一句名言：“对历史缺乏兴趣，蔑视历史，正是计算机科学还不够成熟的原因。” 因此，过去几年人们对回顾机制以及它们如何融入我们日常工作中重新产生兴趣，即使不是完全具有讽刺意味，也有些认知失调。
当然，回顾并非新鲜事物，至少在软件开发领域是这样。15 年多来，大写的敏捷软件开发方法一直在颂扬在每个开发冲刺结束时安排、内置反思期的优点。（这些是否真正在实践敏捷的组织中发生仍然是一个悬而未决的问题。）这 15 年也见证了软件交付方式的巨大转变：行业总体趋势已从将这些比特和字节打包成盒子运送给用户“自行操作”，急剧转向将其部署在大型服务器设施上，而这些设施我们负责维护，为用户运营我们开发的软件。
这种转变使得软件运营实践，以及如何做好它的研究，引起了行业从业者和观察家的兴趣。作为软件运营实践的一部分，人们重新审视了运营回顾（在工业环境中更常被称为事后分析）所起的作用。简而言之，回顾过去以改善未来已成为许多公司的首要考虑，正是因为在软件开发阶段不这样做的成本可能难以衡量，但在软件运营中不这样做的成本却非常明显：影响服务的事件很容易（而且经常）转化为惊人的收入损失或服务级别协议处罚。
回想一下您参与的上次事件事后分析（或者如果您从未有机会参与过，请花点时间想象一下那里可能会发生什么）。它可能看起来像这样：事件发生几天后，一群人会面一小时。（总是一小时。）小组的规模（以及在场的经理人数）与事件的重要性（可见或代价高昂的代码）成正比。讨论从回顾事件的细节开始，通常从停机事件的具体代价或可见性开始。接下来，讨论事件期间“实际发生了什么”：它是如何开始的，谁做了（或没做）什么，以及团队之间如何相互配合来解决问题。也许这次讨论得到了预先编译的时间轴的帮助（或者时间轴可能是在会议上制定的）；可能会展示日志和其他指标。
谈话可能会变得紧张，并且根据一些组织因素，可能会在房间里互相指责。或者，也许有人负责提醒大家，他们都是无辜的。也许他们相信这一点。也许他们是否相信这一点取决于房间里的人。在某个时候，要么是为了缓和动荡的局面，要么是因为有人注意到还剩 10 分钟，要么只是为了改变一个没人想深入探讨的话题，讨论转向了补救措施。问题是，“我们要做什么来 100% 确保这种情况永远不会再次发生？” 小组集思广益了一份补救措施清单。它们的范围从低成本、高价值的项目（一位工程师自豪地报告说：“我们已经实施了那些”）到高成本、价值可疑的项目，否则会被嘲笑，但在这种特定情况下，每个人都默默地点头表示同意。有人写下这些补救措施，或拍摄写有这些措施的白板的照片。然后团队解散。
建议的补救措施可能会输入到票务跟踪系统中。也许公司有一个团队，其唯一目的是追踪这些项目，并确保每个开发和基础设施团队在某个（可能讨论过、可能同意、可能两者都不是）时间范围内完成该列表上的每个项目。也许团队在接下来的两到三个冲刺中完成了补救清单上的大量项目；希望组织对此感觉良好。或者，也许这项工作的重要性，曾经被认为如此关键，却在满足其他持续不断的 goals 的过程中迷失了方向，例如承诺的新功能或大型平台迁移。或者，也许另一个关键事件（可能相关？）占据了所有可用于“对早期事件做些什么”的精力。
如果这种模式感觉熟悉，那应该是的。大多数技术公司的运营回顾和事件分析流程或多或少都像这样。一些组织比其他组织更有实践经验，一些组织为此培养了比其他组织更“健康”的环境，还有一些组织在如何向客户交付和运营软件的计算中更重视它。但是，模型及其预期输出通常是相同的，这引出了一个重要的问题：在我们行业通常解决事件的这种普遍的重复循环中，我们是否遗漏了任何可能有用的东西？
换句话说：当我们经历事件、解决事件并处理其后果时，如果我们撇开特定于事件的，因此从根本上是静态的补救措施（无论是在技术方面还是在流程方面），我们是否学到了任何其他有用的东西来处理和响应事件？我们能否描述这种知识？如果是这样，我们又将如何利用它来利用过去的痛苦并提高未来成功的机会？
“学习”是什么意思？
组织学习的主题长期以来一直是安全科学关注的焦点，研究人员已经观察了它在从航空到医疗保健到海运等行业的背景下如何运作了近 90 年。组织学习已被分解为三个不同的探究类别，遵循的演变与网络规模基础设施和软件的运营非常相似
• 首先，只是简单的个体、单一的课程是如何学习的——也就是说，什么是事件，你如何检测到你正处于事件之中，以及这些事件究竟如何成为个人或整个组织学习的素材。
• 其次，既然我们可以识别输入的模样，我们就可以询问从事件中学习的过程在实践中是什么样的。组织学习的大部分重点都放在这个特定方面，因为它深入了解了现实世界的团队如何识别要学习的课程，以及如何在他们的系统中实施这些课程（或不实施）。
• 最后一个探究类别着眼于组织学习的必要条件，本质上是促进它的要素（或者，通常是阻碍它的障碍）。这个领域的主题可能会让人感到熟悉，包括组织信任和责备、组织如何理解事件影响，以及事件调查和补救的各种机制——例如，谁参与和不参与这些过程（以及他们何时参与或不参与，以及原因）。
洞察力的类型
区分组织学习的各个阶段非常重要，因为它使我们能够根据在观察组织和团队中发生的事情时应该关注的洞察力类型来描述每个领域。
• 这些洞察力中的第一个根植于心理/认知视角，其重要性在本期特刊的其他文章中得到了很好的涵盖。
• 这种洞察力与第二种类型密切相关：社会学洞察力，当您较少关注个人，而更多关注试图理解事件以及如何解决事件的个人群体时，团队和公司范围内的背景中会发生什么。
• 最后，存在“政治洞察力”，无论是在事件的前端还是尾端。换句话说，您必须承认，在任何系统中，政治都在决定什么是事件、是什么促使事件被报告以及最终报告会发生什么方面发挥作用。然后，在事件发生后，政治还在补救措施如何沟通（或不沟通）、如何实施（或不实施）以及整个过程如何在时间、精力或实际资金方面获得资助方面发挥作用。（或不资助。）
这些用于调查组织学习的框架已应用于众多行业。（我个人最喜欢的一个深入研究了瑞典铁路工人如何从事件中学习，与铁路公司认为他们如何学习，与铁路公司本身如何“学习”进行了对比。）然而，直到过去五年左右，软件运营才被纳入相同的视角，这必然将软件开发也拖入显微镜下（一个有趣的转折是，这在安全科学研究的其他行业中是缺失的）。
科技行业中这些探究的重点一直是具有影响或可见的站点/服务中断，正是因为工程师和公司在事件期间和之后会采取一系列实践，但这些实践差异很大，并且在文献中没有得到很好的描述。（我的目标是在 2017 年末进行的研究中改变这一点，该研究最近以硕士论文的形式发表。）
事故后分析产物
即使是最新的事故后分析流程也会产生一些输出。常见的例子包括事后分析报告、补救项目票证（与软件、基础设施或两者相关）、更新的文档或运行手册，或为其他群体（如客户或高管）提炼的沟通内容。我对软件开发和运营组织中的组织学习的深入研究专门关注这些输出，从它们采取的各种形式开始。关于事件的所有其他细节——事件本身、回顾期间发生的事情，甚至这些产物是如何创建的——都被认为是黑匣子。
对这些产物的研究始于更广泛的行业层面，通过调查征集回顾和事后分析模板。然后分析这些模板的结构元素，以找到共同点（例如，事件摘要、基本时间轴和操作项是事后分析模板中观察到的前三个结构），以及更独特的结构。（最不常见的元素包括：文档版本/上次修改日期、提醒模板用户根本原因不存在以及广泛的组织发现。）
分析这些各种事后分析模板后，最值得注意的发现也许是，行业内使用了不同的模板原型，每个原型都有不同的重点并服务于不同的目的。从行业样本中可以看出三个
• 记录员。这是最常见的行业模板，也是大多数从业者在想到事后分析报告时所想到的：它用于为组织提供事件记录，包括组织认为相关的信息。虽然这是最常见的原型，但值得注意的是，它并没有直接表明任何关于组织学习的内容；事实上，它通常专门用于记录组织“做了一些事情”来响应事件，即使“某事”的完整性、贯彻执行或有效性不是模板目的的一部分。
• 促进者。促进者在结构上与记录员相似，但包括额外的提示和“暗示”，以促进事故后分析流程的运行。这些可以包括组织希望在事后分析会议期间提出的问题，或提醒参与者组织重视的文化精神（例如，无责备），或者在这些过程中希望向参与者或促进者强调的其他内容。
• 路标。这种模板原型可以恰当地描述为指针：它可以提供报告功能，分发给更大的组织用于培训或信息目的，也可以充当简短的“逐项收据”，指向关于事件的其他数据源，通常是各种组织记录系统。在任何一种情况下，它的特点是对事件和分析结果的轻量级处理，因此，它通常用作关于（尤其是有影响的）事件的广泛组织沟通手段。
这三种模板原型并不排除其他原型的存在；如果收集和分析更多的行业模板，其他具有足够唯一可识别元素结构的共同点可以定义其他原型。事实上，随着行业内事件分析实践的发展，这些原型也应该随之发展。
生产环境中的产物使用
对行业事故后分析产物的使用情况的第二阶段探究，围绕着对它们在生机勃勃的组织中的实际使用情况以及这种使用情况的影响的现象学案例研究。选择组织进行案例研究的一个重要方面是，它既开发软件又运营该软件。根据 2016 年和 2017 年 DevOps 状况报告中描述的指南，它必须被认为是高绩效组织。在三个月的时间里，观察了来自三个不同团队（开发、运营和安全）的 12 名工程师，了解他们在响应事件过程中如何使用各种事故后产物——分析、补救和从中学习。在此期间，还收集和分析了来自组织实际事件的产物。
最初的发现之一是，不同的团队以不同的方式使用这些相同的事故后分析产物来开展工作。在分析每位工程师对产物特定用途的引用的频率时，出现了各种主题。例如，运营工程师使用产物对各种系统因素进行趋势分析，并用于其他更长期的用途（例如，创建用于对公司事件进行分类的模型）。他们还大量使用产物来创建用于运营工作的知识库类型的信息库。（事实上，他们使用产物生成和更新文档的频率明显高于其他组。）
开发人员倾向于使用这些产物来帮助确定事件的“根本原因”（他们所指的），以及为新功能工作和架构重构生成需求规范。产物还用于证明或澄清以前对新团队成员和其他团队做出的工程决策，但个别工程师已经忘记了随着时间的推移的具体原因。（安全科学的敏锐追随者会熟悉与根本原因概念相关的问题；撇开这些讨论，值得注意的是，开发人员使用根本原因这个术语的频率是安全工程师的两倍，安全工程师使用它的频率又是运营工程师的两倍，而运营工程师几乎从不使用它。）
最后，安全工程师比其他团队更多地将产物用作推动其工作的主要工具之一。在响应安全事件的背景下，这在直觉上是有道理的：安全工程师需要响应他们在生产系统中看到的真实世界威胁，因此他们使用过去的事件作为获取更强信号的一种方式，表明他们应该计划努力的方向和未来的重点。这包括指导安全相关文档的生成和分发，以及推动内部安全产品路线图。
总而言之，这些不同的用途加起来超过了它们各部分的总和。在当今的现代分布式系统中，指出工程师在复杂的系统中工作既不是新鲜事，也没有争议。在安全科学中，复杂社会技术系统一词通常用于指出系统不仅是代码、计算、网络和存储的混合体，而且还是人员和团队的混合体。这些人自然有相互竞争的优先事项、偏好、激励和目标，并且他们经常面临必须在极端时间和压力下做出关键决定的情况，在这些情况下，所有这些因素都会有意识地（和下意识地）影响他们的决策和行动。
关于这些事故后产物用途的最重要发现之一是，参与者使用它们来帮助创建和更新他们负责参与的新兴的复杂社会技术系统的心理地图。由于这些网络规模的复杂软件和基础设施系统不断发展，无论是在技术方面还是在技术背后的团队方面，个人、团队甚至组织对系统如何工作的心理地图都可能随着时间的推移而退化。任何对在内部 wiki 上找到四个架构图感到沮丧的人，但没有一个是当前的，都经历过这种情况。事件产物实际上为这些地图提供了“补丁”，使工程师和团队能够更新他们对系统的上述表示，并相互讨论他们的跨界（团队或系统）心理模型在哪里不匹配、不准确或以其他方式阻碍了他们的工作。
在几种方式中观察到了这种组织复杂社会技术系统地图的更新。首先，产物提供了看似不同、不相关的更广泛系统组件之间联系的证据。有许多技术示例（“这个微服务，在特定的故障模式下，将调用它过去依赖的另一个微服务，但该依赖关系被认为已删除；但是，该依赖关系实际上仍然存在，但仅在此特定错误条件下”）。但这种影响也确定了系统中人员和团队之间未知和缺失的联系。最突出的例子是一个团队，事实证明他们正在处理大量的安全问题。他们位于不同的州，专注于客户支持，因此他们无法联系可以帮助他们的安全工程师；因此，发生了安全事件，社会技术系统地图的社会部分的更新之一是，“这些人需要被介绍给那些人，并且需要在他们之间建立持续的沟通渠道。” 其中一部分包括培训需求，最终推广到一系列团队。
观察到这种产物使用的第二种方式是作为识别社会技术系统内热点的一种方式。古老的谚语“哪里有烟，哪里有火”在这里很贴切，事故后分析产物让工程师能够感受到烟雾是来自几秒钟内触发厨房烟雾探测器的小油火，还是烟雾从四个街区外可见，并且可能应该引起更多关注。同样，这为绘制复杂社会技术系统的地形提供了输入，不仅运营工程师在上面运营，而且开发人员也在更新和更改，安全工程师也在防御外部攻击。这种“烟雾”可能表明组织已经忽视并且需要更多投资的（再次，包括技术和社会）领域，但也可能突出显示完全新兴的领域，这些领域仅仅因为复杂系统以某种未曾设想的方式演变而需要解决。
作为这种影响的一个例子，一位安全工程师禁用了工程师通过使用公司范围内的网络库可以使用的一组特定选项；这提高了公司的安全态势。几天后，一个团队去部署他们微服务的新版本，部署引发了中断。在检测到并补救问题后，事件分析通过事故后产物的分发提出的“冒烟”问题之一是，安全团队没有任何关于公司范围内正在使用的库版本的数据。
这不是组织忽视其他优先事项；相反，这是因为系统在微服务和软件依赖复杂性方面已经发展到这样的程度，以至于现在值得收集此类数据，并且可以突出显示其他潜在问题，其中一个因素是团队使用已被假定为已弃用的旧版本。这导致了技术解决方案（开始跟踪库版本使用情况）和社会解决方案（该团队现在定期与数据表明仍在继续使用旧版本库的其他团队联系，以了解他们为什么没有迁移，他们是否可以帮助他们迁移，以及他们是否需要在迁移之前获得任何新功能）。
转向动态补救措施
行业调查数据显示，91% 的受访者认为收集和记录补救措施是其事故后分析会议和这些会议产生的产物的核心目的。然而，花三个月时间观察高绩效组织如何不同地使用其产物，揭示了另一种方法：专注于收集、理解和分享关于子系统的技术状态以及负责运营和维护它的团队的优先事项、偏好、激励和约束的更深入、更丰富的上下文。在这个组织的环境中，静态的补救措施清单退居次要地位，让位于对这种丰富上下文的搜索和传播。
在事故后分析阶段以及因此编码到该阶段产生的文档中的主要组织关注点包括
• 个人和团队如何处理事件以及他们如何协调工作。
• 他们当时对系统的心理模型是什么，包括代码状态、基础设施以及其他团队的期望，以及这些心理模型如何影响他们的决策。
• 他们的心理模型在哪里存在分歧，以及这种分歧在事件响应期间的影响。
• 在事件的边缘，团队对可能导致事件的因素有哪些背景知识（即，团队面临的其他压力、激励或情况可能使其本地环境更容易促进与事件相关的因素）。
死记硬背的补救措施不是讨论的重点。当然，这并不是说不讨论补救措施；相反，团队的期望是在事故后分析之前已经在内部确定了他们负责的项目，并且（被允许）负责决定这些修复的优先级。在某些情况下，它们在事后分析会议之前完成。在其他情况下，需要进一步讨论以获得——你猜对了——进一步的背景信息，以充分了解所有潜在的补救措施及其在更广泛的组织背景中的相对优先级。
也许最令人着迷的是：团队可以决定完全不实施补救措施。他们可能会确定，考虑到组织已分配给他们的其他优先事项，采取一系列他们认为可以足够快地补救的小型中断是正确的决定。这在他们的组织中行得通，因为人们认识到开发、运营和安全团队最接近他们运营的系统，因此被信任能够根据他们的本地合理性和他们从周围的其他团队和系统收集的背景信息做出正确的决定。如果该决定导致进一步的中断，从而影响组织的其余部分或客户，那么上下文的交换会在相关团队之间以另一种方式流动——而不是针对特定事件的补救措施清单——并推动更具弹性和灵活性的解决方案。一位工程师恰当地将此模型描述为“战略问责制，而非战术问责制”。
这种上下文共享还有另一个好处：它促进了无责备的概念。无责备的事后分析的概念已经在行业中流传了相当长一段时间，并受到了一些怀疑。对于可能造成数百万美元损失（甚至对公司构成生存威胁——问问骑士资本就知道了）的中断，完全可以理解的是，当节奏很快且后果非常严重时，无责备是否可能存在。但是，由于对社会技术系统各个子组件的上下文的搜索和交换比单独的补救措施更受重视，因此在事件发生后，理解发生了什么的第一步是“分享为什么发生任何事情的背景信息”。这与以“你做了什么？”这个问题开始，然后寻求对采取“正确”行动与否进行全民公决的方法截然不同。
早期，激动人心的时代
科技行业喜欢将航空业作为事件和事故调查的黄金标准，但情况并非总是如此。机组资源管理 (CRM) 在 20 世纪 80 年代的引入是提高航空安全的最大贡献之一。将 CRM 推向航空业前沿的洞察力并非基于特定事故的一系列补救措施，而是基于对一系列事故的整体看法，并寻找跨公司、情况、设备和人员的共性。它并非源于对零敲碎打的修复的关注，而是源于认识到改进人们开展工作、相互互动以及与设备互动的方式，以及有效地沟通和响应其复杂社会技术环境中的变化，是“热点”的最大发现之一，也是最大的安全胜利可以出现的地方。
鉴于人类对安全社会学因素的研究已有近一个世纪的历史，科技行业的事故后分析实践以及我们创建和使用这些实践产生的产物仍处于起步阶段。因此，不要对许多这些实践如此相似感到惊讶，用于解析和理解事件和中断的认知和社会模型很少且根深蒂固于运营精神中，并且从事故后分析中寻求的副产品远远侧重于补救措施和预防（通常带有不同程度的责备，无论我们是否愿意承认）。
但这不必保持这种状态。该行业正处于复兴的最佳时机，但我们必须克服事故后分析的唯一价值在于静态补救措施清单这一概念，即使许多流程都被建模甚至优化以产生这些清单。否定这种概念需要习惯于远离（诚然令人欣慰的）假设，即如果清单上的所有项目都已实施——我们“100% 补救了事件！”——那么它就不会再次发生。
克服（诚然很高的）障碍可以创造必要的认知和社会空间，以探索有影响力的，甚至是痛苦的事件试图传达的各种教训。组织可以开始从更广泛的解决方案出发来解决问题，而不是从试图解决可能永远不会再次发生的情况的任务和错误修复清单出发，而是从解决倾向于创造可能发生此类事件的情况的因素出发。而这最终将推动事件分析流程从如此专注于导致我们糟糕一天的特定事件，转向糟糕的一天揭示了关于我们的实践、流程、激励机制、本地环境、我们每天运营的复杂系统的真正性质，也许最重要的是：彼此。
相关文章
动态环境中的事后调试
现代动态语言缺乏理解软件故障的工具。
David Pacheco
https://queue.org.cn/detail.cfm?id=2039361
网络是可靠的
真实世界通信故障的非正式调查
Peter Bailis, Kyle Kingsbury
https://queue.org.cn/detail.cfm?id=2655736
为什么 SRE 文档很重要
文档如何使 SRE 团队能够管理新的和现有的服务
Shylaja Nukala 和 Vivek Rau
https://queue.org.cn/detail.cfm?id=3283589
J. Paul Reed 的职业生涯始于构建/发布和运维工程师的第一线。他现在是 Netflix CORE 团队的高级应用弹性工程师，专注于事件分析、系统性风险识别与缓解、弹性工程以及流媒体领导者各种社会技术系统中体现的人为因素。Reed 拥有隆德大学人类因素与系统安全专业的理学硕士学位。
版权 © 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 年首次引入，并在后来普及，就是这些成熟的解决方案之一。
© 保留所有权利。