《DevOps实践指南》笔记-Part 3

一篇文章显得略长，本文对应第5-6章、附录、认证考试、参考资源等。
前言、第1-2章请参考Part 1，第3-4章内容，请参考Part 2。

持续学习与实验的技术实践

通过以下方式制定有关提高安全性、持续改进和边做边学的制度：

• 建立公正的文化，使人们有安全感；
• 通过故障注入的方式，增强生产环境可靠性；
• 将局部发现的经验知识转化成全局提升；
• 预留专门的时间段，用来开展组织性的改进和学习活动。

将学习融入日常工作

可恢复型组织：熟练地发现问题，解决问题，并通过在整个组织中提供解决方案来扩大经验的效果。具有自我愈合的能力。

Chaos Monkey：Netflix首创，通过不断地随机删除生产服务器，来模拟AWS环境故障。不断地将故障注入到预生产和生产环境中，从而实现运维上的恢复性目标。

这一做法后来为业界广泛模仿和参考，并形成一个系统性学科：混沌工程，Chaos engineering，一门对系统进行实验的学科，旨在了解系统对应生产环境的各种混乱状况的能力，建立对系统的信心。

学习型组织是如何思考故障、事故和错误的：将其视为学习的机遇，而不是惩罚的机会。如何通过定期演练和人为模拟故障的方式加速学习。

坏苹果理论：Sidney Dekker博士提出，人为错误并不是问题的原因；恰恰相反，人为错误是提供的工具存在设计问题而造成的后果。

两个有助于创造公正的学习型文化的有效实践：

• 不指责的事后分析；
• 在生产环境中引入受控的人为故障，用于创造机会针对复杂系统中不可避免的问题进行练习。

当事故和重大事件发生时，应该在问题解决后进行不指责的事后分析（对事不对人的事后分析、事后反思）。

应对措施的范例包括：新增能检测部署流水线异常状况的自动化测试，添加更深入的生产环境遥测指标，识别需要额外同行评审的变更类型，以及在定期的演练日里进行针对此类故障的演习。

广泛地公开这些事后分析文档并鼓励组织中的其他人阅读，能增进组织学习。对于提供线上服务的公司来说，针对影响到客户的事故发布事后分析报告也越来越普遍。可显著提高对内部和外部客户的透明度，也反过来增强客户对Google的信任。

Morgue：Etsy公司开发的工具，更加轻松地记录每个事故各方面的细节（如平均恢复时间(MTTR)和严重性），更好地解决时区问题，纳入其他数据（如Markdown富文本、图片、标签和历史记录等）。Morgue的设计宗旨是让团队更加轻松地记录：

• 该问题是由于计划中还是计划外的事件引起的；
• 事后分析会议的负责人；
• 相关IRC聊天日志；
• 相关的JIRA工单，包含纠正措施及其到期时间；
• 到客户论坛帖子的链接（客户在那里对问题发牢骚）。

在复杂系统中工作时，放大微弱的故障信号对于防范灾难性故障是至关重要的。想一想宇宙飞船等系统。

两种典型的组织结构模型：

• 标准化模型：用制度和系统管理一切，包括严格遵守时间表和预算；
• 实验模型：在一种类似于研究和设计的实验室文化中，对每天的每次实验和每条新信息进行评估和辩论。

DevOps必须允许这种创新，并接受因此带来的风险。在生产环境中会遇到更多的失败。但这是一件好事，不应该惩罚。

Game Day：演练日，亚马逊引入的灾难恢复演练。

DiRT：Disaster Recovery Testing，谷歌的灾难恢复计划，参考SRE、CRE。

不指责的事后分析会议和在生产环境中注入故障都强化了这样一种文化：每个人都应该坦然面对失败，承担责任，并从失败中学习。组织唯一的可持续竞争优势就是比对手更快的学习能力。

将局部经验转化为全局改进

在整个组织的全局范围里共享和应用局部获得的新经验和优化方法，从而大大提高组织的全局知识和改进效果。

使用工具自动积累组织知识

ChatOps：最早始于GitHub的技术实践，将自动化工具集成到聊天室的会话中，帮助确立工作透明度和创建工作文档。

Hubot，聊天应用软件，用来在聊天室中和运维团队进行交互。能够触发各种自动化工具：Puppet、Capistrano、Jenkins、Resque（一个Redis维护的、创建后台作业队列的库）和GraphMe（从Graphite生成图形）​。

软件中便于重用的自动化、标准化流程

与其将专业知识写到Word文档中，不如将其转化为一种便于执行的形式，提供其易用性。如将其保存在集中的源代码库里，使之成为所有人都可以搜索和使用的工具。

ArchOps机制：将手动操作流程转换为可自动化执行的代码，流程得到广泛采纳，并为所有的使用者提供价值。

创建全组织共享的单一源代码库

在全企业范围内建立共享的源代码库是一种用来整合组织内所有局部发现的强大机制。当源代码库（例如，共享库）中的任意东西更新时，都会被自动地迅速传