本周二（2月26日） 20:30 – 22:00，骞云科技在 DockOne 社区进行了主题为「骞云科技 DevOps 实践」的在线直播，反响热烈。分享内容及问答整理如下：
摘要
随着公司业务的快速发展，需要加快开发流程的规范化和自动化，以提高产品的开发效率和交付效率。之前的开发测试和资源管理主要是半自动化的，个人生产力和资源利用率仍有很大提升空间。
在DevOps的具体实践中，一方面， Gerrit + GitLab + Jenkins + CMP（Ansible）共同构建了更好的 CI/CD 流程，对自动化持续交付流水线进行了优化；另一方面，CMP（Self-Service Portal）帮助建立了自服务自运维门户，公司所有人员都可以通过统一的门户自助申请各类资源，并自助完成日常运维。
主要内容：
1.为什么我们要加强DevOps？
2.DevOps整体规划
3.DevOps实践（一）：构建更好的CI/CD流程
4.DevOps实践（二）：建立自服务自运维门户
5.总结与建议
6.未来发展方向
为什么我们要加强 DevOps？
在公司创立早期，为了尽快实现产品从0到1的转化，我们将更多的资源投入到了产品的新功能开发上，在产品开发自动化方面的投入并不高。
随着公司业务的迅速发展，一方面，团队规模不断扩大，服务器资源也越来越多；另一方面，产品的功能逐渐丰富，开发代码工程数和分支数增加，而开发测试和资源管理仍以半自动化为主。
面临的问题
问题一：人力资源浪费
手工打包、手工创建虚机、手工部署、手工升级、较低程度的自动化测试，这些重复且低效的开发测试模式导致开发测试人员不能将宝贵的时间用于更加有创造力的工作上，不利于个人和公司的快速发展。
问题2：IaaS资源管理混乱
我们的开发测试环境主要构建在内部的vSphere和OpenStack云台上，当然也会在Aliyun、AWS、Azure等公有云上创建资源。在日常工作过程中，我们经常会听到这样的声音：“我的环境怎么这么卡”、“阿里云上又没钱啦”、“OpenStack上的机器我要删了啊”、“谁删了我的机器，我的数据还在上面呢”。由于没有权限控制导致资源随意创建，资源不及时释放导致大量资源闲置和浪费，另外还存在资源误删除情况。
问题3：内部系统运维成本居高不下
我们没有专职的内部系统运维人员，平时开发过程中，遇到CPU/Memory调整、磁盘物理卷/逻辑卷扩容、操作系统故障、应用故障等一系列问题都会占用研发人员大量的时间和精力。
问题4：产品交付难度大
为满足稳定性、高可用性、可扩展性等交付需求，我们的产品在软件架构设计上具有较高的复杂度，这样一来安装部署实施的难度也就比较大。售前团队到客户现场做POC，想要快速部署一套公司产品比较困难；售后团队在项目交付的过程中也经常遇到各种各样的安装配置问题。
基于上述问题，我们希望通过对DevOps工作流程进行改造和增强，以提高产品开发效率和交付效率，以及提升个人生产力和资源利用率。
DevOps 整体规划
我们将DevOps工作流程改造分为了两个方面，一个是对CI/CD工作流的优化，一个是搭建自服务自运维门户。
（一） CI/CD目标
·所有代码工程能够自动化打包
·所有代码提交后能够自动构建编译检查以及单元测试任务
·每小时完成一次软件集成、部署以及核心功能的集成测试（API&UI）
·每天完成一次完整功能的集成测试（API&UI）
·每周完成一次7×24小时Longrun系统测试
·自动更新经过测试的nightly build到开发测试环境
·自动发布经过测试的weekly build到Demo环境
（二）自服务自运维目标
公司所有人员，都可以通过一个统一门户Portal，自助申请各种类型的IaaS资源，如： x86物理服务器、vSphere虚拟机、OpenStack虚拟机、Kubernetes上的容器服务，以及Aliyun、AWS、Azure等公有云上的云资源；自助申请日常开发所需的软件应用，如：Nginx、Tomcat、MySQL、RabbitMQ，以及SmartCMP等。
具体目标如下：
·开发Dev，测试QA，售前交付需要使用不同的资源，做到资源隔离；
·资源的使用需要有权限控制；
·需要能够一键部署单节点和HA多节点应用系统；
·提供环境自动初始化，一键升级能力；
·提供系统和应用级别的监控告警；
·资源需要能够定期回收。
DevOps 实践（一）：构建更好的CI/CD流程
概述
我们的 DevOps 工具链由 GitLab、Gerrit、Jenkins、CMP 构成。
· GitLab：代码托管
· Gerrit：代码审查
· Jenkins：单元测试、自动化打包、集成测试
· CMP：vSphere、OpenStack、Kubernetes等云资源统一管理，应用系统自动化部署，版本更新
开发人员提交代码后，触发Jenkins完成代码编译检查和单元测试，Jenkins返回代码检查结果给Gerrit，人工Review后merge代码，触发Jenkins完成该项目的打包。Jenkins定时完成各个工程的集成打包，然后通过调用CMP的API触发自动化部署，部署完成后进行场景化的集成测试，测试完成后卸除资源。
持续集成（Jenkins）
起初我们使用GitLab Runner实现CI，在每个代码工程中添加“.gitlab-ci.yaml”文件，不同项目各自创建和维护自己的.gitlab-ci.yaml脚本，这样的实现可以解决各自工程的编译测试和打包问题，在代码工程数量较少时，我们也使用了较长一段时间。
现在我们的代码工程数量已超过20个，每个代码工程都设置了访问权限，如果需要专人维护CI脚本的话，那他需要能够访问所有代码工程，显然这样是不合理的，而且把集成打包脚本放在哪个工程里都不合适。
考虑到Jenkins有强大的CI能力：通过安装插件就能快速与Gerrit、GitLab集成，能够参数化执行各种类型的脚本。所以，我们使用Jenkins代替gitlab-runner完成CI，通过Jenkins可以统一管理各个工程的编译、测试、打包，而且比较方便构建流水线完成较多工程集成打包及测试。
持续部署（Ansible）
我们的产品由20多个服务组成，可部署在一个或多个虚拟机上，使用Shell脚本或Python脚本已经很难完成这么多服务程序的自动化安装部署配置。
恰巧团队有使用Ansible做复杂系统部署的经验，Ansible的学习成本也较低，所以我们选择使用Ansible Playbook 实现这20多个服务程序的统一编排部署和配置，并且可以同时支持单节点和HA多节点自动化部署。
我们设计Ansible Playbook时，将每个服务都独立成一个角色，这样保证了各个服务部署的独立性，这种分布式部署架构为将来容器化部署和微服务化奠定了基础。
Ansible自动化标准化部署不仅大大缩短了部署时间，也极大地降低了部署出错的概率。原先，按照HA架构部署一套产品需要1天时间来完成各个服务的部署和配置，通过使用Ansible playbook，我们只需要45分钟，而且中间过程完全可以放手去做别的事情。
集成测试（Robot Framework）
目前，我们在Jenkins中使用Robot Framework框架做集成测试。Robot Framework（以下简称RF）是一个基于Python的、可扩展的、关键字驱动的测试自动化框架。
选用RF的原因：
·一致性：目前公司的UI自动化测试使用的就是RF框架，RF框架也完全有能力做集成测试，因此使用RF框架做集成测试，可以降低学习成本，提高可维护性。
·复用性：在安装了Robot-Framework-JMeter-Library后，RF可以运行JMeter脚本，并且将JMeter运行结果转为Html格式。公司目前性能测试用的就是JMeter，对于相同场景，只要小幅修改JMeter脚本即可将其复用到集成测试上面。
选用RF也存在一些问题：
·如果不复用JMeter脚本，编写的API测试用例的成本非常高。
RF对于变量类型的规定堪称僵硬（当然，这么规定带来的好处是方便类型检测），RF中对于字典类型的创建非常麻烦，对于我们公司API请求中携带大量参数的情况，只能创建关键字来解决，不管是采取RF自带创建字典的方法，还是创建关键字的方法，都比较浪费时间（因为难以复用）。
·RF可以轻松扩展关键字，也因此可能带来乱扩展关键字的问题，导致测试用例可读性和可维护性差的问题。
在RF中，关键字其实就是Python/Java的类方法，因此扩展起来非常容易，但是关键字一旦多起来，一个同事写的测试用例，其他人（甚至他自己过了一段时间）维护就非常麻烦（需要回去看关键字是如何规定的）。因此需要严格规定关键字的创建规范是一件值得深入讨论的事情。
