从我们的视角谈DevOps

DevOps源于Development和Operations的组合

常见的定义

DevOps是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

下面这个戴明环也是常见的表达形式：

在深度实践DevOps后，结合对DevOps理解和经验总结，重新定义了DevOps。即下图这6个英文单词的首字母组成：

Do、Efficiency、Value、Open、Progress、Security。

结合这六个词、结合我们产品团队在今年6月我们DevOps活动上的分享以及个人理解，我们将从我们的视角展开来谈谈DevOps：

Do实践：以实践为基础推行DevOps

DevOps文化、理论体系的宣导者众多，各种大会也会去介绍各种“道、法、术”；大一些的企业基本都会有设立教练的角色，指导各个研发团队开展DevOps转型。但一些企业用户在听完各种“道、法、术”之后，要么是讲的听不懂，要么是懂也不会做、做也做不好。也有企业先找咨询公司做咨询，但咨询完后却不知道怎么落地。

我们认为DevOps的第一要素，就是实践，即所谓的“事上练”。没有实践过DevOps的经历就没有感悟，谈论再多的文化、理论，还不如贴近业务研发痛点，动手行动，用实践来验证想法和理论，点滴积累，绘成逐渐强大的DevOps体系。

Efficiency效能：效能是DevOps追求的目标

在我们开展实践之后，需要有目标。DevOps 根本的目标就是提升研发效能。

首先，效能体现在可以让大家可以“Focus On Your Job”。开发人员的职责是写代码和合并代码，合并代码完就去抽烟，其他的交给平台自动化执行；而不是去推动打包、申请资源、部署、测试、生产上线。

其次，效能体现在可以让大家在同一套平台中进行工作和协同，而不是在不同的工具中做不同的事情。一个企业IT部门有18套研发、测试、运维工具，这代表先进还是落后呢？很显然，这是一种落后的表现，因为这几乎将无法实现跨系统自动调度。我们DevOps平台可以将DevOps工具链进行整合，让不同的角色专注于其本职工作，达到提升效能的目标。

Value价值：DevOps必须输出价值

DevOps要为用户不断的输出价值，就要为DevOps体系中融入更多的提供价值的功能。例如：

• 在DevOps平台中加入质量红线，可以提供给用户来建立各种质量门禁，如：代码准入门禁、迭代验收门禁、发布控制门禁；

• 在DevOps平台中提供编译加速，帮助用户提升编译的性能；

• 在DevOps平台中提供构建资源池，在构建的时候可以自动调度构建资源，完成构建之后可以自动释放资源等等；

• 在DevOps平台中优化流水线的体验和原子，用户可以轻松组装出来各种复杂的业务场景……

价值也应该是可以复制的，企业通常有多个团队同时开展多个项目，我们对某个项目团队进行了大量DevOps方面的改进，并邀请工信部对项目进行了DevOps能力成熟度评级，我们团队达到了3级。但是，其他的项目或团队呢？他们能否达到3级标准？我们在DevOps方面做出的努力，是否可以平行复制到其他团队？

我们DevOps有一个理念是——价值应被平行复制到各个项目团队。每一个价值点的输出，都可以让用户真正的感受到DevOps所能带来的改变，这样才能把用户凝聚在平台上，而不是总是考虑哪里用得不顺，自己建立一套平台。我们DevOps带来的体系完善、效能提升，不是针对某个团队，而是可以平行复制到所有的研发团队，这就是最大的价值。

Open开放：以开放的心态面对各种场景

不同的企业甚至同一家企业的不同团队，其DevOps落地的进程和对DevOps的要求都有差异的，我们必须用开放的心态接受这种差异。

例如：我们DevOps平台里面有敏捷协同模块，可以管理项目的需求、任务、缺陷、迭代计划等等，但是许多传统行业，基于企业的研发管控制度等原因，已经建立了适合自己的需求管理平台、研发任务管理平台等工具平台，我们的解决方案是不断给用户洗脑让用户放弃现有的协同和管理模式，还是以开放的心态来面对客户现有的管理体系呢？

我们的选择是以开放的体系面对不同团队的需求，提供尽可能灵活的架构和工具，通过工具开放的方式来兼容不同团队的模式。我们本身也是面向CI-CD-CO的研运一体化平台。

Progress演进：持续交付核心在于不断演进

DevOps的一个重要理念就在于持续改进。我们可以通过各个子系统的数据进行整体的度量，来发现哪个项目、哪些环节经常出现停滞、失败率比较高、耗时比较长，并且进行针对性的改进。

例如：如果研发效能瓶颈在测试环节，就需要深究导致测试耗时长的问题。如果是因为没有引入自动化的测试、手工测试耗时较长，就可以逐步补充自动化测试用例；如果研发效能瓶颈需要人工响应才能推进，就可以引入自动化的流水线和优化研发流程，减少人工参与和不必要的审核节点。

只有通过不断的改进，企业才能将原来的每月迭代和发布，缩短为每周迭代和发布，甚至逐步改进为每天迭代和发布，最终达到Google、FaceBook等企业达到的1天若干次发布的效果。

各个团队可以跟自己比，每一阶段都相比前一阶段有进步，就是团队的自我发展。而我们DevOps平台也是不断演进的成果。

Security安全：安全是基础

一个企业级的DevOps平台，安全是非常重要的。研发人员电脑、代码库、构建机、测试环境、制品库都可能导致代码及软件包的泄露，这也导致游戏行业大量私服的出现。而软件上线之后还要考虑漏洞被利用、跨站***、数据窃取等等问题。

不论DevOps平台本身，还是从平台流出的制品，一切要以安全为依归。DevOps平台本身应该提供监、管、控手段，可以进行细粒度的权限控制，避免非法访问和非法窃取数据、代码、软件包。DevOps平台也应该提供代码扫描、安全扫描、质量红线等安全工具，可以独立运行或者结合到流水线里面自动调用，保证交付的软件的可靠性，给平台使用者以及产出软件的用户一个安全保障。

作者：方勇