零、DevOps背景
从2017年DevOpsDays大会北京站举办以来，DevOps在国内的发展正式驶向了快车道。DevOps的影响力与日剧增，不仅仅是互联网行业，就连传统的电信、金融，甚至是政府机构，也都把DevOps作为核心能力在快速建设。公司内成立了Devops俱乐部，Ones和DevTools平台也是在这个场景驱动下建设的。软件开发过程的改进，除了依赖于技术进步，还依赖于流程、理念、文化等全方位的改进，而这正是DevOps带给软件开发方式的一场革命。
一、DevOps定义&解决问题
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
瀑布流式开发模式: 将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。缺点：应对变化能力弱，变更导致延期风险多，对用户反馈响应慢。
敏捷开发模式: 核心理念是，既然我们无法充分了解用户的真实需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工。缺点：并没有把运维团队纳入进来，需要等运维发布窗口期。
DevOps模式：在传统模式下，度量开发团队效率的途径就是看开发完成了多少需求。对于运维团队而言，他们的考核指标却是系统的稳定性、可用性和安全性。DevOps从一开始想要促进开发和运维的协作，团队慢慢发现，其实在整个软件交付过程中，不仅只有开发和运维，业务也是重要的一环。
二、DevOps的价值&指标
企业在做数字化转型，软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心。软件交付的效率和质量成了当今企业的核心价值和核心竞争力。DevOps能提高软件交付效率和质量，这是DevOps的价值。
DevOps的4个结果指标。
- 部署频率：指应用和服务向生产环境部署代码的频率。
- 变更前置时间：指代码从提交到成功运行在生产环境的时长。
- 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
- 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
三、DevOps的3个支柱
DevOps是文化、工具、技能的结合。
对工具和文化的体系化认知，可以归纳到DevOps的3个支柱之中，即人（People）、流程（Process）和平台（Platform）。3个支柱之间两两组合，构成了我们实施DevOps的“正确姿势”，只强调其中一个维度的重要性，明显是很片面的。
四、DevOps涵盖内容
中国信息通讯研究院牵头制定的一套DevOps能力成熟度模型。这套模型覆盖了软件交付的方方面面，包括敏捷开发管理、持续交付和技术运营三大部分，同时，也有与应用架构设计、安全和组织结构对应的内容。
对于开发DevOps工具的企业来说，系统和工具模型更加偏向于平台能力，稍加整理就可以作为平台需求输入到开发团队中。
实施步骤和原则
1.识别差距
从“道法术器”的角度来说，DevOps的成熟度模型和框架处于“法”这个层面，也就是一整套实施DevOps的方法论，相当于是一幅战略地图，最重要的就是对DevOps实施所涉及到的领域和能力图谱建立全面的认知。
2.锚定目标
数字化转型的核心在于优化软件交付效率。通过对标模型框架，企业需要明确什么是影响软件交付效率进一步提升的最大瓶颈，当前存在的最大痛点是什么，哪些能力的改善有助于企业达成预定的目标……同时，要根据企业的现状，甄别对标的差距结果，识别出哪些是真实有效的，哪些可以通过平台能力快速补齐。
3.关注能力
模型和框架是能力和实践的集合，也就是道法术器的“术”这个层面，所以在应用模型的过程中，核心的关注点应该在能力本身，而不是单纯地比较数字和结果。
4.持续改进， ITIL V4的指导原则，包括：关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。
五、价值流VSM
Jenkins的主要维护者CloudBees公司最新推出的DevOptics产品，主打VSM功能，而经典的持续交付产品GoCD的VSM视图也一直为人所称道。那么，这个VSM究竟是个啥玩意儿呢？
VSM是Value Stream Mapping的缩写，也就是我们常说的价值流图。要说清楚VSM，首先就要说清楚什么是价值。简单来说，价值就是那些带给企业生存发展的核心资源，比如生产力、盈利能力、市场份额、用户满意度等。
它起源于传统制造业的精益思想，用于分析和管理一个产品交付给用户所经历的业务流、信息流，以及各个阶段的移交过程。通过观察完整流程中各个环节的流动效率和交付质量，识别不合理的、低效率的环节，进行优化，从而实现整体效率的提升。
通过使用价值流图对软件交付过程进行建模，使整个过程可视化，从而识别出交付的瓶颈和各个环节之间的依赖关系，这恰恰是“DevOps三步工作法”的第一步“流动”所要解决的问题。
简单介绍下“DevOps三步工作法”。它来源于《DevOps实践指南》，可以是说整本书的核心主线。高度抽象的“三步工作法”，概括了DevOps的通用实施路径。
- 第一步：流动。通过工作可视化，限制在制品数量，并注入一系列的工程实践，从而加速从开发到运营的流动过程，实现低风险的发布。
- 第二步：反馈。通过注入流动各个过程的反馈能力，使缺陷在第一时间被发现，用户和运营数据第一时间展示，从而提升组织的响应能力。
- 第三步：持续学习和试验。没有任何文化和流程是天生完美的，通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。
关键要素
你并不需要花大力气去研究生产制造业中的价值流分析到底是怎么玩的，你只要了解有关VSM的几个关键要素和核心思想就行了。那么，VSM中有哪些关键要素和概念呢？有3点是你必须要了解的。
- 前置时间（Lead Time，简称LT）。前置时间在DevOps中是一项非常重要的指标。具体来说，它是指一个需求从提出（典型的就是创建一个需求任务）的时间点开始，一直到最终上线交付给用户为止的时间周期。这部分时间直接体现了软件开发团队的交付速率，并且可以用来计算交付吞吐量。DevOps的核心使命之一就是优化这段时长。
- 增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称VAT/NVAT）。在精益思想中，最重要的就是消除浪费，也就是说最大化流程中那些增值活动的时长，降低不增值活动的时长。在软件开发行业中，典型的不增值活动有很多，比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等。
- 完成度和准确度（% Complete/Accurate，简称%C/A）。这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回。这里面蕴含了大量的沟通和返工成本，从精益的视角来看，也是一种浪费。
在实践中，企业往往将需求作为抓手，来串联打通各个环节，而前置时间是需求管理的自然产物，采集的难度不在于系统本身，而在于各环节的操作是否及时有效。有的团队也在使用需求管理工具，但是前置时长大多只有几秒钟。问题就在于，他们都是习惯了上线以后，一下子把任务状态直接从开始拖到最后，这样就失去了统计的意义。
需要注意的是，关于前置时间，有很多种解释，一般建议采用需求前置时间和开发前置时间两个指标进行衡量，关于这两个指标的定义，你可以简单了解一下。
需求前置时间：从需求提出（创建任务），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队整体的交付能力，也是用户核心感知的周期。
开发前置时间：从需求开始开发（进入开发中状态），到完成开发、测试、上线，最终验收通过的时间周期，考查的是团队的开发能力和工程能力。
六、业务敏捷开发
敏捷开发，是一种新型软件开发方法，应对快速变化的市场和技术环境。它 更 强 调价值交付过程中所涉及的各类角色（如业务、产品、开发和测试等）之间的紧密协作、能够很好地适应变化的团队组织、协作和工作方式，主张演进式的规划和开发方式、
持续和尽早的交付，并不断反馈调整与持续改进，并且鼓励快速与灵活的面对变更，更注重软件开发过程中人的作用。敏捷开发分为价值交付管理、敏捷过程管理、敏捷组织模式三个维度。
敏捷开发方法，你可能会情不自禁地联想到双周迭代、每日站会、需求拆分等。的确，作为一种快速灵活、拥抱变化的研发模式，敏捷的价值已经得到了行业的普遍认可。
敏捷开发方法——精益看板。而在生产制造系统中，看板作为一种信号卡，主要用于传递信息。《改变世界的机器》一书首次提到了著名的丰田准时化生产系统，而看板正是其中的核心工具。
简单来说，看板系统是一种拉动式的生产方式。区别于以往的大规模批量生产，看板采用按需生产的方式。也就是说，下游环节会在需要的时候，通过看板通知上游环节需要生产的工件和数量，然后上游再启动生产工作。
说白了，所谓拉动式生产，就是从后端消费者的需求出发，向前推导，需要什么就生产什么，而不是生产出来一大堆没人要的东西，从而达到减低库存、加速半成品流动和灵活响应变化的目的。
我把精益看板的实践方法分为了五个步骤。
- 第一步：可视化流程；
- 第二步：定义清晰的规则；
- 第三步：限制在制品数量；
- 第四步：管理工作流程；
- 第五步：建立反馈和持续改进。
七、工具图谱
八、DevOps工程师
附录：
Atlassian: www.atlassian.com/devops
