首先说 DevOps 非常重要，今年其实是一个很特别的年份，赶上疫情，触动最大的就是开年的法定上班日是2月10号，大家开始远程办公，开工当天朋友圈基本就刷爆了，我想问一下大家远程办公第一天的障碍是什么？反正从我这边的朋友圈看到的都是各种会议室不稳定，VPN连不上，电话占线之类，还有开发反馈代码下不下来，开发等测试，部署也没法进行。




但在朋友圈这些“负面”消息中，发现朋友圈有一个亮点，我觉得这个很有意义，就是我们的一个客户，他们在应对疫情方面显得非常从容，也是远程办公，但各项工作井井有条，而且还在“朋友圈撒狗粮”，表达 DevOps 对我们帮助很大。




可以说这一点也是这两年 DevOps 红透半边天的原因，其实我觉得这是一个很常见的现象，最近几年每个企业都特别注重工程效率的提升，在工程效率提升这方面， DevOps 绝对是一个最亮的明星词，大家都在想怎么通过 DevOps 改进研发效率。




DevOps 这么好，但企业在实施 DevOps 过程中发现并不容易，而且做着做着可能死掉了，那么在这里结合我自己的经验，还有最近给企业做转型实施时发现的问题，总结了 DevOps 实施过程中的 10 个深坑，给大家做一个简单的分享。

先给大家整体介绍一下，我整理的十个深坑。

下面来给大家逐条分析每个问题。

首先说一下，因为大家听到很多都是技术这方面的故事，那么在实施 DevOps 过程中，很关键的一点是建流水线平台，在与客户交流过程中发现流水线很多设计不合理，经常会有一些问题。




常见的问题比如缺少提交即构建，我们要不要做提交即构建？因为有一个误区，就是会有流水线从头到尾只有一条的情况，但其实不是这样。




还有就是开发和测试会脱节，比如开发这边有一套 Jenkins，测试也维护一套 Jenkins，甚至流水线没有集成自动化测试，其实就是从构建编译最终到发布，但是这条流水线有点形成虚设，下面的流水线还有大量的手工操作。在流水线里面没有质量门禁也是一个问题，合乎门禁做得比较弱，就是起不到门禁的效果。还有单元测试，有的没有，有的甚至覆盖率非常低。还有整个会有大量重复的构建，而不是制品晋级的方式。




说到这个，好的流水线应该是什么样？其实就是刚才说的提交即构建这个问题，我觉得提交即构建，首先就是提交之后应尽早发现问题、实现问题，但是提交即构建并不一定放到完整的一条流水线里，我们一般会独立出一条提交即构建的流水线，至少它不会到交付和发布阶段做提交即构建。

总结一下，好的流水线的16个特征，首先要有版本控制，其次有最优的分支策略，还有代码扫描、单测覆盖率、漏洞扫描、制品管理、开源工具的扫描，还有像集中测试、性能测试、功能开关；还有就是要有较高的接口覆盖率，然后发布要支持这种零停机发布。还有很关键的就是非常常见每次提交触发都要有构建、部署和自动化测试，这是我们评价一条好的流水线的16个特性。

这里也给大家介绍一下金融机构的流水线是什么样，因为材料会涉及到客户的隐私问题，也只能找一些公开的材料。




首先说明这是某家金融机构的流水线，他们有提交即构建的功能，这个流水线是干什么的？首先是代码提交即构建，提交即构建流水线不够，MR是肯定不通过的，还有代码评审，我也是建议把这个功能建上，由提交构建是单独流水线，在做代码评审时都会等你的单测，检查之后这些都过了，才做代码评审。因为我觉得我这个人比较懒，如果在之前能用自动化的工具，我绝对不会费我的眼睛。




应用部署流水线也在这里解释一下，因为流水线不是一条，你可以按阶段去定制流水线，还有就是开发比较灵活的时候，像之前我们会把流水线实践成多条，单条可执行，流水线之间是可以首尾相接的，这一块后边大家需要，我们可以单独分享。




再者就是要有一条独立的数据库变更流水线，这是某金融机构的流水线，大家有可能在网上也能找到相关的信息。

下面某银行的流水线，同样是提交即构建是单独的一条，在做好了编译、单元测试，还有下边的持续交付流水线，这个时效的部署。这是第一个。

顺着第一个，第二个就是流水线的内建质量不足，这也是一个坑。举一个例子，就是在说到内建质量时通常拿这两个例子，一是美国汽车流水线，经常会在流水线末端有一个人拿锤子敲敲打打来检验这个门的质量是不是OK。如果要靠最后的人去验证车的质量是否OK，我觉得这是是不对的。




另外一个就是丰田公司，他们是怎么做流水线的？其实就是在流水线有一个安灯系统，这个流水线在执行过程中，只要任何人发现问题都可以亮红灯，可以马上发现去修复，用这种方式把前期在流水线跑完，出来以后肯定是一个质量OK的。




那接着这个问题说一下在软件流水线中常见的问题，经常是有单元测试，但是单元测试很低，也没有代码评审，或者代码评审放得比较靠后，或者要投产的时候才会做代码评审，还有就是流水线的缺少静态代码检查或者门禁标准非常低，很容易过了。




说到质量内建，我觉得大家应该遵循两个原则，其实这个不是说通过 DevOps 才有，其实在最早的时候，问题发现越早，修复成本越低。质量是每个人的责任，而不只是测试团队的责任。我觉得从经验上来说，流水线质量内建的核心就是检验左移，就是尽量把在流水线最左端能识别出来的问题就不要把它放到右端，但这么说，现实中实现起来大家还是要酌情处理。




我这边的建议是质量左移的工具是持续可见的过程，这块的意思是，结合我以前的经验，比如最开始会确定一个检查类型，单测和覆盖率要多少，还有就是静态代码检查，我会很注重左侧和，还有这一般的经验性我就会放宽一点，如果不这样，一开始你的质量门永远过不去。




还有基于这个我们会定义质量阈值，就是刚才说到的，比如覆盖率要百分之百过，错误（error）要百分之百过，你可能一边检查，或者一边建议型的，后面就是作为技术栈。你设定一个阈值，基于这个阈值在质量门禁里强制执行。


至于质量门禁一开始要定义你的处理方式，比如怎么去修复，很严重的问题是不是要做回本，不能影响其他人的流水线去跑。你要制定规则，根据这个规则持续改进。比如说质量提升，要重新去定义检查类型和范围，不断提升内建质量。这是我的一个建议的过程。

还有一个怎么落实到流水线，其实很多企业都是这么实施的，这个跟上面金融企业是一个图，其实也就是说，你看在提交即构建时，就是把新的UT做Sonar，Sonar是扫描管理之后，其实这个才会去后边做MR和评审，还有在应用部署流水线里面，也是在Dev的时候会有测试，还有覆盖率，都会有相应的质量门。

有了流水线，DevOps 也建得差不多，那目前来说发现安全能力其实跟整个的 DevOps 其实还是隔离的，这也是一个普遍存在的问题。从去年的 DevOps 国际峰会（DOIS），大家对 DevOps 已经越来越重视，但速度非常快，特别像去年的网络安全会，一些安全事件来推动你必须要赶快把安全问题内建到 DevOps 能力里，再实施 DevOps，如果不考虑安全问题，我觉得 DevOps 的整体实施也是一个落后。




这一块我也整理了基于 DevOps 工具链和 DevOps 研发过程的阶段，即项目过程管理、配置管理、构建串起来，并且附了一些相关的安全的方法。比如说在这个过程中，需要每天做安全培训，安全需求威胁模型分析，在配置管理阶段要引入OWASP理论，还有IDE的安全插件，然后去补充安全相关的技术栈。构建方面，在门禁上配置安全门，还有就是配置分析、单元测试，静态扫描也要充分的纳入一些安全方法。




测试质量这方面可能要有动静交互应用安全测试，还有混沌工程等等，制品库这块刚刚 JFrog 王青老师也介绍了，其实制品库已经在往安全方面注入了很多东西，包括实际过程中还要做安全扫描、渗透测试这些安全策略签名等。在基础设施我们要加强安全监控、配置监控，也要有分析，后边就是什么协同沟通、快速反馈，还有就是可视化要SIEM安全信息和事件管理。

说到流水线，还有一个很大的问题，就是自动化测试不被信任，这个我觉得对于自动化测试每个企业都会有这个，因为自动化解决了我们现在测试面临很难的问题，就是测试时间越来越多，但是整个测试时间越来越短，但是真正做起来，据我走访的企业，很多要不没有自动化测试，要不有，但是也是马马虎虎。




在实施 DevOps 初期，可能要面临一些相关的问题就是自动化测试用例覆盖不够，还有选用需要积累时间，整个误报率居高不下，自动化在跑，错了就错，有一些问题大家也不处理，关键是场景覆盖不够，可能就是为了写一些自动化测试而写，但是一些场景能做自动化的反而没做。整个用例的测试结构不稳定，时对时错，还有测试用例质量差，测试用例永远不报错，为什么？因为测试用例连最基本的一些断弦都没有。




在面对这些测试问题我觉得解决起来也很朴实，首先你要提升你的测试覆盖率，其实提升测试覆盖率也有策略的，至少要先要把核心场景覆盖了，这时候再去覆盖一般场景，最后再可能实现全场景覆盖。至少你哪些已经覆盖了，后边手工测试就可以简化一些，回归也会质量更高更快一些，还有就是收到了用例积累时间不够，这个我觉得没有办法，就是想办法积累。




然后就是要提升修复测试的误报率，就有一些误报的测试要及时修复，否则后面会很干扰你测试的质量，那就没有什么效果。还有就是用例设计要考虑整个数据的独立性，就是整体怎么提升测试率的质量，我觉得比较好的方式就是定期的用例评审，分级的用例评审。

说到自动化测试，发现做了自动化测试，但在一个团队里大家都不知道自己在做什么，或者怎么做，可能会有一些谁也不知道怎么做，这样的话建议把自动化测试体系这块做得健全一些，这一方面我也是结合之前的经验，在建自动化测试体系里面应该有一些能力。




第一就是测试分层，分层方法，分层策略，测试时机，这一块其实史立龙老师也介绍了，测试分层并不是说，因为我这边给大家列了几个，像比较流行的，三角形、纺锤形、橄榄球形，这个是给大家的一个参考，真正做自动化测试分层的时候要结合实际的业务形态，比如说像我之前做外网合格服务的时可能倾向于做接口级的测试，因为我觉得这个接口级的测试成本最低，这种情况下我本来如果画一些单测去和UI集中精力做接口级的测试。




还有可能在我之前会偏向于前端大服务端，其实在那个阶段我比较倾向于三角形，那个时候觉得单测是执行最快，成本最低，维护起来也是最容易。但是其实还有，你可能有一些老的项目，可能之前已经积累很多代码没有单测，这个时候还是视大家的实际情况，但是首先要把你的分层策略明确下来，在你的组织上执行，这样整个你的测试团队至少你的思想是统一的。那这是测试分层。




还有代码质量管理，这一块现在已经有很好的工具，只要定义好规则、方式，及时做修复，这一方面有一点大家一定要注意质量规则，因为我也遇到过一个客户，他们用了很多规则，我记得当时一开始的时候有一千多条规则，我说这些规则你们怎么定门禁？当时他们就一愣。其实就是我们的规则一开始没有必要定义过多，定一个适合的，把相应的门禁配上，然后严格执行，随着你不断增加去更新你的规则，比如说你需要定期的更新，有一些好的规则让我加入，有一些不适用的你要定期去移除，这样也避免你质量门禁那一块产生困扰。




自动化测试设计，因为现在一些大企业整个测试团队不是一个人，首先要从你的设计、开发、执行要定义清楚，至少有统一的工具、统一的架构，你的开发将来不同的人调用你的开发模式，你写的用例应该是相似的，因为我之前是开发的，所以我比较看重这种。之前我没有这种设计，在做接口的时候比如前期定义这个接口，接口都可以了，评审都通过了才会进行实际的开发。还有就是测试数据管理这一块，你要把你的数据来源、数据覆盖、数据独立性这一块要去规范清楚。这是我的测试体系不健全这块的建议。

说到度量，DevOps 也实施了，有什么效果？之前也问过一个客户，客户说会统计需求的交付周期，现在流水线有一千多条，自动化接口有多少多少。但是我想这些真的是 DevOps 需要的吗？所以说很多 DevOps 是为了什么？是为了提效增质、安全，但是这些我是没有看到。所以这一块也是整理了一些结合我之前的经验还有一些企业里面总结比较好的度量指标。




首先要从需求在各阶段的停留时长，还有就是需求的逃逸率，逃逸率就是生产缺陷，研发阶段缺陷及自动化测试的误报率，这个指标也非常好，如果你看你的自动化测试的质量。还有就是技术债务，这方面其实非常重要，你要看整体的代码质量是不是有一个维持上下的趋势和稳定，还有 DevOps 里核心的其他指标，就是变更的前置时间、部署频率，变更失败率、服务恢复时长，每个点其实都是能通过度量去驱动改进。每个点做指标的时候，首先要明确你的受众，这些指标是给谁看，还有每个指标要直指问题，并且这个是可度量的，反馈问题以后要驱动改进，改进完了之后要能看到你的这个指标是变好还是变坏？




在右边的图，其实还会积累一些其他的一些企业实践里面更好的指标，大家看一下，比如像代码提交频率、效能指标、测试成功率等等。时间关系后边我们再去看。

还有就是整个在项目实施过程中也会遇到很严重的坑，没有明确实施路线和目标。DevOps要做成什么样子？我们怎么做？其实 DevOps 本身就像盲人摸象，可能每个人手上有大量的资料，但是看完这些资料都有不同的理解。




结合我这边的经验，还有我们现在也有一个至少在设计里面有比较好的实践，就是如果参照标准执行，至少我发现了一个比较好的标准，这个标准可执行，比如在 DevOps 里面覆盖哪些领域，每个领域都会定义很清楚，比如说在不同阶段不同的级别应该做成什么样子，做成什么样子才能达到这种级别？我觉得这个建议大家还是参考标准，通过这种赋能培训的方式希望大家有一个对 DevOps 的认识，并且能明确在做到什么情况下能达到一个什么水平，基于这个水平定义我们的目标。

定好目标了整个 DevOps 的实施路线，结合我之前在企业的一些经验给大家做了总结。首先要选择试点项目、组件推进小组、了解项目现状，然后识别你要改进的事项和痛点，改进获得成功，提升信心，然后持续用这种方式改进。


这块其实也是怎么去识别痛点，也是刚刚上图有一个标准，其实 DevOps 标准里有一些很明确，你能通过标准去看当前的项目的状况在哪里，可以基于标准对照有哪些问题。


我觉得大家后边可以去了解一下，我觉得这个是比较好的方式，为什么？如果你没有目标，尤其是这两年企业，一般都是重效率，看产出。做一个没有目标没有结果的项目，很多领导不会支持你。

实施 DevOps 过程中有一个很容易犯错的就是经常选错实验田，DevOps 虽然好，但在实施过程中选择的实验团队经常有误区。一开始我们心很大，会选择一个很大的团队，或者选择不是核心业务的团队，做着做着资源也就没有保证，或者选一个非敏捷业务团队，过来要去做敏捷导入，可能这个时间效果也不好，还有可能综合能力比较差动手能力也差。


DevOps 和敏捷对整个团队的能力要求越高越好，还有确定你是否团队其他同事认同DevOps 的价值。总结我在企业和自己在团队的实践经验，我觉得 DevOps 试点选择的时候应该考虑以下几点：

• 贴近核心的业务团队。因为这样资源有保证，而且实施出来的效果后再往下推的时候别人也能认；
• 团队规模要适中，以我的经验来说要控制在20人左右，因为 DevOps 也是属于一个变革的过程，人多沟通起来成本也会高，实施效果其实也会有影响；
• 敏捷的业务；
• 项目压力不能太大。因为做任何的变革，包括变敏捷的时候也要有一个适应期，这个时候压力太大，可能业务那边被迫无法配合你，尤其很多企业有窗口期，到什么时候你就要上，所以你要选一个压力适中的；
• 认同 DevOps 的价值。这个是我们在选择团队的时候要做的。
  

实施 DevOps 过程中，一个很正常的就是，会有一个J型曲线，一开始可能很顺利，团队转型也起到一定的效果，比如说自动化测试，自动化效能能配套整个流程和效能会有一定的提升，但是接下来马上就会有一个向下，为什么？因为一些自动化导致我们的人工处理测试需求也会增加，也会有大量的技术债阻碍我们的进展。

还有技术债变更会导致变更流程中增加人工的控制环节，过程审批环节，减缓工作速度。这其实在 DevOps 实施过程中很正常。

用什么方案解决？其实在实施 DevOps 前期要组件一个 DevOps 转型小组，这里面包括大领导的配合，顶住业务压力，支持你的转型。然后业务团队、工具团队，有了这些相当于一个专家来推动，你在遇到问题时能够很快解决。在转型过程中要经常给大家信心，怎么给？经常借助评估标准的方式，以评促建，以评促改，这是我们的一些经验。

下面还有最重要的一个坑，就是在没有获得高层领导就开工，我觉得这个是最大的一个坑，其实 DevOps 实施是一种突破现有习惯和流程，改革现有文化，通过文化、工具、流程三位一体整体的实施，所以说很容易遇到部门墙和业务团队、工具团队的不配合，甚至会改变我们现有的审批流程和结构，还有关键的就是需要人，需要软件资源，需要时间，这些其实没有一个高层管理者的支持，实施过程中很容易断粮，导致你的莫名其妙 DevOps 实施就失败了。

那怎么来获得领导的支持？这边我觉得你要跟领导讲清楚，DevOps的价值，你要让领导对你的这个项目有信心。首先DevOps价值里面能够提升提质增效，减少我们停机时间，更快上线，让我们的上线更安全，故障更少，同时通过自动化减少我们的人员流失带来的伤害。


还有就是行业趋势，同行已经在这样做了，同时就是这几个是定性的指标。同时DevOps自身也有一些可量化的指标，那就是说我们的部署频率、变更前置时间、服务恢复时间，变更失败率，其实这些都能在DevOps里面体现出来，这些都是你的能去说服领导做 DevOps 的。还有一个很重要的就是同行对比，右边的图大家可以看到，我们通过DevOps评估的方式，能让你看，比如说实施DevOps之后，我能达到一个什么水平，其实我是不光跟内部比质量提升，还有可以跟同行比，看在这个行业里的一个水平。

总结总结一下，什么是一个好的 DevOps？我借鉴了 DevOps 三剑客的内容，一个 Feature 从开发到上线的关键路径上，除了功能开发的时间要尽量短，这就是一个好的 DevOps。整个实施 DevOps 过程中，如果不改变下游流程以及人的行为习惯去实施 DevOps，本身就是不现实的，要机制改变行为，行为改进文化。这个就是我关于 DevOps 的一个分享，后续有兴趣可以联系我们，谢谢大家。（施景丰）

首先说 DevOps 非常重要，今年其实是一个很特别的年份，赶上疫情，触动最大的就是开年的法定上班日是2月10号，大家开始远程办公，开工当天朋友圈基本就刷爆了，我想问一下大家远程办公第一天的障碍是什么？反正从我这边的朋友圈看到的都是各种会议室不稳定，VPN连不上，电话占线之类，还有开发反馈代码下不下来，开发等测试，部署也没法进行。




但在朋友圈这些“负面”消息中，发现朋友圈有一个亮点，我觉得这个很有意义，就是我们的一个客户，他们在应对疫情方面显得非常从容，也是远程办公，但各项工作井井有条，而且还在“朋友圈撒狗粮”，表达 DevOps 对我们帮助很大。




可以说这一点也是这两年 DevOps 红透半边天的原因，其实我觉得这是一个很常见的现象，最近几年每个企业都特别注重工程效率的提升，在工程效率提升这方面， DevOps 绝对是一个最亮的明星词，大家都在想怎么通过 DevOps 改进研发效率。




DevOps 这么好，但企业在实施 DevOps 过程中发现并不容易，而且做着做着可能死掉了，那么在这里结合我自己的经验，还有最近给企业做转型实施时发现的问题，总结了 DevOps 实施过程中的 10 个深坑，给大家做一个简单的分享。

先给大家整体介绍一下，我整理的十个深坑。

下面来给大家逐条分析每个问题。

首先说一下，因为大家听到很多都是技术这方面的故事，那么在实施 DevOps 过程中，很关键的一点是建流水线平台，在与客户交流过程中发现流水线很多设计不合理，经常会有一些问题。




常见的问题比如缺少提交即构建，我们要不要做提交即构建？因为有一个误区，就是会有流水线从头到尾只有一条的情况，但其实不是这样。




还有就是开发和测试会脱节，比如开发这边有一套 Jenkins，测试也维护一套 Jenkins，甚至流水线没有集成自动化测试，其实就是从构建编译最终到发布，但是这条流水线有点形成虚设，下面的流水线还有大量的手工操作。在流水线里面没有质量门禁也是一个问题，合乎门禁做得比较弱，就是起不到门禁的效果。还有单元测试，有的没有，有的甚至覆盖率非常低。还有整个会有大量重复的构建，而不是制品晋级的方式。




说到这个，好的流水线应该是什么样？其实就是刚才说的提交即构建这个问题，我觉得提交即构建，首先就是提交之后应尽早发现问题、实现问题，但是提交即构建并不一定放到完整的一条流水线里，我们一般会独立出一条提交即构建的流水线，至少它不会到交付和发布阶段做提交即构建。

总结一下，好的流水线的16个特征，首先要有版本控制，其次有最优的分支策略，还有代码扫描、单测覆盖率、漏洞扫描、制品管理、开源工具的扫描，还有像集中测试、性能测试、功能开关；还有就是要有较高的接口覆盖率，然后发布要支持这种零停机发布。还有很关键的就是非常常见每次提交触发都要有构建、部署和自动化测试，这是我们评价一条好的流水线的16个特性。

这里也给大家介绍一下金融机构的流水线是什么样，因为材料会涉及到客户的隐私问题，也只能找一些公开的材料。




首先说明这是某家金融机构的流水线，他们有提交即构建的功能，这个流水线是干什么的？首先是代码提交即构建，提交即构建流水线不够，MR是肯定不通过的，还有代码评审，我也是建议把这个功能建上，由提交构建是单独流水线，在做代码评审时都会等你的单测，检查之后这些都过了，才做代码评审。因为我觉得我这个人比较懒，如果在之前能用自动化的工具，我绝对不会费我的眼睛。




应用部署流水线也在这里解释一下，因为流水线不是一条，你可以按阶段去定制流水线，还有就是开发比较灵活的时候，像之前我们会把流水线实践成多条，单条可执行，流水线之间是可以首尾相接的，这一块后边大家需要，我们可以单独分享。




再者就是要有一条独立的数据库变更流水线，这是某金融机构的流水线，大家有可能在网上也能找到相关的信息。

下面某银行的流水线，同样是提交即构建是单独的一条，在做好了编译、单元测试，还有下边的持续交付流水线，这个时效的部署。这是第一个。

顺着第一个，第二个就是流水线的内建质量不足，这也是一个坑。举一个例子，就是在说到内建质量时通常拿这两个例子，一是美国汽车流水线，经常会在流水线末端有一个人拿锤子敲敲打打来检验这个门的质量是不是OK。如果要靠最后的人去验证车的质量是否OK，我觉得这是是不对的。




另外一个就是丰田公司，他们是怎么做流水线的？其实就是在流水线有一个安灯系统，这个流水线在执行过程中，只要任何人发现问题都可以亮红灯，可以马上发现去修复，用这种方式把前期在流水线跑完，出来以后肯定是一个质量OK的。




那接着这个问题说一下在软件流水线中常见的问题，经常是有单元测试，但是单元测试很低，也没有代码评审，或者代码评审放得比较靠后，或者要投产的时候才会做代码评审，还有就是流水线的缺少静态代码检查或者门禁标准非常低，很容易过了。




说到质量内建，我觉得大家应该遵循两个原则，其实这个不是说通过 DevOps 才有，其实在最早的时候，问题发现越早，修复成本越低。质量是每个人的责任，而不只是测试团队的责任。我觉得从经验上来说，流水线质量内建的核心就是检验左移，就是尽量把在流水线最左端能识别出来的问题就不要把它放到右端，但这么说，现实中实现起来大家还是要酌情处理。




我这边的建议是质量左移的工具是持续可见的过程，这块的意思是，结合我以前的经验，比如最开始会确定一个检查类型，单测和覆盖率要多少，还有就是静态代码检查，我会很注重左侧和，还有这一般的经验性我就会放宽一点，如果不这样，一开始你的质量门永远过不去。




还有基于这个我们会定义质量阈值，就是刚才说到的，比如覆盖率要百分之百过，错误（error）要百分之百过，你可能一边检查，或者一边建议型的，后面就是作为技术栈。你设定一个阈值，基于这个阈值在质量门禁里强制执行。


至于质量门禁一开始要定义你的处理方式，比如怎么去修复，很严重的问题是不是要做回本，不能影响其他人的流水线去跑。你要制定规则，根据这个规则持续改进。比如说质量提升，要重新去定义检查类型和范围，不断提升内建质量。这是我的一个建议的过程。

还有一个怎么落实到流水线，其实很多企业都是这么实施的，这个跟上面金融企业是一个图，其实也就是说，你看在提交即构建时，就是把新的UT做Sonar，Sonar是扫描管理之后，其实这个才会去后边做MR和评审，还有在应用部署流水线里面，也是在Dev的时候会有测试，还有覆盖率，都会有相应的质量门。

有了流水线，DevOps 也建得差不多，那目前来说发现安全能力其实跟整个的 DevOps 其实还是隔离的，这也是一个普遍存在的问题。从去年的 DevOps 国际峰会（DOIS），大家对 DevOps 已经越来越重视，但速度非常快，特别像去年的网络安全会，一些安全事件来推动你必须要赶快把安全问题内建到 DevOps 能力里，再实施 DevOps，如果不考虑安全问题，我觉得 DevOps 的整体实施也是一个落后。




这一块我也整理了基于 DevOps 工具链和 DevOps 研发过程的阶段，即项目过程管理、配置管理、构建串起来，并且附了一些相关的安全的方法。比如说在这个过程中，需要每天做安全培训，安全需求威胁模型分析，在配置管理阶段要引入OWASP理论，还有IDE的安全插件，然后去补充安全相关的技术栈。构建方面，在门禁上配置安全门，还有就是配置分析、单元测试，静态扫描也要充分的纳入一些安全方法。




测试质量这方面可能要有动静交互应用安全测试，还有混沌工程等等，制品库这块刚刚 JFrog 王青老师也介绍了，其实制品库已经在往安全方面注入了很多东西，包括实际过程中还要做安全扫描、渗透测试这些安全策略签名等。在基础设施我们要加强安全监控、配置监控，也要有分析，后边就是什么协同沟通、快速反馈，还有就是可视化要SIEM安全信息和事件管理。

说到流水线，还有一个很大的问题，就是自动化测试不被信任，这个我觉得对于自动化测试每个企业都会有这个，因为自动化解决了我们现在测试面临很难的问题，就是测试时间越来越多，但是整个测试时间越来越短，但是真正做起来，据我走访的企业，很多要不没有自动化测试，要不有，但是也是马马虎虎。




在实施 DevOps 初期，可能要面临一些相关的问题就是自动化测试用例覆盖不够，还有选用需要积累时间，整个误报率居高不下，自动化在跑，错了就错，有一些问题大家也不处理，关键是场景覆盖不够，可能就是为了写一些自动化测试而写，但是一些场景能做自动化的反而没做。整个用例的测试结构不稳定，时对时错，还有测试用例质量差，测试用例永远不报错，为什么？因为测试用例连最基本的一些断弦都没有。




在面对这些测试问题我觉得解决起来也很朴实，首先你要提升你的测试覆盖率，其实提升测试覆盖率也有策略的，至少要先要把核心场景覆盖了，这时候再去覆盖一般场景，最后再可能实现全场景覆盖。至少你哪些已经覆盖了，后边手工测试就可以简化一些，回归也会质量更高更快一些，还有就是收到了用例积累时间不够，这个我觉得没有办法，就是想办法积累。




然后就是要提升修复测试的误报率，就有一些误报的测试要及时修复，否则后面会很干扰你测试的质量，那就没有什么效果。还有就是用例设计要考虑整个数据的独立性，就是整体怎么提升测试率的质量，我觉得比较好的方式就是定期的用例评审，分级的用例评审。

说到自动化测试，发现做了自动化测试，但在一个团队里大家都不知道自己在做什么，或者怎么做，可能会有一些谁也不知道怎么做，这样的话建议把自动化测试体系这块做得健全一些，这一方面我也是结合之前的经验，在建自动化测试体系里面应该有一些能力。




第一就是测试分层，分层方法，分层策略，测试时机，这一块其实史立龙老师也介绍了，测试分层并不是说，因为我这边给大家列了几个，像比较流行的，三角形、纺锤形、橄榄球形，这个是给大家的一个参考，真正做自动化测试分层的时候要结合实际的业务形态，比如说像我之前做外网合格服务的时可能倾向于做接口级的测试，因为我觉得这个接口级的测试成本最低，这种情况下我本来如果画一些单测去和UI集中精力做接口级的测试。




还有可能在我之前会偏向于前端大服务端，其实在那个阶段我比较倾向于三角形，那个时候觉得单测是执行最快，成本最低，维护起来也是最容易。但是其实还有，你可能有一些老的项目，可能之前已经积累很多代码没有单测，这个时候还是视大家的实际情况，但是首先要把你的分层策略明确下来，在你的组织上执行，这样整个你的测试团队至少你的思想是统一的。那这是测试分层。




还有代码质量管理，这一块现在已经有很好的工具，只要定义好规则、方式，及时做修复，这一方面有一点大家一定要注意质量规则，因为我也遇到过一个客户，他们用了很多规则，我记得当时一开始的时候有一千多条规则，我说这些规则你们怎么定门禁？当时他们就一愣。其实就是我们的规则一开始没有必要定义过多，定一个适合的，把相应的门禁配上，然后严格执行，随着你不断增加去更新你的规则，比如说你需要定期的更新，有一些好的规则让我加入，有一些不适用的你要定期去移除，这样也避免你质量门禁那一块产生困扰。




自动化测试设计，因为现在一些大企业整个测试团队不是一个人，首先要从你的设计、开发、执行要定义清楚，至少有统一的工具、统一的架构，你的开发将来不同的人调用你的开发模式，你写的用例应该是相似的，因为我之前是开发的，所以我比较看重这种。之前我没有这种设计，在做接口的时候比如前期定义这个接口，接口都可以了，评审都通过了才会进行实际的开发。还有就是测试数据管理这一块，你要把你的数据来源、数据覆盖、数据独立性这一块要去规范清楚。这是我的测试体系不健全这块的建议。

说到度量，DevOps 也实施了，有什么效果？之前也问过一个客户，客户说会统计需求的交付周期，现在流水线有一千多条，自动化接口有多少多少。但是我想这些真的是 DevOps 需要的吗？所以说很多 DevOps 是为了什么？是为了提效增质、安全，但是这些我是没有看到。所以这一块也是整理了一些结合我之前的经验还有一些企业里面总结比较好的度量指标。




首先要从需求在各阶段的停留时长，还有就是需求的逃逸率，逃逸率就是生产缺陷，研发阶段缺陷及自动化测试的误报率，这个指标也非常好，如果你看你的自动化测试的质量。还有就是技术债务，这方面其实非常重要，你要看整体的代码质量是不是有一个维持上下的趋势和稳定，还有 DevOps 里核心的其他指标，就是变更的前置时间、部署频率，变更失败率、服务恢复时长，每个点其实都是能通过度量去驱动改进。每个点做指标的时候，首先要明确你的受众，这些指标是给谁看，还有每个指标要直指问题，并且这个是可度量的，反馈问题以后要驱动改进，改进完了之后要能看到你的这个指标是变好还是变坏？




在右边的图，其实还会积累一些其他的一些企业实践里面更好的指标，大家看一下，比如像代码提交频率、效能指标、测试成功率等等。时间关系后边我们再去看。

还有就是整个在项目实施过程中也会遇到很严重的坑，没有明确实施路线和目标。DevOps要做成什么样子？我们怎么做？其实 DevOps 本身就像盲人摸象，可能每个人手上有大量的资料，但是看完这些资料都有不同的理解。




结合我这边的经验，还有我们现在也有一个至少在设计里面有比较好的实践，就是如果参照标准执行，至少我发现了一个比较好的标准，这个标准可执行，比如在 DevOps 里面覆盖哪些领域，每个领域都会定义很清楚，比如说在不同阶段不同的级别应该做成什么样子，做成什么样子才能达到这种级别？我觉得这个建议大家还是参考标准，通过这种赋能培训的方式希望大家有一个对 DevOps 的认识，并且能明确在做到什么情况下能达到一个什么水平，基于这个水平定义我们的目标。

定好目标了整个 DevOps 的实施路线，结合我之前在企业的一些经验给大家做了总结。首先要选择试点项目、组件推进小组、了解项目现状，然后识别你要改进的事项和痛点，改进获得成功，提升信心，然后持续用这种方式改进。


这块其实也是怎么去识别痛点，也是刚刚上图有一个标准，其实 DevOps 标准里有一些很明确，你能通过标准去看当前的项目的状况在哪里，可以基于标准对照有哪些问题。


我觉得大家后边可以去了解一下，我觉得这个是比较好的方式，为什么？如果你没有目标，尤其是这两年企业，一般都是重效率，看产出。做一个没有目标没有结果的项目，很多领导不会支持你。

实施 DevOps 过程中有一个很容易犯错的就是经常选错实验田，DevOps 虽然好，但在实施过程中选择的实验团队经常有误区。一开始我们心很大，会选择一个很大的团队，或者选择不是核心业务的团队，做着做着资源也就没有保证，或者选一个非敏捷业务团队，过来要去做敏捷导入，可能这个时间效果也不好，还有可能综合能力比较差动手能力也差。


DevOps 和敏捷对整个团队的能力要求越高越好，还有确定你是否团队其他同事认同DevOps 的价值。总结我在企业和自己在团队的实践经验，我觉得 DevOps 试点选择的时候应该考虑以下几点：

• 贴近核心的业务团队。因为这样资源有保证，而且实施出来的效果后再往下推的时候别人也能认；
• 团队规模要适中，以我的经验来说要控制在20人左右，因为 DevOps 也是属于一个变革的过程，人多沟通起来成本也会高，实施效果其实也会有影响；
• 敏捷的业务；
• 项目压力不能太大。因为做任何的变革，包括变敏捷的时候也要有一个适应期，这个时候压力太大，可能业务那边被迫无法配合你，尤其很多企业有窗口期，到什么时候你就要上，所以你要选一个压力适中的；
• 认同 DevOps 的价值。这个是我们在选择团队的时候要做的。
  

实施 DevOps 过程中，一个很正常的就是，会有一个J型曲线，一开始可能很顺利，团队转型也起到一定的效果，比如说自动化测试，自动化效能能配套整个流程和效能会有一定的提升，但是接下来马上就会有一个向下，为什么？因为一些自动化导致我们的人工处理测试需求也会增加，也会有大量的技术债阻碍我们的进展。

还有技术债变更会导致变更流程中增加人工的控制环节，过程审批环节，减缓工作速度。这其实在 DevOps 实施过程中很正常。

用什么方案解决？其实在实施 DevOps 前期要组件一个 DevOps 转型小组，这里面包括大领导的配合，顶住业务压力，支持你的转型。然后业务团队、工具团队，有了这些相当于一个专家来推动，你在遇到问题时能够很快解决。在转型过程中要经常给大家信心，怎么给？经常借助评估标准的方式，以评促建，以评促改，这是我们的一些经验。

下面还有最重要的一个坑，就是在没有获得高层领导就开工，我觉得这个是最大的一个坑，其实 DevOps 实施是一种突破现有习惯和流程，改革现有文化，通过文化、工具、流程三位一体整体的实施，所以说很容易遇到部门墙和业务团队、工具团队的不配合，甚至会改变我们现有的审批流程和结构，还有关键的就是需要人，需要软件资源，需要时间，这些其实没有一个高层管理者的支持，实施过程中很容易断粮，导致你的莫名其妙 DevOps 实施就失败了。

那怎么来获得领导的支持？这边我觉得你要跟领导讲清楚，DevOps的价值，你要让领导对你的这个项目有信心。首先DevOps价值里面能够提升提质增效，减少我们停机时间，更快上线，让我们的上线更安全，故障更少，同时通过自动化减少我们的人员流失带来的伤害。


还有就是行业趋势，同行已经在这样做了，同时就是这几个是定性的指标。同时DevOps自身也有一些可量化的指标，那就是说我们的部署频率、变更前置时间、服务恢复时间，变更失败率，其实这些都能在DevOps里面体现出来，这些都是你的能去说服领导做 DevOps 的。还有一个很重要的就是同行对比，右边的图大家可以看到，我们通过DevOps评估的方式，能让你看，比如说实施DevOps之后，我能达到一个什么水平，其实我是不光跟内部比质量提升，还有可以跟同行比，看在这个行业里的一个水平。

总结总结一下，什么是一个好的 DevOps？我借鉴了 DevOps 三剑客的内容，一个 Feature 从开发到上线的关键路径上，除了功能开发的时间要尽量短，这就是一个好的 DevOps。整个实施 DevOps 过程中，如果不改变下游流程以及人的行为习惯去实施 DevOps，本身就是不现实的，要机制改变行为，行为改进文化。这个就是我关于 DevOps 的一个分享，后续有兴趣可以联系我们，谢谢大家。（施景丰）