敏捷大会 II DevOps的工程化(下)

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

3.DevOps工程化

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

如果你的团队想要去实施DevOps，从我的观点来说它由 四部分 组成。

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

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

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

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

人和角色： 主要分两类， 开发测试 和 运维 。开发跟测试放在一起，因为我认为这两个角色按道理来说是属于一个工种。在谷歌其实是没有测试这个职业的，他们都叫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解决方案。

认真可以把一件事做对，用心可以把一件事做好。