在当今的信息化、数字化、网络化和智能化时代，企业数字化转型势不可挡。作为支撑企业 IT 运营的基石，运营体系也正向多元化发展。DevOps（研发运营一体化）、Ops（智能运维）、DataOps（数据研发运营一体化）、MLOps（机器学习研发运营一体化）、BizDevOps（业务研发运营一体化）和 FinOps（云财务运营）等概念层出不穷，逐渐形成覆盖研发一体化、研发效能度量、安全体系建设、智能化和 IT 资源财务运营等多个方面的 XOps 体系。本文将重点探讨 DevOps 的相关知识。

背景

随着大数据、人工智能、云计算、数字孪生、物联网和区块链等新一代数字技术的应用，企业业务亟需构建持续化、端到端的运营体系，以推动新技术、新业务和新业态的发展。企业 IT 管理面临着以下三个挑战：

• 业务需求变化快，IT 响应速度难以跟上。
• 新技术应用落地难，无法发挥其应有的价值。
• IT 资源利用率低，成本居高不下。

因此，企业 IT 管理迫切需要探索新技术、新方法和新模式，以提升需求响应速度，加强技术深入应用和迭代能力，最终实现业务价值。

发展历程（DevOps->XOps）

整体而言，企业 IT 运营管理对象可分为七层：战略与规划、业务管理、财务与成本、数据生命周期、机器学习工程、软件生命周期和基础设施运行。在战略与规划层面，自 2009 年 DevOps 被首次提出以来，相继在不同领域的面向对象中诞生了创新应用体系。如下图所示，DevOps 在企业应用中的成熟度最高，其次是 AIOps 和MLOps、DataOps，而近年来，企业更关注成本和业务创新，BizDevOps 和 FinOps 也进入企业重点关注和落地范围。

尽管 XOps 各领域的关注对象不同，但它们都以文化、组织和流程三个维度贯穿多个流程领域。在提升效率的同时，XOps 也注重提高质量，并强调持续优化和改进。对于人员意识的培养、组织的协同能力和流程闭环的管理与持续反馈，XOps 都至关重要。

什么是 DevOps

维基百科：DevOps（Development 和 Operations 的组合词）是一组将软件开发（Dev）和 IT 运营（Ops）实践相结合的原则，其目的是缩短软件开发生命周期并持续交付高质量的软件。

谷歌云：谷歌云认为 DevOps 旨在提高软件交付速度，提升服务可靠性，并在软件利益相关者之间构建共享所有权的一种组织和文化运动。

AWS：AWS 将 DevOps 定义为集文化理念、实践和工具于一体，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，DevOps 能够帮助组织更快地发展和改进产品。

Gartner：Gartner 认为 DevOps 是一种使用敏捷方法、协作和自动化交付解决方案的业务驱动方法。

从业界对 DevOps 的定义中可以看出，DevOps 不仅是一种技术，更是一套涉及文化、组织、流程和系统的综合实践。DevOps 通过打破研发、测试和运维之间的信息壁垒，改善团队之间的合作关系，并自动化、敏捷化和一体化软件交付和架构变更流程，实现更加便捷、频繁和可靠的软件发布。

笔者观点：DevOps 是一种交付方式，其涉及技术、工具、文化和组织多个环节的实践方法。如下图所示，笔者对 DevOps 的理解更加直观和简洁。

DevOps 的价值和发展趋势

随着近年来 DevOps 在企业应用中的成熟度越来越高，一些文章开始宣称 DevOps 已死。笔者认为这是一种误导性的说法。就像为了推广微服务而出现的对单体架构的贬低言论，或是推广敏捷而踩低瀑布开发一样，在不同的业务领域、业务复杂度、公司组织结构和企业 IT 基础设施等多方面维度，都会影响对 DevOps 的决策。如上文所述，DevOps 是一种交付方式，只有适不适合，没有死不死的说法。

接下来，我们探讨一下 DevOps 的价值和发展趋势。根据 IDC 报告显示，2022 年全球 DevOps 市场规模预计将达到 138 亿美元，到 2026 年将增至 320 亿美元。这表明 DevOps 正在成为企业数字化转型中不可或缺的一部分。

DevOps 的主要价值包括：

• 缩短软件开发生命周期
• 提升软件质量和可靠性
• 提高团队协作效率

DevOps的设计实践

起初对于DevOps的概念的理解仅仅停留在“使用Bamboo自动化部署服务到指定环境上”，当我们开始尝试着对DevOps的流程开始做推广，首先确定的方案是，推动各组使用Bamboo做CI/CD的集成，第二是针对当前项目面临管理混乱的痛点问题，进行项目发版采用语义化版本管理。但正如康威定律所言，“设计系统的组织其产生的设计等价于组织间的沟通结构。”，我们不能仅仅在一次讨论中确定的方案就企图变革组织间的长达几年的沟通协作习惯。并且DevOps也不简单是一个普适的解决方案，它是一个 平台（Platform）、流程（Process）和人（People）的有机整合。

根据 martinfowler博客 中发表的对DevOps文化的见解（如下图），他认为DevOps文化中最重要的原则是 责任共担和质量导向 。在这点上，我认为我司有天然的优势，在项目开展的初期，包括当前项目运行生命周期中，研发包揽了大部分运维工作。可以说我们不从来不缺敢于担责的“勇士”。但同时，在我司大幅扩招的现状中，加强流程管理，保证这种文化的延续，同时在人员流动中能动态的加强文化导向，这是DevOps指导思想中重要的一环。

工具 = 平台+ 流程，首先，平台最重大的意义是承载企业内部的标准化流程，平台固化的每种流程，都可以用来解决某些实际问题，这样就会形成一下特征：

通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。

任何方法论不结合企业实际的现状来分析都是耍流氓（无处不在的康威定律），那么对于我司的实际现状，建立这一套体系能解决哪些问题呢？在和研发童鞋讨论问题的时候，能看到他们往往是处于只见树木不见森林的状态，整个“森林”往往是被少数的人所掌握的，这点在季度述职时候已经被不少人提出来过。诚然我们作为安全公司，部分产品是敏感且需要保密的，但是从整个层次和架构来讲，我们需要适配一套流程，达到 对技术开放，对数据加密 ，安全的流程正是SecDevOps需要解决的问题。同时这也很切合“三步工作法”中 流动 原则，只有 把复杂的流程简单化，可视化 我们才有机会让更多的人看见森林。而目前结合生态，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，DevOps作为软件工程的第三次革命，总结来看它的价值体现在以下两点：

让一切软件交付过程的手动环节，都是未来可以尝试进行优化的方向。DevOps倡导职责共担，持续改进是需要将规则内建于工具之中，并通过工具来指导实践。如果仅仅是把线下的流程搬到线上执行，是没法发挥DevOps真正的价值。说到底，工具没法解决人的问题，这样一条看似取巧的路径，却没法解决企业的根本问题。这时候，就需要文化闪亮登场了。 总而言之，DevOps 中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。我们要做的是 关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践。

敏捷管理不仅仅与研发敏捷，同时也要针对于业务敏捷， 开发更少的功能，聚焦用户价值，持续快速验证，就成了产品需求管理的核心思想。

另外通过“研发一体化流程”图示，我们也能见微知著。在我司目前在产品使用JIRA的看板形式做需求管理，这套流程在敏捷业务管理中已经有很好的天然优势， 我们需要做的是打通产品和开发的交流屏障 ，这部分流程以及功能，在我们的排期中暂时靠后，现未有具体实施方案，目前仅给出 BizDevOps 的核心理念：

关于持续交付功能，是初期内我们重点投入的阶段，这也是作为研发真正的用武之地，首先面临着第一个问题，自研OR开源？在我们开始做DevOps之前，已经有了部分在用的优秀开源工具作为支撑点，Jira、Bamboo、BitBucket。这些工具一定程度上减少了我们初期的工作量，在后续的项目计划中，我们做了基础存储，权限、DevOps流程等多方调研。关于存储和权限这类基础架构目前都有着成熟的开源解决方案。但是DevOps流程关联公司TOG的业务性质，以及目前的项目现状，我们选择自研平台，主要的规划方向有： 1.版本控制、变更管理 主要核心思想是： 版本变更标准化，将一切纳入版本控制，全流程可追溯和单一可信数据源。 ，一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。 2.持续构建和持续集成、部署与发布的模式 主要核心思想是：用自动化的方式完成从项目编译到发布的流程 3.环境的搭建管理、元数据、初始数据的管理 这是目前我们项目发布中的瓶颈，配置、初始化数据应当纳入版本控制，同时制定标准的业务流程； 4.度量与反馈 针对于交付效率、交付能力、交付质量做指标统计，以及建立可视化平台。主要的指标包括， 需求前置时间、开发前置时间、发布频率、发布前置时间、交付吞吐量、线上缺陷密度、线上缺陷分布 等。 5.内建质量、保证测试 内建质量有两个核心原则 ：

在为期近4个月的DevOps实践中，我们主要做了三件事情， 部分项目Bamboo的集成、基础架构的建设、DevOps平台的开发 。

初期我们做了一些关于DevOps的调研和实践，在 尽可能采用开源项目 的原则上，依赖于现有的技术结构，摸出了一套关于Bamboo的使用流程

开源OR自研？这永远是一个需要不断权衡和取舍问题，之前我们已经谈论到持续交付要做的事情有哪些，当开源组件不能Cover我们当下的流程，自研平台自然得上线了

基于上图我们可以看到FlowDevOps平台的基本的交互和流向。平台开发到现在经历了四个小版本的迭代，主要包含以下几个特性：

值得一提的是，我们选型了Jinja2作为配置模块统一管理，对各个环境公共组件的地址存放与平台，保证了服务离线部署中各类连接出错的问题。同时这种方式对业务的侵入较小，符合我们短期内提升部署效率的预期。

诚然，DevOps的建设在短期内已经做了不小的工作量，但是还是存在一定程度的问题。包括以下方面：

根据全球云计算峰会成熟度模型预估来看

在我司云原生于我们似乎是非常遥远的，陌生的技术栈，各类反直觉的故障。但是为什么我还是坚持认为云原生是我们未来建立DevOps，以及发展基础设计的最佳实践呢？引用CNCF对云原生的官方定义：

关键词有 开源软件、微服务应用、容器化部署和动态编排 ，虽然我们目前部分业务场景有传输相关的瓶颈，容器化则可能带来更大的存储体积。但从宏观角度来看，这并不是大部分项目的现状，而我们更多的项目核心的问题在于 数据量大、业务和配置复杂、依赖模块多 。而云原生应用天生就和DevOps 是绝配，自带高可用、易维护、高扩展、持续交付的光环，同时原生支持微服务、不可变基础设施以及服务网格这些技术领域，能天然解决业务复杂，依赖模块多的现状。 这也是我在基础设施建设工作中，坚持积累云原生技术方案的原因，云原生的技术方案，我始终认为它能大大推进我司效率建设和技术发展。即便我们在云原生的方案技术积累还不足够，比如还不能确认大数据在容器中运行的效率这类技术问题，但是当我们建设起更具效率的运营一体化流程，也就有更多的资本去进行试错，这片星辰大海等待我们去探索。

我们都期待完美，但在绝大多数时候，任何事情都不可能完美。软件更是如此，DevOps亦是如此。我们能做的就是基于每次的反馈，一点点的改进流程，一次次的反思提高。在不断的持续改进中，可能永远触及不到完美，但是就像美国著名女演员莉莉·汤姆林（Lily Tomlin）的那句经典名言所说的那样： The road to success is always under construction.（通往成功的道路，永远在建设之中） 。

Devops概述

目前在国外，互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、Microsoft、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。 那么DevOps究竟是怎样一回事？ DevOps一次词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。 DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。 不过需要澄清的一点是，从开发到运维，中间还有测试环节。 DevOps其实包含了三个部分：开发、测试和运维。 换句话说，DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。 专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。 由上所述，相信大家对DevOps有了一定的了解。 但是除了触及工具链之外，作为文化和技术的方法论，DevOps还需要公司在组织文化上的变革。 回顾软件行业的研发模式，可以发现大致有三个阶段：瀑布式开发、敏捷开发、DevOps。 DevOps早在九年前就有人提出来，但是，为什么这两年才开始受到越来越多的企业重视和时间呢？因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。 微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。 当今世界改变的速度已与过去不同，而每当经历一个颠覆性的技术革命时，都给这个世界带来了深刻的变化，大数据、云计算、人工智能、VR/AR和区块链等新兴技术推动着世界不断变化，如何应对这样一个VUCA时代，让我们能够在环境变化的时候快速响应呢？ 在些我引用了圣贤王阳明的一句名言，他提倡“知行合一”，通俗的讲就是做事情要理论与实践相结合。 我们在实现DevOps落地时也一定要遵循“理论与实践相结合”的方式进行，理论就是我们做事的指导思想，而实践就是具体做事的方法，接下来我就从我在公司中是如何按照理论与实践相结合来推动DevOps落实地。 首先我们还是要回到什么是DevOps，如果大家忘记了可以回到之前再温故一下，包括我总结的DevOps公式。 其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。 其基本原则如下： DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。 Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告中，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司可以完成平均每年1460次部署。 与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。 在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。 所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。 DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。 员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。 快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地相应。 而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。 因此，认为速度就意味着危险是一种偏见。 此外，滞后软件服务的发布也并不一定会完全地避免问题，在竞争日益激烈的IT行业，这反而可能错失了软件的发布时机。 技术的发展使得DevOps有了更多的配合。 早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。 DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack， Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。 IT行业已经越来越于市场的经济发展紧密挂钩，专家们认为IT将会有支持中心变成利润驱动中心。 事实上，这个变化已经开始了，这不仅体现在Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。 能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。 DevOps 2016年度报告给出了一个运维成本的计算公式： 而对于工程师而言，他们也是DevOps的受益者。 微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。 工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。 （You build it, you run it） 上文提到了工具链的打通，那么工具自然就需要做好准备。 现将工具类型及对应的不完全列举整理如下： 在工具的选择上，需要结合公司业务需求和技术团队情况而定。 （注：更多关于工具的详细介绍可以参见此文： 51 Best DevOps Tools for #DevOps Engineers ） DevOps成功与否，公司组织是否利于协作是关键。 开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。 并且协作也存在在业务人员与开发人员之间。 出席了ITV公司在2012年就开始落地DevOps，其通用平台主管Clark在2016年伦敦企业级DevOps峰会接受InfoQ了采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品中实现什么，工程师们就按需交付，不做多余工作。 这样，工程师们使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。 此外，DevOps对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。 DevOps正在增长，尤其是在大企业中：调查发现，DevOps的接受度有了显著提高。 74%的受访者已经接受了DevOps，而去年这一比例为66%。 目前，在81%的大企业开始接受DevOps，中小企业的接受度仅为70%。 那么具体而言都有些公司在采用DevOps呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛欧实时全额自动清算系统）、Walmart、Sony等等。 首先，大企业正在自下而上接受DevOps，其中业务单位或部门（31%）以及项目和团队（29%）已经实施DevOps。 不过，只有21%的大企业在整个公司范围内采用了DevOps。 其次，在工具层面上，DevOps工具的用量大幅激增。 Chef和Puppet依然是最常用的DevOps工具，使用率均为32%。 Docker是年增长率最快的工具，用量增长一倍以上。 Ansible的用量也有显著增加，使用率从10%翻倍至20%。 并且调查还发现不到半数（43%）的公司在使用诸如Chef、Puppet、Ansible或Salt等配置工具；然而使用配置工具的公司更有可能同时使用多个工具。 25%的受访者使用两种或更多配置工具，只使用一种工具的比例为18%。 其中Chef和Puppet是最常用的组合：使用Chef的组织中有67%同时也使用Puppet，类似的，使用Puppet的组织中也有67%同时使用了Chef。