DevOps 文字培训
应如何推动 DevOps 持续学习？
你的软件项目经历已经告诉你，即使采用核对清单、同行评审、控制、审计和合规机制，也仍然会出问题。这无法避免。DevOps 团队和组织需要建立自我诊断、自我学习和自我改进的文化。这样的文化接受问题的存在，团队也做好了应对问题的准备。解决问题应是日常工作的一部分，以推动组织不断学习和改进。让问题的解决方案在整个 DevOps 组织内透明可见、易于获取，还能放大这些解决方案的作用。
领先的 DevOps 组织之一 Netflix 开发了一款内部软件 Chaos Monkey，用来模拟云数据中心的灾难性事件。Chaos Monkey 会随机让生产系统中的服务器失效，让 Netflix 团队更有把握地保证其运维具有韧性、稳定性，并持续为客户提供优质服务。他们从每次故障中吸取新经验，再用这些经验进一步提高系统的稳定性和韧性。
认识建立学习文化的重要性
如果组织在事件发生后互相指责，就会让工程师产生恐惧。结果，组织会变得行动迟缓、官僚气息浓重，并陷入复杂的内部争斗。人们不会主动从错误中学习，不会自然提高抵御和承受错误的能力，也不会更留意如何预防错误。在这样的组织中，每个人都忙着自保。工作、问题，甚至解决方案本身，都不会完全透明。
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- 他们少做工作，以便少犯错误。
- 他们不会公开工作、问题和解决方案。
- 他们缺乏动力将解决问题的经验转化为组织学习成果。
- 同样或非常类似的问题一定会再次发生，因为从来没有人花时间和精力了解、分享、讲解问题及其解决方案，也没有人让它们公开可见。
事件发生后立即复盘，趁人们还记得问题的原因
事后复盘的目标很简单：
- 找出做对的地方，以便在类似情况下记得再次尝试。
- 记录本该换一种方式处理的地方，以便今后改进做法。
- 记录做错的地方，并提出下次遇到类似问题时应采用的替代方法或安全措施。
- 了解为何采取（或不采取）导致该事件的行动在当时是合理的。
审视自己的失误令人害怕，在某些组织中甚至有风险。如果承认错误会招致批评或处分，你就不太可能承认。从长远看，这样做会适得其反，因为不了解过去的错误，通常就难免日后重蹈覆辙。真正重视改进的组织明白这一点，并努力建立让人能放心探究错误的流程和文化。
进入事后复盘流程时，必须接受几个基本前提：
- 每个人都会根据自己的理解尽力而为。
- 你在有压力且信息不完整的情况下作出决定。
- 你经常需要用当时手头的工具和资源，完成自己未受过相关培训的任务。
- 在这些情况下，错误不可避免。
- 这个流程的目的是回顾发生了什么，看看能从中学到什么，避免追究个人或其行为的过失。
- 此流程的输出是对流程本身及其改进方式的评估，不用于评价个人或群体。
所有参与者必须完全接受这个“无责学习模式”。许多组织付出很大努力创造这类安全环境。例如，FAA 设立了航空安全报告系统，犯下“错误”的飞行员如果报告相关事件，可以免于监管处分。
事后复盘必须制定可执行的措施，避免事件今后再次发生。此类预防措施包括增加遥测指标和自动化测试用例、确定哪些类型的变更需要额外代码评审，以及重构代码或解耦经常引发问题的复杂系统组件。
在组织内广泛发布事后复盘记录和经验教训。这能帮助你将价值流中某个工作中心的局部经验，转化为整个组织的共同经验。它也会向 DevOps 组织传递明确信息，鼓励透明、开放和学习的文化。
组织故障演练日，改进系统
故障演练日不同于典型的乏味团建，那种活动里外向的人乐在其中，内向的人只顾玩手机打发时间。
在故障演练日，你会在测试系统中模拟灾难性故障，DevOps 团队则努力修复并从故障中学习。
例如，关闭一台关键服务器，验证故障转移机制能否在不中断服务的情况下正常运行。随后，DevOps 团队验证利用备份或基础设施即代码（IaC）的恢复机制是否有效、如何运作。在这些故障场景中发现问题，有助于团队构建有韧性、能容错的系统，并积累经验。
在解决问题的过程中，DevOps 团队可以在没有压力的情况下演练故障场景，与其他部门建立联系。你将检验更大范围组织内的沟通和故障排查流程，并清楚看到改进机会。
此外，你还有机会看到某些微弱信号，它们可能指向未来会暴露的更大问题。在这些故障场景中频繁出现的低优先级事件，或者差点导致架构中另一个关键组件崩溃的小副作用，都是应重视并处理的微弱信号，可以用来改进系统。
总结
鼓励 DevOps 团队承担经过权衡的风险。像你们这样的高绩效 DevOps 组织会更经常犯错。这不仅可以接受，而且是组织不断学习和提升绩效所需要的。
与普通组织相比，高绩效组织的生产系统严重故障少 80%。换句话说，影响客户的事件只有普通组织的五分之一。因此，DevOps 工程师需要敢于犯错，并从中学习。
