DevOps绞杀者之路

作者简介：

景韵
乐视配置管理工程师
目前担任乐视致新 SCM 组配置管理工程师，从事持续交付工程与技术工作。曾任职于用友网络，负责用友集团 DevOps 的整体推进并主导 DevOps 体系搭建，Certificated DevOps Master。

1、缘起

我在2016年底在高效运维公众号投稿了一篇文章《从实践中长出的 DevOps 大树》，想要告诉大家做 DevOps 可以从实践入手，大家留言给了很多反馈。

总的来说，大家还是觉得没有思路，而且需要有一定的级别才能推动 DevOps 落地。所以我才提出 DevOps 绞杀者的思路，希望进一步告诉大家应该怎么在企业中落地 DevOps。

2、大纲

今天的分享主要想跟大家讲三件事：

一是为什么 DevOps 在很多同学看来那么难；
二是绞杀者到底是什么以及怎么做；
三是我关于 DevOps 推进的思考；

3、为什么难？

我们很多人在面对 DevOps 时就像这个小孩拿着一个很大的苹果，无从下口，原因是什么？
DevOps 太大了，以至于无从下手。无论是 DevOps 的概念还是 DevOps 知识体系，涉及内容、角色都非常多。

关于维基百科上 DevOps 的概念，True But Useless。看完之后依然不知道 DevOps 是什么，怎么做？但是至少可以告诉我们，DevOps 是很复杂的，涉及的角色很多，要达到的目标也很高大上。

DevOps 和原来的软件开发过程明显的差别就在于将运维纳入到整个软件交付过程，这也就是我们说的源于敏捷，高于敏捷：

在瀑布模式下，开发、测试、运维被部门墙隔开，井水不犯河水，严格按照移交和签收的方式工作，软件的交付周期非常长。价值的交付总在最后一刻，往往已经过去几个月，客户的需求可能已经发生变化，市场已经被竞争对手占领，客户已经流失。

在敏捷模式下，开发和测试相亲相爱，但是运维依然在墙那头，即便开发和测试敏捷玩出花来，每个迭代都产出，但是运维依然有自己的节奏。价值交付的时刻依然没有改变。

在 DevOps 模式下，开发、测试、运维三角关系最稳定，联合起来支持业务。每个迭代都可以部署上线一次甚至多次，价值交付在持续的产生，客户的需求在持续得到满足。

除了涉及的角色多以外，DevOps 的知识体系也非常复杂。精益管理和TPS是基础，敏捷管理、持续交付、IT服务管理都囊括其中。

图中有两个点希望大家一定要重视：

在整个阶段的划分中，没有测试。并不是说测试不重要，而是说测试已经变成一种能力，内建于各个环节，无处不在。用户故事的验收条件（AC），TDD，持续交付流水线中的自动化测试等等。
敏捷管理的英文原文是 Disciplined Agile，规范或者纪律性的敏捷才有意义，纪律是什么？每日站会只回答三个问题，不迟到，不延时。持续集成被破坏要第一时间修复。这就是纪律，是需要团队承诺并坚持的。

大家从 DevOps 的知识体系可以看出来，DevOps 是一个集大成者，它并不生产概念，它只是大自然的搬运工

DevOps 是丰田生产系统（TPS）在软件及互联网领域的应用；
DevOps 是精益思想、精益创业工程化的应用；
DevOps 是敏捷端到端的应用；
DevOps 是 ITIL/ITSM 轻量级的应用；

以上几点大家可以看出来 DevOps is too big to start.那我们怎么办呢？这就是接下来重点说明的绞杀模式。

4、绞杀模式

这种植物在热带很常见，分为绞杀植物和被绞杀植物。绞杀植物一般是榕树，随着飞鸟将绞杀植物的种子带到树干上，种子就开始生根发芽，长进树干，靠着绞杀植物的营养生存，不断生长垂下来长进土壤里，自己获取养分，将原来的植物绞死，形成独木成林的景象。这就是绞杀现象

我认为 DevOps 在企业中的落地是一条在文化守护下的绞杀者之路，通过单点突破，多点开花的方式，逐渐将现有的不好的做法绞杀掉，最终形成 DevOps 的大树。

绞杀现象里长出的根叫做气生根，我认为每个气生根就是我们的实践点，那我们做 DevOps 的实践分布或者说 DevOps 能力模型是什么样的呢？这是我之前在用友梳理的 DevOps 能力模型，后来参加 DevOps Master 培训逐渐进行了完善。

我认为DevOps能力模型划分为这几个维度：

组织文化：良好的组织文化是基础，至少能接受大家有变化，Westrum将组织划分为病态型、官僚型、生机型可以很好的衡量组织的文化状态。文化能守护大家做好DevOps，反过来，实践也是会影响文化的。比如持续集成就能建立团队良好的质量意识。

可视化：核心是要可视化/度量整个交付过程的效率和质量，比如Kanban可视化整个工作流和当前状态。技术债务度量可以帮助团队定向降低债务，这也是度量驱动开发/改进的基础。

敏捷研发、持续交付、技术运营是按照软件交付过程划分的。其中持续交付是核心工程实践，是驱动力。

如果是手上资源非常少，那建议从持续交付做起，持续交付开发可以做、测试可以做、运维也可以做，当然还有专业的配置管理或者工程效率团队也可以做。

后边想基于持续交付的一个案例分享乐视的实践。

Build-Test-Promotion实践案例

乐视智能硬件主要包括电视、手机、汽车等相关业务，基于Android开发EUI系统。UI系统的持续交付做法和互联网业务略有差异，成本也相对较高。

之前的情况是：

一天做一次 DailyBuild，做一次自动化+手工测试，每次编译耗时都在1小时以上，对编译服务器的资源消耗也较高，失败的成本高，反馈周期很长，开发完的代码可能要明天才能获取到是否能编译通过或者测试通过的反馈。核心功能的自动化测试不是持续的，质量没保障。

所以我们内部尝试采用DevOps和持续交付的理念和实践去改善这个过程，示意图如下：

我们每两个小时进行一次编译打包+自动化测试，持续的验证质量。具体的流程设计图如下：

质量门是我们的核心实践，通过从研发到集成，再到QA的层层质量门控制，保证质量，这也源于UI操作系统发布后的召回或者修复成本高于互联网业务，所以对质量的控制是非常严格和精益求精的。

以上就是我们的实践内容，我刚刚也提到 DevOps 需要文化的守护，这张图是乐视的生态价值观。我们这个实践需要研发、SCM、QA的密切支持和配合。

下边这边图是想要增强大家做 DevOps 的信心，Cloud Native 基金会整理出来的这么多工具和平台可以帮助大家落地 DevOps，你还怕什么呢？

5、思考

之前在用友的集团开发管理部负责推进用友集团的 DevOps 落地，有一些自己的思考和经验，分享给大家，希望能帮助大家在企业落地 DevOps 找到一些参考

我们在用友推进 DevOps 分为这几块工作：

建立共识，老板说要尝试 DevOps，我们会去就概念、DevOps 的范围、意义进行定义达成共识，DevOps 在当时的用友就是要解决最后一公里的问题。同时我们也要分析公司内外的机遇是什么？基础是什么？敏捷的多年推进是非常好的基础。还有就是团队有没有真正的痛点，不能无病呻吟吧。
建立社区，人多力量大。DevOps 很复杂，不是单个部门能做的，我们号召集团内最顶尖的架构师、运维专家、敏捷和持续交付专家成立了内部的 DevOps 社区，共同推进。大家对实践分享复用，相互帮助达成了一致
持续分享，在社区的基础上，持续的分享工程实践和工具平台来形成经验的共享和复用。可以帮助其他团队快速搭建起自己的系统。比如 ELK 日志平台，一个团队分享完，其他团队就可以复用经验，并且改进适配后搭建自己的平台。
建立体系，单点的实践改进效果有限，我们希望更多的角色和团队参与其中，所以编写了 DevOps 指南，从理念、过程、实践、工程四个维度详细说明 DevOps 及落地做法。
建立路线图，有了体系之后，我们梳理了可能的工程实践路线图，输出到团队和内部社区，帮助大家打开思路，找到方向
每个方法下的具体内容如图所示：

最后，我想说，DevOps 不一定非得从顶层设计开始，只要大家在各自的岗位上实践 DevOps，从小事，当前的事做起，不断的绞杀现有的模式，终有一天，会形成长出自己的 DevOps 参天大树。