DevOps 之精益思维

在与很多的公司聊DevOps的时候，大多数公司都说“已经实现了DevOps”。再往下聊，发现这些企业对“实现了DevOps”的理解是在于已经使用Jenkins实现了流水线。是的，在大多数人的概念中，DevOps已经和Jenkins之类的流水线工具划上了等号。

DevOps定义和重心的发展和演变

“DevOps是一组过程、方法与系统的统称”，但我们也不用拘泥于概念，因为每年DevOps权威组织对DevOps的定义或者对DevOps所关注的重心都在发生变化。

我们来看看DevOps定义的发展变化：

2008年

还没有人提出这个DevOps名词，只是强调需要敏捷架构。

2009年

DevOps第一次被提出来，被定义为开发运维一体化。

2010年

DevOps的概念被明确为“一组过程、方法与系统的统称。用于促进开发、技术运营和质量保障之间的沟通、协作与整合”。

2011年

DevOps被定义为“一种强调Dev和Ops之间沟通合作的文化、运动或惯例”。通过自动化式的交付与变更流程，使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

2016年

DevOps被定义为旨在统一开发和运维的一种软件工程文化和实践。目标是：

• 与业务目标保持一致

• 更短的开发周期

• 更高的部署频率

• 更可靠的软件发布

2017年

兴起的DevOps运动，强调了DevOps的重心——“将软件建设的所有环节进行自动化&全面监控”。

精益是DevOps发展的必然途径

开发过程为什么难以衡量？

实现“与业务目标保持一致、更短的开发周期、更高的部署频率、更可靠的软件发布”，这一持续交付的目标肯定是无比正确的。但是我们如何达到朝着这个目标靠近呢？

来看看这些问题：

• 从需求被接收到交付上线，通常需要多少时间？
• 这个时间是否是合理的、能不能被继续压缩、压缩会不会带来质量的问题？
• 开发、测试、发布整个流程哪个环节是瓶颈？
• 开发人员和测试人员的合理配比应该是多少？
• 我们的测试覆盖率是多少？
• 我们的发布成功率算高还是算低？
• 我们要从哪里开始改进/如何去改进？
• ……

貌似这些问题大多难回答，你会说基本上都比较难以衡量啊！在没有数据支撑决策的时候，我们更多的是凭直觉来进行衡量，根据过去的认知、现有的经验来进行管理和优化。

世界上没有任何事物是不能被衡量的。

所有看似无法量化的难题，

只要能让你知道得比以前多， 就是一项成功的衡量。

——道格拉斯‧哈伯德

之所以无法衡量，主要的原因是大部分企业所实现的流水线只是一个流程执行的黑匣子，DevOps整个业务链条的过程无法被覆盖，过程数据没有被记录、收集和分析，我们缺乏数据的支撑。

需要DevOps的表面原因

将软件建设的所有环节自动化，以达到持续、正确、快速，这也是为了DevOps的根本目标。通过尽量减少人的参与，让计算机按照预定义的检查和处理逻辑执行，以工业化的方式减少了人工操作导致的响应等待时间，同时也减少因为人为疏忽导致的错误。

将软件建设的所有环节进行全面监控，可以发现自动化各个流程节点中产生的告警和异常，需要人为进行确认是否可以被忽略，或者需要干预处理。例如：代码扫描发现了开发人员拷贝代码的问题，单元测试发现有测试不通过的问题等等。

上面这两点，我认为只是 “将软件建设的所有环节进行自动化&全面监控”的表面原因。

精益是DevOps的灵魂

“将软件建设的所有环节进行自动化&全面监控”有更重要的任务，那就是通过自动化和全面监控，全面自动记录或收集软件建设过程的数据，这些数据接下来可以发挥巨大的价值——发现持持续交付的过程中，哪些环节存在浪费或者风险，然后进行持续优化。

这就是我们所谓的精益。

通过统一的DevOps平台，对软件建设的过程数据进行收集和监控，然后以直观的精益看板的形式展现，我们可以更容易发现问题、分析问题、解决问题。只有精益求精，整个团队共同协作、持续改进，才能让我们的软件持续交付更快、更稳、更强，达到“与业务目标保持一致、更短的开发周期、更高的部署频率、更可靠的软件发布”。

这就是我所理解的DevOps “精益”思维。

在我规划DevOps产品的时候，我认为精益是DevOps的灵魂。而大多数的企业和DevOps产品并没有重视“精益”，我以为我是孤独者。

直到拜读了一位60多岁的中国台湾资深敏捷开发咨询师李智桦写的书，才发现我的思路还是有同道中人的。而且李老不只是同道，甚至是远远的走在了前面、能提供方法论的导师。

例如，李老画的这一个看板就能体现出来的非常多信息量：

嘉维蓝鲸的DevOps理念

一些企业把Jenkins的应用叫做DevOps。

不可否认，用Jenkins这个流水线工具，可以实现把集成或部署的任务组合为一个流程进行执行，加快了交付的效率。

一些厂商把自己的容器平台叫做DevOps。

不可否认，用容器交付应用，可以让部署和水平扩展的过程变得更简单、更快，也加快了交付的效率。

如果以够用就好的心态来看待，那么恭喜你达到了DevOps的初级阶段。

但是，Jenkins 不是DevOps平台，只能帮你把各个任务连接到一起执行；容器就更不是DevOps平台了，它只是帮助实现应用更容易的部署和扩展的技术。至于协作、精益、持续改进，都不是他们所考虑的问题。

嘉为科技与腾讯蓝鲸一起，在蓝鲸平台之上开发了DevOps社区版并集成于蓝鲸平台社区版，作为CI/CD组件；然后在DevOps社区版的基础上，又继续研发更强大的嘉维蓝鲸DevOps企业版。

嘉维蓝鲸DevOps平台在企业的软件或者功能还是需求的时候就开始记录和跟踪，直到最后的交付和运维，持续优化，提供了全业务链的业务及改进支撑。

嘉维蓝鲸DevOps产品体系架构

最后，再与大家分享一下我们做DevOps产品的几个重大的理念：

01 融合

提供覆盖软件建设全业务链的DevOps平台，在统一的平台上，融合对协作、开发、测试、运维的工作管理支持，同时收集和记录DevOps业务链的过程数据。而不是团队各个角色分散用自己的工具，导致无法监控，也无法获得用于改进的数据。

02 集成

集成腾讯蓝鲸平台强大的自动化运维组件，并重新按照项目进行组织，提供的不再是底层的工具，而是DevOps业务平台的交付和运维功能。每一个集成进来的蓝鲸组件，例如：CMDB、监控平台、故障自愈、标准运维、管控平台等都是业界领先的，为用户提供强大的管理和扩展能力。

03 精益

通过收集和监控各个组件、各个过程的执行数据，提供直观的精益看板进行展示，作为企业持续改进的依据，能帮助企业发现目前项目或研发团队存在的问题，持续改进DevOps团队生产和交付，最大化体现DevOps的价值。