《Devops实践指南》学习总结(全干货)

Devops基于精益原则，约束理论，和丰田套路运动，并拓展了”基础设施即代码“的实践，被人们视作敏捷运动的延续
基础设施即代码 包括 持续集成，持续交付，和持续部署

技术价值流：把业务构想转化为向客户交付价值的，由技术驱动的服务所需要的流程
前置时间：从工单创建到工作完成需要的时间
处理时间：从开始处理到完成需要的时间

Devops的基础原则，三步工作法

第一步：流动原则

实现开发到运维的工作快速的从左向右流动

• 将工作可视化
• 限制在制品数
• 减少批量大小
• 减少交接次数
• 持续识别和改进约束点，环境搭建，代码部署，测试，架构等环节中改进
• 消除日常工作中的浪费

第二步：反馈原则
使得从左到右每个阶段都够快速、持续地获得工作反馈

• 及时发现问题，建立监控系统
• 群策群力解决问题
• 在源头保障质量
• 不断地为下游工作重心做优化，

第三步：持续学习与实验原则
要建立持续学习与实验的文化

• 建立学习型组织和安全文化
• 将日常工作的改进制度化
• 把局部发现转化为全局优化
• 在入场工作中注入弹性模式
• 领导层强化学习文化

从何处开始

5选择合适的价值流作为切入点

绿地项目，绿地项目指全新的软件项目，Devops绿地项目指一些试点项目
棕地项目，devops棕地项目指那些已经服务客户几年几十年的产品或服务，这些项目一般背负大量的技术债务(Technical debt)，无自动化测试，运行在无人维护的平台等

兼顾记录型系统和交互型系统：兼顾”做的正确“和“做的快速”，兼顾质量和速度

从最乐于创新的团队作为切入点，并在此基础上扩大范围

• 发现创新者和早期采用者
• 赢得沉默的大多数
• 识别钉子户：那些有影响力的反对者，只有在获得大多数人的支持，建立起最够的群众基础之后，在考虑这一群体

6理解，可视化和运用价值

确定创造客户价值所需团队**

确定客户价值流团队所需成员：产品负责人，开发团队，QA团队，运维团队，信息安全团队，发布经理，技术主管或价值流经理

针对团队工作绘制价值流图

组件专门的转型团队

• 拥有共同的目标
• 保持小跨度的改进计划，如创业团队一样，在数周内要奴鲁获得可度量的改进成果或者可用的数据
• 为非功能性需求预留20%的开发时间，减少技术债务,确保20%开发时间用于重构，自动化工作，否则应付老问题已经让自己不堪重负，根本无法开展新工作，这就在偿还技术债务的利息
• 提高工作的可视化程度

用工具强化预期行为

比如聊天室

参考康威定律设计组织架构

康威定律：软件的架构反映了软件团队的结构
换句话说，软件开发团队的结构对软件产品的架构和成果有着巨大的影响

组织原型**

职能型：注重提高专业技能，优化分工和降低成本
矩阵型：结合职能型和市场型，组织结构负责，一名员工可能要向多个经理汇报
市场型：注重快速响应客户需求

过度职能导向的危害（成本优化）

根据专业领域组织团队，对于无需进行频繁交付的软件来说肯能没问题，但对于复杂交付工作，一项工作开多个工单，协调复杂，导致交付周期延长，

组建以市场为导向的团队（速度优化）

将工程师及其专业技能嵌入每个服务团队，使每个服务团队都能独立的向客户交付价值，而不必提交工单给IT运维，QA和信息安全部门

使职能导向有效

职能导向也可以成就高效运转的组织，要求组织文化上高度信任，工作优先级透明，系统预留了足够的容量能够迅速的完成高优先级的工作。

将测试、运维和信息安全融入到日常工作中

使团队成员都成为通才

给工程师提供学习必要技能的机会并各职位轮岗，全栈工程师。

投资于服务和项目，而非产品

组建稳定的服务团队，持续提供资金，不因为项目的完成而解散团队。

根据康威定律设置团队边界

理想状况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多的不必要的沟通和协调

创建松耦合架构，提高生产力和安全性

在紧耦合的架构中，即使是小范围的变更也会导致大规模的故障，相反，如果架构能够支持小团队独立，安全、快速的进行开发测试和部署，就可以提高和维持开发人员的生产力，**面向服务架构(SOA)**就有这种特征，微服务就是基于这种架构。

将运维融入日常开发工作

三个通用策略：

• 构建自服务能力，帮助开发人员提高生产力
• 将运维工程师融入服务团队
• 如果运维工程师人数紧张，则可以采用运维联络人模式

创建共享服务，提高开发生产力

运维部门要想取得以市场为导向的成果，一种做法是创建一套集中式全自动化平台与工具及服务(例如流水线，自动化测试平台)，并且是按需提供，不用提交工单等待手动处理。

将运维工程师融入服务团队

另一种做法：将运维工程师融入团队，使团队自给自足。参与开发团队的相关讨论，计划会议，每日站会等

为每个团队分派运维联络人

与融入运维工程师的模式相同，运维联络人也要参加团队的站会，把团队的需求纳入整体的运维计划，并且在必要的时候执行相关任务，在发生资源竞争或优先级冲突时，团队依赖运维联络人推进问题的解决。

邀请运维工程师参加开发团队的会议 包括每日站会、计划会议、回顾会议

• 更好的了解开发团队的文化
• 更好的为产品团队植入运维能力

流动的技术实践

重点讨论以下内容：

• 为部署流水线奠定基础
• 实现快速可靠的自动化测试
• 实现并实践持续集成和持续测试
• 通过自动化、架构解耦等方式实现低风险发布

为部署流水线奠定基础

如何搭建环境，
如何使用版本控制系统的使用范围包含价值流中的每个成员，
如何使基础设施更容易重复搭建，

按需搭建开发环境、测试环境和生产环境

自动化的搭建环境

应用统一的代码仓库

版本控制系统应该应用到价值流中的每一个环节，我们能够重复和可靠地重新生成软件系统的所有组件，必须把下列资源纳入版本控制系统，要求能重现各个环境，包括预生产环境和构建环境

• 应用的所有代码和依赖项
• 任何用于创建数据库模式的脚本、应用的参考数据等
• 所有用于搭建环境的工具和工件 puppet或chef配置模块等
• 任何构建容器所使用的文件
• 所有支持自动化测试和手动测试的脚本
• 任何支持代码打包、部署、数据库迁移和环境置备的脚本
• 所有项目工件(需求文档、部署过程、发布说明等)
• 所有云平台配置文件
• 创建支持多种基础设施服务(企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备)所需的任何脚本和其他配置信息

为什么要对环境进行版本控制更能预测IT效能和组织绩效呢？
实际上，几乎在所有情况下，环境的可配置参数都要比代码的可配置参数多好几个数量级，所以，环境最需要使用版本控制

使基础设施的重建更容易

就算生产环境只有一台服务器，也要采取按需快速重建环境的方法
通过重复创建环境，更快的水平扩容，避免当不可再现的基础设施发生灾难性故障后必须修复的痛苦。
要确保所有变更都能自动地复制到所有环境并被版本控制系统记录，而不需要手动登陆服务器
要频繁的更新环境，这样在能在开发周期的最早阶段找出问题(整个应用栈和环境都可以固化到容器中，这也可以简化整个部署流水线)

运行在类生产环境(类似生产环境)里才算完成

构建从开发到运维的快速工作流，需要确保任何人都能按需获得类生产环境，通过让开发人员在最初就用类生产环境，可以显著降低生产环境出现问题的风险

实现快速可靠的自动化测试

来自谷歌的统计数据：

• 每天4万次代码提交
• 每天五万次代码构建
• 拥有12万个自动化测试套件
• 每天运行7500万个测试用例
• 拥有100多名专门执行测试用例、持续集成和发布工具的工程师，他们负责提升开发人员的生产效率

对代码和环境做持续构建、测试和集成

让开发人员在日常工作中创建自动化测试套件，建立快速的反馈回路，尽早发现问题
通过创建部署流水线，当新的变更进入版本控制系统时，就会触发一系列自动化测试
部署流水线确保所有检入版本控制系统的代码都是自动化构建的，并在类生产环境中测试过。当开发人员提交代码变更之后，立即就能获得关于构建、测试和集成错误的反馈，从而使开发人员能够立即修复这些错误。正确的持续集成实践总是可以确保代码处于可部署和可交付状态。
为了实现这点，必须在专用环境中创建自动化构建和测试流程，原因如下：

• 在任何时候，构建和测试流程都能够运行，无论工程师的个人习惯如何
• 独立的构建和测试流程确保工程师能理解构建、打包、运行和测试代码所需的全部依赖(消除在开发人员电脑上可以运行，在生产环境不行的问题)
• 将应用的可执行文件和配置打包，并可以在环境中重复安装
• 将应用打包到可部署的容器中
• 以一致、可重复的方式进行类生产环境配置

构建快速可靠的自动化测试套件

强调执行持续集成和持续测试的必要性？如果只夜间构建，将会发生什么？
假设团队10名开发人员，每人每天检入一次，而某个开发人员的代码导致夜间构建和测试失败，则第二天才能发现，可能要花几个小时才能解决问题，更糟的是如果问题不是代码变更，而是测试环境(例如某个错误的环境配置)，那么开发团队很可能认为问题已经解决，因为所有的单元测试都通过了。可是在夜间构建的过程中，集成测试仍会失败，如果新的一天又检入10个变更，而每个变更都可能引入错误，进一步增加了解决问题的难度

这样就要求当有新的变更检入控制系统时，需要在构建和测试环境中运行快速的自动化测试，立即发现问题，
通常自动化测试从快到慢分为以下几类：

• 单元测试：确保每个方法，类函数正确，
• 验收测试：整体测试应用，确保各个功能模块按照正常设计正常工作，并且没有引入回归错误（没有破坏以前正常的功能）
• 集成测试：保证应用和生产环境中的其他应用和服务正确交互

要度量测试覆盖率，并可视化，甚至在低于一定水平时时测试套件的验证结果显示失败。
**

在自动化测试中尽早发现错误

自动化测试套件一个设计目标是能尽早在测试中发现错误，因此在执行那些耗时较多的测试之前，应该执行完速度更快的测试（单元测试）。
以上原则得出结论：最快速的测试应该尽可能多的发现错误

尽可能并行的快速执行测试

先编写自动化测试

要确保自动化测试可靠，通过
测试驱动开发 Test-Driven Development，TDD
验收测试驱动开发 Acceptance Test-Driven Development,ATDD
在对系统做任何变更时，都要先编写一个自动化测试用例，执行并确保测试失败，然后在编写代码，并且让测试通过

尽量将手动测试自动化

执行少量可靠的自动化测试，要远远优于大量的不可靠的自动化测试，所以，应该从少量可靠的自动化测试开始，并随着实践的推移不断增加；

在测试套件中集成性能测试

性能问题往往很难检测，所以，编写和执行自动化性能测试的目标时验证整个技术栈的性能，并把它作为部署流水线的一部分，这样才能尽早发现问题，并以最低的成本和最快的速度解决问题。

在测试套件中集成非功能性测试

除了测试代码并验证它符合预期且能在类生产负载下正常运行，还需要验证其他非功能属性，包括可用性、可扩展性、容量安全性等

在部署流水线失败时拉下安灯绳

一旦某个开发人员提交的代码变更导致构建或自动化测试失败，在这个问题被解决之前，不允许提交任何新的变更，来保证部署流水线始终保持绿色状态。
如果不拉安灯绳，也不立即解决问题，会导致应用和环境更难恢复到正常状态，这点很容易想明白，如果一次变更测试失败，而不去修复，其他人又在失败的基础上继续提交代码，自然无法通过自动化测试，使现有的测试都不能可靠的执行

应用和实践持续集成

我们都知道开发人员在自己分支上独自工作的时间越长，就越难将变更并入主干。集成问题会导致大量的返工包括不得不通过手动合并解决冲突，这样会导致恶性循环：既然合并代码那么痛苦，那么就减少合并次数，而这会使未来的合并工作更加令人痛苦。持续集成意在解决这个问题。

小批量开发与大批量发布

前几章说当部署流水线失败时，我们就会群策群力的解决问题，但当开发人员只偶尔将代码合并到主干，那么他们每一次合并都会引入大量变更，造成严重问题。
分支策略：

• 提高个人生产力：分支开发，独立工作，合并代码困难。
• 提高团队生产力：基于主干开发，提交代码过程简单，但任何一次提交都有可能破坏整个项目

应用基于主干的开发实践

解决大批合并的对策使用持续集成和基于主干的开发实践，每天至少提交主干一次，开发人员提交的越频繁，每次提交量就越小，离理想的单件流状态就越近
频繁的提交代码，意味着可以针对整个软件系统执行所有自动化测试，及时发现问题，及时解决。
可以采取门控提交，即部署流水线要确认所提交的变更能成功合并并构建，并且通过所有自动化测试，如果失败，则开发人员将收到通知，这样就可以在不影响价值流中其他人的情况下自己解决问题。

自动化和低风险发布

书中介绍了facebook的案例，实现代码的自动化，可重复，可预测部署，让代码部署变成所有人的日常工作
旨在通过减小生产环境部署的阻力，是运维团队或开发团队能频繁、轻松地进行部署。

自动化部署流程

想向facebook一样，就需要代码自动化部署机制，如果现有部署流程已经存在多年，则需要将流程中所有步骤记录下来，尽可能简化：

• 将代码打包成便于部署的格式

• 创建预配置的虚拟机镜像或容器

• 将中间件的部署和配置自动化

• 将安装包或者文件复制到生产服务器

• 重启服务器、应用或者服务

• 基于模板生成配置文件
  条件允许可以重新设计流程，还要求开发团队和运维团队紧密合作，、
  部署流水线需求：

• 用相同的方式处理所有环境的部署：因为已经经过多次演练，在生产环境中会出现更少的问题

• 对部署执行冒烟测试：应测试部署依赖的所有环境，只要有一处失败，就认为是失败的

• 维持环境的一致性

应用自动化的自助式部署

简单说就是一键式部署，开发人员和运维人员也能进行部署操作
流程步骤如下：

• 构建：部署流水线必须基于版本控制系统构建可部署到任何环境(包括生产环境)的软件包
• 测试：任何人都应该能够在他们的工作站上或测试系统中运行任何一个自动化测试套件
• 部署：任何人都应该能够将这些软件包部署到具有访问权限的任何环境，通过执行脚本来完成部署

在部署流水线中集成代码部署

自动化部署必须具备如下能力：

• 保证在持续集成阶段构建的软件包可以部署到生产环境
• 使生产环境的就绪情况一目了然
• 为能在生产环境中部署的任何代码，建立一键式和自助式的发布机制
• 自动记录审计和合规管理所需的相关内容，包括在哪台机器上运行了命令，运行了什么命令，是谁授权的，以及结果如何
• 通过冒烟测试验证系统正常工作，并且数据库连接字符串等配置正确
• 为开发人员快速提供反馈，使他们能够尽快了解部署结果。

将部署与发布解耦

部署：在特定的环境中安装指定的软件，部署可能与某个特性的发布有关，也可能无关
发布：把一个特性提供给所有客户或者一部分客户，代码和环境架构要能满足 特性发布不需要变更应用的代码
通常使用的发布模式：

• 基于环境的发布：在两个或更多环境中部署系统，通过负载均衡器切换流量，这种模式包括蓝绿发布，金丝雀发布和集群免疫系统
• 基于应用的发布：对应用进行更改，从而通过细微的配置变更，选择性的发布，比如开关

基于环境的发布模式

使用多套环境部署，但实际上只有一套环境处理客户流量，这种方式可以降低生产环境发布风险，缩短部署时间

1.蓝绿部署
一个蓝环境一个绿环境，发布新版本的服务时，先把他部署到非在线环境，以便在不影响客户体验情况下执行测试，一切正常，在切换环境。
2.处理数据库的变更
当应用两个版本用同一个数据库时，如果部署操作需要更改数据库模式，比如增加列，那么数据库将无法同时支持应用的两个版本，解决方法：

• 创建两个数据库：蓝绿数据库，应用的每个版本——蓝色（旧版本）和绿色（新版本）都有自己的数据库，在发布期间，将蓝数据库设置成只读模式，然后执行备份，再恢复到绿数据库，切换流量，这种方式问题是，如果要回滚到蓝数据库，需要将绿数据库的事务数据迁移回蓝数据库，否则会有丢失
• 将数据库变更与应用变更解耦：

3.金丝雀发布模式和集群免疫系统发布模式
金丝雀发布：小范围发布，比如先发布在仅向内部员工提供服务的生产环境服务器，先让小部分用户使用，一旦出现问题，就回滚
集群免疫系统发布扩展了金丝雀发布模式，将生产环境的监控系统和发布流程联系起来，并在面向用户的生产系统的性能超出预定范围时，自动回滚代码
优点：避免了通过自动化测试难以发现的缺陷，其次，减少了排查和解决变更造成的性能下降问题所需的时间

基于应用的发布模式更安全

之前介绍的基于环境发布模式，在多个环境之间切换流量，实现部署与发布的解耦。
1.实现特性开关
基于应用的发布模式主要是通过开关实现的。选择性的启用和禁用特性，可以将应用的特性向某些特定用户开放
通过配置文件或专门设计管理特性开关的web服务来实现。
优势：

• 轻松的回滚：回滚只用禁用某个开关
• 环节性能压力：当服务负载极高时，可以使用特性开关来缓解性能压力，比如减少使用某特性的客户数量，禁用推荐等CPU密集型特性。
• 采用面向服务架构提高恢复能力：某个特性依赖于没有上线的服务，可以禁用他，当依赖的服务中断时，也可以关闭该特性。

2.实现黑启动
黑启动：把所有特性都部署到生产环境中，然后对客户不可见的特性执行测试，对于大规模或高风险的变更来说，黑启动过程往往持续数周，从而保证在正式发布之前测试
此外在发布特性时，可以采用渐进的方式将其开放给一小部分客户，一旦出现问题就终止发布。

持续交付和持续部署实践的调查

持续交付：开发人员在主干上进行小批量工作，按需进行一键式发布，引入错误，就会快速得到反馈，立即加以解决，从而保持主干始终处于可部署状态。
持续部署，在持续交付基础上，定期向生产环境部署优质的构建版本，这意味着每天每人至少做一次上产环境部署，甚至开发人员提交代码变更时就出发自动化部署
在亚马逊和谷歌，大多数团队都采用持续交付实践，但也有一些团队选择持续部署

本章结论：将发布和部署融入日常工作，使组织能够快速地向客户交付价值，此外，开发人员和运维人员紧密合作，能够使运维工作变得人性化

降低发布风险的架构

”任何成功的产品或公司，其架构都必须在生命周期里不断演进“，在数十年前的架构设计往往是紧耦合的架构，当时图提交代码到主干，可能都会导致整个系统的崩溃，更使测试变得复杂，
本章主要介绍逆转上述问题的措施，同时回顾一些主要的架构原型，

能提高生产力、可测试性和安全性的架构

紧耦合架构不仅会降低生产力，还会影响变更的能力。接口定义清晰的松耦合架构优化了模块间的依赖关系，提高了生产力和安全性，
Google和Google Cloud Datastore是世界最大的NoSQL服务，但其支持团队只有8人，主要是因为它构建在一层层可靠的基础服务之上
这种面向服务的架构能让团队各自负责更小、更简单的开发任务，并且每个团队都能独立安全可靠快速的部署。

架构原型：单体架构与微服务

大多Devops组织都曾深深的被紧耦合的单体架构困扰，eBay在2001年的单体C++应用，亚马逊在2001年的单体Obidos应用、Twitter在2009年的Rails前端，每个公司都重构了自己的系统，茁壮成长
单体架构本质并不是不好，只是无法适应规模10倍或100倍扩大的场景。

架构	优点	缺点
单体架构(1.0所有功能都在一个应用里)	开始简单 进程间延迟低，一个代码库，一个部署对象，当规模小时，资源利用率高	协调成本随团队规模增加，模块划分得不清晰，不容易扩展，部署要么全部成功，要么彻底失败，构建时间长
单体架构2.0(一组单体层：“前端展示”“应用服务器“”数据库层“)	开始简单，容易做连接查询，一个数据库模式，一个部署对象，当规模小时，资源利用率高	耦合程度随时间提高，不容易扩展，冗余能力差(要么全做，要么没有，仅支持垂直方向扩展)，不容易调优，数据库模式管理要么全面，要么彻底么有
微服务	每个单元都是简单的，可扩展性和性能都是独立的，独立的测试和部署，能做性能的调优	交互式单元很多，需要很多小代码库，需要更复杂的工具和依赖项管理，网络延迟

安全地演进企业架构

Martin Fowler 创造了绞杀式应用，逐步演进，用API封装已有功能，按照新架构实现新功能，必要时调用旧系统。在这种模式下，所有服务都通过版本化API进行访问，也称为版本化服务。
通过不断地从已有的紧耦合系统中解耦功能，工作被逐渐转移到一个安全且充满活力地生态系统中，使开发人员地生产力大大提高，

总结：在很大程度上，服务赖以生存地架构决定了代码的测试和部署方式。因为我们通常受制于追求不同方向的组织目标和长期存在的传统架构，所以必须安全的进行架构演进。

流动的实践总结：这部分我们实现了使工作从开发到运维快速流动的架构和技术实践，从而快速、安全地向客户交付价值。下部分将创建从反馈从右到左快速流动地架构和机制，更快的发现和解决问题，辐射反馈信息，确保工作取得更好的成果，促进组织进一步提高适应能力

反馈的技术实践

描述如何实现第二部工作法的技术实践，创建从运维到开发的快速且持续的反馈

建立能发现并解决问题的遥测系统

《2015年DevOps现状报告》的调查结果显示：高绩效组织解决生产故障的速度是平均水平的168被，中等绩效平均修复时间以分钟为单位，而低绩效则以天为单位。在运维中能帮助缩短MTTR的亮相技术实践，是版本控制和在生产环境中部署更加主动的监控系统

建设集中式监控系统

多年来运维工程师已使用和定制监控框架来确保生产系统的正常运行，前端通常使用图形化用户界面，后端经常使用诸如Crystal Reports等工具，
对于几乎所有的编程语言，都有各种成熟的日志程序库
在《The Art of Monitoring》一书中，现代监测体系架构具有以下组成部分：

• 在业务逻辑、应用程序和环境层收集数据：在每一层中，建立以事件、日志、和指标为对象的监控。日志可以在所有服务器上使用特定文件(如/var/log/httpd-error.log)来存储，如linux的syslog、windows的事件日志等，在应用程序栈的所有层次都收集指标，能更好的了解系统的活动状态。
• 负责存储和转发事件和指标的事件路由器：此功能支持监控可视化、趋势分析、告警、异常检测等。通过采集、存储和聚合所有监控信息，能实现更深入的分析和健康检查。

建立生产环境的应用程序日志遥测

有了集中的遥测架构，我们必须确保对所有正在构建和运维的应用都建立充分的遥测。开发和运维工程师必须把建设生产遥测作为日常工作的一部分，
价值流中的每个成员都应该以各种方式使用遥测，开发人员可以诊断问题，运维工程师可以使用遥测来诊断生产问题，信息安全和审计师可以确认系统所需控制的有效性，产品经理可以用它们来跟踪业务成果、功能利用和转化率
日志的级别：
调试级别debug
信息级别info
警告级别warnning
错误级别error
致命级别
选择合适的日志级别很重要

使用遥测指导问题的解决

遥测技术赋予了我们一种科学的方法，让我们能够对具体问题的原因和解决方案作出假设，在解决问题的过程中，我们可以回答以下问题

• 监控系统中有什么证据表明了问题实际上正在发生
• 在应用程序和环境中，导致问题的可能的相关事件和变更是什么
• 可以做出什么假设，来证实提出的原因和结果之间的联系
• 如何验证那些假设是正确的，能成功地解决问题。

将建立生产遥测融入日常工作

建立必要的基础设施和库，让任何开发和运维人员都可以很容易地针对任何功能创建遥测。可以用一行代码实现创建一个新的指标，通过仪表板展示出来。
StatsD 可以用一行代码(Ruby、perl、python、Java)产生计时器和计数器经常结合Graphite或Grafana将度量数据呈现在仪表板上
还有其它工具 JMX 和codahale metrics

建立自助访问地遥测和信息辐射器

信息辐射器(information radiator) 指团队放置在一个非常显眼位置上地手写、绘制、印刷或电子信息展示，让所有团队成员以及路过地人都能快速浏览最新信息
就是保持生产监控信息指标具有高度的可见性。
通过将信息发射器放置在非常显眼的地方，我们在团队成员中传播着责任感，同时也积极地展示一下价值观：

• 团队对观察者毫无掩藏
• 团队对自己无所隐藏，他们承认并直面问题。

发现和填补遥测的盲区

我们需要在所有环境中，在应用程序栈的每个层级中，以及支持他们的部署流水线中，建立充分而完整的遥测。需要以下层级的度量指标

• 业务级别：示例包括交易订单的数量、产生的营业额、用户注册数、流失a率、A\B测试的结果等
• 应用程序级别：示例包括事务处理时间、用户响应时间、应用程序故障等。
• 基础架构级别（如数据库、操作系统、网络、存储）：示例包括Web服务器吞吐量、CPU负载、磁盘使用率等
• 客户软件级别(如客户端浏览器上的JavaScript、移动应用程序）：示例包括应用程序的出错和崩溃、用户端的事务处理时间等。
• 部署流水线级别：示例包括构建流水线状态(例如：各种自动化测试套件)
  通过利用遥测完整的覆盖以上领域，用事实说明问题，而不是听信传言，指指点点，互相责备

应用程序和业务度量指标

在应用程序层面，我们不仅要确保产生的遥测能够反映应用程序的健康状况，还要度量目前组织的业务目标实现情况，比如用户增长数，在线人数，等，这样做有利于我们更好的理解我们的工作对业务目标的影响情况。

基础架构度量指标

与应用程序度量指标所做类似，对于生产环境和非生产环境的基础架构，也要建立全面的遥测系统以便在出现问题时可以快速定位问题

显示叠加的指标组合

为了提高变更的可视化程度，可以在监控图形上叠加显示所有生产环境的部署活动。

分析遥测数据以更好地预测故障和实现目标

用均值和标准差识别潜在问题

分析生产环境度量指标最简单的一种统计技术是计算均值和标准差，我们可以创建一个过滤器，用来检测度量指标与正常值显著不同的情况，例如数据库查询速度明显低于平均值时 ，报警
可以通过提高信噪比、关注差异值或异常值，建立更好的告警。把收集到的数据呈正态分布，标准差的常见用途是定期检查数据集的某个度量，如果与均值有显著差异就报警例如，比平均值大三个标准差就告警，只要这个数据呈正态分布，我们预计只有0.3%的数据点会触发告警(因为第一二三标准差分别包含68%、%95、%99.7的数据)

异常状态的处理和告警

策略：分析近期遇到的最严重的事故，并建立一个遥测列表，用来更早、更快地检测和诊断问题，以及更方便、更快捷地确认已经实施了有效的修复措施。
例如，如果NGINX Web服务器停止对请求做出相应，我们会查看主要指标，他们可能已提前警告我们，我们已经开始偏离标准操作，例如：

• 应用级别——网页加载时间正在增加
• 操作系统级别——服务器闲置内存不足、磁盘空间不足等；
• 数据库级别——数据库事务处理时间超出正常值等；
• 网络级别——负载均衡器背后运行地服务器数量

非高斯分布(正态分布)遥测数据的问题

如果数据不呈高斯分布，比如下载量，下图显示了每分钟并发下载量，有一个条形栏覆盖在图形的顶部，黑色表示下载量与均值至少差三个标准差，否则他就是灰色的。

可以看出几乎所有的时间都发生了告警。绘制每分钟下载频率地直方图，

可以看出大多数时间每分钟下载量都很低，但经常飙升，其实大多数生产数据集都不是高斯分布(正态分布)的，运维中很多数据集呈我们所谓的‘卡方’分布。上述问题可采用其他异常检测技术，如Scryer工具

应用异常检测技术

不呈高斯分布时地检测技术统称为异常检测。
书中列举了几种统计技术，需要专业地数据分析知识和技能地人员一起识别共性的问题，并用异常检测和事故预测方法改进他们。

应用反馈实现安全部署

在工程师部署代码的时候，开发人员和运维人员都有代码部署恐惧，但通过提供更快更频繁地反馈，以及减少部署工作的批量大小，可以让工程师获得安全感。
书中列举Right Media公司副总裁Galbreath的例子，论证了实现工作稳定和持续流动的诀窍1.建立更多的生产遥测机制，2.频繁进行小规模的变更

通过遥测使部署更安全

在生产部署过程中积极的监控软件功能的相关度量指标，如果真的破坏或影响了其他功能，可以迅速知道，解决问题。
即使这样，依旧存在检测不到的错误，这就要依靠生产环境的遥测来快速恢复服务了，我们可以使用特性开关关闭出错的功能，可以前向修复，即修改代码然后通过部署流水线部署，或者回滚。

开发和运维共同承担值班工作

让开发人员、开发经理、和架构师轮流和运维团队值班，这确保了价值流中的所有人能够就他们所做的上游架构和编码决策得到直接的反馈。
这种实践让开发人员意识到，每一项产品功能都标记为完成，并不是真正的完成，只有当所有功能都在生产环境中按照设计正常地运行，没有引起重大故障，也没有引发计划外的开发或运维工作，才叫真正的完成。

让开发人员跟踪工作对下游地影响

交互和用户体验设计中最强大的技术之一是情景访谈，用户和开发人员面对面使用app，这就是开发人员跟踪他们的工作对下游地影响，通过用户体验观察，能够在源头保证质量，并对价值流中的其他团队成员产生同理心。

让开发人员自行管理生产服务

总结：本章讨论了反馈机制，它使得我们可以在日常工作中地每个阶段改进服务，不管是将变更部署到生产环境，再出现问题时请求工程师修复代码，让开发人员跟踪下游工作，建立非功能性需求来帮助开发团队编写更优地生产就绪代码，还是将有问题地服务交回给开发团队自己管理
通过创建这些反馈回路，可以使生成环境地部署更安全，提高所开发代码地生产就绪程度，并且通过强化共同的目标、责任和同理心，在开发和运维之间建立更好的工作关系。

将假设驱动的开发和A/B测试融入日常工作

在功能测试中集成A/B

常用A/B测试是，在一个网站上，给访问者随机展示一个页面的两个版本之一，即控制组A和实验组B。基于对这两组用户后续行为的统计分析，可以判断这两者的结果是否存在显著差异，从而找出实验组(例如，功能的变化、设计元素、背景颜色)和结果(例如，转化率、平均订单大小)之间的因果联系。
我们可以通过一组实验，看看改变购买按钮上的文字颜色是否会增加收入，减慢网站的响应速度是否会造成收入降低。这种类型的A/B测试让我们在性能优化方面建立了金钱价值观。

在发布中集成A/B测试

通过在生产环境中快速轻松的按需部署，利用特性开关将软件的多个版本同时交付给多个用户群，可以进行快速、迭代的A/B测试。要实现这一点，需要在应用程序栈的各个层次上进行全面的生产环境遥测。
通过生产环境的A/B测试，可以做出明智的决策，确保向用户推出可用的功能，如果我们经常在一些功能上投入了大量的时间，而且不得不维护，但没有证据表明他们是成功的或者受到客户的欢迎。A/B测试让我们可以在开发过程中就判断一项功能是否值得继续投入

在功能规划中集成A/B测试

一旦拥有了支持A/B功能发布和测试的基础设施，我们还必须确保产品经理将每个功能都视为一个假设，并基于在生产环境中实际的用户实验结果来验证或者反驳假设，比如：
我们相信，增大预定页面上酒店图片的大小
将会提升客户的参与度和转化率
如果在48小时内查看酒店图片并预定房间的客户增加了5%，那么我们将有信心进行这个改变
用实验来进行产品开发。

总结：成功不但需要快速地部署和发布软件，还要在实验方面超越竞争对手。采用假设驱动的开发、定义和度量客户获取渠道，以及A/B测试等技术，能够安全、轻松地进行用户实验，从而让员工发挥出创造力和创新能力，并进行组织性学习。

创建评审和写作流程以提升当前工作的质量

一个典型的例子是 GitHub的Pull Request

• 工程师为了实现一项新功能需求，要基于主干建立一个命名清晰的分支
• 工程师提交代码到本地分支，并定期将工作push到远端服务器的同名分支上
• 当他们需要反馈或帮助时，或者准备合并到主干时，会提交一个新的pull request
• 在他们获得期望的评审并通过审核，就可以将代码合并到主干
• 一旦将代码合并到主干，工程师就可以将其部署到生产环境了。

变更审批流程的危险

书中列举了Knight Capital宕机15分钟损失44亿美金的例子，对于事故发生原因有两种反事实的叙述，一种说由于变更控制失败导致的，一种说由于测试失败导致的。
但现实是在低信任度的指挥与控制型文化环境中，这些变更控制和测试实践反而会增加问题复发的几率

“过度控制变更”的潜在危险

传统的变更控制可能导致意想不到的后果，例如延长交付时间，降低部署过程中反馈的强度和即时性。

• 再变更请求表单中添加更多需要回答的问题
• 经过更多重授权，例如上上级管理层
• 变更审批需要更长的前置实践。
  这些控制带来了大量额外的步骤和审批，增加了部署过程的阻力，同时增加了批量尺寸和部署的前置时间。

变更的协调和排程

每当多个团队在共享依赖关系的系统上工作时，就可能需要协调变更，以确保他们不会相互干扰。一般架构越是松耦合，组建团队之间沟通协调就越少，但是即使是在松耦合的架构里，当多个团队每天进行多次部署时也会出现彼此干扰的风险，这就需要譬如聊天室的方式，发布变更通告，
对于负责组织需要更加小心的来安排变更，各个团队变更代表要聚在一起，做变更的排程和协调

变更的同行审批

对应用程序或环境的变更可以通过工程师同事的仔细核查来减少风险，这种形式的评审不仅提高了变更的质量，还相当于进行了交叉培训，对互相学习和技能提升非常有好处。
对于一些风险更高的变更，比如数据库变更，就需要领域专家做进一步的审查
保持小批量的原则也适用于代码评审。变更批量越大，评审工程师理解这些花费的时间就越长，而且呈非线性增长，所以要求开发人员要以小的，渐进式的步骤工作而不应该在功能分支里长时间工作，
而且随着尺寸的增加，我们对代码变更进行的有意义的评判能力也会下降，请程序员评审10行代码，他会找出10个问题，请他审查500行代码，他会说看起来都不错。
代码评审的指导原则：

• 每个人再将代码提交到主干之前，必须要有同行来评审变更，
• 每个人都应持续关注其他成员的提交活动，以便识别和审查潜在冲突
• 定义那些变更属于高风险变更，决定是否要请专家
• 小尺寸提交
  代码评审形式：
• 结对编程：程序员结对的在一起工作
• 肩并肩：
• 电子邮件送审
• 工具辅助评审：如GitHub的pull request

人工测试和变更冻结的危害

人工测试本来就比自动化测试更慢，这就意味着部署频率更低，进而部署尺寸就会变大，尺寸越大，失败率越高，平均故障修复时间MTTR也都随之上升

利用结对编程改进代码变更

结对编程就是两名开发人员在同一所工作站上编程的方法，他不止是用于开发人员。常见的结对编程一名工程师扮演 驾驶者，一名时导航员 ，两人取长补短，另一种时测试驱动开发模式，一名编写自动化测试，另外一个编写代码，这种具有即时性，评审者就在你的旁边，你不可能忽视它

评估pull request的有效性

消除官僚流程

字面意思很明了，消除一些不必要的流程和琐事。

总结

本章讨论了一些要整合到日常工作中的技术实践，他们能够提高变更的质量，降低部署出错风险，减少对审批流程的依赖。

第四部分总结

第四部分向我们展示了，通过实时反馈回路，可以让每个人都为实现共同布标而协作，当发生问题时及时发现问题，并通过快速检测和恢复机制，保障所有功能不仅能按照设计在生产环境中运行，而且还实现了组织目标和组织学习。我们还研究了如何让开发和运维共享目标，从而提高整个价值流的健康程度。

第三步：持续学习和实验的技术实践

将学习融入日常工作

2011年4月21日，当亚马逊AWS整个美国东部可用性区域宕机时，几乎所有依赖AWS的用户都受到了影响，然而，Netflix却是一个惊人的例外，似乎没有受到影响，解释说，正是他们在2009年的架构设计决策，为这种恢复能力奠定了基础
1.他么的系统架构是松耦合的，每个组件都有特别敏感的超时设计，从而保证出现故障的组件不会拖垮系统，而且他们的每个组件都有服务降级的功能，当流量剧增时，就不显示个性化列表，只显示静态缓存内容。
2他们构建了一种 称为 (chaos Monkey)的服务，他会不断地随即删除服务器，来模拟AWS环境故障。这样一来，使他们积累了大量的故障处理经验。
Chaos Monkey 只是将学习融入日常工作的一个例子。本章将探讨如何建立学习系统

建立公正和学习的文化

学习型文化的先决条件之一是，对待故障或事故的反应 要"公正"，否则就会诱发职业性保密、逃避和自我保护。
公正的学习文化：

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

举行不指责的事后分析会议

当重大事故发生时，应该在解决问题之后进行不指责的事后分析，在记忆消退、因果关系变模糊之前尽快安排会议。做如下事情：

• 构建时间表，从多个角度收集关于故障的所有细节，保证不会惩罚错误的人
• 通过让所有工程师详细说明自己如果导致了故障，使他们提高安全性
• 允许并鼓励那些犯错误的人成为教育他人不犯同样错误的专家
• 营造一个自由决策的空间，让人们决定是否采取行动，并且把对所做决定的评判放在事后
• 指定预防对策并记录，以便进行追踪
  需要参与问题决策的人，识别问题的人，响应问题的人，诊断出问题的人，受问题影响的人，任何有兴趣参加会议的人
  强化建立这样一种文化：信息是共享的，不必害怕因此受到惩罚或报复，需要找一个受过训练的、和事故无关的人来组织并引导会议。
  会议中不要使用反事实陈述，例如“我原本可以。。。如果我知道了这一点，就应该。。。”的想象的方式定义问题，而不是以事实为依据，应该有一个更好的问题：“在进行那个操作的时候，我为什么觉得可行？”

尽可能广泛地公开事后分析会议结果

降低事故容忍度，寻找更弱的事故信号

降低判断故障的阈值，我们需要放大那些微弱的故障信号，持续不断的寻找，进而更好的理解和管理运维中的系统

重新定义失败，鼓励评估风险

高效能的DevOps组织会更频繁地失败和犯错误，这不但是可以接受的，而且是组织所需要的，DevOps必须允许这种创新，并接受因此带来地风险，在生产环境中遇到更多的失败，是一件好事，不该受到惩罚。

在生产环境注入故障来恢复和学习

创建故障演练日

通过向关键系统中诸如大规模故障来提高可恢复性的练习。目的是帮助团队模拟和演练事故，使其具备实战能力。例如，模拟整个数据中心在未来的某个时间点遭到破坏，然后，给团队准备的时间来消除所有地单点故障，并创建必要的监控程序和故障切换程序。

总结：为了创造实现组织学习地公正文化，我们必须重新描述所谓的失败。每个人都应该坦然面对失败，承担责任，并从失败中学习。

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

在整个组织里地全局范围里共享和应用局部获得地新经验和优化方法，从而大大提高组织的全局知识和改进效果，这将提升整个组织地实践状态，使每个人都在工作中从组织积累地经验里收益

使用聊天室和聊天机器人自动积累组织知识

将自动化运维和聊天室集成在一起有助于记录和分享我们的观察和问题解决过程，使其成为日常工作中不可分割地一部分。还加强了透明、协作地文化，有益于我们所有的工作。

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

把手动操作的流程转化为可自动执行地代码，放到代码库中，这为所有的使用者提供了价值。

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

在全企业范围内建立共享的源代码库，保存的不止源代码，还包括：

• 程序库、基础设施和环境
• 部署工具
• 测试标准和工具，包括安全方面
• 部署流水线工具
• 检测和分析工具
• 教程和标准
  使用单一代码库，只要提交更新时，就会触发新的构建，用户也可以方便的访问到最新的代码。

运用自动化测试记录和交流实践来传播知识

当整个组织都使用了共享程序库时，我们应该能够快速传播专业知识和改进方法。确保这些程序库里有大量的自动化测试，意味着这些库能够自动记录并显示其他工程师是如何使用他们的

通过确定非功能性需求来设计运维

当我们为了适应快速地流动和可部署性，应该确定一套非功能性需求，并将其集成到所有的生产服务中。
应该具备的非功能性需求示例：

• 对各种应用和环境进行充分地遥测
• 准确跟踪依赖关系地能力
• 具有弹性并能正常降级地服务
• 各版本之间具有向前和向后地兼容性
• 归档数据来管理生产数据集地能力
• 轻松搜索和理解各种服务日志信息地能力
• 通过多个服务跟踪用户请求的能力
• 使用功能开关或其他方法实现简便、集中式地运行时配置

把可重用地运维用户故事纳入开发

如果某些运维工作无法完全自动化或自助化，我们的目标是尽量将这种反复发生的工作变得能够重复、确定的执行。就像开发阶段创建用户故事，将其放入待办事项然后编码实现一样，我们也可以创建定义明确地“运维用户故事”，说明那些在所有项目中可以重用地工作活动。这样可以创造更好的工作计划和更多的可重复性成果

确保技术选型有助于实现组织目标

在选择技术时地一种哲学决策——可以实现开发和运维都能够理解整个技术栈，让所有人都可以为这个单一平台做贡献，并且让每个人都能够阅读，重构或者修复他人的代码

小结

本章介绍的技术能将一点一滴新的学习纳入组织地集体知识，并成倍地发挥效果。

预留组织学习和改进的时间

有一种称作改善闪电战（improvement blitz 或 kaizen blitz）的实践，是丰田生产系统的重要组成部分，指的是在一个专门集中的时间段里解决特定问题，通常长达几天。

偿还技术债务地制度化惯例

加强为改进工作预留开发和运维时间的实践，可以安排和进行为其几天和几周的改善闪电战，不进行功能性工作，一般由开发，运维，安全团队组成，横跨整个价值流。

让所有人教学相长

不论是通过传统的说教方式，还是通过实验或开放式方法，动态的学习文化不仅能为每个人创造学习条件，还能创造教学的机会。
所有的工程师都越来越需要某些技能，而不只是开发人员如此，例如，对于所有运维和测试工程师来说，熟悉开发技术、惯例和技能越来越重要，熟悉开发技术很重要，熟悉开发技术很重要

在DevOps会议中分享经验

传播实践的内部顾问和教练

小结

本章描述了如何建立一系列惯例，来帮助强化终身学习以及重视在日常生活中改进日常工作的文化，具体实现方法是：预留偿还技术债务的时间；创建论坛，是大家能够在组织内部和外部互相学习和指导；通过辅导、咨询，或者仅仅设置一段面谈时间，让专家能够为内部团队提供帮助。

第五部分总结

我们这部分探讨了在组织中创造学习和实验文化的实践。当我们在复杂系统中工作时，从事故中学习，创建共享代码库和共享知识是必不可少的，这有助于工作文化更公正，系统更安全、更具弹性。

集成信息安全、变更管理和合规性的技术实践

要将信息安全更好的集成到每个人的日常工作中，Devops可能是最佳的一种方式

将信息安全融入每个人的日常工作

要将信息安全团队尽早地与特性团队协作，而不是等项目结束阶段才开始相关工作

将安全集成到开发迭代的演示中

将安全集成到缺陷跟踪和事后分析会议中

将所有的安全漏洞工作都放在开发和运维使用的系统中。在出现安全问题的时候，召开事后分析会议，因为它可以更好地教育工程师如何防止问题复发，也是将安全知识传递给工程团队的绝佳时机

将预防性安全控制集成到共享源代码库及共享服务中

把任何有助于确保应用程序和环境安全性的机制和工具都添加到共享源代码库中，任何工程师都能够在应用程序和环境中轻松、正确地使用日志记录和加密标准，而无需额外的工作

将安全集成到部署流水线中

尽可能地自动化信息安全测试，这样，在每个开发或运维人员代码提交时，甚至在软件项目地最早期阶段，就可以在部署流水线中与其他所有测试一起进行安全测试

保证应用程序的安全性

我们将以下内容作为测试的一部分：

• 静态分析：这是我们在非运行时环境中执行的测试，期望在部署流水线中进行。
• 动态分析：与静态分析相反，动态分析由一系列在程序运行时执行地测试组成。动态测试监视诸如系统内存、功能行为、响应时间和系统整体性能等项目。
• 依赖组件扫描：一种静态测试，通常于构建时在部署流水线里执行。会清点二进制文件和可执行文件依赖的包和库，并确保这些依赖组件没有漏洞或恶意二进制文件。
• 源代码完整性和代码签名：

确保软件供应链地安全

我们在生产中很少编写自定义软件，而是组装所需要的开源组件，在使用各种组件或库时，不仅继承了他们地功能，也包括安全漏洞，在选择软件时，要检测软件项目是否依赖有已知漏洞的组件或库，帮助开发人员慎重的选择要使用的组件

确保环境安全

在这个步骤中，任何有助于加固环境、降低风险地工作都应该做。

将信息安全集成到生产环境遥测中

将安全遥测集成到开发、QA以及运维使用的工具中，价值流中地每个人都可以看到应用程序和环境在恶意威胁入侵中的表现，包括：攻击者不断地尝试利用漏洞，获得未经授权的访问，植入后门，执行欺诈，拒绝服务等破坏活动。
公开的将服务在生产环境中遭遇攻击的过程展现给所有人，能迫使每个人考虑安全风险，并且在日常工作中设计对策

在应用程序中建立安全遥测系统

有问题的用户行为可以揭示或引发欺诈和未授权的访问，为了进行检测，必须在应用程序中创建相关的遥测系统

• 成功和不成功的用户登录
• 用户密码重置
• 用户电子邮件地址重置
• 用户信用卡更改
  例如，暴力登录是企图获取非法访问权限的早期迹象，因此可以显示失败和成功登录次数的比率，当然，我么应该对这些重要事件建立告警策略，以确保能够快速检测和纠正问题。

在环境中建立安全遥测系统

我们需要对某些事件做监控和告警，包括：

• 操作系统的变更（例如生产环境中、构建基础设施中）
• 安全组的变更
• 配置的变更（例如，OSSEC、Puppet、Chef、Tripwire）
• 云基础设施变更（例如，VPC,安全组、用户和权限）
• XSS尝试(即"跨站点脚本攻击“）
• SQLi尝试（即SQL注入攻击）
• web服务器错误 4xx，5xx

保护部署流水线

负责CI /CD的基础设施也容易受到攻击，例如，有人攻陷了运行部署流水线的服务器，而该部署流水线有git的登录信息，那么他们就能窃取程序的源代码，为了保护CICD或部署流水线，环节风险的措施包括：

• 加固持续集成和集成服务器，并确保可以用自动化的方式重建他们，就像构建面向客户的生产服务器基础架构一样，防止持续构建和集成服务器受到破坏
• 审查任何提交到版本控制系统的变更——可以再提交时进行结对编程，也可以再提交和主干合并之间设置代码评审
• 检测包含可疑API调用的测试代码
• 确保每个CI流程都运行在自己的隔离容器或者虚拟机里
• 确保CI系统使用的版本控制凭据是只读的
  小结
  本章介绍了将信息安全融入日常工作中所有阶段的方法。那就是通过将安全控制集成到已经创建的机制中，确保所有按需环境都处于加固的低风险状态，以及通过将安全测试集成到部署流水线中，确保在预生产和生产环境中创建安全遥测系统。这样，我们可以再提高开发和运维效率的同时，提高整体安全性。

保护部署流水线

将安全和合规性集成到变更批准流程中

• 标准变更：遵循既定批准流程的低风险变更，但也可以是预批准的。这种类型的变更包括应用程序税表或国家地区代码的每月更新，变更申请人在部署变更之前是不需要审批的，变更的部署可以完全自动化，而且应该留下用于追溯的日志
• 常规变更：风险更高、需要权威机构评审或批准的变更
• 紧急变更：在紧急情况下必须立即投入生产环境中的变更，例如，紧急安全补丁、恢复服务，属于潜在的高风险变更，需要得到高级管理层批准，但也允许先执行变更操作，之后补上文档。DevOps实践的一个关键目标是简化常规变更流程，使其同样适用于紧急变更

将大量低风险变更重新归类为标准变更

如何处理常规变更

不能归类为标准变更的变更属于常规变更，在部署之前至少需要得到变更顾问委员会部分成员的批准，

减少对指责分离的依赖

一般做法是：要求将开发人员变更提交给代码库管理员接受审查和批准变更，然后由IT运维将变更部署到生产环境
这样职责分离会减慢和减少工程师在工作中获得反馈，这阻碍了工程师对工作质量承担全部责任，降低了企业创建组织学习的能力
因此在可能的情况下，应避免使用职责分离作为控制手段。我们应该结对编程、持续检查代码迁入和代码审查等
小结
本章讨论了让每个人都承担信息安全责任的实践，将所有信息安全目标都纳入价值流中每个人的日常工作。

第六部分总结

第六部分探讨了如何将DevOps原则应用于信息安全，帮助我们实现目标，并确保安全是所有人日常工作的一部分。更好的安全性确保了我么能防护数据、理智的对待数据，能在安全问题酿成灾难以前恢复。

行动起来——本书总结

我们已经对DevOps的原理和技术实践进行了详细的探讨。DevOps的原则和模式能化解开发人员和运维人员之间的核心冲突。
DevOps的践行需要新的企业文化和管理规范，同时会变革技术实践和架构。跨部门协作至关重要，包括管理层、产品管理部门、开发团队、质量保证团队、IT运维、信息安全甚至市场销售人员在内，所有部门通力协作，才能有效构建出一个安全的工作系统，从而帮助小团队快速、自主的开发和验证。这种方式可以最大程度地提高开发人员的生产力、学习积极性、满意度以及提高组织赢得市场的能力
我们呼吁大家行动起来，DevOps不仅仅是技术层面的当务之急，也是组织层面的迫切要务。最关键的一点，DevOps普世，尤其适用于：必须通过技术手段改进工作流程，同时保证产品质量、可靠性和安全性
在许多案例中那个，在取得突破性成功的同时，大部分变革者都得到了晋升，不过也有领导层随后发生变化，变革者离开，他们所创造的变化也会被组织回滚。
不要为此愤世嫉俗。参与变革的人都明白，他们做的事情当然可能会失败，但无论成败如何，他们总要尝试，尝试的最大意义在于，通过实践鼓舞他人。不承担风险，变革是不可能成功的。如果你没有让某些管理层不安，那证明你可能还不够努力。正如亚马逊前 ”灾难大师” 所说：做正确的事情，等着被开除
DevOps会使价值流中的所有参与者都受益匪浅，它能够带给我们那种开发伟大产品而产生的快感。
我们真诚希望本书可以帮助你实现这些目标。