DevOps的工程化

 

孙敬云 --Worktile高级系统架构师，WTC成员

1.研发的困境

互联网的环境

互联网这个环境比较特别，包括如今不仅是互联网，就算是被互联网赋能的这些“互联网+”的企业也在改变，用户在发生变化，用户构成的群体在发生变化，群体形成场景的变化，场景营造新需求，需求养成新用户习惯，新用户习惯造就一批新用户，周而复始。咱们一直在追赶用户，但从用户的角度来讲，他一直都指望有一个好的产品和一个稳定的服务。相信在座各位既是技术从业者也是普通的用户，你们会发现本身老是想尝试一些新的东西和好的东西。

 

 

软件交付的困境

进度不可控： 咱们的研发团队会面临一个问题，一些传统的行业也好，或者如今在实行Sprnit的团队也好，你会发现研发 进度很是不可控 。你有时候感受一切都很可控，完成任务的时候前80%也以为没问题，必定能交付。但一旦到了后20%，测试报出海量的bug，运维问你怎么部署？好多东西尚未定，愈来愈忙。尤为是上线的晚上，必定要搞一个通宵才能把全部的问题解决。这种复杂的困境是技术不可控的;

流程不可靠： 咱们公司老是有各式各样的流程发生，但你会发现这个流程走着走着老是须要有一些 关键角色 蹦出来，必须有一些企业大牛或团队经理站出来讲这个事情应该怎样作，或者说今天谁谁没来，这个流程无法往下作。

环境不稳定： 线上怎么就出问题了？测试环境好好的，本地就没问题，是否是由于线上没有按照我说的作？环境这个问题在哪一个公司都会遇到。

沟通不顺利：研发同窗跟运维同窗在争论，研发同窗说上线以后跑脚本，运维跑完了上线出了问题。研发同窗就问他“你跑脚本了吗？”他说“跑了”，“是部署前跑的仍是部署后跑的？”他说“你没有跟我说这个。”这就是沟通不畅，这个原本是能够避免的。

 

 

咱们须要一种工程手法，让软件在很短的周期内稳定部署上线。 关键词是 “很短” 和 “稳定” ，甚至一键部署到任何版本任何环境中，甚至这些操做都在可视化的环境进行。咱们在研发团队中说，凡是要定目标作计划，怎么办？咱们今天每一个人给本身定一个目标： 从今天开始每一个团队一天部署三次 。你们以为不可能，安排计划Sprint两天就够呛了，怎么可能一天上线三次？

举一个真实的例子

汇丰银行在2014年的时候整年release24次，这个数字至关于 两周有一个 release的版本，很高效。可是2018年整年release12000次，这是什么概念？你今天一天release 几十 次，你们以为这不可能，开发代码能写完吗？这就是一种思惟方式的转变。

若是咱们今天说必定要达成这个目标，无论可能不可能，给我一个执行方案和参考的借鉴点。

概念的组合

咱们把这个事情分为四个步骤：

第一步 ，自动化的流水线，这是稳定可重复使用的。
第二步 ，支持构建流水线所须要的技术平台和工具。
第三步 ，运行这些平台完成流水线所须要的人和角色。
第四步 ，支持可以把这些全部东西所有落地并有稳定持续改善方案的文化与规则。

2.DevOps是什么？

DevOps在维基百科上的定义

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

因此前面全部的都是定语，只有最后一句最关键，就是 ：频繁可靠的发布软件，这就是咱们的终极目标。

 

 

针对刚才定义的原始阐述，从这个环形图上的工做方式，一直在持续演进，好像看起来没有什么特别的，这个神奇点在哪？

 

 

若是你跟别人说你今天看了一篇分享是DevOps，或者你去搜DevOps，会发现所包含的含义和相关的含义特别多，包括 精益思想、自动化、持续集成、持续部署、价值流、三步工做法、持续交付、分级部署、敏捷思想、敏捷开发、团队合做 。

 

 

在我看来这是你们对于美好事物的一种指望，指望DevOps能承担更多。即便咱们今天不提DevOps这个词，把敏捷这个词说出来，你也会说敏捷包含这些部分，换个词也是这样。我认为咱们 千万不要陷入于这个词的含义是什么 ，我是想谈 工程化 ，谈 工程化背后美好的东西。

“持续交付”和“DevOps”

咱们挑两个特别容易被网上的人或你们所对比的词汇，一个是 持续交付 ，一个是 DevOps 。

 

 

持续交付也好，DevOps也好，他们的共同点是秉持交付思想，他们都崇尚精益思想，他们都喜欢自动化，他们都以快速和稳定的变动为目标，这是两个共同点。持续交付偏向于将不一样的过程集中起来，而且更快更频繁地执行这个过程。

虽然咱们对比了这两个词，但我但愿你们不要过分陷入于概念自己，不是说我今天学的到底是DevOps仍是持续交付，这个没有意义。咱们要把好的思想带回项目组，带回团队，能不能落地是咱们的关注点，咱们不要过多对比概念。

基础参与人

凡是涉及人的话题，必定是比较特别的，你只要不把人的范围说清楚，这个事情就别想落地。只要你没说这个事情让他作，他就不会主动问你，若是你主动问你说明这我的是优秀员工。

把敏捷开发单独四个字列出来，持续部署跟持续交付看似范围同样，但持续交付指的是我有交付能力，但我没说必定要部署到线上环境。持续部署讲的是如今既然已经完成了构建的流水线，那么就从头走到尾就结束了，这个讲的是自动化。DevOps讲的是什么？范围好像如出一辙，但 DevOps不强调每个角色应该干什么，而是将全部的角色聚集在一块儿 ，有点像敏捷思想里面的 角色互换 ，你们谁都能干这个事情，不用指定这个事情，你们能够角色互换一块儿来作，因此 DevOps不强调每个人谁是谁，而是强调这些人聚集到一块儿以后，你可以将开发编译测试一次性完成 ，这是他们的区别点。

 

 

3.DevOps工程化

工程化这个词不知道你们怎么理解，你在写代码的时候，咱们说你的代码结构好，你的框架设计得好，这实际上是一个工程，由于它落地。咱们今天谈的DevOps工程化也指的这个含义，到如今为止都是一些比较抽象的概念，它是一些比较好的理念，没有具体的落地点，你没法感觉到它真正的好。

 

 

若是你的团队想要去实施DevOps，从个人观点来讲它由 四部分 组成。

流水线： 流水线必定要自动化，自动化的流水线必须是可靠、可重复、高效的流水线，你的流水线必定要可视化，全程可见，出了问题能够提示你，将你的部署交付给他，完成到哪一步，完成的效果怎么样，咱们须要有实时反馈和实时监督。

技术平台和工具： 这个技术平台我列了 容器 和 集群 ，有人可能说咱们公司也作了流水线，也作了自动化，没有用容器作也挺好的。不知道有没有人最近关注国际和国内比较流行的词汇，最近我发现有两种思惟比较大，一个是微服务，一个是云原生。

你们知道云原生是什么意思吗？你的服务不管部署在哪个云服务的提供商上，它均可以正常去跑，这是一个基金会发起的很是好的倡议。你在百度云上作的好好的，能够拿到阿里云、华为云去作，代码一行都不用变。若是你的部署方式基于物理机而不是容器，未来想作云原生就很难，云原生必定是历史趋势，我建议若是想实施，你能够提早往前多走一步，直接到容器化。使用容器有这么几点。一是既然使用容器必定要有标准化，你的容器是怎么构建的，里面包含哪些东西，须要启动的方式是怎样的，须要怎样的运行，这都是须要你本身规划跟设计的。

有了容器就要有私有镜像仓库，往DockerHub去推，若是被别人拿下来可能会形成代码泄露的问题，因此咱们要搭建私有镜像仓储。再往下要有集群，当前的集群很是多，并且都很是成熟，从今年开始聊Kubernetes的人愈来愈多，由于去年它已经赢得了集群的胜利。自从发表了1.3，如今有1.4，立刻要发布1.5，如今愈来愈强大了，集群这个事情越早越好，我相信有梦想的工程师都想创造出一个QPS几十万的服务。当这一瞬间忽然来的时候，你的服务能不能扛得住？你的基础设施够不够稳定？这就形成了极大的挑战，这时候就须要集群帮你管理一切。
若是有集群，要提早构想微服务怎么搭，怎么充分利用集群的价值。若是用微服务也好，用集群也好，部署管理怎么作，每一份要怎么布，怎么作熔断机制，怎么作监控报警，怎么作扩容，全部的这些东西都须要本身提早考虑，须要提早想清楚。

人和角色： 主要分两类， 开发测试 和 运维 。开发跟测试放在一块儿，由于我认为这两个角色按道理来讲是属于一个工种。在谷歌实际上是没有测试这个职业的，他们都叫QA，都是质量控制帮你把控质量。在百度的时候也没有测试的概念，QA前线大到什么程度？开发了代码就不让你上线，就怀疑有问题，由于我有数据，我发现你的执行速度慢了一毫秒，你将影响咱们多少用户？这些用户加到一块儿是多少小时？你能承担起吗？他们一说我就没话了，承担不起就不上了，不上了老板找谁？由于已经答应了上线。因此开发跟测试必定要搞好关系，咱们是一块儿的，你必定要让我上，你让我上了请你吃饭，咱们俩是一家人。这个是玩笑话，这两个角色不要对立，它们是一块儿的，要共同搭建分支策略。你们必定会听过标准代码分支管理，它们须要共同搭建持续集成。你提交任何一个代码进行持续集成，保证整个代码的质量持续稳定交付，就是须要持续集成做为保证和前提。

文化规则： 讲到团队文化，你们可能会以为很虚，以为不切实际，好像离咱们很远。

举个例子 ，一个好的团队文化，尤为是DevOps团队或敏捷团队，必定要讲角色的互换。今天你作这件事情，明天能够作另外一件事情。咱们不是说缺了谁就不能上线，缺了谁公司就无法转，咱们应该灵活转变本身。如今有一个很是好的职位叫DevOps工程师，什么都能干，甚至DevOps工程师要强到什么程度？他须要出来说课培训DevOps，有时候客户一咨询，我解答不了，可能DevOps工程师写着写着代码就去回答问题了。

说完了整个架构图，咱们再从头看一下 流水线的概念 。

 

 

这是DevOps和持续交付里面标准的流水线。

程序编译 --这个不用多说，不管开发哪一个语言，除了脚本语言以外，多数的语言都有编译环节，原文件要编译要编译成另一种形态才能运行。

单元测试 --我建议你们有空都要写单元测试，单元测试是很是好的东西，由于你写了单元测试以后就会发现，你跟QA的关系会变得很是好，你就不必麻烦他了。

集成测试 --每一块独立的东西测试没问题，放到一块儿以后测能不能正常工做？

性能测试 --你今天上的东西对于咱们如今已经有的东西性能是有提高仍是有损耗？

日志测试 --不少东西表现没问题，但日志中老是报奇怪的错误，有些人意识好，可能会打各类各样的debug。若是你有了日志分析这一步，必定会发现潜在地方有潜在的漏洞，也许到了线上会变动成严重的问题，这个东西在写单元测试的时候可能考虑不到，咱们须要这几步来保证持续集成的正确性。到这为止是持续集成的核心。

镜像 --将如今全部的东西放到一块儿，打成最终的镜像，把镜像上传到云端，专业术语叫制品库。

预发布、验收、部署上线 --验收是预发布环境作回归测试，没有问题就能够直接上线，这个地方能够手动也能够自动，咱们只讲流水线不讲到底指持续部署仍是持续交付。

实战入门

演示时用到的技术若是你们没有接触过也不要紧，一步一步来就行了。

 

 

Gitlab、Docker、Kubernetes、Helm、Harbor、Jenkins这些都是比较标准的，只是入门，咱们只是增强这个意识。

 

 

首先咱们要进行代码分支规范。主干分支切开发分支，完成以后向开发分支提代码，这时候会触发持续集成，验证向分支提交代码是否安全是否对，刚才的东西跑没跑过，跑过要加入代码质量跟代码的review，没有问题往下走，开发分支结束，咱们把东西提交到我的分支上，把代码部署到某一个环境，假如说是测试环境。

 

 

这是持续部署的简单示意图

Github发起通知Jenkins Job1，Job1告诉Job2，在Job2中上传镜像，把镜像传到Helm里，经过Kubernetes部署到Pod节点中，完成部署。咱们把Job2打开，Job2被触发。为何我刚才把Job1跟Job2分开？由于对应的不同。Job1对应项目代码，Job2对应部署代码，咱们如今把它们解耦分开，如今Job2能够复用，能够构建很是多的项目。

 

 

在构建的时候须要制做镜像、上传镜像、部署镜像，每一步均可以用脚本语言实现，经过Jenkins、file串联起来，入门的时候作好这块就能够了。

这套流水线能不能用在不一样的环境上？能够，要作环境的配置管理，须要你在集群里面作一些操做，在Kubernetes的文件里说明这里面须要部署多少的资源，须要使用多少东西。Chart文件能够帮你辅助，把不一样的环境区分开。

 

 

讲完了工具讲文化，实施以后进一步落地DevOps怎么办？资源管理必不可少，分红几步： 监控报警、行为规范、经常使用脚本、操做指南 。每一步都很重要，怎么去监控？监控要注意哪些事项？怎么定义行为规范？脚本很重要，脚本越多越好，能自动化不要手动，多写一些文档，供别人使用，新人文档也好，甚至是操做指南，或者线上文档怎么布，用文档记录下来总没有坏处。

 

 

相信一小时以后，你可能就已经忘记我说的是什么了，不要紧我不在乎，但你必定要记住这张图。

 

 

若是你的团队想实施DevOps，四个因素必定要有：

自动化流水线
技术平台和工具
人和角色
文化和规则 。

这四个一个都不能缺，缺一个都不能叫DevOps团队，只能叫感受还不错的团队 。

总结

没有最好的实践，只有最合适的实践，每一个公司落地的方案都不尽相同。但愿你们在不断探索更好的过程当中，找到本身团队适合的DevOps解决方案。

认真能够把一件事作对，用心能够把一件事作好。

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。