DevOps 实施中的10个“深坑”，你必定要警戒

做者简介

施景丰
DevOps 标准编写专家
高效运维社区资深 DevOps 专家

我叫施景丰，来自高效运维社区，多年一线开发、测试、架构经验，在软件方面有十多年的工做经验，聚焦金融行业\通讯行业\工业互联网行业\大数据行业工程效率的提高及 DevOps 解决方案的实施。

首先说 DevOps 很是重要，今年实际上是一个很特别的年份，遇上疫情，触动最大的就是开年的法定上班日是2月10号，你们开始远程办公，开工当天朋友圈基本就刷爆了，我想问一下你们远程办公第一天的障碍是什么？反正从我这边的朋友圈看到的都是各类会议室不稳定，***连不上，电话占线之类，还有开发反馈代码下不下来，开发等测试，部署也无法进行。
但在朋友圈这些“负面”消息中，发现朋友圈有一个亮点，我以为这个颇有意义，就是咱们的一个客户，他们在应对疫情方面显得很是从容，也是远程办公，但各项工做层次分明，并且还在“朋友圈撒狗粮”，表达 DevOps 对咱们帮助很大。
能够说这一点也是这两年 DevOps 红透半边天的缘由，其实我以为这是一个很常见的现象，最近几年每一个企业都特别注重工程效率的提高，在工程效率提高这方面， DevOps 绝对是一个最亮的明星词，你们都在想怎么经过 DevOps 改进研发效率。
DevOps 这么好，但企业在实施 DevOps 过程当中发现并不容易，并且作着作着可能死掉了，那么在这里结合我本身的经验，还有最近给企业作转型实施时发现的问题，总结了 DevOps 实施过程当中的 10 个深坑，给你们作一个简单的分享。

先给你们总体介绍一下，我整理的十个深坑。

• 1、流水线设计不合理
• 2、质量内建不足
• 3、安全能力和 DevOps 分裂
• 4、自动化测试不能被信任
• 5、自动化测试体系不健全
• 6、度量与可视化能力薄弱
• 7、选错了实验田
• 8、不明确痛点和收益就开工
• 9、转型途中半途而废
• 10、没有高层领导的支持就开工

下面来给你们逐条分析每一个问题。

1.流水线设计不合理

---

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

常见的问题好比缺乏提交即构建，咱们要不要作提交即构建？由于有一个误区，就是会有流水线从头至尾只有一条的状况，但其实不是这样。还有就是开发和测试会脱节，好比开发这边有一套 Jenkins，测试也维护一套 Jenkins，甚至流水线没有集成自动化测试，其实就是从构建编译最终到发布，可是这条流水线有点造成虚设，下面的流水线还有大量的手工操做。
在流水线里面没有质量门禁也是一个问题，合乎门禁作得比较弱，就是起不到门禁的效果。还有单元测试，有的没有，有的甚至覆盖率很是低。还有整个会有大量重复的构建，而不是制品晋级的方式。
说到这个，好的流水线应该是什么样？其实就是刚才说的提交即构建这个问题，我以为提交即构建，首先就是提交以后应尽早发现问题、实现问题，可是提交即构建并不必定放到完整的一条流水线里，咱们通常会独立出一条提交即构建的流水线，至少它不会到交付和发布阶段作提交即构建。

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

这里也给你们介绍一下金融机构的流水线是什么样，由于材料会涉及到客户的隐私问题，也只能找一些公开的材料。
首先说明这是某家金融机构的流水线，他们有提交即构建的功能，这个流水线是干什么的？首先是代码提交即构建，提交即构建流水线不够，MR是确定不经过的，还有代码评审，我也是建议把这个功能建上，由提交构建是单独流水线，在作代码评审时都会等你的单测，检查以后这些都过了，才作代码评审。由于我以为我这我的比较懒，若是在以前能用自动化的工具，我绝对不会费个人眼睛。
应用部署流水线也在这里解释一下，由于流水线不是一条，你能够按阶段去定制流水线，还有就是开发比较灵活的时候，像以前咱们会把流水线实践成多条，单条可执行，流水线之间是能够首尾相接的，这一块后边你们须要，咱们能够单独分享。
再者就是要有一条独立的数据库变动流水线，这是某金融机构的流水线，你们有可能在网上也能找到相关的信息。

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

2.流水线内建质量不足

---

顺着第一个，第二个就是流水线的内建质量不足，这也是一个坑。举一个例子，就是在说到内建质量时一般拿这两个例子，一是美国汽车流水线，常常会在流水线末端有一我的拿锤子敲敲打打来检验这个门的质量是否是OK。若是要靠最后的人去验证车的质量是否OK，我以为这是是不对的。
另一个就是丰田公司，他们是怎么作流水线的？其实就是在流水线有一个安灯系统，这个流水线在执行过程当中，只要任何人发现问题均可以亮红灯，能够立刻发现去修复，用这种方式把前期在流水线跑完，出来之后确定是一个质量OK的。
那接着这个问题说一下在软件流水线中常见的问题，常常是有单元测试，可是单元测试很低，也没有代码评审，或者代码评审放得比较靠后，或者要投产的时候才会作代码评审，还有就是流水线的缺乏静态代码检查或者门禁标准很是低，很容易过了。
说到质量内建，我以为你们应该遵循两个原则，其实这个不是说经过 DevOps 才有，其实在最先的时候，问题发现越早，修复成本越低。质量是每一个人的责任，而不仅是测试团队的责任。我以为从经验上来讲，流水线质量内建的核心就是检验左移，就是尽可能把在流水线最左端能识别出来的问题就不要把它放到右端，但这么说，现实中实现起来你们仍是要酌情处理。
我这边的建议是质量左移的工具是持续可见的过程，这块的意思是，结合我之前的经验，好比最开始会肯定一个检查类型，单测和覆盖率要多少，还有就是静态代码检查，我会很注重左侧和，还有这通常的经验性我就会放宽一点，若是不这样，一开始你的质量门永远过不去。
还有基于这个咱们会定义质量阈值，就是刚才说到的，好比覆盖率要百分之百过，错误（error）要百分之百过，你可能一边检查，或者一边建议型的，后面就是做为技术栈。你设定一个阈值，基于这个阈值在质量门禁里强制执行。
至于质量门禁一开始要定义你的处理方式，好比怎么去修复，很严重的问题是否是要作回本，不能影响其余人的流水线去跑。你要制定规则，根据这个规则持续改进。好比说质量提高，要从新去定义检查类型和范围，不断提高内建质量。这是个人一个建议的过程。

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

3.安全能力和 DevOps 相割裂

---

有了流水线，DevOps 也建得差很少，那目前来讲发现安全能力其实跟整个的 DevOps 其实仍是隔离的，这也是一个广泛存在的问题。从去年的 DevOps 国际峰会（DOIS），你们对 DevOps 已经愈来愈重视，但速度很是快，特别像去年的网络安全会，一些安全事件来推进你必需要赶快把安全问题内建到 DevOps 能力里，再实施 DevOps，若是不考虑安全问题，我以为 DevOps 的总体实施也是一个落后。
这一块我也整理了基于 DevOps 工具链和 DevOps 研发过程的阶段，即项目过程管理、配置管理、构建串起来，而且附了一些相关的安全的方法。好比说在这个过程当中，须要天天作安全培训，安全需求威胁模型分析，在配置管理阶段要引入OWASP理论，还有IDE的安全插件，而后去补充安全相关的技术栈。构建方面，在门禁上配置安全门，还有就是配置分析、单元测试，静态扫描也要充分的归入一些安全方法。
测试质量这方面可能要有动静交互应用安全测试，还有混沌工程等等，制品库这块刚刚 JFrog 王青老师也介绍了，其实制品库已经在往安全方面注入了不少东西，包括实际过程当中还要作安全扫描、***测试这些安全策略签名等。在基础设施咱们要增强安全监控、配置监控，也要有分析，后边就是什么协同沟通、快速反馈，还有就是可视化要SIEM安全信息和事件管理。

4.自动化测试不被信任

---

说到流水线，还有一个很大的问题，就是自动化测试不被信任，这个我以为对于自动化测试每一个企业都会有这个，由于自动化解决了咱们如今测试面临很难的问题，就是测试时间愈来愈多，可是整个测试时间愈来愈短，可是真正作起来，据我走访的企业，不少要不没有自动化测试，要不有，可是也是马马虎虎。
在实施 DevOps 初期，可能要面临一些相关的问题就是自动化测试用例覆盖不够，还有选用须要积累时间，整个误报率居高不下，自动化在跑，错了就错，有一些问题你们也不处理，关键是场景覆盖不够，可能就是为了写一些自动化测试而写，可是一些场景能作自动化的反而没作。整个用例的测试结构不稳定，时对时错，还有测试用例质量差，测试用例永远不报错，为何？由于测试用例连最基本的一些断弦都没有。
在面对这些测试问题我以为解决起来也很朴实，首先你要提高你的测试覆盖率，其实提高测试覆盖率也有策略的，至少要先要把核心场景覆盖了，这时候再去覆盖通常场景，最后再可能实现全场景覆盖。至少你哪些已经覆盖了，后边手工测试就能够简化一些，回归也会质量更高更快一些，还有就是收到了用例积累时间不够，这个我以为没有办法，就是想办法积累。
而后就是要提高修复测试的误报率，就有一些误报的测试要及时修复，不然后面会很干扰你测试的质量，那就没有什么效果。还有就是用例设计要考虑整个数据的独立性，就是总体怎么提高测试率的质量，我以为比较好的方式就是按期的用例评审，分级的用例评审。

5.自动化测试体系不健全

---

说到自动化测试，发现作了自动化测试，但在一个团队里你们都不知道本身在作什么，或者怎么作，可能会有一些谁也不知道怎么作，这样的话建议把自动化测试体系这块作得健全一些，这一方面我也是结合以前的经验，在建自动化测试体系里面应该有一些能力。
第一就是测试分层，分层方法，分层策略，测试时机，这一块其实史立龙老师也介绍了，测试分层并非说，由于我这边给你们列了几个，像比较流行的，三角形、纺锤形、橄榄球形，这个是给你们的一个参考，真正作自动化测试分层的时候要结合实际的业务形态，好比说像我以前作外网合格服务的时可能倾向于作接口级的测试，由于我以为这个接口级的测试成本最低，这种状况下我原本若是画一些单测去和UI集中精力作接口级的测试。
还有可能在我以前会偏向于前端大服务端，其实在那个阶段我比较倾向于三角形，那个时候以为单测是执行最快，成本最低，维护起来也是最容易。可是其实还有，你可能有一些老的项目，可能以前已经积累不少代码没有单测，这个时候仍是视你们的实际状况，可是首先要把你的分层策略明确下来，在你的组织上执行，这样整个你的测试团队至少你的思想是统一的。那这是测试分层。
还有代码质量管理，这一块如今已经有很好的工具，只要定义好规则、方式，及时作修复，这一方面有一点你们必定要注意质量规则，由于我也遇到过一个客户，他们用了不少规则，我记得当时一开始的时候有一千多条规则，我说这些规则大家怎么定门禁？当时他们就一愣。其实就是咱们的规则一开始没有必要定义过多，定一个适合的，把相应的门禁配上，而后严格执行，随着你不断增长去更新你的规则，好比说你须要按期的更新，有一些好的规则让我加入，有一些不适用的你要按期去移除，这样也避免你质量门禁那一块产生困扰。
自动化测试设计，由于如今一些大企业整个测试团队不是一我的，首先要从你的设计、开发、执行要定义清楚，至少有统一的工具、统一的架构，你的开发未来不一样的人调用你的开发模式，你写的用例应该是类似的，由于我以前是开发的，因此我比较看重这种。以前我没有这种设计，在作接口的时候好比前期定义这个接口，接口均可以了，评审都经过了才会进行实际的开发。还有就是测试数据管理这一块，你要把你的数据来源、数据覆盖、数据独立性这一块要去规范清楚。这是个人测试体系不健全这块的建议。

6.度量可视化与驱动改进能力薄弱

---

说到度量，DevOps 也实施了，有什么效果？以前也问过一个客户，客户说会统计需求的交付周期，如今流水线有一千多条，自动化接口有多少多少。可是我想这些真的是 DevOps 须要的吗？因此说不少 DevOps 是为了什么？是为了提效增质、安全，可是这些我是没有看到。因此这一块也是整理了一些结合我以前的经验还有一些企业里面总结比较好的度量指标。
首先要从需求在各阶段的停留时长，还有就是需求的逃逸率，逃逸率就是生产缺陷，研发阶段缺陷及自动化测试的误报率，这个指标也很是好，若是你看你的自动化测试的质量。还有就是技术债务，这方面其实很是重要，你要看总体的代码质量是否是有一个维持上下的趋势和稳定，还有 DevOps 里核心的其余指标，就是变动的前置时间、部署频率，变动失败率、服务恢复时长，每一个点其实都是能经过度量去驱动改进。每一个点作指标的时候，首先要明确你的受众，这些指标是给谁看，还有每一个指标要直指问题，而且这个是可度量的，反馈问题之后要驱动改进，改进完了以后要能看到你的这个指标是变好仍是变坏？
在右边的图，其实还会积累一些其余的一些企业实践里面更好的指标，你们看一下，好比像代码提交频率、效能指标、测试成功率等等。时间关系后边咱们再去看。

7.没有目标和实施路线图

---

还有就是整个在项目实施过程当中也会遇到很严重的坑，没有明确实施路线和目标。DevOps 要作成什么样子？咱们怎么作？其实 DevOps 自己就像盲人摸象，可能每一个人手上有大量的资料，可是看完这些资料都有不一样的理解。
结合我这边的经验，还有咱们如今也有一个至少在设计里面有比较好的实践，就是若是参照标准执行，至少我发现了一个比较好的标准，这个标准可执行，好比在 DevOps 里面覆盖哪些领域，每一个领域都会定义很清楚，好比说在不一样阶段不一样的级别应该作成什么样子，作成什么样子才能达到这种级别？我以为这个建议你们仍是参考标准，经过这种赋能培训的方式但愿你们有一个对 DevOps 的认识，而且能明确在作到什么状况下能达到一个什么水平，基于这个水平定义咱们的目标。

定好目标了整个 DevOps 的实施路线，结合我以前在企业的一些经验给你们作了总结。首先要选择试点项目、组件推动小组、了解项目现状，而后识别你要改进的事项和痛点，改进得到成功，提高信心，而后持续用这种方式改进。
这块其实也是怎么去识别痛点，也是刚刚上图有一个标准，其实 DevOps 标准里有一些很明确，你能经过标准去看当前的项目的情况在哪里，能够基于标准对照有哪些问题。
我以为你们后边能够去了解一下，我以为这个是比较好的方式，为何？若是你没有目标，尤为是这两年企业，通常都是重效率，看产出。作一个没有目标没有结果的项目，不少领导不会支持你。

8. 选错实验田

---

实施 DevOps 过程当中有一个很容易犯错的就是常常选错实验田，DevOps 虽然好，但在实施过程当中选择的实验团队常常有误区。一开始咱们心很大，会选择一个很大的团队，或者选择不是核心业务的团队，作着作着资源也就没有保证，或者选一个非敏捷业务团队，过来要去作敏捷导入，可能这个时间效果也很差，还有可能综合能力比较差动手能力也差。
DevOps 和敏捷对整个团队的能力要求越高越好，还有肯定你是否团队其余同事认同DevOps 的价值。总结我在企业和本身在团队的实践经验，我以为 DevOps 试点选择的时候应该考虑如下几点：

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

9.DevOps 实施过程受阻，转型半途而废

---

实施 DevOps 过程当中，一个很正常的就是，会有一个J型曲线，一开始可能很顺利，团队转型也起到必定的效果，好比说自动化测试，自动化效能能配套整个流程和效能会有必定的提高，可是接下来立刻就会有一个向下，为何？由于一些自动化致使咱们的人工处理测试需求也会增长，也会有大量的技术债阻碍咱们的进展。
还有技术债变动会致使变动流程中增长人工的控制环节，过程审批环节，减缓工做速度。这其实在 DevOps 实施过程当中很正常。
用什么方案解决？其实在实施 DevOps 前期要组件一个 DevOps 转型小组，这里面包括大领导的配合，顶住业务压力，支持你的转型。而后业务团队、工具团队，有了这些至关于一个专家来推进，你在遇到问题时可以很快解决。在转型过程当中要常常给你们信心，怎么给？常常借助评估标准的方式，以评促建，以评促改，这是咱们的一些经验。

10.没有得到高层领导的支持就开工

---

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

那怎么来得到领导的支持？这边我以为你要跟领导讲清楚，DevOps的价值，你要让领导对你的这个项目有信心。首先DevOps价值里面可以提高提质增效，减小咱们停机时间，更快上线，让咱们的上线更安全，故障更少，同时经过自动化减小咱们的人员流失带来的伤害。
还有就是行业趋势，同行已经在这样作了，同时就是这几个是定性的指标。同时DevOps自身也有一些可量化的指标，那就是说咱们的部署频率、变动前置时间、服务恢复时间，变动失败率，其实这些都能在DevOps里面体现出来，这些都是你的能去说服领导作 DevOps 的。还有一个很重要的就是同行对比，右边的图你们能够看到，咱们经过DevOps评估的方式，能让你看，好比说实施DevOps以后，我能达到一个什么水平，其实我是不光跟内部比质量提高，还有能够跟同行比，看在这个行业里的一个水平。

总结

---

总结一下，什么是一个好的 DevOps？我借鉴了 DevOps 三剑客的内容，一个 Feature 从开发到上线的关键路径上，除了功能开发的时间要尽可能短，这就是一个好的 DevOps。整个实施 DevOps 过程当中，若是不改变下游流程以及人的行为习惯去实施 DevOps，自己就是不现实的，要机制改变行为，行为改进文化。