牛年收官之作：谈一谈DevOps框架与流程

最近和朋友聊起一本新书，发现作者没有把他要说的“ DevOps的总体结构和流程” 讲清楚，甚至会误导读者，并且透过这些内容，感觉作者自己也没有真正理解“什么是DevOps”。为此，为了你不被误导，我就来写一篇有关 DevOps框架（“总体结构”一般适用于系统的描述，我们也可以把DevOps看成一个系统，但还是有点不合适，觉得这里用“框架”更合适些）与流程的文章，作为牛年的收官之作，自己在牛年也牛一把 😄 

1. DevOps概念的澄清

（一千个人就有一千种DevOps的解读）

什么是DevOps？4年前我写的 “整理了一份史上最全的DevOps 工具链 ”一文中，就通过追溯DevOps的历史发展过程来帮助大家理解、澄清这个概念，后来我还整理了 DevOps发展史（征求稿）。如果有兴趣，您可以打开这两篇文章看看。

2009年DevOps概念引入之时，就是基于“Development”和“Operation”合成的一个新词“DevOps”，强调开发（指交付前的研发活动，包括测试，不要简单理解为狭义的开发）与运维的融合，要求人们把注意力放在开发和运维的合作上，促进开发、技术运维和QA部门之间的沟通、协作与整合，这属于简要版的DevOps（DevOps lite）。而现在通常意义的DevOps是强调整个组织的协作和整合（约束理论也是要求优化整体而不是单个的 "孤岛"），超越IT和公司的边界，扩展到HR、财务、供应商与客户。

这里，我把几个有代表性的DevOps定义列出来，然后综合这些定义，我再试图给出更为清晰、完整、易理解的DevOps定义，从而帮助大家全面了解DevOps的内涵。

【维基百科】DevOps是一种重视 “软件开发人员（Dev）” 和 “IT运维技术人员（Ops）” 之间沟通合作的文化、运动或惯例。通过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。（注：“软件开发人员” 已经被误用，所以这个定义是有问题的，这里的Dev应该是指整个研发）

【Gartner的定义】DevOps代表了一种IT文化的变化，侧重于通过在面向系统的背景下采用敏捷、精益的做法来快速提供IT服务。DevOps强调人（和文化），寻求改善运维和开发团队之间的合作。DevOps的实施利用了技术（特别是自动化工具），可以从生命周期的角度利用日益可编程和动态的基础设施（注：如基础设施是代码、容器/虚拟化技术）。

【PMI的定义】严谨的DevOps是指IT解决方案的开发、IT运维活动以及支持企业的其它IT活动（如安全和数据管理）的流水线化（streamlining），以便为企业提供更高效的结果。

【Gitlab的定义】DevOps是软件开发人员（dev）和运微（ops）的结合。它被定义为一种软件工程方法，旨在通过促进协作和责任分担的文化，整合软件开发和软件运维团队的工作。（注：狭义的DevOps，问题同上）

【SAFe】DevOps是一种思维方式、一种文化以及一套技术实践。它提供了沟通、整合、自动化以及计划、开发、测试、部署、发布和维护解决方案所需的所有人员之间的紧密合作。DevOps是精益企业的敏捷产品交付能力的一部分，企业实施DevOps是为了打破组织上的隔阂，开发一个持续交付（CD）流水线（CDP）——一个高性能的创新引擎，能够以业务的速度交付市场领先的解决方案。

【Atlassian的定义】DevOps是一套实践、工具和文化理念，它使软件开发和IT团队之间的流程自动化和一体化，强调团队授权、跨团队的沟通和协作以及技术自动化。

【Amazon的定义】DevOps 集文化理念、实践和工具于一身，可以提高组织快速交付应用程序和服务的能力。开发团队和运维团队不再是“孤立”的团队，他们的工程师会在应用程序的整个生命周期（从开发、测试到部署、再到运维）内相互协作，开发出一系列不限于单一职能的技能，并使用能够帮助其快速可靠地操作和发展应用程序的技术体系和工具，可以独立完成通常需要其他团队协作的任务。

【Microsoft的定义】DevOps使以前孤立的角色——开发、IT运维、质量工程和安全——能够协调和合作，以开发更好、更可靠的产品。通过采用DevOps文化、实践和工具，团队获得了更好地响应客户需求的能力，增加了对其构建的应用程序的信心，并更快地实现业务目标。

从上面这些定义看，DevOps 是一套文化理念、实践和工具，而且文化理念更重要，它决定了人们的实践，会促进不同团队之间的沟通和协作，也促进所使用的流程和工具向持续集成（Continuous Integration，CI）/持续交付（Continuous Delivery，CD）、流水线化方向改进。为了能实现快速交付、持续交付，需要自动化技术支持，包括自动构建、自动集成、自动测试、自动部署。

DevOps之父Patrick Debois在回答他为什么不支持DevOps的宣言时，就指出人们应该回到敏捷宣言中去，并再次大声地、重复朗读它。敏捷向 “更快地交付软件”的转变，以及对最终目标（业务价值）的关注，使其自然也成为DevOps的精神所在，所以DevOps是建立在敏捷、精益开发的基础之上的，在敏捷中就开始强调CI/CD和价值的交付、强调开发与客户的合作，DevOps可以看作是敏捷的自然延伸，从研发周期向右延伸到部署、运维，不仅打通研发的 “需求、开发与测试” 各个环节，还打通 “研发” 与 “运维”，最终打通用户、PMO、需求、设计、开发、测试、运维等各上下游部门或不同角色，消除开发与运维之间存在的“鸿沟”，消除制度化的孤岛或部门墙，消除“ 一个团队的成功衡量标准与另一个团队的KPI直接相悖” 这样的问题，例如运维部门要求研发交付慢些、频率低些从而使系统具有更高的可靠性和安全性，而业务部门则希望更快地、将更多的特性发布给用户。

DevOps流水线贯通，一方面依赖于文化、组织、制度、流程上的改变，另方面也要依赖于支撑整个公司研发、运维、业务/服务的基础设施，依赖在业务、架构、代码、测试、部署、监控等之上相互联通的工具链，才能在实践中践行DevOps的文化理念。如果没有技术支持，就难以践行DevOps的文化理念，久而久之会放弃。今天虚拟化和云计算基础设施日益普遍，使DevOps流水线的实现也水到渠成。

QA和安全团队也会与开发和运维团队更紧密地结合在一起，贯穿应用程序的整个生命周期。当安全是所有 DevOps 团队成员的工作重心时，这时可以被称为“DevSecOps”；当质量是所有 DevOps 团队成员的工作重心时，这时可以被称为“DevQAOps”。但DevSecOps、DevQAOps这种提法很不好，因为今天的DevOps已经强调整个组织的协作和整合，甚至超越了IT和公司的边界，自然安全、质量也是贯穿整个软件生命周期的，希望少制造一些概念。

概括起来，DevOps是建立在敏捷与精益开发之上的一套文化理念、实践和工具，以促进整个组织的各部门之间的沟通与协作，整合研发和运维的各种活动，并借助良好的流程、技术和工具构建贯通业务、设计、编程、测试、部署、监控等全生命周期的交付流水线，提高研发效能、减少运维成本，从而能够快速地、可靠地响应日益增长的业务和客户的需求，最大化业务价值。

2. DevOps常见实践

在清楚了DevOps概念之后、讨论DevOps框架之前，我们需要了解一下DevOps主要实践有哪些，这样有利于理解DevOps的框架和流程。

从宏观上看，DevOps主要实践有：MVP、CI/CD、交付流水线、微服务架构、基础设施即代码、自动化测试、测试左移和测试右移、A/B实验、混沌工程、持续测试、智能监控、日志分析、快速反馈/持续反馈、面对面沟通、加强协作、快速创新、可观察性等。

如果更深入看DevOps实践，可以看一下张乐老师之前在QECon大会上的分享： DevOps五大理念及其落地实践（注释版），其中五大理念是：

1. 局部性和简单性；
2. 专注、流动和快乐；
3. 改善日常工作；
4. 心理安全；
5. 以客户为中心。

而其实践总共有17项，分布在5大理念中，可以看到一些新的主题词：规模化、依赖矩阵、云原生应用架构、看板、价值流、管理流、工程流、滞留项、流动阻塞、代码分支、质量守护模型、高频集成、满意度反馈体系、技术负债、研发效能度量等。

第一理念（減轻团队/组件之间的依赖）下的实践：

• 在规模化之前先去规模化
• 通过依赖矩阵识别并暴露依赖
• 通过管理和技术手段减少依赖
  
• 通过云原生应用架构简化开发工作

第二理念（工作的流动使人专注和快乐）下的实践：

• 通过看板暴露未计划的工作

• 通过看板管理端到端价值流动

• 通过滞留项报告暴露流动阻塞

• 建立代码分支及质量守护模型

• 高频集成，打造持续交付流水线

• 建立管理流与工程流之间的联动
• 建立满意度反馈体系

第三理念（持续改进、偿还技术债务）下的实践：

• 关注代码的技术负债率
  
• 为每种工作类型预留工作时间

第四理念（高效能预测因子，使能改进）下的实践：

• 事后：不指责的事后故障回顾
• 事前：通过混沌工程加强服务健壮性

第五理念（优化客户价值，不是职能KPI）下的实践：

• 基于价值流的研发效能度量
  
• 系统思考，打造研发效能提升的金三角

3. DevOps框架

上面列出了DevOps的各种实践，虽然由于篇幅有限，无法展开讨论，但我们构成的框架，需要把这些实践包含进去或整合起来，例如：

• 从文化看，包括以客户为中心、跨部门的密切沟通与协作、MVP、价值交付、快速创新、质量内建文化、测试左移和测试右移思维方式、CI/CD文化等。

• 从组织和人员看，建立自组织的特性团队，提升组织意识和客户意识，提升团队技术能力和沟通、协作能力，培养DevOps文化、质量文化。

• 从流程看，关键是构建交付、反馈的闭环，构建有效的、价值流、管理流、工程流的流程及其管理平台，建立看板和协作机制等；
  

• 从技术和工具上看，涉及的内容更多，微服务架构、CI/CD基础设施、基础设施即代码、自动化测试、单一代码管理平台、交付流水线、A/B实验、混沌工程、依赖矩阵、智能监控、实时日志分析、满意度反馈平台等，如基于Jenkins 全过程自动调度的流水线、基于容器技术的研发/生成环境管理。

DevOps框架就可以简单描述如下图所示。

我们也可以看一下更为简单或企业应用的DevOps框架或模型，例如CAMS模型（Culture, Automation, Measurement, Sharing）就更简单，4个基本要素：

1. 自动化（Automation）可以映射到领域1：交付过程，包括自动部署、自动测试、自动监控，消除等待时间、减少人为错误等；

2. 度量（Measurement）似乎可以映射到领域2：反馈过程必须穿越部门墙、跨越传统的筒仓（烟囱）界限，充分共享、密切协作；

3. 文化（Culture）属于领域3：生产环境中的嵌入式研发（人员），开发人员在利用运维知识时能做出更好的决定；

4. 分享（Sharing）到领域4：嵌入项目（研发）中运维（人员），运维人员在应用研发知识时也能做得更好。

这里提到的4个领域，来自DevOps之父Patrick Debois的DevOps的法典式模型：

• 领域1：将交付延伸到生产，这是开发和运维合作的地方，以改善项目交付到生产中的任何事情。
• 领域2：将运维延伸到项目，所有来自生产的信息都会被辐射到项目中。
• 领域3：将项目（开发）嵌入到运维中，当项目对生产中发生的所有事情拥有共同所有权时。
• 领域4：将生产（运维）嵌入项目中，从项目一开始，运维就参与进来。

在每一个领域，开发和运维之间都会有一个双向的互动，从而产生知识交流和反馈。领域1和领域2往往更偏重于工具方面，领域3和领域4将更多地与人/文化的变化有关。基于CAMS模型的DevOps框架如下所示，每一个域或核心元素都需要人、流程和工具的支持。

（基于CAMS模型的DevOps框架）

另外一个类似框架就是CALMS，它是评估公司采用DevOps流程能力的框架，也是衡量DevOps转型期间成功与否的一种方式。这个缩写是由The DevOps Handbook的作者之一Jez Humble创造的，代表文化、自动化、精益、度量和分享，也只是比CAMS多了一个精益（Lean）。

IBM的企业级DevOps框架（含流程）更完整，参考下图及其文字。

1. 分析和计划：查看组件间依赖关系（应用发现和交付智能），提高速度，计划和协作（工作流管理）。
2. 代码和构建：快速交付，云原生开发，更快地构建混合应用，一次构建、随处部署（一致的管理和协调），自由选择SCM（软件配置管理，自动配置和变更控制）。
3. 自动测试：测试左移，容器化测试，单元测试。
4. 预置、部署和发布：自动化部署（利用快速反馈、持续交付和审计跟踪），预置多云环境，同步分发应用程序。
5. 监控：监控应用程序，代码级的洞察力，提高性能。
6. 为复杂环境创建优质系统。

华为集30年经验提炼为一张DevOps 实施框架图，如果看不清楚，请访问 这里 下载高清版本。

4. DevOps流程

DevOps流程其实大家看的比较多，如同上面这张图所显示的那样，形成研发与运维闭环、闭环、闭环（重要的事说三遍），其核心就是研发这边的CI/CD（持续集成与交付）和运维那边（来自客户）的持续反馈，并需要持续的协作和沟通的支持。即使加上安全、质量保证，称其为DevSecOps、DevQAOps，其实也是形成安全、质量保证的闭环。

把持续交付表现得淋漓尽致的是下面这张图，包含：持续计划、持续开发、持续测试、持续发布和部署、持续监控、持续反馈与优化。

如果只强调持续交付流水线，就可以用SAFe的两张图来描述，这里的核心是持续探索、持续集成（包含的持续测试）和持续部署，而且这种发布是可以做到按需交付。

在流程上，也可以参考张乐老师写的《什么是 DevOps 三步工作法？》

（来源：张乐《什么是 DevOps 三步工作法？》 ）

三步工作法：

1. 让价值快速流动，其中有六个实践：可视化、限制在制品、减少规模、减少交接数量、持续识别和拓展约束，以及在价值流中消除浪费。
2. 反馈原则，有四个实践：是在出现问题时及时发现，密集解决问题、构建新的知识，将质量向源头推进，为下游工作进行优化。
3. 持续学习和实验原则，有四个实践：开启组织学习和安全文化，让日常工作的改进做到制度化，将局部发现转为组织全局改进，在日常工作中注入恢复模式

详细内容，请参考图书：The DevOps Handbook。

参考：

• https://en.wikipedia.org/wiki/DevOps

• https://www.atlassian.com/devops

• https://www.scaledagileframework.com/devops/

• https://cloud.google.com/devops

• http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/

• https://devops.com/surprise-broad-agreement-on-the-definition-of-devops/

借此机会祝各位读者新春快乐！

未来事业有成、生活幸福安康！