从优秀到卓越，2020，DevOps 路在何方

字数 5630阅读 10010评论 0赞 6

## 一、DevOps 的起源

DevOps 的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois，他喜欢从各个角度研究IT组织。2007年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中，他负责测试和验证工作。所以他不光要和开发团队（Dev）一起工作，也要和运维团队（Ops）一起工作。

他第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作氛围的切换令他十分沮丧。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异：开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者，他渐渐的明白如何在这种状况下改进自己的工作。

## 二、DevOps 的初期困局

从 DevOps 发展的前十年，一直不温不火，究其原因，众说纷纭。根据近几年的DevOps发展报告的数据统计，不难看出DevOps发展初期的困局。

文化基因 ，DevOps 是一种文化，不仅仅是角色这么简单，推进DevOps需要高级领导层的支持，也需要和最终产品相关的所有人参与。DevOps的覆盖面不仅仅是开发、运维和测试部门，基于IT人员的思维局限性，能效和质量提高仅仅依靠基础架构的演进和代码质量的提升是全局意识的文化缺失。

DevOps 概念的不健全 ，DevOps发展初期，对于软件开发领域来说，只是个小众产品，容器技术还没有横空出世，虚拟化是主流。在资源输出方面，重资产大行其道，应用规模方面，巨石应用比比皆是。

ITIL的理念深入人心 ，在运维领域，ITIL和DevOps的冲突由来已久，在二者产品和思维两点尤为突出。ITIL在产品上以流程为核心目标的设计，很难满足自动化的要求，DevOps极力推崇工具、平台、自服务文化；理念也是如此，ITIL以流程为先介入到一个企业的IT过程。本质上来说，这两者不是同一个东西，但聚焦到降本增效领域，二者截然不同。

DevOps 聚焦存在滞后 ，DevOps发展初期，互联网企业的规模普遍偏小，DevOps聚焦的点也过于狭窄，随着互联网对传统企业的冲击，IT人员对于DevOps的理解也显然慢了半拍。企业IT的精益运营不仅仅是为了IT的降本增效，根本目的是为了更快的交付，提升业务的创新和试错能力。

开源的困惑 ，在那个时候，开源软件还处在要怎么样让别人自由使用的同时而得到报酬，开源项目主要是在替代现成的产品，并没有成为解决方案的一部分。在那个时候，开源对DevOps的支持还不够，因此，开源软件第一个十年成为DevOps发展很大的制约。

## 三、DevOps 的本质

DevOps是什么？从概念上说，DevOps是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。

概念有了，怎么落地？很多公司在实施容器云时实现CI（Continuous Integration，持续集成），或者CI/CD（Continuous Integration/Continuous Delivery or Deployment， 持续集成/持续交付 or 持续部署）就叫DevOps。笔者觉得这只是实现DevOps的一部分，但不等于DevOps，那DevOps的本质究竟是什么。

* 回归DevOps的本源 ，DevOps的本源有两个阶段，其一为基于流程高效交付，其二为基于数据的交付反馈。在基于流程的高效交付方面，根据2019年的DevOps调查报告，全球近万家推进DevOps的IT公司的数据统计，达到基于流程的高效交付每年可以完成接近2000次的部署，在部署频次上相比较，提升接近200倍，产品投入的速度提升接近3000倍，服务恢复速度快30倍。基于流程的高效交付使公司产出的效率提高，同时工作质量得到提升。在基于数据的交付反馈方面，通过数据的度量，不断的优化高效交付过程中的问题和缺陷，从而确保数据反馈价值输出。对于软件交付来说，提高软件交付的质量和效率不是根本目标，而通过提升软件的价值交付，来促进产品达到商业目标才是最终的目标，从而实现DevOps研发运营一体化，从根本上提升 IT 的生产效率，加速部门、企业的业务创新能力。让团队从IT支撑部门，转向为IT创新部门，最终助推企业发展。

* 千人千面的 DevOps ，本质是人与信息的联姻。千人千面，是基于用户群的覆盖率，在DevOps的能力域中，大致分为项目管理、需求管理、资源管理、研发管理、测试管理、运维管理、成本管理。在以上能力域中，不同的用户群的视野对DevOps的理解也是不一样，因此在相关子域的推进过程中，会造成边界不明确和冲突。所以DevOps需要打通各能力子域之间的边界墙，各能力子域需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。

* DevOps 的投资回报 ，格局决定了结局。做 DevOps 的核心初衷是什么？大致有以下出发点，配置管理，构建与持续集成，测试管理，部署与发布管理，环境管理，数据管理，度量与反馈。基于流水线的需求，以上任意一个或多个节点都会构成流水线，通过过程管理和反馈达到效率和质量的提升。在企业级DevOps赋能（共促）计划所描述，为了更好地促进中国企业实现 组织级DevOps能力，打造一流的、端到端的 DevOps 持续交付流水线平台、提升组织效率与质量，让IT更好地支撑业务快速发展。因此DevOps的结局取决于项目的目标，对组织级的目标进行分解，大致分为两大类。其一，各能力子域的纵向管理，其二，各能力子域的横向管理。纵向集成，打通应用全生命周期（需求、设计、开发、编译、构建、测试、打包、发布、配置、监控等）的工具集成。纵向集成中DevOps强调的重点是跨工具链的自动化，最终实现全部人员的自助化。项目组的开发人员可以通过DevOps的平台上，自主申请开通需要的各种服务，比如开通开发环境、代码库等。横向集成，打通架构、开发、管理、运维等部门墙。横向集成中DevOps强调的重点是跨团队的线上协作，也即是通过IT系统，实现信息的精确传递。传统的系统上线部署方式，可能是一个冗长的说明文档，上百页都有可能，但在DevOps的平台下，就应该是通过标准运行环境的选择、环境配置的设置、部署流程的编排，实现数字化的部署手册，并且这样的手册，不仅操作人员可以理解，机器也能够执行，过程可以被追踪和审计。

## 四、DevOps 落地的必备条件

DevOps 落地的方式，大致有四种，以项目交付周期为全局的、以持续集成持续部署为延展的、以需求吞吐为度量的、以工程效率为基准的。在这四种方式中，各窗口期的服务输出方式各不相同，最终服务能力殊途同归，在此过程中，有以下必备条件。

1. 文化和组织，公司组织是否利于协作是关键。IT内部可以良好沟通互相学习，从而拥有高生产力。并且协作也存在于业务人员与IT人员之间。在产品交付期间，业务人员非常清楚他们希望在最小化可行产品中实现什么，IT人员就按需交付，不做多余工作。这样，IT人员使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。此外，DevOps对IT人员的个人的要求也是一种挑战，这也是DevOps文化。

1. 工具链的打通，工具链是自动化覆盖率的保证，而工具链的打通是DevOps成功与否的关键。基于工具链本身，逐步承建DevOps文化的落地，也是项目、需求、研发、运维、测试各能力域自动化的保障。工具链的打通，逐步构建以流程驱动的交付流水线，同样，工具链相关数据的落地，也将在流程驱动的同时实现数据度量，最终形成流程和数据双驱动的双轨模式。在此之中，工具的驾驭、工具的价值、工具的赋能、工具的本质是我们选择工具的基本方法。

1. 价值交付的流程，在价值交付体系中，各能力域发挥至关重要的作用，过程管理，流程先行。大致有以下流程，基于软件版本的全链路交付流程、基于快速交付的产品需求流程、基于持续发布的运维部署流程、基于自动化测试的质量体系流程、基于软件度量和成本复盘的后评价流程。

## 五、2020、DevOps 路在何方

（1）DevOps是衡量CMDB是否成功的重要方式 CMDB的核心功能大致分为数据采集、数据管理、数据输出服务，在过往的评判标准中，CMDB的成功与否更关注于数据的自动采集、数据时效性准确率和可视化。现在，对于资源容量管理和资源数据输出已上升到新的高度，由基于IT的资源管理上升基于业务的资源管理，由应用驱动上升到业务驱动，因此CMDB是否成功取决于基础数据和业务架构视图对DevOps的支撑是否足够。

（2）DevOps 逐渐回归本质 在最新的定义中，DevOps 的本质越来越纯粹，提升组织级的能效和质量。在过去几年，DevOps的本质是敏捷，现在，DevOps随着云计算、大数据、人工智能的新兴技术的助推，由提升IT支持能力到提升IT管理能力。在未来，DevOps会紧扣“组织级”的范畴，通过价值交付，助推企业发展，着力于IT的降本增效，才不会被管理者所抛弃。

（3）AI对于DevOps的赋能，蜜糖还是毒药？ 在AI和DevOps相遇的时候，DevOps进入了弱人工智能的时代。在DevOps领域，场景适配成了新的难题，除了告警抑制、服务自愈、资源计算等场景外，很难再开辟新的战场，因此在很长的一段时间内，人类会把一部分偏数据场景的运维工作交给AI，同时去创造一些新的运维工作。因此摆在面前的有两个难题，场景门槛和数据门槛，在业务连续性的红线面前，AI对DevOps的赋能，是蜜糖、毒药，还是最后的一地鸡毛？

（4）DevOps 的趋势是成为服务目录门户 服务目录门户对于业务的价值在不断的攀升，业务需要一个关于IT服务的统一数据源，同时确保业务的不同视野可以查看IT服务各模块详细信息和状态，最重要的是业务需要自助式预定IT服务的各项功能和视图，包括成本复盘和利润预测。这与DevOps的度量优化和打通部门墙的理念一致，DevOps在未来需要覆盖更多的受众人群，成为服务目录门户是大势所趋。

（5）DevOps 也需要傍数据中台 近年来，中台概念越演越烈，业务服务、数据服务、基础共享服务逐渐成为中台的核心场景。作为数据中台，承担了企业数据的汇聚联通、数据治理和数据资产的消费升级，这与DevOps的未来方向不谋而合，随着DevOps数据驱动时代的来临，在数据度量和反馈优化方面的发力，需要碰瓷数据中台，蹭一波热度。

（6）DevOps 是否爆发式成长取决于企业领导是否赋予研发人员更多的话语权 随着O2O融合，线上业务在企业的占比越来越高，越来越多的业务增长越来越依赖科技，而研发人员作为IT利润中心的主力军，在过往的DevOps的最佳实践中对话还不够强烈。因此研发人员分享对DevOps的见解，传递对DevOps的实践，成为DevOps是否再次爆发性增长的关键因素，实现此目的取决于企业领导是否赋予研发人员更多的话语权。

（7）自动化已经逐渐脱离 DevOps 的范畴 根据《企业IT运维发展白皮书》所述，IT工具发展已经经历过手工、自动化、平台化的阶段，逐步进入DevOps阶段。从国外相关统计数据来看,传统企业对于DevOps的接受程度比互联网企业还要广，随着传统企业纷纷踏足DevOps领域，同时创业公司普遍选择业务上云服务，因此自动化已逐渐脱离DevOps的范畴。

（8）没有度量的 DevOps 即将沦为鸡肋 通过质量内建确保软件交付的质量，通过对过程性数据的持续收集和分析发现交付过程中存在的瓶颈，通过对软件产品和用户的线上数据获取反馈并且及时作出调整，通过结果性数据去评价团队的成效，来打造和构建度量体系。没有度量，意味着只有流程驱动，没有度量，意味着事中和事后的风险无法掌控。因此，缺乏度量将导致无法管理和优化，DevOps即将沦为鸡肋。

（9）CICD 流水线已不再是潮流 在很多企业，CICD依然没有解决开发、运维、质量来保证部门之间的协作和整合。职责依然没有划分清楚，而且目前的容器云CICD流水线设计，不足以支撑企业生产环境部署要求。更多像是POC概念验证阶段，这也是为什么很多公司即便采用容器云也只是在开发测试环境使用的原因。除此之外，全链路交付流水线已成为更多受众人员关注的点，CICD已不再是潮流。

（10）成本复盘将成为 DevOps 的新方向 成本复盘是财务的重要指标，在软件交付领域，成本复盘是判断人力资源、软硬件资源的投入和产品运营后的产出对比，也是判断项目或产品的成功与否，更是从较高的视野来进行项目和产品优化的重要手段。在DevOps达到数据驱动和度量反馈阶段，基于成本复盘能够从IT的角度实现投入产出比的数据化展现，通过全局的优化来实现组织级的能效和质量的提升。因此成本复盘将成为DevOps的新方向。

（11）SEC 成为 DevOps 爆发式发展的另一道鸿沟 DevOps 和安全性是软件组织的首要考虑因素，缺乏安全性的软件将会成为业务连续性的根本性障碍，同时也会为企业带来灭顶之灾。在大部分互联网企业，把运营安全团队和运维安全团队放在一起，于是出现了根本性的冲突。敏捷和安全的冲突、发现漏洞和回归测试的冲突、传统安全和新兴安全的冲突、安全角色主动入侵和被动入侵的冲突，最为主要的安全漏洞的不确定性导致延迟发布成为最大的导火索。因此，不解决以上问题，SEC将成为DevOps爆发式发展的另一道鸿沟。

CMDB 自动化运维 DevOps

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

从优秀到卓越，2020，DevOps 路在何方

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料