企业级DevOps平台建设方案.docx
《企业级DevOps平台建设方案.docx》由会员分享，可在线阅读，更多相关《企业级DevOps平台建设方案.docx（13页珍藏版）》请在冰豆网上搜索。
企业级DevOps平台建设方案
企业级DevOps平台建设方案
一、DevOps平台建设历程
随着DevOps理念的兴起，企业的数字化转型的需求也愈发强烈，于是开始着手研发DevOps平台，并在这个过程中不断探索微服务、DevOps、容器云、ChatOps等的关系和最佳实践。
这里为什么要强调“企业级”呢？
一个小团队如果想要实现DevOps能力其实可以很简单，因为团队规模不大，比较容易管理，同时负责的应用也不会特别多，通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付，同样可以带来极大的效率提升，这其实也是一些互联网企业内部小团队的特色。
但是当这一切放大到一个数百人，数千人甚至数万人的企业时，就会发现遇到的问题、阻碍呈几何级的上涨。
一个企业要考虑的因素太多，历史越悠久的企业，内部的文化、流程越是根深蒂固，而当一个平台需要打通整个IT生命周期时，现有的文化、流程，现有的组织结构都不得不慎重推敲下是否能够满足。
所以，如何建设适合自己企业的DevOps平台，即使现有市场的DevOps理念已经基本普及开了，但是到落地的时候，却总会发现困难重重。
到底该怎么去落地呢？
明确定位：
DevOps是覆盖IT全生命周期的生产线
对于DevOps平台的定位还是要再明确下，DevOps代表的含义早已不仅仅是简单的开发运维一体化，而是在此基础上，打通产品、项目的软件研发全生命周期，覆盖持续交付、持续改进等能力，在纵向打通应用的全生命周期（需求、设计、开发、编译、构建、测试、部署、运维等），横向打通架构、开发、测试、质量、运维、运营等部门。
我们把DevOps分为三大领域，敏捷过程、持续交付、持续改进，三者相互独立却又相辅相成。
通过DevOps平台将企业软件研发的全生命周期管理起来，在保证质量、安全的前提下，通过一些自动化的手段不断提升软件交付的效率，通过不断精益度量对过程、对技术持续改进，最终支撑起企业的IT精益运营。
理清思维：
DevOps思维和互联网思维的区别
可能很多人对于DevOps的理念还存在这样的误解：
DevOps来源于互联网，也只适合互联网企业。
但DevOps思维和互联网思维还是有着一定的区别的，不能简单的认为只有互联网公司才适合DevOps。
恰恰相反，其实DevOps理念的提出以及最初的发展并非是互联网公司而是传统企业。
互联网公司强调的是快速、用户口碑，性能，并且对于上线的大部分应用具有一定的容错性，严重的错误可以快速的修改和再上线。
而DevOps追求的是质量、效率、精益、价值、稳定，企业尤其是金融类的企业对于线上应用的问题容忍度其实很很低的，很难想象如果一个交易业务出现问题后，会给企业带来多大的损失。
所以，DevOps绝不只是互联网企业可以实行，对于传统企业而言，更加适合。
通过建设DevOps平台来大幅提升软件研发效率，提升对市场的响应速度，支撑企业的数字化转型，也许对于传统企业而言，DevOps平台带来的价值才是更大的。
认清价值：
DevOps给你带来怎样的业务价值
清楚了DevOps平台的定位，也明白了DevOps平台对于任何企业都是可以实现的，那么还是回归到自身上，需要结合企业自身的现状思考下：
到底DevOps能给自己的企业带来什么样的业务价值呢？
DevOps平台的理念固然是将软件研发的全生命周期管理起来，但是并不意味着一定要做到全生命周期的管理，落实到企业内部，终究还是要结合企业的现状和实际的需求，有选择性有目标的去建设。
比如某企业由于组织的问题无法打通整个生命周期，那么通过持续集成、自动化测试、自动化部署等能力，提升软件交付的效率也是极好的。
对于企业而言，不管是提升IT的运营效率70%，还是做到开发测试环境的持续集成、自动化测试、自动化部署，亦或是一天部署10次这种DevOps最初的目标，最重要的还是要结合现状，先认清DevOps能给企业带来什么样的业务价值。
建设步骤：
DevOps平台建设步骤
Step1梳理企业的流程和规范：
梳理企业的流程和规范是企业建设DevOps的前提，甚至即使不建设DevOps平台，这也是一个必不可少的行为。
只有统一了企业的流程和规范，才能建设出一个适用于企业的DevOps平台，否则到最后，有可能会让DevOps平台脱离实际，导致没有人会去使用。
那么有哪些流程和规范是要提前梳理和统一呢？
这里列举几个如下：
∙产品（应用）管理规范：
包括版本管理、需求管理的规范等
∙项目管理规范：
包括团队的角色构成、过程工作流模板（Agile,CMMI,Scrum）、计划/任务管理规范等
∙开发和编译规范：
包括代码开发规范（分支主干的使用）、代码提交规范、构建规范（触发策略，是否需要代码提交时构建等）、介质管理规范等
∙部署相关的流程和规范：
比如部署架构的规范，环境的管理规范、软硬件资产管理规范等...
Step2总结自身的痛点和需求，规划建设路线图（MVP）
完整的DevOps平台是个很庞大的体系，如果全都靠自己建设的话，很显然不可能短时间建设完成，那么就要结合自身的痛点，从痛点入手，认清自己最迫切的需求，规划出DevOps平台的建设路线图。
基于MVP（）的理念，一步步有序的推MinimumViableProduct进整个平台建设。
假如自己的企业目前主要的瓶颈在于如何提升研发效率，那么就可以从统一开发平台、打通持续集成作为切入点。
如果目前的主要问题是软件交付速度太慢，那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。
Step3从组织、技术、流程、文化四个维度持续优化与改进
DevOps的实施和企业的组织、技术、流程、文化紧密结合，根据我们的经验，在企业中，技术方面的实践最容易在团队中实践，流程次之，组织的优化与变革则是最为困难的。
很多时候，不是技术上打不通整个生命周期，而是一些客观的因素导致无法打通各个部门。
我们建议，在实践的过程中，由易入难，持续优化和改进。
细节至上：
DevOps平台建设关键点
在建设DevOps平台中，有一些关键点是不得不注意的，简单列举几点：
∙如何支持异构环境、异构应用自动化部署？
企业的应用类型多样，纯前端应用（通过nginx等运行），传统war包（通过tomcat等应用服务器运行），springboot应用（fatjar包直接运行）、android应用、IOS应用等等，运行环境复杂的要同时支持物理机、虚拟机、容器云。
如何做到异构环境、异构应用的部署支撑，并且考虑到后续的可扩展性，对于平台架构的设计是有一定要求的，这个会在后面的部署架构的章节中详细介绍。
∙如何打通工具链的集成？
其实大部分企业，现状都是在软件研发生命周期各个环节，已经有了一批的工具，只是这些没有串联起来，如果是小工具随便用用还好，但是如果是一些用的比较根深蒂固的，可能就不是那么好替换了，方案会更加倾向于集成。
集成除了技术因素外，还必须要想清楚哪些工具去集成，哪些不集成。
集成到什么程度，比如针对于底层的IaaS平台或者容器云平台，我们就只是进行接口调用，而并非功能的接管。
对于Jenkins这种敏感资源，更倾向于把整个Jenkins封装起来，不对外进行暴露。
∙如何与现有的企业流程紧密结合？
不同企业有着不同的流程和规范，以持续交付流水线为例，可以是构建、SIT部署、SIT测试、提测、UAT部署、UAT测试、LAB部署、LAB测试、预发演练、生产部署等环节构成的一个大流程，也有会拆分成集测流程（开发过程中不断运行）、发布流程（从提测开始，UAT和LAB可以是并行的）两个流程，当然也有可能流程和这完全不一样。
这也就对DevOps平台的建设提出了要求，如何和现有的实际流程紧密结合。
除此之外，还有一些问题也是要考虑进去的，如何快速支持流程使用过程中的一些微调（如环节的配置字段属性等）？
如何做到流程手工和自动执行的自定义？
如何让buildNumber贯穿整个流程，让后续环境部署的介质对应的是哪个buildNumber有迹可循？
如何直观的查看交付？
当做到这些的时候，才能让整个交付流程目前到了哪个环节、每个环节的状态是什么样的？
如何以环境为视角，看到该环境下正在运行哪些应用流水线真正的实现价值。
关于这一部分我们的设计同样在后面的持续交付流水线架构章节中进行详细介绍。
∙如何支撑企业IT精益运营？
精益运营的基础是度量，度量的三大维度：
指标、执行监控、预测。
首先是明确指标和执行监控，基于软件全生命周期的度量过程中企执行监控业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。
当DevOps平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。
当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。
我们目前主要从质量、效率、进度三个维度，普通员工、团队负责人、部门领导等角色视角出发，提供如下能力：
三、DevOps平台架构剖析 1.总体架构解析
先看看DevOps的整体架构，正如最一开始所说，我们把DevOps平台划分为三大模块：
敏捷过程、持续交付、持续改进。
平台的概念模型如图所示，划分为5大领域：
产品域、组织机构与权限域，项目域、部署域、持续集成域。
平台的逻辑架构如下：
DevOps平台划分为领域层、基础服务层、工具层三层。
领域层和概念模型的5大领域基本一一对应，包括项目管理、产品管理、交付中心、组织机构等。
服务层则是封装的一些基础能力，如编译、部署、代码管理等。
底层运行环境支撑传统主机、PaaS平台、容器云平台。
同时平台机制支持灵活的的扩展（如工具集成扩展、部署能力扩展等），面对复杂的场景或者特殊的需求时，平台也可以提供更加灵活地能力。
2.敏捷过程
敏捷过程的架构核心在于工作项（WorkItem）的设计，工作项涵盖了需求（长篇故事、特性、用户故事）、开发（任务、缺陷）、测试（测试用例、测试计划）等。
可以说，在整个项目周期中，将所有的工作项统一管理起来，工作流和工作项关联，不同的过程对应不同的工作项，比如Agile对应的需求相关工作项是Feature/Story。
Scrum过程体系对应的需求工作项则是Epic/Feature/UserStory。
通过对工作项的设计，可能支撑多种工作流的差异化，便于设计和扩展，同时，可以从统一的视角查看所有的工作项，更加便于统一管理、统计分析。
其实jira、tfs也是类似的设计思路，只不过jira把一切看成是“issue”，tfs则是把一切看成“工作项”。
以需求为例说明，需求分Epic/Feature/UserStory三层，每一层都是一种工作项，工作项有哪些属性，属性对应的值类型，控件类型都会在数据中定义，页面上表单页面通过数据库中定义的属性和控件数据动态生成表单。
用户可以自定义项目中需求属性和状态。
3.持续集成
持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。
在构建定义管理模块中，DevOps平台将构建任务分成了四种类型：
∙编译类任务：
Maven、Ant、Gradle、纯前端构建等
∙测试类任务：
Sonarqube、Jmeter、Selenium等
∙打包类任务：
Npm、Archive、Docker等
∙其他工具类任务：
Copyfile、Shell、介质提交到Nexus仓库、介质上传二方库等。
在每个构建定义上可以选择若干个需要的构建任务，通过原子步骤编排，组装成一个完整构建流程。
代码提交时触发构建（支持gitlab、github、svn等常用代码库版本管理工具）、日构建等不同的构建触发策略等支撑了持续集成的完整链路打通。
在持续集成的领域，绝大多数企业应该都会选择Jenkins吧，我们也不例外。
持续集成模块的核心框架就是Jenkins。
每个构建任务对应Jenkins的一个pipelinestage。
在执行时，将所有构建任务结合构建定义的一些基础信息，创建Jenkins的pipeline进行执行。
Jenkins的搭建采用master/slave集群模式，面对大量应用的编译压力时可以更好的分散压力，保证编译速度。
如果想更灵活的话，可以考虑Jenkins集群部署在容器中，通过容器云的动态伸缩能力，可以更灵活的去使用资源。
这里要提到一个关于异构环境的编译，如ios应用的编译，就必须在macos系统中进行。
这就要求编译机和其他的机器有所区别。
我们是采用Jenkins的节点标签能力，如果是要进行ios编译任务的话，就会通过标签到ios的工作节点中执行任务。
4.自动化部署
在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：
设计、转换、运维。
设计阶段：
将部署架构分为三层：
部署装配（Assembly）、部署容器（Platform）、部署组件（Component）。
部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。
操作流程：
1.创建Assembly
∙通过选择可用的系统模版（PlatformTemplate），添加一个新的Platform。
∙每一个Platform都对应一种应用（如mysql，tomcat，springboot，nginx）。
∙每一个Platform都是有一组组件（Component）组成的，并且已定义好了组件之间的依赖关系。
2.管理ComponentComponent是最底层的部署（或者配置）单元，如springboot中的secgroup,compute,os,jdk,fatjar,lb都是一个组件每一个Component都有相应的配置模版。
3.提交设计提交的过程是将已经完成的设计做一次Commit，做一次归档。
转换阶段：
转换（Transition），是在Assembly内对应用/系统在某一具体部署环境内的部署过程。
部署环境是配置、架构设计、运行资源、部署策略的结合。
操作流程：
1.创建部署环境（DeployEnvironment）根据环境类型（如dev,test,prod等），添加属于某个Assembly的部署环境。
部署之前，部署环境是应用/系统用于部署的配置的抽象。
部署之后，部署环境就是管理和监控应用/系统的具体实例的集合。
2.配置部署环境设置每个Platform关联的资源（vm/container）、部署模式（单点，高可用）
3.选择Assembly内的一个或多个Platform生成并提交执行计划
根据部署策略不同，一个Platform的执行计划可能包含几个子计划
4.执行部署
每个Assembly/Environment/Platform下面的每个Component都有一个部署实例，这些实例可以进行单独操作
运维阶段：
对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等
考虑到驱动的统一性以及Jenkins2插件的丰富性，DevOps自动化部署框架底层同样使用了Jenkins。
采用DevOps平台（设计）＋Jenkins（执行）的方式完成。
DevOps的职责：
∙完成部署架构设计；
∙根据部署架构设计和部署环境的配置创建生成相应的执行计划及子执行计划，每一个子计划对应一个Jenkinspipelinejob配置文件（config.xml）；
∙查询Jenkins执行job的实时进度与结果。
Jenkins的职责：
∙根据config.xml创建JenkinsPipelineJob；
∙执行pipelinejob；
∙Jenkinsjob通过pipelinescript中ansible／openshift命令进行相应的部署等执行操作；
∙提供查询job执行情况的RestAPI。
DevOps平台中的部署架构设计和Jenkinspipeline的映射关系如下图所示：
可以看到每个组件都会对应Jenkins的一个stage。
所有的stage组装成一个完整的pipeline在通过Jenkins执行。
为什么选择Jenkinspipeline?
主要是结合以下几点进行考虑的
∙durable持久性：
在Jenkins的master按计划和非计划的重启后，pipeline的job仍然能够工作，不受影响。
∙可暂停性：
pipeline基于groovy可以实现job的暂停和等待用户的输入或批准然后继续执行。
∙更灵活的并行执行，更强的依赖控制，通过groovy脚本可以实现step，stage间的并行执行，和更复杂的相互依赖关系。
∙可扩展性：
通过groovy的编程更容易的扩展插件。
∙丰富插件：
Jenkins已经支持通过groovy命令调用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件，不需要我们再单独实现集成。
∙RestAPI：
Jenkins提供通过RestAPI的方式获取每一个stage的执行情况。
5.持续交付流水线
有了持续集成、部署、测试的能力是否就足够了呢？
其实还是不够，DevOps的本质是IT生产线，交付流水线是持续交付的核心能力，它可以把分散的能力如构建、部署、测试等串联在一起，形成一个从代码提交到发布上线的流水线，通过流水线可以很直观的看到当前某个具体构建版本已经到了哪一个环节，从整体上对于软件交付进行更好的把控。
在设计流水线能力时，我们主要考虑到几点：
∙结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置
∙流程的每一个环节都要支持自动执行的配置
∙流程中每个环节的属性和配置信息可以自定义，灵活扩展
∙流程以构建开始，让buildNumber贯穿整个流程，方便追根溯源
∙要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是SIT还是UAT，结果如何
∙要有一个看板，直观的看到每个环境下，有哪些介质在运行
以这些为基础准则，我们底层基于了的BPS流程引擎，支撑流程的自定义和扩展。
并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。
整个流水线从构建开始，以代码的buildNumber贯穿全流程。
便于问题、进度的追溯。
看板的设计如下：
QA环节 Q1：
实施DevOps过程中，持续集成上线有没有引入A/B测试？
DevOps如何开展主流程压力测试的？
A1：
A/B测试现阶段我们还没有引进，压力测试我们是通过集成JMeter实现的，部署到LAB环境，调用JMeter实现压力测试。
Q2：
2009年就实现了CICD和自动化测试，那DevOps和他们比起来最大的优势是？
A2：
最早之前都是自己内部的，主要做到了日编译。
应用类型比较少，没有考虑移动应用、纯前端应用、中间件的部署。
测试倒是涵盖了IDE测试以及WEB的自动化测试。
并且没有真正的把持续集成、自动化部署、自动化测试彻底打通，很多数据都没有收集起来。
DevOps的真正价值，除了更全面的交付能力，提升软件交付速度外，很大一方面在于打通了软件生产的全生命周期。
从而对整个软件过程进行度量和管理，提升软件交付的质量。
Q3：
我们公司现在的业务需求完全hold住，IT不是主要部门，我在思考是不是不需要DevOps?
毕竟DevOps改造的过程成本很大吧？
A3：
是否要实施确实要结合企业实际情况的，如果业务或者应用不多，就几个应用，并且短时间看不到扩大的话，实施DevOps确实意义不大，反之则可以考虑下。
并且实施DevOps并非要一口气就打通整个生命周期，可以有选择的一步步建设。
比如可以先从持续交付开始实施，至少提升IT的交付效率也是一件很好的事情。
以后有机会可以再考虑扩大到整个生命周期。
Q4：
请问怎么通知到下一环节呢？
通过什么样的方式
A4：
我们采用了我们自己的BPS流程引擎，在流程中进行环节的流转的。
通知的方式可以结合企业不同的需求，比如集成邮件、内部通讯工具、OA系统等。
Q5：
那传统的运维人员不转型DevOps是不是要失业了？
A5：
呵呵，其实现在随着IaaS/CaaS/DevOps等理念的盛行和落地，并不是说传统运维人员要面临淘汰，而是传统运维的工作新挑战。
压力更大，比如基础环境的维护，比如部署脚本的管理。
运维依旧是很关键的一环。
Q6：
公司都涉及到哪些业务啊？
A6：
为金融、通信、企业和政府用户提供软件平台产品和解决方案，产品包括SOA、云计算、大数据三方面，帮助用户实现数字化转型。
Q7：
请问Jenkins是自动一键构建到开发、测试各个不通的环境吗？
如果不是如何保证代码唯一性？
A7：
是的，正如文章里分享的一样，在整个发布流水线中，构建是第一步，后面到各个环境的部署，除了生产环境的部署外，其他都是用的同一份介质。
生产部署前会将介质提交到release库中。
Q8：
想请问王老师，devops和微服务之间是一个什么样的关系，或者说是如何结合在一起的，我们公司的业务大都使用PHP做主要开发语言，近期打算往服务化这方面去转变，但现在网上能找到的大多数微服务相关的资料都是基于Java，想请问王老师对于PHP有没有好的微服务框架或者书籍资料的推荐，谢谢！
A8：
微服务其实和容器云结合的很好，但是二者结合，传统的单个应用，拆分成了N个微服务，跑在N个容器中，很难管理和运维。
DevOps平台和微服务、容器云平台的关系，我认为是DevOps提供了一个平台，将微服务和容器云从很散、很裸的状态有效的管理起来，即使应用拆分的很散，依旧可以很方便的进行运维管理。
对于PHP我确实也不是特别了解，不好意思~
Q9：
DevOps一定是指完全打通吗？
那就是开发运维职责有交叠了？
A9：
DevOps的完整场景是打通软件生产的全生命周期，但是由于企业的现实情况，往往确实很难打通。
可以考虑先有选择的部分建设DevOps，等到有机会了再整体打通。
开发和运维的职责还是会切分开的，只是他们共同在平台上协作。
包括测试和QA等角色。
比如运维需要去管理和开通机器。
如果是虚拟机和容器云的话，运维则只需要提供好相关的接口和保证资源充足，开发测试环境完全可以让开发和测试人员直接在平台去部署。
平台会调用底层接口创建虚拟机和容器。
升级会员 