Part 5 第三步 ：持续学习与实验的技术实践
在第三部分中，我们讨论了在价值流里建立快速工作流所需的技术实践。在第四部分中，我们的目标是从工作系统里尽可能多的领域中建立尽可能多的反馈，并且更及时、更迅速、更廉价。
在第五部分中，我们会展示一些能尽量快速、频繁、经济地创造更多学习机会的实践。这包括从事故和故障中学习，因为当我们在复杂的系统中工作时，故障是不可避免的 ；还包括组织和设计工作系统，使我们能不断地尝试和学习，让系统更加安全。期望达到的成果包括获得更高的弹性，以及对系统实际工作机制的日益丰富的集体知识，从而能让我们更好地实现目标。在接下来的几章中，我们将通过以下方式制定有关提高安全性、持续改进和边做边学的制度：
- 建立公正的文化，使人们有安全感 ；
- 通过故障注入的方式，增强生产环境的可靠性 ；
- 将局部发现的经验知识转化成全局的提升 ；
- 预留专门的时间段，用来开展组织性的改进和学习活动。
19. 将学习融入日常工作
在复杂的系统中工作时，我们不可能预测到所有可能的结果。即使使用了静态预防性工具，如核对表和标准化操作手册等，可还是会有意外发生，有时候甚至是灾难性的事故。这些工具只是记录了我们当前对系统的理解。
为了在复杂系统中安全地工作，组织一定要能够进行更好的自我诊断和自我改进，而且必须熟练地发现和解决问题，并通过在整个组织中传播解决方案来扩大效果。这种方式会创造出一个动态的学习系统，让我们理解错误，并将理解转化为防止这些错误复发的行动。
这就像 Steven Spear 博士所说的“可恢复型组织”，能够“熟练地发现问题，解决问题，并通过在整个组织中提供解决方案来扩大经验的效果”。这些组织具有自我愈合的能力。“对于这样的组织，应对危机并不是什么特殊的工作，而是每时每刻都在做的事情。这种响应能力是可靠性的源泉。”
Netflix 团队通过运行“捣乱猴”不断地将故障注入到预生产和生产环境中，从而实现了运维上的恢复性目标。可以想见，当他们在生产环境中首次运行“捣乱猴”的时候，服务发生的故障超出了想象。通过在正常工作时间里不断地探测和解决这些问题，Netflix 的工程师们很快反复打磨出这项弹性十足的服务，同时创造出了组织学习成果（在正常工作时间里！），从而能够开发出超越所有竞争对手的系统。
“捣乱猴”只是将学习融入日常工作中的一个例子。这个故事还展示了学习型组织是如何思考故障、事故和错误的——将其视为学习的机遇，而不是惩罚的机会。本章探讨如何创建学习系统，如何建立公正文化，以及如何通过定期演练和人为模拟故障的方式加速学习。
19.1 建立公正和学习的文化
学习型文化的先决条件之一是，当发生事故时（这是毫无疑问的），对待它的反应要“公正”。Sidney Dekker 博士整理了一些有关安全文化方面的关键要素，并且使用了公正文化这个术语。他写道：“如果对待事件和事故的反应被认为是不公正的，就可能阻碍安全调查，从而在从事安全关键性工作的人员中引发恐惧而非正念，使组织更加官僚而不是更加小心谨慎，并且诱发职业性保密、逃避和自我保护。”
Sidney Dekker 博士将这种通过消除肇事者而消除错误的观念叫作坏苹果理论。他断言这是无效的，因为“人为错误并不是问题的原因；恰恰相反，人为错误是我们提供的工具存在设计问题而造成的后果”
坏苹果理论(坏苹果法则)：如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐烂苹果，这就是坏苹果法则。
如果事故并不是“坏苹果”引起的，而是由于我们所建立的复杂系统中存在着不可避免的设计问题而导致的，那么就不应该对造成故障的人进行“点名、责备和羞辱”。我们的目标应该总是最大限度地抓住组织学习的机会，持续强调我们重视广泛地揭示和交流日常工作中的问题。这样才能提高我们所在系统的质量和安全性，并强化系统内所有人之间的关系。
当工程师犯错误时，如果可以有安全感地给出详细信息，那么他们不仅愿意对事情负责，而且会热情地帮助其他人避免同样的错误发生。这就创造了组织学习。与之相反，如果惩罚那个工程师，每个人都没有了提供必要细节的积极性，想了解故障的机制、原理和操作就无从谈起了，那么这个故障肯定还会再次发生。
有两个有效的实践有助于创造公正的学习型文化：一是不指责的事后分析；二是在生产环境中引入受控的人为故障，用于创造机会针对复杂系统中不可避免的问题进行练习。
19.2 举行不指责的事后分析会议
为了有助于建立公正文化，当事故和重大事件发生时（例如，部署失败，影响到客户的生产事件），应该在问题解决以后进行不指责的事后分析。“不只是事故本身，而且关注事故发生的机制和情景，以及事故相关人的决策过程”。
这种做法也称为对事不对人的事后分析或者事后反思。值得注意的是还有一个类似的常规回顾，是许多迭代和敏捷开发实践的一部分。
想要做到这一点，我们要在事故发生之后，记忆消退、因果关系变模糊、环境改变之前，就尽快地安排事后分析会议。（当然，我们会等到问题解决之后，以免干扰到仍在积极处理这个问题的人。）在不指责的事后分析会议上，我们会做以下事情：
- 构建时间表，从多个角度收集关于故障的所有细节，保证不会惩罚犯错误的人；
- 通过让所有工程师详细说明自己如何导致了故障，使他们能够提高安全性；
- 允许并鼓励那些犯错误的人成为教育他人以后不会犯同样错误的专家；
- 营造一个自由决策的空间，让人们决定是否采取行动，并且把对所做决定的评判放在事后；
- 制定预防类似事故的对策，并确保记录这些对策、目标日期和负责人，以便进行跟踪。
为了获得足够的理解，以下利益干系人需要出席会议：
- 参与相关问题决策的人；
- 识别问题的人；
- 响应问题的人；
- 诊断出问题的人；
- 受问题影响的人；
- 任何有兴趣参加会议的人。
必须关注细节的记录并强化这样一种文化：信息是能够分享的，不必害怕因此受到惩罚或报复。正因为如此，找一个受过训练的、和事故无关的人来组织并引导会议很有帮助，特别是在召开头几次事后分析会议时。
在会议和决议的过程中，应该明确禁止使用“原来应该”或“原本可以”等词语，因为它们是反事实的陈述，源于人类倾向于为已经发生的事件创造可能的选择。例如“我原本可以……”或“如果我知道这一点，就应该……”的反事实陈述都是用想象的方式来定义问题，而不是以事实为依据。我们要限制自己使用这样的语境
会议必须预留足够的时间，开展头脑风暴和决定应对措施。一旦确定了对策，就必须排定工作的优先次序，指定负责人和实施时间表。这进一步表明，我们对改进日常工作的重视程度超过日常工作本身。
这些应对措施的范例包括：新增能检测部署流水线异常状况的自动化测试，添加更深入的生产环境遥测指标，识别需要额外同行评审的变更类型，以及在定期的演练日里进行针对此类故障的演习。
19.3 尽可能广泛地公开事后分析会议结果
开完不指责的事后分析会议以后，应该广泛地公开会议记录和所有相关文档资料（例如，时间表、IRC 聊天日志、外部沟通）。在理想情况下，公开的信息应该放在一个集中的位置，方便整个组织里的所有人访问，从过去的事故中学习。事后分析会议非常重要，我们甚至可以将完成事后分析会议作为整个生产事故处理过程结束的标志。这样做有助于将项目中的学习和改进转化为整个组织的学习和改进。
19.4 降低事故容忍度，寻找更弱的故障信号
随着组织学到如何有效地看待和解决问题，就需要降低判定故障的阈值，以便更深入地学习。为此，我们想放大那些微弱的故障信号。
NASA 在航天飞机时代处理故障信号的方式可以证明这一点。2003 年，哥伦比亚号航天飞机于执行任务的第 16 天，在重新进入地球大气层时爆炸了。我们现在知道，在它起飞时，一块绝缘泡沫击穿了外部燃料箱。然而，在哥伦比亚号返航前，一些中级 NASA 工程师就已经报告了这个事件，但是他们的意见并没有得到重视。他们在发射后的回顾会议期间通过监视器观察到了泡沫块的撞击，并立即向 NASA 的管理人员报告。不过他们被告知，泡沫问题并不是什么新鲜事。在以前的发射中，泡沫漂移曾经损坏过飞船，但从未导致重大事故。NASA 将这次事件定性为维护问题，并没有采取任何行动。直到最后事故发生，一切都晚了。
他们观察到，“当企业在组织里运用错误的思维方式时，就会陷入困境（这决定了他们如何处理不明确的威胁，用本书的术语来说就是微弱的故障信号）……到了 20 世纪 70 年代，NASA营造出了一种僵化的标准化文化，向国会把航天飞机宣传为一种可重复使用的廉价航天器”。NASA 严格遵从流程合规性而不是实验模型，对每条信息都进行评估，确认没有发生偏差。缺乏持续学习和实验的后果是很可怕的。作者的结论是，文化和思维模式是至关重要的，只有“谨慎”远远不够。他们写道：“单靠警惕不能防止不明确的威胁（微弱故障信号）变成代价惨重的事故（有时是悲剧）。”
我们在技术价值流中的工作就如同太空旅行，应该将其作为基础的实验性尝试，并以这种方式进行管理。我们所做的全部工作都是潜在的重要假设和数据来源，而不是重复的例行公事或对过去实践的验证。不能将技术工作看成是完全标准化的，力图实现流程合规。相反，必须持续不断地寻找越来越弱的故障信号，进而更好地理解和管理运维中的系统。
19.5 重新定义失败，鼓励评估风险
无论有意还是无意，组织的领导者都会通过行动来加强组织文化和价值观。审计、会计和道德专家长期以来一直认为，“高层的声音”可能意味着欺诈和其他不道德行径。为了加强学习和评估风险的文化，领导者需要不断强调：每个人都应该坦然面对失败并承担责任，并能够从失败中学习
“我和一个同事谈论了 Netflix 刚刚发生的一次大规模服务中断——坦率地说，这是由一个低级错误引发的。事实上，造成此次事故的工程师在过去 18 个月内曾经让 Netflix 宕机两次。然而他是我们绝不会开除的人。在过去的 18 个月里，这名工程师大幅改进了运维和自动化的状态，进步不是以‘千米’而是以‘光年’衡量，成绩突出。他的工作成果使我们每天能够安全地进行部署，而且他亲自执行了大量的生产环境部署。”
他总结道：“DevOps 必须允许这种创新，并接受因此带来的风险。是的，在生产环境中会遇到更多的失败。但这是一件好事，不应该惩罚。”
19.6 在生产环境注入故障来恢复和学习
正如本章开头介绍的，将错误注入到生产环境中（如使用“捣乱猴”）是提高可恢复性的一种方式。本节描述在系统中演练和注入故障的过程，以确保正确地设计和构建系统，进而让故障以特定和受控的方式发生。我们通过定期（甚至持续不断地）执行测试来确保系统正常失败。
可恢复性要求我们首先定义故障模式，然后进行测试，以确保这些故障模式是按照设计运行的。一种做法是，在生产环境中注入故障，并且演练大规模故障。这样才能自信系统在事故发生时能够自我恢复，在理想情况下，甚至不会影响到客户。
主动关注可恢复性意味着公司能够以常规、平常的方式处理可能在大多数组织里引发危机的事件。
他们实现的特定架构模式包括快速失败（设置主动的超时，从而使失败的组件不会造成整个系统中止）、回退（设计每个功能，使其能降级或回退到较低的质量表现）以及功能移除（从任何运行缓慢的特定页面上删除非关键功能，以防用户体验受到影响）。除了在 AWS 宕机期间保持了业务连续性以外，Netflix 团队创造的恢复力还有一个令人惊奇的例子。在 AWS 宕机事故发生 6 个小时以后，Netflix 才对外声明了一级（Sev 1）事故，假设 AWS 服务最终将恢复正常（“AWS 会恢复的……一般都是这样，对吧？”）。在 AWS 服务中断 6 小时以后，他们才启动了所有的业务连续性流程。
19.7 创建故障演练日
本节将描述一种特别的灾难恢复演练，称为演练日（Game Day）。演练日的概念来源于弹性工程学科。弹性工程定义为“旨在通过向关键系统中注入大规模故障来提高可恢复性的练习”。
演练日的目标是帮助团队模拟和演练事故，使其具备实战能力。首先，计划一个灾难性事件，例如模拟整个数据中心在未来的某个时间点遭到破坏。然后，给团队准备的时间来消除所有的单点故障，并创建必要的监控程序和故障切换程序等
通过这样做，我们开始暴露系统中的潜在缺陷。正是因为在系统中注入了故障，才让这些问题浮出水面。Robbins 解释：“你可能会发现，对于恢复过程至关重要的某些监控或管理系统，终将在故障编排的一个步骤里关闭。[或者]你会发现一些未知的单点故障。”然后，以越来越深刻和复杂的方式进行演练，目的是使人们觉得，这就是日常工作的一部分。
在这些灾难中学到的东西包括：
- 当网络连接中断时，做不到用工程师的工作站进行失效备援；
- 工程师不知道如何接入电话会议桥接器或只能容纳 50 人的桥接器，抑或需要一个新的电话会议提供商，好踢掉那个让电话会议中所有人等待的工程师；
- 当数据中心里备用发电机的柴油耗尽时，没有人知道通过供应商进行紧急采购的流程，导致有人使用个人信用卡购买了价值 5 万美元的柴油。
通过在受控的情况下引入故障，我们可以实践、建立所需的操作手册。演练日的另一个输出是，人们确实知道了应该给谁打电话、应该与谁交谈。这样会让他们与其他部门的人建立关系，以便在发生事故时一起工作，将有意识的行动转变为下意识的行动，然后进一步成为惯例。
19.8 小结
为了创造能够实现组织学习的公正文化，我们必须重新描述所谓的失败。当我们正确处理错误时，复杂系统中固有的错误能够为我们创造一个动态的学习环境，其中的所有利益干系人都有足够的安全感来提出想法和见解，而且团队能够更容易地从未能如期执行的项目中恢复。
不指责的事后分析会议和在生产环境中注入故障都强化了这样一种文化：每个人都应该坦然面对失败，承担责任，并从失败中学习。事实上，当事故数量大幅降低时，容忍度同时也下降了，从而让我们能够继续学习。正如 Peter Senge 所说：“组织唯一的可持续竞争优势就是比对手更快的学习能力。”
20. 将局部经验转化为全局改进
本章将建立一种机制，在整个组织的全局范围里共享和应用局部获得的新经验和优化方法，从而大大提高组织的全局知识和改进效果。这将提升整个组织的实践状态，使每个人都在工作中从组织积累的经验里受益
20.1 使用聊天室和聊天机器人自动积累组织知识
许多组织已经建立了用于促进内部快速沟通的聊天室。不过，聊天室也可以用于触发自动化运维
GitHub 发明了一个名叫 Hubot 的聊天应用软件，用来在聊天室中和运维团队进行交互。人们可以通过发送指令（例如，“@hubot deploy owl to production”）来指示它执行某些运维操作。操作的结果也会由它发送回聊天室。类似地，不管是向源代码库提交代码，还是触发生产环境部署的命令，都会向聊天室发送消息。
在聊天室中自动化执行操作具有许多优点（和通过命令行运行自动化脚本相比）：
- 每个人都能看到发生的一切；
- 新来的工程师也可以看到团队的日常工作及其执行方式；
- 看到其他人互相帮助时，人们也会更倾向于寻求帮助；
- 建立起组织学习，知识得到快速积累
此外，除了以上得到广泛验证的好处之外，聊天室还以固有的方式记录并公开所有的沟通信息。相比之下，电子邮件的交流在默认情况下是私密的，而且其中的信息无法方便地在组织内传播。
通过 Hubot 执行的操作包括检查服务的健康状况，执行 Puppet 推送或在生产环境中部署代码，以及当服务进入维护模式时，屏蔽它的监控警报。重复执行的操作都可以用 Hubot 来完成。例如，在部署失败时调出冒烟测试日志，将生产服务器从服务群集里撤出，将生产的前端服务回退到之前的版本，甚至向值班工程师道歉。
GitHub 创造的协作环境能够将在局部学习到的知识转化为整个组织的经验。随后，我们将探讨如何创建和加速传播组织学习。
20.2 软件中便于重用的自动化、标准化流程
我们经常把架构、测试、部署和基础设施管理的标准和流程编写成文，存储为 Word 文档，并上传到某个服务器里。然而问题是，那些正在构建新应用或新环境的工程师往往不知道这些文档的存在，或者根本没有时间按照文档中的标准去实施。结果就是，他们创建了自己的工具和流程，结局令人失望：应用和环境脆弱、不安全、无法维护，而且运行、维护和更新的成本都很昂贵。
与其将专业知识写到 Word 文档中，倒不如将完整包含组织学习和知识的各种标准和流程转化为一种便于执行的形式，使之更容易重用。实现这种知识重用的一种好方法是：将其保存在集中的源代码库里，使之成为所有人都可以搜索和使用的工具。
他们创建了一种称为 ArchOps 的机制，“使工程师成为构建者，而不是砌砖工。通过将设计标准转换成可以自动化执行的蓝图，使任何人都能轻松地使用，我们实现了副产品的一致性”。
通过将手动操作流程转换为可自动化执行的代码，流程得到了广泛采纳，并为所有的使用者提供了价值。Arbuckle 总结道：“组织的实际合规性与其用代码表达政策的程度成正比。”
把自动化流程变为实现目标的最简单方式，可以让实践得到广泛采纳——甚至可以考虑将其转换为由组织支持的共享服务。
20.3 创建全组织共享的单一源代码库
在全企业范围内建立共享的源代码库是一种用来整合组织内所有局部发现的强大机制。当源代码库（例如，共享库）中的任意东西更新时，都会被自动地迅速传播给所有调用它的其他服务，并且通过每个团队的部署流水线进行集成
我们保存在共享源代码库里的不仅是源代码，还有包含其他学习经验和知识的工件：
- 程序库、基础设施和环境（Chef 的配方文件、Puppet 类文件等）的配置标准；
- 部署工具；
- 测试标准和工具，包括安全方面；
- 部署流水线工具；
- 监测和分析工具；
- 教程和标准
“防止谷歌发生故障的最强大机制就是单一代码库。每当有人向代码库里提交更新时，都会触发一个新的构建，它使用的所有依赖也都是最新的。一切都是由源代码构建而成的，而不是运行时的动态链接——总是只有单一版本的库可用，也就是当前使用的那个，而它是在构建的过程中静态链接的。”
如果不能构建单一的源代码树（源代码库），就必须找到另一种维护程序库的方法，从而保证依赖程序库的都是已知的可用版本。例如，可能要搭建一个全组织范围的仓库，如 Nexus、Artifactory 或者一个 Debian 或 RPM 库，然后针对已知的安全漏洞同时更新这些仓库和生产系统。
20.4 运用自动化测试记录和交流实践来传播知识
当整个组织都使用了共享程序库时，我们应该能够快速传播专业知识和改进方法。确保这些程序库里有大量的自动化测试，意味着这些库能够自动记录并显示其他工程师是如何使用它们的。
如果采用测试驱动开发（TDD）实践，即在编写代码之前编写自动化测试，好处是测试几乎全部自动化。这个原则将测试套件变成活跃、保持更新的系统规范。任何想知道如何使用系统的工程师都可以查看测试套件，找到系统 API 的可行使用示例。
理想情况下，每个程序库都有一个所有者或支持团队，他们拥有相关的知识和专长。此外，我们应该（最好）只允许在生产环境中使用一个版本，确保生产的一切都用到了组织的最佳集体知识。
在这个模型中，程序库的所有者还需要帮助每个依赖它的团队安全地从一个版本迁移到下一个版本。这反过来要求我们对所有依赖它的系统进行综合的自动化测试和持续集成，从而迅速发现回归误差。
为了更快地传播知识，还可以为每个程序库或服务建立讨论组或聊天室。任何有问题的人都可以在此得到其他用户的反馈，响应速度通常比开发人员还要快。
相比分散在组织各处的专业知识，通过使用这种类型的沟通工具能够促进知识和经验的交流，确保员工在问题和新模式上互相帮助。
20.5 通过确定非功能性需求来设计运维
实现这些非功能性需求会使我们的生产服务更易于部署并持续运行，从而可以快速地检测并修复问题，还能保证在服务组件出现故障时正常降级。下面是应该具备的非功能性需求示例：
- 对各种应用和环境进行充分的遥测；
- 准确跟踪依赖关系的能力；
- 具有弹性并能正常降级的服务；
- 各版本之间具有向前和向后的兼容性；
- 归档数据来管理生产数据集的能力；
- 轻松搜索和理解各种服务日志信息的能力；
- 通过多个服务跟踪用户请求的能力；
- 使用功能开关或其他方法实现简便、集中式的运行时配置。
通过确定这些非功能性需求，能更容易地把集体知识和经验运用到新服务和已有服务上。这些责任都由构建服务的团队承担。
20.6 把可重用的运维用户故事纳入开发
如果某些运维工作无法完全自动化或自助化，我们的目标是尽量将这种反复发生的工作变得能够重复、确定地执行。我们通过将所需工作标准化、使其尽可能自动化并且记录下所做工作来做到这一点，从而使产品团队能够最好地为这种活动建言献策。
与其手动搭建服务器，然后按照检查清单逐条核对并在生产环境里投产上线，不如尽可能地自动化这些工作。如果某些操作步骤是不能自动化的（例如，手动进行服务器上架，然后让网络组连接电缆），就应该将工作交接内容定义得尽量清晰，以缩短前置时间和错误。这也便于以后更好地计划和安排这些步骤。
就像在开发阶段中创建用户故事，将其放入待办事项然后编码实现一样，我们也可以创建定义明确的“运维用户故事”，说明那些在所有项目中（例如部署、容量规划、安全性加固等）可以重用的工作活动。通过创建这些明确定义的运维用户故事，我们把可重复的 IT 运维工作和相关开发工作共同展现出来，从而创造更好的工作计划和更多的可重复成果。
用户故事是指开发团队为满足一个用户特定需求而设计的特定功能、路径和服务，以满足其在应用程序中的行为和任务的完整叙述或描述。从整体来看，用户故事是软件信息的面向对象分层分析，主要包括核心用户故事，衍生故事和产品属性，其中核心用户故事是一种叙述性状态，用于描述用户正在使用的系统及其主要功能和可用性；衍生故事必须是核心用户故事的一部分，实施衍生故事可以改善基础用户故事的质量；产品属性可以定义复杂性属性的类别。这既受到用户的建议，也受到管理者的建议，基于这两部分，把它们结合起来，然后把它们以故事形式表达出来，以更具体的方式完成所要求的软件需求。
20.7 确保技术选型有助于实现组织目标
当我们使用面向服务的架构，并且目标之一是最大化开发人员的生产力时，小型服务团队可以使用最适合特定需求的语言或框架来构建和运行服务。在某些情况下，这是我们实现组织目标的最佳方式。
如果还没有开发和运维共同制定的、组织支持的技术清单，就应该系统地研究生产环境基础设施和服务，以及当前支持的底层技术，从而识别出造成了一定无谓故障和计划外工作的技术。我们需要识别有下列特征的技术：
- 阻止或减慢了工作流；
- 造成了不成比例的大量计划外工作；
- 产生了不成比例的大量支持请求；
- 与我们所需的架构结果（例如吞吐量、稳定性、安全性、可靠性和业务连续性）完全不一致。
通过从运维团队支持的技术中排除这些有问题的基础设施和平台，运维团队就可以专注于最有助于实现组织全局目标的基础设施。
20.8 小结
本章介绍的技术能将一点一滴新的学习纳入组织的集体知识，并成倍地发挥其效果。我们通过主动和广泛地传播新知识来实现这个目标，例如采用聊天室、架构即代码、共享源代码库、技术标准化等方法。这样做不仅能提升开发和运维团队，更能提升整个组织，因此组织中的每个工作者都在为积累集体经验添砖加瓦。
21. 预留组织学习和改进的时间
有一种称作改善闪电战（improvement blitz 或 kaizen blitz）的实践，是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定问题，通常长达几天。Steven Spear 博士解释：“改善闪电战经常采取的形式是，一个小组聚在一起，专注探究一个存在问题的流程……改善闪电战通常持续几天，目标是优化流程，方法则是集中地让流程之外的人给通常在流程里的人提建议。”
本章随后介绍多种方法，用于为组织学习和改进预留时间，以及进一步将投入时间改进日常工作的做法制度化。
21.1 偿还技术债务的制度化惯例
本节介绍的惯例做法，有助于加强为改进工作预留开发和运维时间的实践，如非功能性需求和自动化等。一个最简单的方法就是，安排和进行为期几天或几周的改善闪电战，让团队里的每个人（或整个组织）自行组织来解决关心的问题——不允许进行任何功能性工作。可以着眼于代码、环境、架构、工具等的一个问题点。这些团队经常由开发、运维和信息安全工程师组成，横跨整个价值流。一般不在一起工作的团队可以把各自的技能和努力结合起来，改进选定的领域，然后向公司中的其他人展示成果。
我们在这些闪电战期间的目标不是简单地为了测试新技术而进行实验和创新，而是改进日常工作，如找出日常工作中的变通方案。虽然实验也会带来一定的改进，但是改善闪电战的重点是解决日常工作中遇到的具体问题。
21.2 让所有人教学相长
不论是通过传统的说教方式（如上课、培训），还是通过更具实验性或开放式的方法（例如会议、工作坊、指导），动态的学习文化都不仅能为每个人创造学习条件，还能创造教学的机会。我们可以投入专门的组织时间来促进这种教和学。
从本书中可以明显发现，所有工程师都越来越需要某些技能，而不只是开发人员如此。例如，对于所有运维和测试工程师来说，熟悉开发技术、惯例和技能变得越来越重要，例如版本控制、自动化测试、部署流水线、配置管理和自动化。熟悉开发技术有助于运维工程师保持相关性，因为越来越多的技术价值流采用了 DevOps 的原则和模式
开发和运维团队可以通过共同执行代码审查，在日常工作中进一步教授技能，从而在做中学，并且一起解决一些小问题。例如，开发人员可以向运维人员演示应用程序如何认证用户，登录应用程序，以及进行各个组件的自动化测试，从而确保关键组件正常工作（例如，应用程序的核心功能、数据库事务、消息队列）。然后，将这个新的自动化测试集成到部署流水线中并定期运行，把测试结果发送到监控和告警系统，以便在关键组件出现故障时及早发现。
21.3 在 DevOps 会议中分享经验
在许多注重成本的组织中，工程师常常不愿参加会议和向同行学习。为了建立起学习型组织，我们应该鼓励工程师（来自开发和运维部门）参加会议，并在必要时自己创建和组织内部或外部会议
21.4 传播实践的内部顾问和教练
成立内部的教练和咨询组织是一种在组织内传播专业知识的常见方法。它可以有许多形式。在第一资本银行里，所有领域专家都会指定一些时段用于接受任何人的咨询，以及回答提出的问题。
在本书前面，我们讲述了谷歌的测试小组 Testing Grouplet 如何从 2005 年开始在谷歌内部建立起世界级的自动化测试文化。他们的故事还在不断向前发展——为了全面提升谷歌内部的自动化测试实践，他们使用了改善闪电战、内部教练，甚至内部认证计划。
21.5 小结
本章描述了如何建立一系列惯例，来帮助强化终身学习以及重视在日常工作中改进日常工作的文化。具体实现方法是：预留偿还技术债务的时间；创建论坛，使大家能够在组织内部和外部互相学习和指导；通过辅导、咨询，或者仅仅设置一段面谈时间，让专家能够为内部团队提供帮助。
通过使所有人都在日常工作中相互学习，我们比在竞争中学到的更多，从而能够赢得市场。与此同时，我们也在帮助彼此激发出人类的全部潜力。
21.6 第五部分总结
在第五部分中，我们探讨了在组织中创造学习和实验文化的实践。当我们在复杂系统中工作时，从事故中学习，创建共享代码库和共享知识是必不可少的，这有助于工作文化更公正，系统更安全、更具弹性。
在第六部分中，我们将探讨如何扩展流动、反馈、学习和实验，让它们同时帮助我们实现信息安全目标。