1. DevOps的概念

DevOps 至今都缺乏一个清晰和统一的认识。对于一场运动来说，这是一件好事，也同样是一件坏事。虽然 Patrick 曾经在自己的博客里一再提到自己对 DevOps 的”正确认识’’，但社区似乎不以为然。
缺乏“官方定义”好处是人人都可以定义，因此没有一个人或者组织可以垄断 DevOps 定义权。所以每个人都自己可以参与到这一运动中去，不断为其增加新的概念、新的实践和新的工具。这会使 DevOps 社区不断的繁荣。
而坏处也很明显，对于 DevOps 的后来者 —— 那些没有参与进来的人，需要学习和理解的 DevOps 知识的广度和深度也越来越大。
以至于后来出现了这幅众所周知的“盲人摸象图”：
这幅图中包含了很多概念，但主要表现的意义 DevOps 是一系列概念的总和，任何一个单方面的定义只是 DevOps 的一个部分，而不是 DevOps 的整体，随着 DevOps 这个概念的不断膨胀，人们就更难理解 DevOps 了。
0.jpeg
2009年DevOps概念引入之时，就是基于“Development”和“Operation”合成的一个新词“DevOps”，强调开发（指交付前的研发活动，包括测试，不要简单理解为狭义的开发）与运维的融合，要求人们把注意力放在开发和运维的合作上，促进开发、技术运维和QA部门之间的沟通、协作与整合，这属于简要版的DevOps（DevOpslite）。而现在通常意义的DevOps是强调整个组织的协作和整合（约束理论也是要求优化整体而不是单个的 “孤岛”），超越IT和公司的边界，扩展到HR、财务、供应商与客户。

  • 【维基百科】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 是一种工作方式
  • DevOps 是一种组织结构

那么，我们分别来谈谈这四类 DevOps。
DevOps 是一组技术/实践
在工程师文化的组织里，对先进技术的渴望是最常见的学习动机。可以促进工程师用更有效率，更优雅的方式解决问题。而对于非工程师文化的组织，新的技术往往是提升其 KPI 的工具。以下是我听到 DevOps 的时候，经常触及的话题：

  • 高频部署
  • 持续交付
  • 云计算/虚拟化技术
  • 基础设施即代码
  • Docker
  • 自动化运维

1、高频部署
曾经和某跨国著名银行的外汇交易产品的 IT 产品负责人交流 DevOps。对方很自豪的告诉我，他们产品每天的部署频率超过500次，我听了不以为然。因为，部署频率高不见得是件好事。于是我问了以下几个问题：

  1. 为什么你们需要这么频繁的部署？有这么频繁变动的业务需求吗？
  2. 在这么多次部署里，是发布业务价值的部署更多，还是修复问题的部署更多？
  3. 这些生产环境的变更难道完全是不可规划的吗？

由于对方的金融业务有相应的法律法规，理论上没有这么频繁的变更需求，除非清理技术债，否则没有很强烈的变更动机。但对方并没有直接回答我的问题，而是换到了其它问题上，因此我最终也不清楚对方这么频繁变更的驱动力。
这对我有一个重要的：指标导向的 DevOps 往往是一种 DevOps 的反模式，它会忽略和掩盖真正的问题。
指标的背后是某种度量，如果部署频率一直很高，一定反应了某种现象。
而这些现象不一定是个好现象：不是业务的变动很频繁，就是技术的变动很频繁。但如果二者都频繁，我们应该衡量变更带来的价值和风险（当然，DevOps 可以降低变更的风险），并优先变更价值较高的请求。
有可能新的业务尝试让我们从市场上获得了更多的关注，也有可能新的技术提升了生产率。但无论是哪一种，部署频率应该是一个有多到少不断循环的过程。
这表明系统在走向成熟和稳定的同时，能够及时响应变化，无论是对技术还是对业务，对变更产生的影响都需要一段时间去积累和总结数据。
此外，DevOps 绝不是为了提升部署频率而牺牲了软件质量和业务价值，甚至是安全措施。
换句话说，DevOps 不是一种对质量的平衡和妥协，它是一种全局改进。全局的改进就意味着以价值为最高原则所度量的相关指标是不能有所下降的。

2、持续交付
持续交付是 DevOps 中非常重要的实践，持续交付的思想远早于 DevOps 。但直到第二届欧洲的 DevOpsDays 才有了持续交付这个重量级话题。因为持续交付本身也通过技术手段和实践解决了 DevOps 最初所面临的 Dev 和 Ops 的合作问题。
不夸张的说，如果 Patrick Debois 早一点读到持续交付中运维相关的话题，说不定就没有 DevOps 了。
然而，随着 DevOps 的理念的发展比持续交付融汇了更多的概念（这就是没有一个人能垄断定义的好处），使得 DevOps 更加广泛和盛行。因此， DevOps 所涵盖的范围已经超出了持续交付本身。
我把 持续交付 列为 DevOps 的核心实践之一，因为如果你没有实践 持续交付。那么根本不能称之为 DevOps，但是如果你完整实践了持续交付，那么你离完整的 DevOps 也不远了。

3、云计算/虚拟化技术
随着分布式应用的井喷式发展。基础设施的管理成为了分布式应用的新瓶颈。在集中式管理的时代，大型应用只能运行在昂贵的小型机上，只有微软，SAP， IBM ，Oracle 和 EMC 这样的企业才有能力提供相应的产品完成这样复杂度很高的架构。因此企业需要单独的运维部门（Ops）来管理这些软件和设备。
而随着虚拟技术和云计算的兴起，企业的基础设施管理工作往往变得很简单。VMWare 这样的虚拟技术企业和 AWS 这样的云计算供应商提供了更加成熟和稳定的产品。大大的节约了企业机房管理的开支。
而 Ops 也不再需要进出机房，只需要通过远程桌面的方式就可以使用各种 SDK 开发工具去完成过去很多只有在机房才能做到的操作。
然而，即使云计算和虚拟化技术提升了 Ops 的生产率，减轻了 Ops 的痛苦。但仍没有解决 Dev 和 Ops 之间的矛盾 —— 开发团队和维护团队仍然各自为政，仍然通过制度谈判而不是合作共赢来工作，毕竟目标是相对立的。

4、 基础设施即代码
随着设备和网络的持续增多，加之更加复杂的应用部署和初始化。基础设施的管理成为了一个十分尖锐的问题。
当复杂度上升一个量级，就需要专业的管理工具来管理这类问题。于是 Puppet 这样的框架顺势而出。以至于在 《DevOps Handbook》中，合著者之一的 John Willis 在理解了 PuppetLab 的创始人 Luke Kanies 的想法之后，才有了 DevOps 的最初理解。
基础设施即代码利用了编程语言和虚拟化工具 API 的无缝连接达到这一目的。它在很大程度上把基础设施的管理当做其问题域，采用正确的面向对象方式，让开发人员和运维人员能够理解并设计出更加稳定和灵活的基础设施。
大大降低基础设施变更的风险：提升了运维知识的透明度并使基础设施变更具备幂等性。
此外，它在一定程度上解决了不同环境（开发，测试，生产）之间的不一致问题，也让开发人员能够学习到 Ops 领域的知识并用软件开发的优秀思想解决运维领域的问题。
因此，基础设施即代码除了工具以外，更是一种 Dev 和 Ops 之间相互沟通的媒介，能够让开发人员和运维人员相互理解。所以，基础设施即代码毫无疑问的是 DevOps 的核心实践之一。

5、Docker
Docker 是含着 DevOps 的金钥匙出生的，它诞生的第一天就带着 DevOps 的基因：更简单的解决了基础设施即代码和虚拟化在实践中的问题，进一步提升了自动化能力以提升效率，并且对开发人员和运维人员都十分友好。
甚至很多地方都会以是否采用 docker 来评判是否采用了 DevOps 的相关技术。
Docker 一定程度上简化了基础设施的初始化和状态管理问题。通过镜像和运行时容器封装了应用运行时的复杂度。并通过容器的编排实现轻量级的分布式架构，也更加经济快捷。
但是，Docker 和任何一种工具一样，都不是”黄金锤“。当用错了场景，使用 docker 可能是一场灾难。
我曾经参与并帮客户完成了一个数据中心迁移的项目，就是采用的 docker 作为统一的运行时容器。最初是因为 docker 镜像的移植性好，在各种异构 Linux 系统上可以正确执行，且镜像构建过程透明。
但是客户为了能让这个业务场景更加通用，又分别采用了另外两种工具对其部署场景进行封装，并写出了第三个工具。
由于这个工具并没有很好的分离其业务关注点和技术关注点，导致这个工具使用异常繁琐，需要增加更多额外的配置去定制化容器运行环境。原本为了提升生产效率的手段反而成为了阻碍效率的绊脚石。

6、 自动化运维
看了以上那么多的工具和技术，很多对 DevOps 望文生义或有些技术了解的运维工程师认为提高了自动化运维的水平，就是 DevOps。
虽然 DevOps 里的一个重要特征是“自动化”，但拥有自动化运维，并不代表你就正在实践 DevOps，很可能你仅仅提升了运维部门的效率，但并没有从全局的角度提升开发和运维之间的效率和端到端价值的流动。因此，仅仅有自动化运维，还不足以称之为 DevOps。

DevOps 是一个岗位角色
当 DevOps 传播开来，大家都会倾向于去找叫做 “DevOps” 的人，希望通过招聘和培训来提升自己的 DevOps 能力。
于是设置了一些称之为 “DevOps 工程师” 的岗位和角色。通过对这些招聘需求以及客户对 DevOps 的需求，我发现了四个不同但是相关的 “ DevOps 工程师 “ ：

  • 作为 Dev 的 Ops（会开发技能的运维工程师）
  • 作为 Ops 的 Dev（会运维技能的开发工程师）
  • 基础设施开发工程师
  • 全栈工程师

1、作为 Dev 的 Ops
有很多人也会认为，只要让开发工程师掌握运维技能，运维工程师掌握开发技能，就做到了 DevOps。
这招来了很多运维工程师的反感。我采访过一些运维工程师，当初他们就是不喜欢也不想写代码，才选择了运维方向。
这种想法的其中一个动机是在于架构的逐渐稳定带来的运维工作减少，特别是使用了云计算技术和虚拟化技术的企业。这会让管理层有一种错觉，认为运维团队的空闲状态，一定程度上是浪费。
因此，为了达到“人尽其用”，让运维工程师进入开发团队去写业务代码。并用“DevOps”作为对这种措施这一合理化的幌子。
这种想法的天真在于忽视了开发和运维的专业性和差异性。这让我想起一个段子：
老板：“我怎么觉得在公司的运营中你们部门没起多大作用？”
运维经理：“你走过大桥吗？”
老板：“走过。“
运维经理：“桥上有栏杆吗？”
老板：“有。”
运维经理：“您过桥的时候扶栏杆吗？”
老板：“不扶。”
运维经理：“那么，栏杆对您来说就没用了？”
老板：“那当然有用了，没用栏杆护着，掉下去怎么办？”
运维经理：“可是您没有扶栏杆啊！？”
老板：“…… 可是 …… 可是没有栏杆，我会害怕！“
运维经理：“那么，运维就是桥上的栏杆。“
虽然我不否认技术的发展对二者来说难度和门槛在不断降低。而且掌握一定开发技能的运维工程师前景更加光明。但是强人所难并不会让事情变好。此外，这类人才可遇不可求，也不要因为招不到这样的人而阻止了 DevOps 实践。

2、作为 Ops 的 Dev
同样的误解也会发生在开发工程师身上。对于开发工程师来说，其实难度并没有增加。无非是把 Ops 的工作当做需要通过别的工具完成的开发需求而已，甚至很多开发工程师自己也这么认为。
运维除了知识以外，很大一部分的不可替代性来源于生产环境的维护经验。然而这些经验不可复制，因为有些问题作为开发人员来说你很难碰到。我曾打趣的说，当你听到有人说“这不可能啊”，他一定是个运维新手。
就像我在上文强调的，软件开发和软件维护是相互关联但是各自独立的专业领域。DevOps 并不是要消除任何一方，而是要通过更加深入的合作成为彼此工作的润滑剂而非绊脚石。
对于开发工程师来说，掌握更多的技能绝对是一件好事。但也不要低估运维的专业性和经验性。

3、基础设施开发工程师
由于有了虚拟化和基础设施即代码这样的技术，“通过 Dev 的方式完成 Ops 的工作，就是 DevOps “ 也很自然的成为了很多 Ops 对 DevOps 的认识。指的是通过 SDK，相关工具和配置文件，利用现有的平台资源，为应用程序构建基础设施。
而他们往往有一个新的称谓：基础设施开发者 （Infrastructure Developer）或这 云计算工程师 （Cloud Engineer）。
有一次到马来西亚出差，我称自己是 Infrastructure Developer 被 Uber 司机当做政府基建项目开发商问了一堆稀奇古怪的问题，当然我并没有澄清，而是继续逗他 。在一些企业里，基础设施开发工程师都会肩负着推行企业 DevOps 的责任。
但很少有企业能够明确 DevOps 是要做什么（这就是 DevOps 缺乏基准定义的坏处），而这些基础设施开发工程师会慢慢变成一个孤立的“平台团队”，这对 DevOps 是不利的。

4、全栈工程师
当然绝对不排除有些工程师是既懂开发也懂运维的”复合型人才”。但这样的人才的成本也十分高昂：一方面是寻找这样的人所花费的时间。另一方面是雇用这样的人所花费的资金。此外，对于某些企业来说还有培养这样人才的成本。
但是，仅仅认为有了这样的人才就具备 DevOps 的能力也并不现实。首先，DevOps 是一个团队属性，而不是一个人属性。
一个人的力量相较于一个团队来说，还是很有限。其次，招聘这样的人主要还是为了胜任纷繁多变的工作，创业公司尤其如此。因此，我有时候会戏称全栈工程师为“全干工程师”，听起来很厉害，但工作境遇并不见的很好。

3. 你可能只需要一个 “DevOps 晃动器”

软件开发和软件运维，是两类不同但联系很密切的事务，在过去很长的时间里。由于专业性和责任的不同从甲乙双方的矛盾变成了企业内部的矛盾。
这是企业在互联网转型过程中的必经阶段，因为运维的开发不密切合作带来的问题日渐突出。
而如何平滑的过渡，则是 DevOps 成败关键所在。你所需要不光是工程人才，你还需要新型的管理人才或者外部顾问来推动这项改进。
一般来说，DevOps 的变革一定会调整组织的制度和做事方式。而制度层面的改变从企业内部是很难做到的。
企业越大，“不求有功，但求无过”的鸵鸟心态普遍存在，因此越是大型的组织，所面临的组织僵化会越严重。组织僵化不见得是一件坏事，这意味着你的企业组织形态更加的问题和高效，这是长时间积累的结果。但由于过于高效，组织僵化的负面效应就是缺乏创新。
所以，要推动企业的 DevOps 转型，特别是制度方面的创新，往往需要从组织外部引入“晃动器”（无论是聘用新的管理人才，还是外部顾问）来松动一下过于高效的组织，这都是能够帮助组织解除僵化的方式。
本文讨论了 四种 DevOps 认识的两种：

  • DevOps 是一组技术/实践
  • DevOps 是一个角色

在 DevOps 的实践中，我们仍然需要理清不同 DevOps 所包含的内涵。才能正确实践 DevOps，并为 DevOps 的实践提供启发。关于剩下两种 DevOps 的认识，请见后续文章。

image.png

4. DevOps常见实践

从宏观上看，DevOps主要实践有：MVP、CI/CD、交付流水线、微服务架构、基础设施即代码、自动化测试、测试左移和测试右移、A/B实验、混沌工程、持续测试、智能监控、日志分析、快速反馈/持续反馈、面对面沟通、加强协作、快速创新、可观察性等。
如果更深入看DevOps实践，可以看一下张乐老师之前在QECon大会上的分享： DevOps五大理念及其落地实践（注释版），其中五大理念是：

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

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

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

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

  • 通过看板暴露未计划的工作
  • 通过看板管理端到端价值流动
  • 通过滞留项报告暴露流动阻塞
  • 建立代码分支及质量守护模型
  • 高频集成，打造持续交付流水线
  • 建立管理流与工程流之间的联动
  • 建立满意度反馈体系

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

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

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

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

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

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

    5. DevOps框架

    image.png

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

  • 从文化看，包括以客户为中心、跨部门的密切沟通与协作、MVP、价值交付、快速创新、质量内建文化、测试左移和测试右移思维方式、CI/CD文化等。
  • 从组织和人员看，建立自组织的特性团队，提升组织意识和客户意识，提升团队技术能力和沟通、协作能力，培养DevOps文化、质量文化。
  • 从流程看，关键是构建交付、反馈的闭环，构建有效的、价值流、管理流、工程流的流程及其管理平台，建立看板和协作机制等；
  • 从技术和工具上看，涉及的内容更多，微服务架构、CI/CD基础设施、基础设施即代码、自动化测试、单一代码管理平台、交付流水线、A/B实验、混沌工程、依赖矩阵、智能监控、实时日志分析、满意度反馈平台等，如基于Jenkins 全过程自动调度的流水线、基于容器技术的研发/生成环境管理。

DevOps框架就可以简单描述如下图所示。
image.png
我们也可以看一下更为简单或企业应用的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框架如下所示，每一个域或核心元素都需要人、流程和工具的支持。
image.png
（基于CAMS模型的DevOps框架）
另外一个类似框架就是CALMS，它是评估公司采用DevOps流程能力的框架，也是衡量DevOps转型期间成功与否的一种方式。这个缩写是由The DevOps Handbook的作者之一Jez Humble创造的，代表文化、自动化、精益、度量和分享，也只是比CAMS多了一个精益（Lean）。

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

image.png

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

    参考：