今天我跟大家分享的话题是 “DevOps落地的关键要素”，分为三部分。
一、你的 DevOps 是什么样？

场景一、形式主义

之前我们在做 KPI 或 OKR 的时候，是不是经常会看到这样的字眼：我完成了多少需求、推进了多少业务线，虽说它也达到了量化，但这样做是否合理需要进一步的考量？其实在上线了多少个需求后，最终“解决了多少问题”才是最终的价值体现，而不是上线了多少需求。但这个结果，在整个绩效考核当中是没有人负责的，这是比较常见的场景。我们后续回到公司的时候，可以看看是否存在这样的问题，考虑一下要出于什么角度定 OKR 或 KPI。

场景二、心急火燎

我们在做整个 DevOps 实施或转型落地的时候，可能会定一个非常庞大的计划，声势造得特别大，但这不是 DevOps 真正要做的事情。我们可以把 DevOps 做一个不恰当的比喻，把它比喻成癌症的癌细胞，它要不断扩散。也就是说，从点到面，然后要成就面，这是 DevOps 本身的发展路径。而不是一上来就做一个宏观庞大的，一是见效速度非常慢，二是推广成本比较大。所以我们尽量做到，当前哪个点有问题，就优先解决哪个点的问题。

场景三、百家争鸣

这个问题我之前也遇到过，一个企业里有多个 DevOps 平台。什么原因产生的？比如一个比较狼性的企业，最开始说我们每个团队都可以做，谁做得好用谁的，到最后却变成了各玩各的。“有开始，没结束”开始的方向错了，导致一系列的问题产生，这也是 DevOps 里常见的问题。

场景四、混乱之墙

在企业内部，肯定有一些合作不顺畅的点。产生不顺畅的原因有很多，包括目标不一致性，例如开发跟运维，他们的目标完全是不一致的，一个要变，一个要稳，两方领导的做事方式不一样，目标不一样，想达成的结果也不一样。

场景五、盲目跟风

不是说别人做 DevOps，我们也跟着做。这个场景可能导致一个问题，荒废了很多人力，最终根本落不了地。总结一条我个人的建议：DevOps 的根基是什么？一定是出于解决某个问题的角度出发，而不是出于规划。DevOps 本身萌发的萌芽，就是你要解决企业内部的一个问题。

二、DevOps 落地要素

整体来说，落地要素就是组织结构、企业文化、人员能力、技术、工具平台等等，我挑出来了几个比较主要的因素，跟大家进行交流。

2.1 企业文化

企业文化到底是如何影响员工的？我经过很长时间的发现和总结，得出了一个结论：不同的行为影响产生不同的行为结果。在企业内部，你周边的人往往是对你影响最大的人，包括你的同事和领导。你的同事做事风格如果是好的、积极向上的，你大概率会跟他一样。如果你的同事比较闭塞，是合作不太顺畅的人，久而久之你也会受到影响，这是定律。

企业文化传承的有效途径，主要来自于“近亲”。企业文化的传承主要依靠主管的影响力，而不是全员都在做企业文化的宣传。这是我自己对企业文化的理解，比较小众。

2.2 工具建设

这是整个 DevOps 落地的关键节点。之前我听有人说过，工具建设不重要，企业文化更重要，组织结构更重要。DevOps领域里，没有什么东西是谁比谁更重要的，它们都同等重要。你把每一项都做好，你的DevOps结果就会很好。

DevOps 工具，有一个核心环节（CD过程），上线流程的每一块，都需要很细的点，不知道大家在内部的 DevOps 平台里做到什么样的方式，你们有定义过多少个规则？我见过的 DevOps 平台里的规则，比功能点还要多，整个标准化达到了非常高的程度，所以系统不需要做到那么复杂的程度，系统就是一个流程。

1、Plan。工具层面的计划挺简单的，需求管理跟最终的上线有一一对应的过程。相信现在大家都有电子看板的能力，电子看板有一个很有意思的点，可以松，可以紧，就看我们用到什么程度。当你做后续度量的时候，比较宽泛的看板能力可能满足不了你的度量要求，因为你规范不了用户的行为习惯。如果有企业在做类似于看板的系统，需要想想后续的度量要怎么做，有可能你要先做度量指标，再考虑看板，这是一种方式，这样可以规范看板里的功能点。可视化和可量化，就是整个需求管理的内容。

2、Code。代码管理是比较重要的，你说它简单，也很简单。说它复杂，也很复杂。说它简单，就是给用户开一个类似自由编译的入口，让他自己做编译就可以了，包括现在云厂商提供的工具，也是类似的概念。因为是通用型产品，所以提供的是通用型功能。

但是我们在企业内部做这个事情的时候，往往不会那么简单，我们需要在这个环节里加上一定的控制条件，保证代码的质量或者自动化程度能够进一步的提升。这里边的限制条件包括整个代码结构有没有做做规范性，比如某某文件应该做在哪、另外一点比如是否定义与业务匹配的分支模型等等。在我们内部的 DevOps 平台里，大部分都不会线上化管理分支，都是线下依靠开发人员遵守分支模型做线下规范性约束。

相关命名规范也很重要，这是自动化的前提，比如代码库名称、分支名称，都要有一个规则，规则有了才能在系统上自动化。

完善的校验机制，这个也很重要，不知道多少人在做代码编译之前会做一系列的检查？包括代码结构的检查，包括配置文件的检查，大家可以考虑一下，在编译前要做哪些合规性的校验检查。

3、Build。

统一编译环境，对 DevOps 一体化成熟度模型熟悉的同学都知道，“标准8”有一个系统工具的要求，对构建环境需要有一个统一要求。为什么要统一？环境不统一容易产生很多问题，修改的东西没办法控制。统一编译脚本，需要在前面标准化的前提下进行统一。咱们在座的同学里，有哪些企业能做到编译脚本是统一的，不需要开发人员自己写，编译的时候调一个脚本，就能直接编译。

其实我想强调的内容是，尽量让开发人员做本身和业务相关的事情，而不是在这个过程中，又需要让他写很多他不懂的内容，让他弄他能懂、能接受的东西。

4、Test。除了持续集成、持续部署、持续交付，还有持续测试。持续测试的目的，反馈回路比较短。前天我跟一个同学一起讨论问题，自动化测试能更好的减少反馈回路，代码提交之后出结果，很快进行自动化测试，所以在整个交付过程里，持续测试非常重要，但现在在很多企业它是薄弱环节。能做到的点我们尽量做到，单测我们还是鼓励做的，投入产出比很高。其次，我们常用的是接口测试，这个也是投入产出比比较高的自动化测试。UI测试在整个测试的能力模型里，处于比较上级。可视化反馈，这个跟度量类似，要有好的方式呈现给这次测试的结果。

5、Release。制品这块有几个关键点，尤其是制品安全，有一些商用软件提供了非常好的功能，当然我们也可以自己用一些插件做安全扫描。但是我们往往会忽视管理制品版本和元数据，现在有多少企业会把制品元数据记录下来？比如制品对应的代码的commitID是什么、提交人是谁、什么时间生成的？这是后续做自动化的先决条件。

我列了一些重要的制品元数据（推送者、推送时间、制品大小、MD5、版本号、commitid、源码地址等）尽量要跟制品进行绑定，比如通过哪个代码过来，单元测试覆盖率达到百分之多少，这些要全部记录下来，单元测试覆盖率达到80%才能自动晋级，否则要系统人工卡点，没法做到自动化，所以能做到极致的东西，我们就尽量做到极致。

6、Deploy。整个配置分离、应用中心的概念。估计大部分企业现在都做到了这种程度，因为这不是最近才兴起的话题。生产环境不允许接入，基本也能做到，容器化之后这一点控制得比较好。中台的目标，就是代码跟环境统一发布，我们是以这样的思路做这个事的，但是在环节来说，里边有一些比较重要的点，不见得好做，回想一下之前我提到的问题，你要找其中能做的一个点，而不是把所有东西全部做出来。比如现在的自动化测试做得不好，不好的原因在哪？理想状态应该是什么样的？需要谁协助？比如这个自动化测试我做不了，原因是什么？代码架构的问题，可能需要整个架构层面一起考虑这个事情该怎么做。

3.3 度量驱动

这一点我有比较深的体会，大家在做度量的时候，往往会跑偏。之前我在一家企业问有没有做度量，他们说做了，给了我一个报告，拿出来一两百个度量指标。需要那么多度量指标吗？当然，有度量指标的比没有的要好，但某种程度上，不一定要展示出来，可以作为数据积累。

我列了一些好的度量指标和不好的度量指标，大家可以参考一下，什么样的是好的度量指标，什么样是不好的度量指标？度量要以什么为导向？

这是给大家的度量建议，整个企业在度量的时候需要走的路径是什么样的？1.现状与目标。比如阿里的“211”，两周内交付多少，一周内开发多少，一小时提交代码发布。首先要考虑你能不能做到，其次考虑这个东西是否适合你，这不是完全拷贝的过程，要明白自己现状跟目标，再做后面其他的事情。2.策划指标。3.查缺补漏。4.可视化。5.推送预警。6.提供决策。这一点很重要。

在度量这块，你要抛弃过多的无意义指标，因为你做了那些指标，会陷入更糟糕的环境，比如数据造假，衡量这个没意义，反倒影响人的行为习惯，对 DevOps 的整个进展会有很大的影响。

其次，结果导向指标>过程导向指标，我要衡量的是最终结果的指标，而不是过程的指标。度量的最终结果，不是可视化视图，最终出来的应该是一个带着问题清单和解决的方案，这才是度量的意义。

也就是说，人、工具、度量，这是反馈环节的东西，比较重要，当然这里面还有其他 DevOps 的相关要素，比如组织结构，我没有提，但是从我个人的角度来说，组织结构没有这几点重要，人是最重要的，人的行为影响，其实是 DevOps 进展是否顺利的条件。后面的工具建设，我们都是科技企业，技术能力不是问题，都能做到，加上自己的业务特点，总结一些实践放进去，不是什么大的问题。

三、小结

第一，基于问题定目标

我是谁、我要到哪里去、会到哪里去、需要谁协助？把这个事情列清楚了，这个事我们就成功了一大部分。所以不要盲目做 DevOps。

第二，做正确的事情

要了解现状，定义自己的规范，再考虑做到系统工具里，这是一个过程，不是一次性就能做好的。当然我们可以先做工具，解决当前我们能解决的问题，陆续把规范往工具里嵌入。最后的反馈环节除了度量以外，还有自动化测试、运维监控，都是反馈闭环的过程，有很多种方式可以做。

第三，尽量将反馈回路做到极致

维基百科以及其他指南，对 DevOps 有很多定义。但我个人理解，无论从文化、组织、工具、度量方向来说，DevOps 是努力将结果的反馈回路缩短到极致，这就是 DevOps 的核心理念。

不知道大家有没有产生共鸣，其实你做什么事情，它都是在缩短/左移的过程。我们强调的就是左移，开发开始做单测就是左移，自动化测试也是左移，安全也是左移，左移的过程就是缩短反馈回路的过程，我们把反馈回路缩短到极致，DevOps的整个闭环就可以做得非常好。(转自韩洪雷）

今天我跟大家分享的话题是 “DevOps落地的关键要素”，分为三部分。
一、你的 DevOps 是什么样？

场景一、形式主义

之前我们在做 KPI 或 OKR 的时候，是不是经常会看到这样的字眼：我完成了多少需求、推进了多少业务线，虽说它也达到了量化，但这样做是否合理需要进一步的考量？其实在上线了多少个需求后，最终“解决了多少问题”才是最终的价值体现，而不是上线了多少需求。但这个结果，在整个绩效考核当中是没有人负责的，这是比较常见的场景。我们后续回到公司的时候，可以看看是否存在这样的问题，考虑一下要出于什么角度定 OKR 或 KPI。

场景二、心急火燎

我们在做整个 DevOps 实施或转型落地的时候，可能会定一个非常庞大的计划，声势造得特别大，但这不是 DevOps 真正要做的事情。我们可以把 DevOps 做一个不恰当的比喻，把它比喻成癌症的癌细胞，它要不断扩散。也就是说，从点到面，然后要成就面，这是 DevOps 本身的发展路径。而不是一上来就做一个宏观庞大的，一是见效速度非常慢，二是推广成本比较大。所以我们尽量做到，当前哪个点有问题，就优先解决哪个点的问题。

场景三、百家争鸣

这个问题我之前也遇到过，一个企业里有多个 DevOps 平台。什么原因产生的？比如一个比较狼性的企业，最开始说我们每个团队都可以做，谁做得好用谁的，到最后却变成了各玩各的。“有开始，没结束”开始的方向错了，导致一系列的问题产生，这也是 DevOps 里常见的问题。

场景四、混乱之墙

在企业内部，肯定有一些合作不顺畅的点。产生不顺畅的原因有很多，包括目标不一致性，例如开发跟运维，他们的目标完全是不一致的，一个要变，一个要稳，两方领导的做事方式不一样，目标不一样，想达成的结果也不一样。

场景五、盲目跟风

不是说别人做 DevOps，我们也跟着做。这个场景可能导致一个问题，荒废了很多人力，最终根本落不了地。总结一条我个人的建议：DevOps 的根基是什么？一定是出于解决某个问题的角度出发，而不是出于规划。DevOps 本身萌发的萌芽，就是你要解决企业内部的一个问题。

二、DevOps 落地要素

整体来说，落地要素就是组织结构、企业文化、人员能力、技术、工具平台等等，我挑出来了几个比较主要的因素，跟大家进行交流。

2.1 企业文化

企业文化到底是如何影响员工的？我经过很长时间的发现和总结，得出了一个结论：不同的行为影响产生不同的行为结果。在企业内部，你周边的人往往是对你影响最大的人，包括你的同事和领导。你的同事做事风格如果是好的、积极向上的，你大概率会跟他一样。如果你的同事比较闭塞，是合作不太顺畅的人，久而久之你也会受到影响，这是定律。

企业文化传承的有效途径，主要来自于“近亲”。企业文化的传承主要依靠主管的影响力，而不是全员都在做企业文化的宣传。这是我自己对企业文化的理解，比较小众。

2.2 工具建设

这是整个 DevOps 落地的关键节点。之前我听有人说过，工具建设不重要，企业文化更重要，组织结构更重要。DevOps领域里，没有什么东西是谁比谁更重要的，它们都同等重要。你把每一项都做好，你的DevOps结果就会很好。

DevOps 工具，有一个核心环节（CD过程），上线流程的每一块，都需要很细的点，不知道大家在内部的 DevOps 平台里做到什么样的方式，你们有定义过多少个规则？我见过的 DevOps 平台里的规则，比功能点还要多，整个标准化达到了非常高的程度，所以系统不需要做到那么复杂的程度，系统就是一个流程。

1、Plan。工具层面的计划挺简单的，需求管理跟最终的上线有一一对应的过程。相信现在大家都有电子看板的能力，电子看板有一个很有意思的点，可以松，可以紧，就看我们用到什么程度。当你做后续度量的时候，比较宽泛的看板能力可能满足不了你的度量要求，因为你规范不了用户的行为习惯。如果有企业在做类似于看板的系统，需要想想后续的度量要怎么做，有可能你要先做度量指标，再考虑看板，这是一种方式，这样可以规范看板里的功能点。可视化和可量化，就是整个需求管理的内容。

2、Code。代码管理是比较重要的，你说它简单，也很简单。说它复杂，也很复杂。说它简单，就是给用户开一个类似自由编译的入口，让他自己做编译就可以了，包括现在云厂商提供的工具，也是类似的概念。因为是通用型产品，所以提供的是通用型功能。

但是我们在企业内部做这个事情的时候，往往不会那么简单，我们需要在这个环节里加上一定的控制条件，保证代码的质量或者自动化程度能够进一步的提升。这里边的限制条件包括整个代码结构有没有做做规范性，比如某某文件应该做在哪、另外一点比如是否定义与业务匹配的分支模型等等。在我们内部的 DevOps 平台里，大部分都不会线上化管理分支，都是线下依靠开发人员遵守分支模型做线下规范性约束。

相关命名规范也很重要，这是自动化的前提，比如代码库名称、分支名称，都要有一个规则，规则有了才能在系统上自动化。

完善的校验机制，这个也很重要，不知道多少人在做代码编译之前会做一系列的检查？包括代码结构的检查，包括配置文件的检查，大家可以考虑一下，在编译前要做哪些合规性的校验检查。

3、Build。

统一编译环境，对 DevOps 一体化成熟度模型熟悉的同学都知道，“标准8”有一个系统工具的要求，对构建环境需要有一个统一要求。为什么要统一？环境不统一容易产生很多问题，修改的东西没办法控制。统一编译脚本，需要在前面标准化的前提下进行统一。咱们在座的同学里，有哪些企业能做到编译脚本是统一的，不需要开发人员自己写，编译的时候调一个脚本，就能直接编译。

其实我想强调的内容是，尽量让开发人员做本身和业务相关的事情，而不是在这个过程中，又需要让他写很多他不懂的内容，让他弄他能懂、能接受的东西。

4、Test。除了持续集成、持续部署、持续交付，还有持续测试。持续测试的目的，反馈回路比较短。前天我跟一个同学一起讨论问题，自动化测试能更好的减少反馈回路，代码提交之后出结果，很快进行自动化测试，所以在整个交付过程里，持续测试非常重要，但现在在很多企业它是薄弱环节。能做到的点我们尽量做到，单测我们还是鼓励做的，投入产出比很高。其次，我们常用的是接口测试，这个也是投入产出比比较高的自动化测试。UI测试在整个测试的能力模型里，处于比较上级。可视化反馈，这个跟度量类似，要有好的方式呈现给这次测试的结果。

5、Release。制品这块有几个关键点，尤其是制品安全，有一些商用软件提供了非常好的功能，当然我们也可以自己用一些插件做安全扫描。但是我们往往会忽视管理制品版本和元数据，现在有多少企业会把制品元数据记录下来？比如制品对应的代码的commitID是什么、提交人是谁、什么时间生成的？这是后续做自动化的先决条件。

我列了一些重要的制品元数据（推送者、推送时间、制品大小、MD5、版本号、commitid、源码地址等）尽量要跟制品进行绑定，比如通过哪个代码过来，单元测试覆盖率达到百分之多少，这些要全部记录下来，单元测试覆盖率达到80%才能自动晋级，否则要系统人工卡点，没法做到自动化，所以能做到极致的东西，我们就尽量做到极致。

6、Deploy。整个配置分离、应用中心的概念。估计大部分企业现在都做到了这种程度，因为这不是最近才兴起的话题。生产环境不允许接入，基本也能做到，容器化之后这一点控制得比较好。中台的目标，就是代码跟环境统一发布，我们是以这样的思路做这个事的，但是在环节来说，里边有一些比较重要的点，不见得好做，回想一下之前我提到的问题，你要找其中能做的一个点，而不是把所有东西全部做出来。比如现在的自动化测试做得不好，不好的原因在哪？理想状态应该是什么样的？需要谁协助？比如这个自动化测试我做不了，原因是什么？代码架构的问题，可能需要整个架构层面一起考虑这个事情该怎么做。

3.3 度量驱动

这一点我有比较深的体会，大家在做度量的时候，往往会跑偏。之前我在一家企业问有没有做度量，他们说做了，给了我一个报告，拿出来一两百个度量指标。需要那么多度量指标吗？当然，有度量指标的比没有的要好，但某种程度上，不一定要展示出来，可以作为数据积累。

我列了一些好的度量指标和不好的度量指标，大家可以参考一下，什么样的是好的度量指标，什么样是不好的度量指标？度量要以什么为导向？

这是给大家的度量建议，整个企业在度量的时候需要走的路径是什么样的？1.现状与目标。比如阿里的“211”，两周内交付多少，一周内开发多少，一小时提交代码发布。首先要考虑你能不能做到，其次考虑这个东西是否适合你，这不是完全拷贝的过程，要明白自己现状跟目标，再做后面其他的事情。2.策划指标。3.查缺补漏。4.可视化。5.推送预警。6.提供决策。这一点很重要。

在度量这块，你要抛弃过多的无意义指标，因为你做了那些指标，会陷入更糟糕的环境，比如数据造假，衡量这个没意义，反倒影响人的行为习惯，对 DevOps 的整个进展会有很大的影响。

其次，结果导向指标>过程导向指标，我要衡量的是最终结果的指标，而不是过程的指标。度量的最终结果，不是可视化视图，最终出来的应该是一个带着问题清单和解决的方案，这才是度量的意义。

也就是说，人、工具、度量，这是反馈环节的东西，比较重要，当然这里面还有其他 DevOps 的相关要素，比如组织结构，我没有提，但是从我个人的角度来说，组织结构没有这几点重要，人是最重要的，人的行为影响，其实是 DevOps 进展是否顺利的条件。后面的工具建设，我们都是科技企业，技术能力不是问题，都能做到，加上自己的业务特点，总结一些实践放进去，不是什么大的问题。

三、小结

第一，基于问题定目标

我是谁、我要到哪里去、会到哪里去、需要谁协助？把这个事情列清楚了，这个事我们就成功了一大部分。所以不要盲目做 DevOps。

第二，做正确的事情

要了解现状，定义自己的规范，再考虑做到系统工具里，这是一个过程，不是一次性就能做好的。当然我们可以先做工具，解决当前我们能解决的问题，陆续把规范往工具里嵌入。最后的反馈环节除了度量以外，还有自动化测试、运维监控，都是反馈闭环的过程，有很多种方式可以做。

第三，尽量将反馈回路做到极致

维基百科以及其他指南，对 DevOps 有很多定义。但我个人理解，无论从文化、组织、工具、度量方向来说，DevOps 是努力将结果的反馈回路缩短到极致，这就是 DevOps 的核心理念。

不知道大家有没有产生共鸣，其实你做什么事情，它都是在缩短/左移的过程。我们强调的就是左移，开发开始做单测就是左移，自动化测试也是左移，安全也是左移，左移的过程就是缩短反馈回路的过程，我们把反馈回路缩短到极致，DevOps的整个闭环就可以做得非常好。(转自韩洪雷）