ACM通信
实践
超越“修理”跑步机
图片来源:Andrij Borys Associates
在科技行业所有闻名的特质中，自我反思和历史反省并没有排在榜单的前列。正如业界传奇人物Alan Kay曾经说过的一句名言:“对历史的缺乏兴趣和蔑视使得计算机不是一个真正的领域。”因此，在过去的几年里，人们重新对回顾的机制以及它们如何融入我们的日常实践产生了兴趣，这在一定程度上是一种认知上的不和谐，如果不是完全的讽刺的话。
当然，回顾并不新鲜，至少在软件开发中是这样。在超过15年的时间里，敏捷软件开发方法一直在鼓吹在每个开发sprint结束时都有一个既定的反思期的优点。(这些是否真的发生在实施敏捷的组织中仍然是一个悬而未决的问题。)这15年也见证了软件交付方式的结构性转变:总的行业趋势已经从把那些比特和字节打包到盒子里，交付给用户，让他们自己“操作”，到把它们部署到我们负责维护、操作我们开发的软件的大规模服务器安装上为用户。
这种转变使得软件操作的实践，以及如何做它并把它做好的研究，引起了行业从业者和观众的兴趣。作为软件操作实践的一部分，对操作回顾所扮演的角色进行了重新审视——在工业环境中通常称为的解剖。简而言之，回顾过去以改善未来已经成为许多公司的优先考虑事项，这恰恰是因为在软件开发阶段不这样做的成本可能难以衡量，但在软件运营阶段不这样做的成本是非常明显的:影响服务的事件可能(而且经常)很容易转化为令人瞠目结舌的收入损失或服务水平协议罚款。
回想一下你最近一次参与的事后分析(或者如果你从来没有机会参与，花点时间想象一下那里可能发生什么)。它可能看起来是这样的:事件发生几天后，一群人见面一个小时。(总是一个小时。)团队的规模(以及有多少经理在场)与方式成正比重要的代码为可见或昂贵的——事件。讨论从讨论事件的细节开始，通常从详细说明中断的具体代价或可见性开始。接下来，讨论事件中“实际发生了什么”:它是如何开始的，谁做了(或没有做)什么，以及团队之间如何相互作用来解决问题。也许这个讨论得到了事先编制的时间轴的帮助(或者这个时间轴是在会议上拼凑起来的);可能会给出日志和其他指标。
谈话可能会变得紧张，根据组织的一些因素，指责可能会在房间里到处出现。也可能是某人的工作就是提醒大家他们都是无辜的。也许他们相信。也许他们是否相信这取决于谁在房间里。在某些时候，为了缓和混乱的局面(因为有人注意到这个小时还有10分钟)，或者只是为了改变一个没人想深入探讨的话题，讨论就会转向补救项目。问题是，“我们在做什么100%确保这种事不会再发生小组头脑风暴列出了一系列补救措施。它们包括低成本、高价值的物品——“我们已经实施了那些一位工程师自豪地报告说，这些产品成本高，价值可疑，否则会被嘲笑，但在这种特定的环境下，每个人都静静地点头表示同意。有人写下这些补救项目，或者拍下写这些项目的白板的照片。团队解散了。
也许建议的补救项目被输入到票据跟踪系统中。也许公司有一个团队，其唯一的目的是追踪这些项目，并确保每个开发和基础设施团队在某个(可能讨论过，可能达成一致，也可能两者都没有)时间框架内完成列表中的每一项。也许团队在接下来的两到三个sprint中完成了修复列表中的大量项目;希望公司对此感觉很好。或者可能是这项工作的重要性，曾经被认为是至关重要的，在满足其他目标(如承诺的新功能或大型平台迁移)的持续冲击的混乱中迷失了。又或者是另一起可能相关的关键事件?-占据了所有可以用来对之前的事件“做点什么”的注意力。
如果你对这种模式感到熟悉，那就应该熟悉。大多数技术公司的操作回顾和事件分析流程或多或少都是这样的。一些组织在实践方面比其他组织更有经验，一些组织为它培养了一个“更健康”的环境，一些组织在考虑如何向客户交付软件并为客户操作软件时更重视它。但是这个模型和它的预期输出通常是相同的，这就引出了一个重要的问题:在这个流行的清洗和重复的周期中，我们是否遗漏了一些有用的事件?
换句话说:当我们经历事件，处理它们，并处理它们的后果时，如果我们在技术和过程中撇开针对事件的，因此基本上是静态的补救项目，我们是否能学到任何其他对处理和响应事件有用的东西?我们能描述一下这种知识吗?如果是这样，我们将如何利用它来利用过去的痛苦，并提高未来成功的机会?
什么是“学习”?
组织学习的话题长期以来一直是安全科学的兴趣，研究人员已经观察了它如何在从航空到医疗到海运等行业的背景下工作近90年。组织学习被解构为三种不同的探究类别，其演进与网络规模的基础设施和软件的操作没有什么不同:
- 首先，简单地说，就是个人的、独特的教训是如何习得的——也就是说，什么构成了一个事件你如何发现你正处于其中，以及这些事件究竟如何成为个人或整个组织学习的素材。
- 其次，既然我们可以确定输入是什么样的，我们就可以询问从实际事件中学习的过程是什么样的。组织学习的很多焦点都集中在这个特定的方面，因为它涉及到真实世界的团队如何识别需要学习的经验教训，并在他们的系统中实施它们(或者不这样做)的细节。
- 最后一类研究着眼于组织学习所需的条件，主要是促进它的要素(或者，通常是阻碍它的障碍)。这一领域的主题可能会让人感到熟悉，包括组织信任和指责，组织如何设想事件影响，以及如何调查和补救事件的各种机制——例如，谁参与和不参与这些过程(以及何时参与或不参与，以及为什么会参与)。
类型的见解
将这些组织学习的不同阶段分开是很重要的，因为它允许我们在观察组织和团队中发生的事情时，根据我们需要注意的洞察力类型来描述每个领域。
- 第一个观点是基于心理学/认知的观点，其重要性已经在最近的实践部分的文章中提到。
- 这种洞察力与第二种类型密切相关:社会学洞察力，这是指在团队和整个公司的背景下，当你较少地关注个人，而更多地关注试图弄清事件的意义和如何解决它的个人群体时发生的事情。
- 最后，还有“政治洞察力”，既存在于事件的前端，也存在于事件的尾部。换句话说，你必须承认，在任何制度中，政治都在决定事件的构成、促使事件被报道的因素以及报道的最终结果方面发挥着作用。然后，在事件发生后，政治在如何沟通(或不沟通)补救项目、如何实施(或不实施)以及整个过程如何及时获得资金支持、关注份额或实际资金方面也发挥着作用。(或不)。
这些研究组织学习的框架已经应用于许多行业。(我个人最喜欢的一篇文章探讨了瑞典铁路工人如何从事故中学习，而铁路公司是如何学习的认为他们是如何学习的，而不是铁路公司本身)然而，仅仅在过去五年左右的时间里，软件操作才被置于同样的镜头下，这必然会拖累软件发展随着它在显微镜下(有趣的是，这是其他行业的安全科学所缺少的有研究了)。
在技术行业，这些调查的重点是有影响的或可见的站点/服务中断，这恰恰是因为工程师和公司在事件发生期间和之后会进行一套实践，但它们高度可变，在文献中没有很好地描述。(我的目标是在2017年底进行的一项研究中改变这一点，并在最近作为硕士论文发表。)
事后分析工件
即使是最新生的事件尸检过程也会产生某物作为一个输出。常见的例子包括事后分析报告、修复项目票据(与软件、基础结构或两者都有关)、更新的文档或运行手册，或为其他组(如客户或管理人员)提炼的通信。我深入研究了软件开发和运营组织中的组织学习，特别关注这些输出，从它们采取的各种形式开始。所有关于该事件的其他细节——事件本身、回顾展期间发生了什么，甚至这些文物是如何被创造出来的——都被认为是一个黑匣子。
这些工件的研究开始于更广泛的、行业范围的水平，通过调查征求回顾性和事后分析模板。然后分析这些模板的结构元素，以便找到共性(示例包括事件摘要、基本时间轴，以及在事后分析模板中观察到的前三个结构)，以及更独特的结构。(最不常见的元素包括:文档版本/最后修改日期、模板用户根本原因不存在的提醒，以及广泛的组织发现。)
通过分析这些不同的事后分析模板，也许最值得注意的发现是，行业中使用了不同的模板原型，每一个都有不同的重点和服务于不同的目的。从行业样本中可以明显看出以下三点:
- 记录者。这是最常见的行业模板，也是大多数从业者在想到事后分析报告时所想到的:它提供了传统的提示和“提示”，以促进事后分析流程的运行。这些问题可以包括组织希望在事后会议中提出的问题，或者提醒参与者关于组织价值观的文化气质(例如，无可指责)，或者在这些过程中希望向参与者或促进者强调的其他问题。
- 主持人。虽然在结构上类似于记录保管员，但推动者包括额外的提示和“提示”，以促进事件后分析流程的运行。这些问题可以包括组织希望在事后会议中提出的问题，或者提醒参与者关于组织价值观的文化气质(例如，无可指责)，或者在这些过程中希望向参与者或促进者强调的其他问题。
- 路标。这个模板原型可以恰当地描述为一个指针:它可以提供一个报告功能(用于分发给更大的组织进行培训或提供信息)，或者作为一个速记的“分项收据”(itemized receipt)，指向与事件相关的其他数据源，通常是各种组织记录系统。在这两种情况下，它的特点是对事件和分析结果的轻量级处理，因此，它通常被用作关于(特别是有影响的)事件的广泛组织沟通的手段。
这三个模板原型并不排除其他原型的存在;如果收集和分析了更多的行业模板，那么具有足够独特可识别元素结构的其他共性就可以定义额外的原型。事实上，随着行业内事件分析实践的发展，这些原型也应该得到发展。
产品环境中的工件使用
对行业使用事件后分析工件的调查的第二阶段围绕着一个现象学的案例研究，他们在一个生活的，呼吸的组织中观察实际使用，以及使用的影响。选择一个组织进行案例研究的一个重要方面是它都是开发软件的而且操作软件。根据2016年和2017年DevOps状态报告中描述的指导方针，它必须被认为是一个高效的组织。来自三个不同团队(开发、操作和安全)的12名工程师在三个月的时间里被观察，以了解他们如何在响应事件的过程中使用各种事件后工件——分析、补救和从中学习。在此期间，还收集和分析了来自组织实际事件的工件。
回顾过去以改善未来已经成为许多公司的首要任务，这恰恰是因为在软件开发阶段不这样做的成本难以衡量，但在软件运营阶段不这样做的成本是非常明显的。
最初的发现之一是，不同的团队以不同的方式使用相同的事件后分析工件来进行他们的工作。在分析每个工程师对工件的不同特定用途的引用频率时，出现了各种各样的主题。例如，操作工程师使用这些工件来执行关于各种系统因素的趋势分析，以及其他长期使用(例如，创建用于处理公司事件的模型)。他们还大量使用工件来为操作工作创建知识库类型的信息存储库。(事实上，他们对生成和更新文档的工件的使用明显高于其他组。)
开发人员倾向于使用这些工件来帮助确定(他们所谓的)事件的“根本原因”，以及为新特性工作和架构重构生成需求规范。工件还被用来证明或澄清以前对新团队成员和其他团队所做的工程决策，但是随着时间的推移，单个工程师已经忘记了具体的推理。(安全科学的精明追随者将熟悉与根本原因概念相关的问题;撇开这些讨论不谈，值得注意的是开发人员使用了这个术语根本原因安全工程师的使用频率是安全工程师的两倍，安全工程师的使用频率是操作工程师的两倍，操作工程师很少使用它。)
最后，安全工程师比其他团队更多地使用这些工件作为驱动他们工作的主要工具之一。在响应安全事件的背景下，这很直观:安全工程师需要对他们看到的针对生产系统的真实世界威胁作出响应，因此他们使用过去的事件作为一种增强信号的方式，表明他们应该在哪里计划他们的努力和未来的重点。这包括指导安全相关文档的生成和分发，以及推动内部安全产品路线图。
这些不同的用途加起来比它们各部分的总和还要多。在今天的现代分布式系统中，指出工程师在复杂系统中工作既不新奇也不具有争议性。在安全科学中，这个术语复杂的社会技术系统通常用来指出系统不仅是代码、计算、网络和存储的混合体，而且是人员和团队的混合体。这些人自然有相互竞争的优先事项、偏好、动机和目标，他们经常面临在极端时间和压力下做出关键决定的情况，所有这些因素有意识(或下意识)影响他们的决定和行动。
关于这些事件后人工制品使用的一个最重要的发现是，参与者使用它们来帮助创建和更新他们负责参与的紧急的、复杂的社会技术系统的心理地图。因为这些web规模的复杂软件和基础设施系统在技术和技术背后的团队方面不断发展，个人、团队甚至组织对系统如何工作的心理地图都可能随着时间的推移而退化。如果您在内部wiki上找不到4个架构图(其中没有一个是最新的)，那么您一定有过这样的经历。实际上，事件工件为这些地图提供了“补丁”，允许工程师和团队更新他们的系统的在线表示，并相互讨论他们的跨界(团队或系统)心智模型不匹配、不准确，或以其他方式妨碍了他们的工作。
对该组织复杂的社会-技术系统地图的这种更新是通过几种方式观察到的。首先，这些工件提供了更广泛的系统中看似不相干、不相连的组件之间的联系的证据。有很多这样的技术例子(“这个微服务，在特定的失败模式下，将调用它过去依赖的另一个微服务，但该依赖被认为是被删除的;然而，依赖实际上仍然存在，但只在这个特定的错误条件下”)。但这种效应也确定了未知和缺失的联系人和团队之间在系统中。最突出的例子是一个团队发现了大量的安全问题。他们位于另一个州，专注于客户支持，所以他们没有办法联系可以帮助他们的安全工程师;正因为如此，发生了一次安全事件，并进行了一次更新社会社会技术系统地图的一部分是，“这些人需要被介绍给那些人，他们之间需要建立一个持续的沟通渠道。”其中包括培训的需求，最终推广到一系列团队。
观察这种人工制品使用的第二种方式是作为识别社会技术系统内热点的一种方式。“哪里有烟，哪里就有火”这句古老的格言在这里很适用，事后分析文物让工程师们有一种感觉，即烟雾是来自于一个小的油烟火灾(触发了厨房烟雾探测器几秒钟)，还是说烟雾在四个街区外都能看到，可能需要更多的关注。同样，这提供了映射的输入地形在复杂的社会技术系统中，不仅操作工程师在操作，而且开发人员也在更新和改变，安全工程师在抵御外部攻击。这种“烟雾”可以指示(再次强调，技术和社会)组织忽略的领域，并且需要在其中投入更多的资金，但是它也可以仅仅因为复杂系统以某种意想不到的方式发展而突出需要处理的全部紧急领域。
作为这种影响的一个例子，安全工程师禁用了工程师通过使用公司范围内的网络库可用的一组特定选项;这改善了公司的安全状况。几天后，一个团队去部署他们微服务的新版本，而这个部署导致了一次宕机。在这个问题被发现并修复后，事件分析通过分发事件后的工件提出了一个“烟雾”问题，即安全团队没有任何关于他们的库的哪个版本在整个公司被使用的数据。
就组织关注其他优先事项而言，这不是忽视;更确切地说，是系统在微服务和软件依赖的复杂性方面已经发展到这样一个地步，这样的数据现在值得收集，并可能突出其他潜在的问题，其中一个因素是团队使用的旧版本被认为已被弃用。这产生了一个技术解决方案(开始跟踪库版本的使用)而且社交解决方案(该团队现在经常与数据显示仍在使用旧版本库的其他团队合作，以了解他们为什么没有迁移，是否可以帮助他们迁移，以及在迁移之前是否需要任何新特性)。
迈向动态补救项目
行业调查数据表明，91%的受访者认为收集和记录补救项目是事故后分析会议和这些会议产生的工件的核心目的。花三个月的时间观察一个高效的组织如何以不同的方式使用他们的工件，然而，揭示了另一种方法:集中于收集、理解和共享关于子系统的技术状态以及负责操作和维护它的团队的优先级、偏好、激励和约束的更深入、更丰富的上下文。在这个组织的环境中，修复项目的静态列表让位于对这一丰富背景的搜索和发布。
事件后分析阶段的主要组织重点，因此编入该阶段产生的文件，包括:
- 个人和团队如何处理事件以及他们如何协调工作。
- 他们当时对系统的心理模型是什么，包括代码的状态、基础设施和其他团队的期望，以及这些心理模型如何对他们的决策做出贡献。
- 他们的思维模式是不同的，这种差异在事件反应中的影响。
- 在事件的边缘，团队有哪些可能促成事件发生的因素(也就是说，团队面临的其他压力、激励或环境可能使他们的当地环境更容易促进与事件相关的因素)。
死记硬背的修复项目并不是讨论的主要内容。当然，并不是没有讨论补救项目;相反，它是团队已经在内部确定了他们要负责的项目的期望之前事件后分析，并(允许)负责决定这些修复的优先级。在某些情况下，它们在事后审查会议之前完成。在其他情况下，需要进一步的讨论来获得—您猜得到—进一步的上下文，以充分理解所有潜在的补救措施以及它们在更广泛的组织上下文中的相对优先级。
也许最吸引人的是:团队可以决定不来实现补救项目。考虑到组织指派给他们的其他优先事项，他们可能会认为采取一系列他们认为可以迅速修复的小型中断是正确的决定。这在他们的组织中是可行的，因为开发、操作和安全团队与他们操作的系统最接近，因此，考虑到他们的本地合理性，以及他们从周围的其他团队和系统收集到的环境，他们可以做出正确的决策。如果该决定导致进一步的中断，从而影响到组织的其他部分或客户，则相关团队之间的上下文交换将以另一种方式进行——而不是针对特定事件的补救项目列表——并推动更有弹性、更灵活的解决方案。一位工程师恰当地将这种模式描述为“战略责任多于战术责任”。
这种语境共享还有另一个好处:它促进了无可指责的概念。在相当长的一段时间里，“死后解剖是无可指责的”的观点一直在业内流传，并遭到了一些质疑。由于宕机可能会造成数百万美元的损失(甚至会对公司的生存构成威胁——只要问问Knight Capital就知道了)，我们完全可以理解这样的疑问:在节奏如此之快、后果如此之严重的情况下，是否存在无可指责的存在。但是，因为这种对社会技术系统的各种子组成部分的背景的搜索和交换比单独的补救项目更有价值，在事件发生后，理解发生了什么的第一步是“分享为什么发生了什么，为什么发生了”。这明显背离了以“你做了什么”这个问题开始的作法，然后寻求就所采取的行动是否“正确”举行一次集体公投。
早期时代，激动人心的时代
科技行业喜欢把航空作为事件和事故调查的黄金标准，但事实并非一直如此。对改进航空安全的最大贡献之一是在1980年代引入机组资源管理(CRM)。将CRM带到航空行业前列的洞察力不是基于一组针对特定事故的补救项目，而是基于对一系列事故的整体视角，并在公司、情况、设备和人员之间寻找共性。它的诞生并不是专注于零碎的修复，而是意识到改善人们的工作方式，与他人和他们的设备互动，有效地沟通和应对复杂的社会技术环境中的变化，是“热点”的一些最大发现和最大的安全胜利可能出现的地方。
鉴于人类对安全中的社会学因素的研究已经有将近一个世纪的历史，科技行业的事故后分析实践，以及我们如何创造和使用这些实践产生的人工制品，都仍处于初级阶段。因此，不要惊讶于许多这样的实践是如此相似，用于分析和理解事件和中断的认知和社会模型很少，并且固化在操作的理念中，而从事件后分析中寻求的副产品远远侧重于补救项目和预防(通常有不同程度的指责，无论我们是否愿意承认)。
但它不必一直这样。该行业是复兴的最佳时机，但我们必须摆脱这样的观念:事故后分析的唯一价值是在静态修复项目列表中，许多过程都是建模的，甚至是优化的。要否定这一概念，就需要摒弃这样的假设(当然这是令人欣慰的):如果清单上的所有项目都实现了——我们“100%地补救了这个事件!”-这样就不会再发生了。
克服这一(不可否认的)障碍，可以创造必要的认知和社交空间，以探索一件影响深远、甚至令人痛苦的事件试图传递的所有各种教训。组织可以开始采用解决方案，而不是从一系列任务和bug修复(试图解决可能永远不会再次发生的情况)开始，而是从一个地方转向更广泛的解决方案，解决容易导致此类事件发生的情况的因素。最终，这将推动事件分析过程从这种对导致我们糟糕的一天的具体事件的高度关注，演变为糟糕的一天揭示了我们的实践、过程、动机、局部环境、我们每天操作的复杂系统的真实本质，也许最有价值的是:彼此。
相关文章
在queue.acm.org
动态环境中的事后调试
大卫·帕切科
https://queue.acm.org/detail.cfm?id=2039361
网络可靠
彼得·贝利斯，凯尔·金斯伯里
https://queue.acm.org/detail.cfm?id=2655736
为什么SRE文件很重要
Shylaja Nukala和Vivek Rau
https://queue.acm.org/detail.cfm?id=3283589
数字图书馆是由计算机协会出版的。版权所有©2020 ACM股份有限公司
没有发现记录