郭宏泽：全开源架构下的DevOps实践（转）

郭宏泽
公司职务：为胜科技技术总监

　　很高兴在这里跟大家做一次分享，我这次分享题目是全开源架构下DevOps的实践。
　　在最近几年DevOps比较火比较流行，我在这两年里也是，有很多项目我们去学习DevOps，在项目里面实践DevOps，去总结了一些经验，借着今天这个机会跟大家分享一下，跟大家交流一下。

　　首先简单快速来聊一下我对DevOps的理解可能我们今天的分享都会有这个环节，大体来聊一下我们对DevOps的理解。其实我也听过很多分享，也看过很多DevOps的书，大体上的框架都是一样的，但是可能各自的表达略有不同。
　　我对DevOps的理解是这样的，分几个环节，概念环节、流程环节、工具环节和目标环节。我们在DevOps理解上，首先是在概念方面，我们去做一件事的时候先要知道这件事是什么，为什么去做它，做它有什么意义，有什么好处。只有我们完全真正理解DevOps到底是什么的时候，我们去做的时候才会知道在哪里动手，知道怎么样做，知道自己在干什么，这样我们做的会产生一种极高的效率。
　　我们在理解的时候，首先在概念方面，DevOps是一种思想，是在我们软件开发生产实践过程中产生的一种思想，这种思想是经过我们漫长的开发过程来历练出来、提取出来的一种极致效率的，来解决我们在开发过程中遇到问题的这么一种新的思想，形成我们的方法论，最后通过实践来落地，最终我们的团队里形成一种DevOps文化。
　　我们在DevOps的实践过程中有个很重要的，就是在团队中形成DevOps文化，这种DevOps文化的形成要大于我们对DevOps工具的应用，因为工具可以变可以换，但是这种文化如果没有形成，空有工具产生不了很大的效果。
　　我们在流程上也是，DevOps对流程改造是巨大的，DevOps落地的情况下，我们对原来很多的流程过程都要进行改变，都要进行优化，冗余的要缩减，时间长的要压缩，不应该有的要删掉，缺失的要补上。
　　在流程里要涉及四个方面，开发、测试、运维，这是我们常常说的，另外一个是管理，管理很重要，管理是什么，让领导参与进来，参与到我们整个的DevOps流程制定，还有DevOps目标实现这个过程中，领导不能说我只负领导责任，别的具体都不管，一句话就完了，这不行。
　　这种在传统公司可能会出现为了管理而管理出现的情况，但是我们DevOps真正落地的创业公司、互联网公司没有这个事，所有的责任大家都要一起来扛，管理必须参加进去，如果管理没有参加进去，DevOps落地比较难。
　　我们有一系列的代码管理的工具，持续集成的，自动化测试或者部署的，有很多工具。最终我们要在实施DevOps之前想清楚一件事，我们为了什么来实施DevOps，把这个弄清楚了，可能我们的切入口就好办一些，我们就为了实现生产力的提高，快速交付，保证生产环境的稳定、安全，降低成本。这四个目标加在一起是非常难的。

　　在组织方面，以我的实践来说，我在公司的DevOps团队组织方面，我建议按照我们传统里面理解的产品线这种方式来进行DevOps团队的组织，这样整个的效果会好一些，大家在一个团队里来共扛KPI，对于所有的质量都是共扛的。
　　但是我们在实践过程中，可能部门是不拆的，部门还有，开发、测试、运维还有，但是部门的人进行虚拟的划分，划分到一个产品线里。我的经验是产品线的考核占70%，30%的考核还是传统部门那些任务的考核，这个各公司有自己的实际情况，可以根据自己的实际情况来做一下。
　　我们在每个产品线里都有自己产品线项目的领导，大家都在一个船上了，这个产品成，大家都拿钱，败，大家都扣钱。

　　成熟度模型，这个是给大家的一个参考，这里面的这些要求，我们通过成熟度模型，拿着成熟度模型来衡量我们公司目前处于的系统状态，系统是处于原始阶段还是在可优化阶段还是在某一个阶段。
　　在每个阶段，它在某一个环节里体现的现象是不一样的，比如在环境和部署阶段，在测试阶段，我有没有进行自动化测试，通过这一系列的考核来发现自己企业和公司的短板到底在哪里，我现在处于一个什么样的状态，这样我们才有一个切入的点。
　　如果你想直接一下落地整个DevOps的生产线是很难的，所以你必须要找一个点，我在哪一个点上发力突破，用我公司有限的人力和资源，把这个点做好，再做下一个点，这样以点带面，最终形成DevOps的落地。

　　我们引入DevOps以后，其实我们要来跟以前比较，要考量要评估，也就是说我们在引入DevOps以后，看看我们历史的趋势。
　　我们在第一个，在瀑布流开发的时候，我们只看重点，我们看在瀑布流的时候，我们看时间占比是47%，一个软件整个组织过程中所有的时间，开发的时间只占了47%，其他时间都干吗了？设计占了25%，测试占了15%，我的部署占了13%，我们在瀑布流的时候，这种大的规划细化，整个开发时间占比比较少，开发人员始终在等着前面产品经理、项目经理、架构师等等。
　　我要把这些事都弄清楚了，都考虑了再开发，结果开发以后，经过很长时间的开发，N多功能一起来进行集成测试的时候，发现各种各样的问题，这样导致我们开发的节奏比较慢。后来我们通过敏捷的实施，小步快跑，通过每一个周期，这种周期变快了，有问题能快速解决。但是Scrum有一个问题，没有考虑交付的问题，只有开发，形成一些迭代周期，只考虑开发了，后面交付以前一直被我们忽视。
　　所以当我们时代变到我们现在云计算时代了，基础设施的部署上线能力已经很快了。我们到敏捷的时候，对于环境部署还有交付这些的要求变得非常高。所以我们迫切需要一个新的理论来解决这个问题，我们通过DevOps的实施，将我们原来敏捷里没有解决的这些问题，把它解决掉，部署的问题。

总结一下整个软件的发展过程，从瀑布流到敏捷到DevOps，应用架构是从大而全的架构到SOV的架构再到现在微服务的架构。在运维技术的方面，通过原来的命令行、脚本到后来我们用Python进行大规模的运维工具的开发，到现在我们进行平台化的开发。

我们现在在实施DevOps的时候，要解决一系列的问题，基础设施的问题，中间件应用还有服务的问题，把所有一切的在四重环境。我们的研发测试、生产环境上全部自动化，让它run起来，只有在需要我们控制和暂停的地方才暂停，其他的全部可查询、可回滚。

　　我们对DevOps进行了一个定义，我们通过这个定义来分析我们公司在哪块来做这件事，我们的定义是这样的，我们公司现在源码管理做得好不好，我们的持续集成做没做，我们有没有自动化测试环节，我们来持续部署。
　　我去年给一个很大的国家机构做了一次DevOps的咨询，我去的时候他们在做什么，他们在测试环境到生产环境去上线的时候用U盘拷，把这个包拷过来，交给那个工程师，他再插到哪个服务器上。
　　他们这样的环节特别多，每到一个环节里去都要很长时间才能把环境运行起来。经常出错，每一次升级的时候都非常困难，二三十个工程师或者是更多的工程师，靠到晚上多少点，然后第二天早晨熬到几点。后来我们经过一系列的变革，我们所有的升级全都是在白天做，没有问题。

我们到源码管理这块来考量什么问题，就是我们的源码管理够不够先进，我们有没有源码管理，如果没有我们马上要上源码管理了，现在仍然有公司用文件夹来管理。

　　我们在源码管理里，我们在DevOps里，我们推荐用GIT的生态体系来管理我们的源码。这里也涉及整个团队Git的学习，构建Git的私有库，通过Gitlab。还有Gitflow、CR，整个过程run起来以后，每一个环节都是很流畅的，而且这个环节是我们历练出来以后它必须的环节。

　　剩下的我们代码管理用什么流程的管理，这个很重要，用Git以后会发现什么问题，Git过于灵活，到底用什么流程来控制我的代码。我们主要有三种方式，githubflow是最简单的是，直接开一个主干，开一个Master，我把Master克隆到本地，我在开发功能的时候，我创建一个功能的分支。从Master创建克隆到本地，开一个分支，开发完了推上去。如果再有人需要，再把它默认到本地，再合并到自己分支里去。这种比较适合大家都对Git比较熟，整个团队里面对Git用得还不错，几个人的效率也比较高，所以没有必要搞那么多花样去限制自己的效率。但是稍微大点的团队可能又要考虑了，这种有点不太合适了。

　　下面我们考虑Gitlabflow，在刚才那个基础上，建了几个分支，建了Master分支、预生产分支和生产分支，每次开发完之后，到预生产环境，他把它放到预生产那，如果到生产，再把它默认到生产那。是为了解决什么问题。

　　比如说我们发一个苹果，你在底下都测试好了，但是苹果想要上线需要很长时间，你上不去，你又不能老在测试环境呆着，所以你要建一个生产分支，把它放那，因为我已经开发完了，它在生产分支上堆着，堆了好几个生产分支的版本，是因为审核没有过。

Git flow是一个比较严格的Git的流程。Master只放线上生产的代码，所有的开发都从Dev的分支上开发，如果出现bug，现场修bug，再合并回去。整个Gitlab也是被业界最为接受的一个开发过程。像Jira、SourceTree这些都内置了对于Gitlab的支持。

　　我们对自动化测试的要求是，我们从传统上不怎么做单测，接口测做，转换到我们做TDD，做单元，必须做单元测试，接口测，最小化的UI测，等到UI测的时候其实没有问题了，后端的BUG都已经处理完了。我们整个的单元测的要求覆盖率是要求达到70%。剩下我们还要做到一些代码的style的控制。

　　我画了一个简单的图，持续部署。对于整个的运维环境里，现在在我们生产里面，底层所有的账号是通过LDAP打通的，所有的运营环境没有暴露在公网上的，运维系统变得越来越重要，运维系统被黑，整个生产系统就被黑了。这是持续部署简单的逻辑图。

我们的工作通过DevOps组织起来之后，最终我们形成一个循环，我们始终在这种周而复始的循环中进行我们的管理和工作。我们让这个循环run的平滑流畅，整个过程中我们工程师会亲送一些。我们这些运维工程师要去承担更大的任务，去开发公司的一些基础性运维管理的平台，让我整个公司系统运行得更加强壮。

谷歌的SRE，SRE的要求是什么，一个运营工程师应该50%的时间是在自己的日常任务中的，50%的时间是在写代码、在维护自己的运维平台的，这是一种理想的状态。做不到这样的状态，我们也不能把100%的时间都放在处理故障上，这种团队是没有成长的，这种团队整个的气氛也会很差，工作压力太大，大家都在一种恶性的环境中来工作。所以我们作为工程师，为自己也好，为别人也好，要把环境改变，让自己的工作环境变得良好。

DevOps一个发布流大概是这样的，我们在GOPS上还会发布一个更强壮的版本。我们开发工程师把代码提交上来以后，出发生产build，通过Maven，包括单元测，没有问题都通过以后，我们可以对测试团队进行提测，通过冒烟，那些基本的测试要做一下，但是不会所有的都回归。

到我的预发布环境，再到我的正式发布，通过灰度的方式来逐步将线上的集群把它发布，是这么一个流程。所以我们整个的过程做了很大的简化，这里面有很多的工具和来控制我们的过程。

这是我用到的工具，这里面大家很多都耳熟能详。我们用Git来做版本管理，SaltStack来做开发的PC端的版本管理，用Jenkins做编译和持续集成，用ansible、Puppet来做配置管理、环境管理，用JMeter做压力测试，底层可能是公有云、私有云，日志用ELK，我们用Docker来做持续集成的小平台等等。

这是Gitlab的一个截图，整个项目里有746个库，有371个开发人员，这是当时我在这个项目的时候，37个团队，这里面每天各种任务或者push，这都是上万次的任务。

这是Jenkins的界面，我们有几十个产品、APP等等，这是个整合测试，我们将JMeter整合到Jenkins这边来了。

DNS系统有个泛域名是指到Nginx上去的，每当提交一次项目，会直接发个邮件给相关的开发和测试人员那边去，测试人员通过域名就可以访问这个项目，进行相关的测试，这是我们自己写的一个容器平台。

CMDB每个公司应该都是需要的，我在不同的公司做了不少这样的项目，但是没有一个能够开源的，为什么，因为和系统耦合度过高。

今年春节的时候我闲着在家没事，写了一个开源的CMDB，功能大部分都有，但是如果自己用的话，根据我这个基准大家可以调一下，如果有公司没有CMDB，可以把这个用下去，因为你好多基础的工作可以不用做了，包括一些基础信息的配置。

这是一个导航界面，我做这个是要把我们说话的平台做一个入口，这个很简单。

这是一个CMDB的界面，这里面我们CMDB的基础功能都有，也会有自动录入的功能，我们有一个脚本直接在目标机器上执行之下，它就会把信息自动上报到CMDB里，有直接来导入的API的接口。

我还写了一个任务编排，当然这个任务编排还没写完，目前只支持推送任务。我和ansible来进行一个结合，我把CMDB里面的信息，我在这可以做一个下拉的选择，我在选择安装什么样的，一点执行直接就推到目标机器上去了。也做审核，所有的任务都在后台的日志打出来了。还有个shell的执行，和这个类似。

这是开源的，叫做AdminSet，在github上已经公开了。