DevOps是研发领域最近几年最热的一个概念。参加过一些讲座，也看过不少的书籍，经常听到以下说法：
- DevOps是没有明确定义的，一千个研发心中就有一千个Devops；
- DevOps是一种文化，每个团队的DevOps实践都不一样；
- DevOps就是消除Dev与Ops之间的壁垒，让两者通力合作；
- DevOps就是业内敏捷、精益等各种优秀实践的混合体；
- DevOps就是工具和自动化
相信很多人听完和我感觉一样，感觉自己就像是盲人摸象，管中窥豹，在似懂非懂的边缘徘徊，无法系统地了解到DevOps的全貌，对DevOps的理念和实践清晰了很多。
1. DevOps是什么？
我个人给梳理和总结出DevOps定义:
DevOps是对敏捷软件开发和精益生产思想的一种演进，应用于IT端到端的价值流中，使得业务基于现代信息技术，并通过文化、组织和技术变革来获得更大成功。
- DevOps不是一个完全新的概念。它是由于敏捷软件开发方法的演进，加上以代码形式管理基础设施成为可能，逐渐产生出IT管理的新方法，最后激发出现了DevOps。它的理论基础是敏捷软件开发+丰田精益生产。
- DevOps的本质在于基于这样一个事实，即IT部门与业务部门所考虑的不仅是软件开发，而是整个价值链。价值链始于产品同学产生的新想法，经过开发、测试和部署，最后到运维。
- 一般来说，信息技术能为组织带来更多收益（通过创造新机会或者消除现有约束）、降低风险并优化资源。
- DevOps并不是简单的流程自动化。DevOps领先者的经验表明，文化（人）、组织（流程）、技术（自动化）这几个因素都至关重要。
2. 为什么要实施DevOps？
DevOps不是某个作者或大师想象出来的管理框架或产品，而是诞生于对实际问题的解决。目前不同组织应用DevOps所试图解决的问题，主要有3类。
2.1. 缩短市场响应时间
传统IT部门遵循"为成本而优化（optimize for cost）"的模式，而DevOps组织遵循"为速度而优化（optimize for speed）"的模式（这句话说到互联网人的心坎里了）。具体包括：
- 减少批量大小
- 减少交接次数
- 持续识别和消除损失
- 自动化所有例行的运维工作
- 团队内部专业人员可替换
- 自给自足的团队（包含了产品、开发、测试、运维、安全人员等，上线产品不需要依赖外部团队）
2.2. 减少技术债务
技术债务在团队成员选择一个非最优的方式解决问题以缩短开发时间时产生。这是一个自然的过程，问题是累计的非最优方案导致了IT产出的逐步退化，并且因此降低了产品质量。DevOps讲求持续重构程序代码，重视在操作中取得经验，以及与构造新功能同等重要的、计划一些用来消除之前所造成的瓶颈的工作；DevOps强烈推荐 "应用尽可能频繁地直面问题" 的实践，以防出现这样一种情况：每个人都知道问题就在那儿，却没有人着手去处理。
2.3. 消除系统脆弱性
在组织中最重要的和业务收益相关的系统往往是最脆弱的。由于业务中断的高风险，对停机的零容忍，以及持续发生的变更和改进与这些系统关联紧密，所以降低这些系统的脆弱性非常困难。
DevOps以最激进的方式反对脆弱性：完全排除。
- 在DevOps中，代码和系统作为一个整体，在某个时刻是全功能的， 如果接下来的变更破坏了性能，就要马上回滚并且让系统持续正确地工作
- DevOps的实践，有意引入混乱和不稳定性到生产环境，目标IT系统必须以独立和快速的方式做出反应，探测到故障并恢复它们的正常运作，理想情况下最终用户是无感知的，当然数据也不会丢失。
3. DevOps的理论基础
DevOps不是凭空产生的，而是有其坚实的理论基础。主要包括， 精益和敏捷 两大部分。
3.1. 精益生产
丰田式生产管理(Toyota Management)，或称丰田生产体系（Toyota Production System，TPS）由日本丰田汽车公司的副社长大野耐一创建，是丰田公司的一种独具特色的现代化生产方式。精益生产( Lean Production)管理是美国麻省理工学院给丰田式生产管理的名称。
精益生产的理论框架包含 一个目标 、 两大支柱 和 一大基础 。
3.1.1. 一个目标
"一个目标"是低成本、高效率、高质量地进行生产，最大限度地使顾客满意。
3.1.2. 两大支柱
"两大支柱"是准时化与人员自主化。
准时化(JIT-Just in time)生产。即以市场为龙头在合适的时间、生产合适的数量和高质量的产品，JIT需要以拉动生产为基础，以平准化(Leveling System)为条件。所谓拉动生产是以看板管理为手段，采用"取料制"即后道工序根据"市场"需要进行生产，对本工序在制品短缺的量从前道工序取相同的在制品量，从而形成全过程的拉动控制系统，绝不多生产一件产品。平准化是指工件的被拉动到生产系统之前要进行人为的按照加工时间、数量、品种进行合理的搭配和排序，使拉动到生产系统中的工件流具有加工工时上的平稳性，保证均衡生产，同时在品种和数量上实现混流加式运动，起到对市场多品种、小批量需要的快速反应和满足功能。
人员自主化是人员与机械设备的有机配合行为。生产线上产生质量、数量、品种上的问题机械设备自动停机，并有指示显示，而任何人发现故障问题都有权立即停止生产线，主动排除故障，解决问题。该系统在丰田被称为安灯系统，也是蓝盾质量红线服务的设计思想来源，具体可见《质量红线，研发流程中的安灯系统！》
3.1.3. 一大基础
"一大基础"是指改善(Improvement)。改善是丰田式生产管理的基础。据说丰田的主管如果两周之内团队没有任何改善将会直接被辞退。 这里的改善是指这样的含义：
- 从局部到整体永远存在着改进与提高的余地。在工作、操作方法、质量、生产结构和管理方式上要不断地改进与提高。
- 消除一切浪费。丰田式生产管理哲理认为不能提高附加价值的一切工作(包括生产过剩、库存、等待、搬运、加工中的某些活动，多余的动作，不良品的返工等)都是浪费。这些浪费必须经过全员努力不断消除。每一种浪费对应到IT领域都是可以找到对应关系的，例如库存，可以对应我们平时部分未完成的工作，这些工作不能给最终客户带来价值，但是资源已经被消耗了。具体如下图所示。
- 连续改善 (Continuous Improvement)是当今国际上流行的管理思想。它是指以消除浪费和改进提高的思想为依托，对生产与管理中的问题，采用由易到难的原则，不断地改善、巩固，改善、提高的方法，经过不懈的努力，以求长期的积累，获得显著效果。
3.2. 敏捷
敏捷是大家比较熟悉的，它的很多核心思想和实践已经融入到了我们日常的工作中。不过敏捷并不是用户故事卡片、站立会议或开发软件的方法，而是一套价值观和原则。
我们不妨一起来回顾一下敏捷宣言：
- 个体和交互 优先于 流程和工具
- 可工作的软件 优先于 面面俱到的文档
- 客户协作 优先于 合同谈判
- 响应变化 优先于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
DevOps很大程度上基于敏捷，并把"敏捷开发"的想法延展到了整体的敏捷IT交付、整个组织、整个流程以及整个价值链。
4. 核心原则是价值流
价值流源自精益，这个概念本身已经使用了很多年。 我们从创造价值以相应客户请求的角度来考虑组织中的工作，将完成客户请求所需要实施的相关行动，按照顺序排列起来，这就是价值流。 而致力于可视化价值流的工作被称为"价值流映射"。
如上图所示，就是一个软件开发过程的价值流图样例。 其中有几个关键指标：
- 前置时间 Lead Time (LT)。即每个环节从开始到交付所花费的时间。
- 处理时间 Process Time (PT)。即每个环节真正处理事情的时间。LT-PT就是等待时间，应该越短越好。PT/LT也是一个实际操作中经常用到的值，用于衡量队列和等待损耗时间的情况。
- 完整性与准确性占比 Percent Complete and Accurate (%C/A )。可以理解为返工情况，约接近于100%说明返工越少。
在进行价值流映射之后，我们可以很好识别出浪费，以便于进行下一步的改进，无论是工具还是文化上的。在改进之后，也可以通过前后价值流的对比，来评估出改进的收益。可以看到价值流图就像是施工图，也像是指南针，这也是DevOps咨询师进入一个团队后首先做价值流分析的原因。
5. 关键实践
日常标准化实践。
- 发布是日常活动（想发就发，发得响亮）
- 发布是业务决定的（产品想要三更发，何必留版到午时）
- 一切都是自动化的（代码检查、测试、发布、监控都要自动化）
- 事件要立即解决（出现基础故障先立即回滚，因为上一个版本肯定是稳定可用的）
- 缺陷是立即被修复的（让缺陷在最短路径内闭环，通过自动化的手段发现系统问题并立即修复）
- 流程是持续更新的（通过价值流识别出流程短板并立刻消除，让有问题的流程尽可能重复执行）
- 工作可视化（通过看板可视化构建拉动系统，改善任务透明度，改善对剩余工作以及当前状态的了解，改善优先级排序，降低交接次数）
- 限制在制品（一次只做一件事，促进前置时间估算，减少切换工作丢失的生产率）
- 减少批次大小（小步快跑，而不是憋大招。一是可以改善工作的节奏，使其变得更稳定并且在各方面都更可预测；二是缩短前置时间，加快产出的交付；三是小的批次减少进行中的任务总数；四是小的批次降低了缺陷的数量，这样即使返工浪费也少。）
- 留意运维需求（DevOps中，最主要的关注点从可靠性转移到可恢复性，或反脆弱性，即系统应该能检测到并更正故障，恢复到正常的运维状态，过程中没有明显的性能损失，同时也不会影响到用户）
6. 我的感悟
6.1. 让缺陷在最短路径内闭环
在DevOps的关键实践中，要求"尽早检测并修正缺陷"。因为随着交付流水线阶段向后移动，识别和消除缺陷的成本也随之增加。缺陷一旦流入生产环境，将会造成重大的损失，那么DevOps快速交付的好处也失去意义了。在Capers Jones的《Applied Software Measurement》一书中，就通过曲线图对在不同研发阶段的缺陷修复成本进行了较为细致的说明。
CodeCC 一直以来主张的"让缺陷在最短路径内闭环"，与上述思想是非常一致的。 因为在CodeCC推出之前，很多团队都没有使用代码检查工具，不少缺陷流入系统测试等后续阶段才被发现，导致返工和扯皮。
我们从创造价值以相应客户请求的角度来考虑组织中的工作，将完成客户请求所需要实施的相关行动，按照顺序排列起来，这就是价值流。
CodeCC本身的产品进化也经历了三个阶段，也是朝着 更短路径内闭环 、 尽早检测并修正缺陷 的思路去走的。
- 第一阶段是推出CodeCC独立服务，主打每日定时构建的代码检查；
- 第二阶段是与流水线（如蓝盾流水线）融合，能够支持代码提交、代码合入、版本转测、发布上线等环节之前的代码检查。
- 第三阶段是研发质量保证的进一步"左移"，推出了IDE插件PreCI。从上述图中可以看到编码阶段产生了85%的缺陷，如果能在代码提交到代码库之前，在IDE中进行充分的代码检查、单元测试、自测等质量保证活动，将对产品质量有很大的提升。
如果工具检查出了缺陷，但是部分开发同学就是不处理，那该怎么办呢？那么质量红线就可以派上大用场了。它可以为关键节点（即控制点）设置质量标准，控制交付流水线的行为，使得每一阶段的入口/出口质量都必须符合质量标准的一种服务。不满足质量标准的产出不得发布到线上。
6.2. 尽可能频繁地直面问题
有一本著名畅销书叫做《反脆弱》。在DevOps中，也有一个质朴实用的反脆弱思想，让我很受启发，那就是"尽可能频繁地直面问题"。
曾经有一位朋友，打篮球右腿受伤了，做了膝关节半月板手术。在休养了一个月之后，逐步可以抛开拐杖了，但是右腿肌肉已经肉眼可见地缩小了，而且他心里也有阴影，对右腿有些丧失信心。于是他从轻轻用力，到慢慢走路，再到正常走路，再到小跳，再到大跳，再到上篮和跳投，随着他不断去使用它，感受它的状态，修正它的姿势，最终朋友重拾自信，重回球场。
其实DevOps中的反脆弱也是同理，一个流程经常出问题，那就把它再做一遍，再做一遍，出了问题就立即优化其中的问题，不断重复做。为什么一开始大家都讲持续集成（CI）呢，因为瀑布流开发模式下把代码合并到一起，发布到测试/生产环境，巨坑无比，要花费很长的时间。既然集成到环境已经成为了一个坑，那么我就每天都集成，提交了代码就集成，失败了我就立刻修复报错，太慢了我就优化流程和工具。持续集成千百遍，蓦然回首，一天发几个版本也不成问题了。
DevOps反脆弱对于工具化和自动化的要求还是很高的，类似于蓝盾DevOps这样的平台必不可少。因为重复做一件事，工具是最擅长的。而且要持续监控是不是有问题，并且立即回滚，没有一套自动化的体系，人工是很难去做的了。
6.3. DevOps不只是打破研发和运维的壁垒
很多网上的文章和视频把DevOps简单地解释成合并Dev和Ops，打破开发与运维的壁垒。我觉得这个观点是比较片面的。 DevOps是一整套面向研发效能的思想和原则，它的应用绝不止研发和运维这2个角色。
以安全为例，在各类公司大家都是非常重视软件安全的。在Exin课程中老师就举了个例子：有时会出现开发同学写的软件未通过安全团队审计，最终被打回重做。那么怎么解决这个问题呢？大家可以一起脑暴下。
我们公司安全做得还是很不错的。因此结合实际工作经验，我个人思考如下： 从组织（流程）的角度，要实现"尽早检测并修正缺陷"的实践，应该尽早进行安全宣导和审计。安全同学更早地参与到研发流程中去，例如立项、技术选项、代码检视等，进行安全准则宣导，及早地发现并暴露风险。 从文化（人）的角度，要实现"自给自足的团队"，需要研发同学更懂安全，能够了解安全准则，选用更加安全的技术。安全同学更懂研发，能够为安全漏洞提供好的修复建议。 从技术（自动化）的角度，可以把安全审计工具化、自动化，融入到整个研发流程中去。比如开发同学写了一个高危函数或使用了某个高危组件，还没提交代码，PreCI就已经检查出来了。而这个安全漏洞未被修复的话，他是无法合入代码到主干的，更无法转测或发布了。这块公司安平与CodeCC联合推出的啄木鸟安全检查系列规则集，就是这个思路。
因此可以看到，DevOps的思想是一整套体系，可以应用到研发的各个领域中。安全是其中一个例子，对于产品经理、测试同学的工作，也是有指导意义的。DevOps的核心是价值流，讲究的是从用户提出需求开始，到最后交付给用户价值。在价值流中任何环节存在浪费，都应该被优化。因此我们大部分互联网人的工作，其实都在DevOps里了。
7. 疑问和思考
暂无
8. 参考文档
暂无