【www.shanpow.com--热门范文】
devops是什么意思一:译言网 | 什么是DevOps？
如果你对IT管理感兴趣，尤其是对Web运维感兴趣，那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客Twitter上，同时DevOps相关的技术交流聚会也在慢慢增多。
DevOps在很大程度上是一个集合性概念，指的是能够理顺开发和运维之间相互配合关系的任何事物。但是DevOps背后的理念要比上述说法更深远。
什么是DevOps？
人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。
正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。
以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。
而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们已经多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变。
开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。
更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。
让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和日常使用的常见工具，再看一下系统管理员，你会发现两者存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然；而且两部分工具之间也不存在重要的集成。即使在某些工具类型上有一些重叠之处，使用方式也完全不同。
当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布（Release）”，有人则称其为一次“部署（deployment）”，但有一件事情是公认的，问题可能会随之而来。下图虽然是一个抽象化场景，但是如果你经历过这一过程，一定会感觉到它的真实性。
开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已完成的工作；而糟糕的情况是，他们将引入或发现新的漏洞。
运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。当然，期间如果发生一个问题，开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。
没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。
部署阶段已经非常明显的需要DevOps理念来解决问题，但需要DevOps的绝不仅仅是这一阶段。正如约翰·阿尔斯帕瓦（John Allspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。
DevOps所带来的好处
DevOps是一个非常强大的概念，因为它可以在众多不同层面上产生共鸣。
从开发或运维的一线人员的观点来看，DevOps可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药，但是如果你能够让DevOps奏效，则会节省大量时间，而且不至于打击自己的士气。显而易见，投入精力将DevOps落到实处，我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps是一个遥不可及的目标，但这并非说我们不应该去尝试实现它。
对于企业来说，DevOps直接有助于实现两个强大战略性企业品质，“业务敏捷性”和“IT融合”。它们可能不是IT人士所担忧的事情，但是却应该获得掌握财政大权的管理者的注意。
IT融合的一个简单定义是，“企业渴望达到的一个状态，能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。”
通过从共同企业目标角度出发来校准开发和运维的职责和流程，DevOps有助于实现IT融合。开发和运维人员需要明白，它们仅仅是一个统一业务流程中的一部分。DevOps思想确保个体决策和行为应力求支持和改进这个统一的业务流程，无论你是来自哪一个组织架构。
业务敏捷性的一个简单定义是，“一个机构以高效、经济的方式迅速适应市场和环境变化的能力。”
当然对于开发人员来说，“敏捷”有专门的含义，但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步，尽管需求不断变化，也可以产生高品质软件。对于多数机构来说，迭代项目管理方法Scrum是敏捷的代名词。
业务敏捷性承诺，在企业权益集团作出决策和开发者进行响应之间能够紧密互动和快速反馈。看一下一家运转良好的敏捷开发团体的产品，你会看到一个与业务需求保持一致的稳定持续改进。
但是，当你从企业角度回顾一下整个开发-运维周期，敏捷方法的相关优势通常会变得非常模糊。混乱之墙导致了应用程序生命周期的分裂。开发和运维分别按照不同的节奏进行。实际上，产品部署之间的长期间隔使得一个团体的敏捷工作变成了它一直试图避免的瀑布生命周期。当存在混乱之墙时，无论开发团体有多么敏捷，改变企业缓慢和迟钝的特点是极其困难的。
DevOps使得敏捷开发的优势可以体现在机构层面上。通过考虑到快速、反应灵敏但稳定的业务运维，使其能够与开发过程的创新保持同步，DevOps可以做到这一点。
如果你希望在自己的组织内建立一个DevOps项目，务必牢记“IT融合” 和“业务敏捷性”。
如何将DevOps落到实处？
和多数新出现的话题一样，发现问题的共性特点要比找到解决方案容易的多。
要想实现DevOps相关解决方案，以下三方面需要关注：
1、评价和鼓励改变文化
改变文化和激励系统从来不是一件易事。但是，如果你不改变企业文化，兑现DevOps的承诺将非常困难。考察一个企业的主导文化时，你需要紧密关注如何评价和判断企业业绩。评价的内容将影响和刺激行为的发生。开发-运维生命周期中的所有当事方需要明白，在更大的企业流程中自己只是其中一部分。个体和团队的成功都要放在整个开发-运维生命周期内来进行评价。对于许多机构来说，这是一个转变，不再是孤立的来进行业绩评价，每一个团队不再是基于自己的团队来评价和判断业绩好坏。
2、统一标准化的流程
这是DevOps的一个重要主题，整个开发-运维生命周期必须被看作一个端对端过流程。流程的不同阶段可以采取不同的方法，只要这些流程可以被组合到一起创建一个统一的流程。与评价和激励的问题相似的是，实现这个统一的流程时每个组织可能会有略微不同的需求。
3、统一的工具
这是大多数DevOps讨论一直在关注的领域。这一点不令人吃惊，因为当技术专家在考虑解决一个问题时，第一反应往往就是直接跳转到工具讨论上。如果你关注Puppet、Chef或ControlTier等工具社区，那么你可能已经意识到人们对在开发和运维工具之间建立桥梁的重大关注。“基础设施即代码（Infrastructure as code）”、“模型驱动自动化（model driven automation）”和“持续性部署（continuous deployment）”都是可以划归DevOps旗下的概念。
关于把DevOps变为现实需要哪些类型的工具，杰克·索罗夫曼（Jake Sorofman）提出如下建议：
一个版本控制软件库
它可以确保所有系统产品在整个版本发布生命周期中被很好的定义，且能够实现一致性共享，同时保持最新信息。开发和QA机构能够从中取得相同平台版本，生产机构部署已经被QA机构验证过的相同版本。
深层模型系统
它的版本系统清晰的描述了软件系统相关的所有组件、策略和依赖性，从而可以简单的根据需要复制一个系统或在无冲突的情况下引入变化。
人工任务的自动化
在依赖关系发现、系统构造、配置、更新和回滚等过程中，减少人工干涉。自动操作变为高速、无冲突和大规模系统管理的命令和控制基础。
在从开发到运维的生命周期中存在许多不同的工具。工具选择和执行决策需要根据它们对端到端生命周期的影响来决定。
关于DevOps的澄清
现在某些系统管理员正在试图把自己的岗位名称改为“DevOps”。但是，DevOps不应该是一个单一的位置或职称。把DevOps变成一个新职位名称或特定角色是一件非常危险的事情。例如这会导致以下错误端点：你是一个DBA？或者是一个安全专家？那么不用担心DevOps，因为那是DevOps团队的问题。
设想一下，你不会说“我需要招聘一个Agile”或“我需要招聘一个Scrum”或“我需要招聘一个ITIL”，而只是会说需要招聘了解这些概念或方法的开发人员、项目经理、测试人员或系统管理员。DevOps也是同样道理。
与DevOps具有相同理念的术语很多，例如敏捷运维（Agile Operations）、敏捷基础设施（Agile Infrastructure）和Dev2Ops。还有很多人虽然没有提及“DevOps”，但却在遵循着类似的理念。
devops是什么意思二:DevOps 标准体系发布及权威解读
作者简介：
栗蔚中国信息通信研究院主任工程师 / 云计算开源产业联盟秘书长
一、DevOps 标准体系
2017年11月17日，云计算开源产业联盟第一次跟高效运维社区一起在上海合办了首届金牌运维峰会，在工信部软件司的指导下，由中国信通院牵头的云计算开源产业联盟在推动运维相关标准方面也有了很大成果，我将代表编写团队，发布两个已经完成的标准（DevOps 标准、蓝鲸运维标准），本文将着重介绍 DevOps 标准。
1.1、DevOps 体系
DevOps 的标准体系，目前我们发布的是一个 Beta 版，用我们业界比较流行的代码术语是一个体验版。
为什么要做 DevOps 的标准体系，已经有这么多的最佳实践和开源工具，我们为什么要做这个事情呢？
我们经常在不同的场合听到了 DevOps 这个词，但是我听到大家讲的角度维度都不一样，有人认为自动化运维就是 DevOps，有人认为运维的人员会开发，是不是就是 DevOps，那么还有一些我们的容器厂商从产品的角度说 DevOps，还有我们从培训的角度去玩玩沙盘，是不是就会懂了 DevOps，是不是我们把上面的组合起来就知道什么是 DevOps 呢？其实不是的。
我们在不同场合听到 DevOps 都好像盲人摸象一样，谁都只是摸到了大象的一部分。所以我们做这件事情的目的主要有两方面：
第一个方面就是三正，正什么呢？
第一正概念，就是 DevOps 的概念，它的范畴；
第二个就是正框架，我们 DevOps 到底包含哪几个过程，从人员组织架构到工具，到底要达到一个什么样的框架才是 DevOps；
第三个就是正能力，很多人说 DevOps 太难了，目前我们公司做不到，其实有的时候觉得难，是因为我们不知道如何达到，所以在这里我们的标准叫做能力的成熟度模型，也就是说你很容易的清楚自己在哪个层级，那么你也很清楚如何晋级到更高级的 DevOps 的能力，这样一个很清晰的标准。
正因为我们可以做到三正，所以这个标准是有实操意义的，拿了这个标准，不管是运维人员还是 CIO 等等，就可以看到你们的公司团队如何根据这个标准去明确不同的流程，明确不同的组织架构，明确如何一步一步的去实施。
1.2、DevOps 体系系列标准——前三部分
我们这个标准体系一共有7部分：
第1部分是总体架构，包括概念、框架和能力的分级。从第2部分到第7部分就是我们这个框架里的每一个部分的能力成熟度模型，主要包括敏捷开发过程，持续交付过程，技术运营过程，还有总的应用框架、安全管理和组织结构。可以看到从第2部分到第4部分，都是过程类的，第5部分是应用架构类的，第6部分是安全管理类的，第7部分是组织结构类的。
“研发运营一体化能力成熟度模型”，是国内外第一个 DevOps 标准体系。
DevOps 标准体系包含下面两大目的：
第一，是明确概念、框架、能力。DevOps 的概念、框架和能力到达什么程度，做一个非常详细明确的说明。
第二，对于 DevOps 涵盖的流程、组织、实施，有明确的指引，企业可以按照这个标准去提升自己 DevOps 各个环节的能力。
本次发布的是前3部分的征求意见稿。
二、DevOps 系列标准前三部分
前三部分为总体架构，敏捷开发管理过程和持续交付过程相关标准。以下为您详细解读。
2.1、第1部分：总体架构
研发运营一体化（DevOps）能力成熟度模型覆盖端到端软件交付生命周期全流程，是一套体系化的方法论、实践和标准的集合。研发运营一体化总体架构可划分为三部分，即过程（敏捷开发管理、持续交付、技术运营）、应用架构和组织结构。
研发运营一体化过程： 从需求开发、交付、运营这几个环节的过程，这三个过程涵盖了很多内容。整个过程我们把它标准化地分成了三部分。
敏捷开发管理从需求管理、计划管理、过程管理、度量分析这四个维度，关注需求到开发阶段的有序迭代，灵活响应，以及价值的快速交付。
持续交付关注应用软件集成交付环节，通过配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理和度量管理领域的能力建设和工程实践保证软件持续顺畅高质量的对用户完成发布。
技术运营，技术运营环节关注应用系统服务发布后的环节，涉及运维成本服务、高可用架构服务、用户体验服务、客户服务、监控服务、产品运行服务和运营数据服务，保障良好的用户体验，打造持续的业务价值反馈流。这里大家要记住一点，我们没有提运维，提的是运营。为什么呢？因为 Operation 这个词它本身的含义就有运维运营的双重意思。并且现在运营人员所做的事情，已经不是简单的背锅。往往背锅的时候还要提炼点东西。大家要用大数据也好，智能化也罢，都是把自己的运维能力转变为运营部门提供更多的数据支撑。
DevOps 涵盖了敏捷开发、持续交付和技术运营三个过程，这是从过程去理解 DevOps。
研发运营一体化应用架构，DevOps 的标准除了过程工程以外，还涉及到应用架构。应用架构指的是应用系统的开发、测试和部署，是否用了微服务等架构。
研发运营一体化安全管理，这是非常重要的，因为 DevOps 在一定程度上降低了安全性，也称为很多企业落地 DevOps 的阻碍之一。这次侧重全流程端到端的全局考虑安全管理及服务。
研发运营一体化组织结构，最深层的就是组织结构的问题。我们知道怎么去做，但是不一定能做到？是因为这三个过程覆盖了某个企业N个部门。据我了解不同的行业，开发、运维都是不同的部门。甚至在金融行业、银行的开发、测试和生产也在不同的部门。
所以如果应用架构、安全管理和组织架构跟不上，也是做不到 DevOps 能力的。往往是每个环节把自己的事做好的，需求迸发出来了，可能才会去推动进一步的组织结构的变动，这是第三个纬度的事情。
理解 DevOps 可以从过程、多个点、不同维度去理解。DevOps 是一个过程，过程里的每一个小环节，涉及到人、团队、工具。后面分级的理念也是每个小环节从人、过程管理、工具团队的协作这几个纬度去分的。
要做好 DevOps，首先把每个小环节做好，进而把整个过程做好了，然后再推动整个组织架构一系列的变革。
为什么这里叫运营研发一体化，不叫 DevOps 呢？
因为国内标准不能出现英文词的，而且 DevOps 这个词它是具有阶段性的。也许过个十几年就没有 DevOps 了，标准要普世性，所以这里没有用 DevOps，用的是研发运营一体化。从这个词也可以看出来它贯穿了研发，一直到运营。
成熟度分级的对象，就是研发运营一体化，研发运营一体化就是刚才讲的那几个纬度。我们分级的时候，可以对整个研发运营一体化进行分级，也可以小到某个环节，大到某个部分去进行成熟度的分级。
这样有助于了解每个环节的情况，有助于逐个击破，提升自己 DevOps 的能力。分级成熟度就是从阻碍一直到优化这五个级别，很容易理解。
2.2 、第2部分：敏捷开发过程
这里面讲的是敏捷需求管理、迭代计划管理和敏捷过程管理，属于刚才讲的第一级的环节，每一个环节可以分成很多小环节。
其中需求管理细分为需求收集、需求分析、需求与用例和需求验收四个细分维度。
需求收集从单个需求点、需求全貌、需求的管理、人员机制以及工具能力五个维度进行评估；
需求分析从需求内容和形式、需求协作、需求的管理、人员机制以及工具能力五个维度进行评估；
需求与用例从需求与用例编写、需求用例验证、需求与用例的管理、人员机制以及工具能力五个维度进行评估；
需求验收从需求验收频率、需求验收范围、需求验收反馈效率、人员机制以及工具能力五个维度进行评估。
其中计划管理细分为需求澄清与拆解、故事与任务排期、计划变更三个维度。
需求澄清与拆解从需求澄清的时间、内容的完备性、协作、人员机制以及工具能力五个维度进行评估；
故事与任务排期从排版要素、排版容量、排版管理、人员机制以及工具能力五个维度进行评估；
计划变更从变更决策、应对变更、减少变更、人员机制以及工具能力五个维度进行评估。
其中过程管理细分为迭代管理、迭代活动、过程可视化及流动、度量分析四个维度。
迭代管理从迭代时间周期、迭代协作机制、迭代流程改进、人员机制以及工具能力五个维度进行评估；
迭代活动从迭代活动约定、迭代活动时间约定、迭代活动范围、人员机制以及工具能力五个维度进行评估；
过程可视化及流动从过程可视化、过程价值流动、迭代过程改进、人员机制以及工具能力五个维度进行评估；
度量分析从度量粒度、度量范围、度量驱动持续改进、人员机制以及工具能力五个维度进行评估。
以下就部分内容进行阐述。
敏捷开发过程-需求管理-需求收集
需求收集环节是需求提出方和产品经理之间明确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品的需求具象化，形成待办事项列表的过程。
需求收集环节包括三个方面工作:
明确单个需求点，即以问题驱动为核心，探索问题核心相关事项的过程
梳理需求全貌，应能列出为了落实产品的愿景而需要完成的所有事项，即待办事项列表
确定待办事项列表，应包括用户需求所涉及的所有事项，并且作为产品研发路线图
这三个工作从人员机制到工具能力，会用到不同程度的工具，以及人员协作的流畅度，协作的程度是不一样的。所以把它分成五级，大家可以看一下上图右边的内容。
最高级的是，需求方就是产品经理可以把需求方的每个点形成一个功能点，并且把功能点形成整个需求的全貌，形成一个列表，进一步形成路线图，这个路线图可以是在后续的迭代开发中不断的优化。
在工具能力方面会用到很多需求管理，用统一的工具对需求进行管理。组织架构方面，企业采用扁平化的敏捷团队组织架构，赋予团队围绕产品自组织、自管理的权力，包括但不限于产品规划、建设、运营、人力、绩效、核算等。
例如，敏捷团队以业务价值为核心以运营为驱动的敏捷工作模式，企业为团队提供IT基础设施、基础管理等支持。第一个环节，如果做到这一级的话，是非常好的。如果是普通程度的情况，一个是传达的需求不明确，第二个没有用到任何的工具，这样普通的级别在后续的迭代计划中根据计划的改变而进行改变，是不够灵活的。
这是需求收集环节我们的分级。大家可以对应表看看你是属于哪个程度哪一级的。
敏捷开发过程-需求管理-需求分析
需求分析是产品经理将需求细化和拆解成用户故事的过程。
主要体现三个方面:
明确需求内容和形式，需求分析形成用户故事，用户故事描述用户场景。
需求分析协作，用户故事是适度详细并适应变化的，可以在开发过程中对其进行评估不断细化。
需求管理方式 用户故事统一管理，并按照业务价值由高到低排定优先级。
需求分析最主要的方式是把整个甲方或者需求方的需求场景，进行统一的分类。在开发过程中对它进行不断的评估，进行细化，最后把场景按照业务价值，由高到低进行排定优先级。
上面需求收集只是说形成了一个待办事项列表，保证不停的更新。这个时候需求分析能够按照不在待办事项里，能够按照优先级去进行标注，进一步根据后面的迭代开发情况进行不断的反馈。
敏捷开发过程-需求管理-需求与用例管理
需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性，能验收产品功能是否满足用户故事的要求的过程。
主要体现在三个方面:
梳理需求用例，编写需求验收标准，形成测试用例的过程。
使用需求用例，需求用例指导需求开发，验证产品功能的过程。
管理需求用例，建立需求与用例的统一管理库，持续的使用和优化。
刚才已经把需求分了级，分了场景后，开发有没有达到我们的需求呢？这个地方对需求管理很重要了，要预先有一些测试例，能够很好地判断后面的开发有没有达到。如果有问题再反馈回来，我们的需求进一步调整。
应建立企业级可视化便捷的平台，管理需求文档，且可以通过需求文档能查看产品的全貌，且通过平台，需求提出人、最终使用人、产品经理、开发运维人员进行更好的沟通和协作。保证可持续性，它有一个持续，每个环节都可以持续，持续都是持续到下一个环节，交付环节的。
敏捷开发过程-需求管理-需求验收
需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快速确认、快速反馈、快速优化。
本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。需求验收主要体现在以下三个方面:
需求验收的频率指不同角色对需求功能验收的频率，频率越高效果越好。
需求验收的范围指需求验收应尽量具备有业务价值的端到端的验收。
需求验收的反馈效率指需求验收的结果能准确、快速的反馈到开发团队的过程。
最后是需求的验收，包括设计验收的频率、制定验收的测试方案、指标等等。并不是强制要求你的频率一定要达到多少次。不同的产品验收频率验收结果是不一样的。更多是告诉你一种方法论，在这个过程中也是需要你用到一系列的工具，去辅助你能够自动化去进行需求的验收等等。
最高级别应建立企业级大数据分析工具，能抓取用户行为数据，通过大数据分析，在用户功能验收和用户体验时作为辅助决策依据，持续优化改进。需求的环节在敏捷开发里是非常重要的，下面的环节叫迭代计划管理。
其他相关标准内容，详解相关文档（文末可下载）。
2.3、 第3部分：持续交付过程
第三个标准就是持续交付的过程，它分为配置管理、部署等等，分了好几个环节。每个环节包括一些子环节，每个子环节从很多纬度进行能力的评估。
其中配置管理细分为版本控制、版本可追踪性两个维度。版本控制从版本控制系统、分支管理、构建产物管理、单一可信数据源四个维度进行评估；版本可追踪性从变更过程、变更追溯、变更回滚三个维度进行评估。
其中构建与持续集成分为构建实践、持续集成两个维度。构建实践从构建方式、构建环境、构建计划、构建职责四个维度进行评估；持续集成从集成服务、集成频率、集成方式、反馈周期四个维度进行评估。
其中测试管理分为测试分级策略、代码质量管理、测试自动化三个维度。测试分级策略从分层方法、分层策略、测试时机三个维度进行评估；代码质量管理从质量规约、检查策略、检查方式、反馈处理四个维度进行评估；测试自动化从自动化设计、自动化开发、自动化执行、自动化分析四个维度进行评估。
其中部署与发布管理分为部署与发布模式、持续部署流水线两个维度。部署与发布模式从部署方式、部署活动、部署策略、部署质量四个维度进行评估；持续部署流水线从协作模式、流水线过程、过程可视化三个维度进行评估。
其中环境管理分为环境类型、环境构建和环境依赖与配置管理。
其中数据管理分为测试数据管理和数据变更管理两个维度。测试数据管理从数据来源、数据覆盖、数据独立性、数据安全四个维度进行评估；数据变更管理从变更过程、兼容回滚、版本控制、数据监控四个维度进行评估。
其中度量与反馈分为度量指标和度量驱动改进两个维度。度量指标从度量指标定义、度量指标类型、度量数据管理、度量指标更新四个维度进行评估；度量驱动改进从报告生成方式、报告有效性、报告覆盖范围、反馈改进四个维度进行评估。
持续交付-配置管理-版本控制
版本控制是从版本控制系统、分支管理和构建产物管理和单一的可信数据源。
从五个方面对它进行成熟度的分级。最高级，比如在版本控制系统方面，要有版本的控制系统，产品开发的版本控制系统。它是有生命周期的，所有的版本，包括修改等等流程都可以进行管理。比如分支的管理，就是持续优化分支管理策略，等等。
持续交付-配置管理-版本可追溯性
版本的可追溯性，版本可追溯性是指软件系统中的每一次变更都可以追溯变更的详细信息，并向上追溯变更的原始需求、流转过程等所有关联信息。支持全程的数据分析管理和满足审计的要求。这里审计要求是指你这个产品的开发，每一步 BUG 的修改、每一步的变更是谁做的，它修改了哪一步。也是可追溯的意思。
可追溯性也是版本回滚的历史依据和实施基础，建立良好的版本可追溯性可实现对任一版本完整环境流程的自动化，精确回滚，快速重现问题和恢复正常环境。
持续交付-构建与持续集成-构建实践
版本的管理就是构建与持续的集成。构建的实践包括持续优化的构建服务平台、持续改建服务的易用性。
构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤，将高级语言代码转换为可执行的机器代码并进行相应的优化，提升运行效率。
持续集成是软件构建过程中的一个最佳实践，在版本控制的基础上，通过频繁的代码提交，自动化构建和自动化测试，加快软件集成周期和问题反馈速度，从而及时验证系统可用性。
这里可以用容器管理工具，因为容器很方便可以把很多应用做成标准化，封装成容器的格式，方便不断做镜像，不断进行扩充管理。方便了微服务架构的开发，可以去管理一些应用，所以这里很多人都会用到容器的原因，在这把它当做一个管理的工具去实现了。
持续交付-构建与持续集成-持续集成
跟构建实践差不多的，持续优化和改进团队的持续集成的能力和变更。
持续交付-部署与发布管理-部署与发布模式
部署与发布泛指软件生命周期中，将软件应用系统对用户可见，并提供服务的一系列活动，包括系统配置，发布，安装等。整个部署发布过程复杂，涉及多个团队之间的协作和交付，需要良好的计划和演练保证部署发布的正确性。
其中部署偏向技术实践，即将软件代码，应用，配置和数据库变更应用到测试环境、准生产环境和生产环境的过程。发布偏向于业务实践，指将部署完成的应用软件功能和服务正式对用户可见，提供线上服务的过程。部署和发布的有机结合，实现了软件价值向最终用户的交付。
持续交付-部署与发布管理-持续部署流水线
持续部署流水线是 DevOps 的核心实践，通过可靠可重复的流水线，打通端到端价值流交付，实现交付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段，每个阶段层层递进，提升软件交付质量信心，并且在流水线过程中提供快速反馈，减少后端环节浪费。
可视化流水线可以增强跨组织的协同效率，提供有效的信息共享平台，从而统一组织目标，并且不断识别流水线中的约束点和瓶颈，以及潜在的自动化及协作场景，通过持续改进而不断提升软件交付效率。
持续交付-环境管理
环境作为 DevOps 持续敏捷交付过程中最终的承载，环境的生命周期管理、一致性管理、环境的版本管理都变得非常重要。环境管理是用最小的代价来达到确保一致性的终极目标。
其他相关标准内容，详见相关文档（文末可下载）。
三、DevOps 系列标准的幕后英雄
devops是什么意思三:如何建设企业级的 DevOps 平台？
普元从 2008 年开始研发持续集成平台（CIP）、自动化测试平台（UTP），2009 年内部的所有产品都实现了持续集成、自动化测试、自动化部署。
随着 DevOps 理念的兴起，企业的数字化转型的需求也愈发强烈，于是开始着手研发 DevOps 平台，并在这个过程中不断探索微服务、DevOps、容器云、ChatOps 等的关系和最佳实践。DevOps 先后历经 4 个大版本，目前已经完成了落地的实践。
2015.7~2016.4：为支撑企业数字化转型，普元开始研发数字化企业云平台（ThePlatform），于 2016 年 4 月完成 1.0 版本并进行内部上线。1.0 版本主要提供了持续集成和持续部署的能力，同时还包含了自己的容器云平台，与容器云平台对接，贯穿设计、开发、测试、上线、维护五大软件研发生命周期，打通代码提交、触发集成、自动部署到容器云的快速链路。
2016.5~2016.9：基于自己吃自己狗粮的思想，通过 1.0 版本研发了 2.0 版本，考虑到产品的发展，将数字化企业云平台中的产品各自独立拆分出来，包括 DevOps、容器云。每个产品都有着独立团队，持续发展。DevOps2.0 在 1.0 版本的基础上，打通规划、需求等环节，将产品管理、项目任务管理等能力纳入进来。
做了 2.0 版本，大家反倒有些困惑了，DevOps 平台真的就只是简单的通过和某些工具（如 Jenkins）集成，然后一键编译、部署到容器云上就可以了吗。我们开始借鉴很多国外的优秀产品，同时也开始和更多的其他公司进行深度交流。慢慢地发现，真正实现一个企业级的 DevOps 平台，远不止和 Jenkins 做集成、一键部署到容器云这么简单。以持续集成为例，一个企业要支持的集成环境肯定不止一种，包括 maven 编译、ant 编译、android 编译、ios 编译、前端应用编译（nodejs），在集成时还要考虑和代码质量分析，单元测试、单元测试覆盖率检查、介质上传等能力的结合，其实集成也是一个工作流。
最典型的一个流程如：maven 编译 (包含单元测试)--》代码质量分析 --》交付物上传到二方库。在构建后还应该看到详细结果：构建详情、日志、单元测试报告、代码质量分析报告、介质查看与下载等能力。想想，这样的一个过程是不是才能基本满足了企业的正常使用方式？
以部署而言，企业的真实环境又岂会是只有容器云。对于大部分企业而言，物理机是必须的，有的企业甚至物理机、虚拟机、容器云三种环境并存，那么在部署的能力上，只支撑容器云环境的部署显然是远远不够的，至于企业实际的部署能力，自然又更加的复杂：应用部署（springboot 应用，传统 war 包、纯前端应用）、中间件部署（数据库部署、分布式缓存、分布式消息队列）等都要一一考虑。所以在 2016.7~2016.8，我们开始研发 3.0 版本中，在持续集成和自动化部署的能力上，参考 tfs 和 oneops 的优秀设计，结合企业实际的使用场景，用了两个月的时间细化打磨持续交付的能力。
2016 年 10 月份开始，我们重新梳理了整个 DevOps 平台的需求，将整个平台划分成了三大领域：敏捷过程、持续交付、持续改进。
敏捷过程：包含产品管理、项目管理、任务管理、进度管理、计划管理等，覆盖产品、项目的全生命周期。
持续交付：包含代码库的管理、持续集成、部署、交付流水线等能力，意在打通从代码提交到部署上线的全流程。持续集成支持编译、打包、测试、工具四类构建任务，支持代码提交时触发构建、定时构建、手动构建三种构建触发策略。在部署方面，支持 springboot 应用、传统 war 包、html 站点、mysql 等部署，支持灰度发布、滚动升级、蓝绿发布等多种部署策略。
持续改进：包含质量标准、质量监控、以及产品项目全生命周期过程中的各种度量报表。支撑企业的精益度量。
2017 年 6 月份会发布 5.0 版本。
这里为什么要强调“企业级”呢？一个小团队如果想要实现 DevOps 能力其实可以很简单，因为团队规模不大，比较容易管理，同时负责的应用也不会特别多，通过集成一些开源的工具完全可以做到持续集成、持续部署、持续交付，同样可以带来极大的效率提升，这其实也是一些互联网企业内部小团队的特色。但是当这一切放大到一个数百人，数千人甚至数万人的企业时，就会发现遇到的问题、阻碍呈几何级的上涨。一个企业要考虑的因素太多，历史越悠久的企业，内部的文化、流程越是根深蒂固，而当一个平台需要打通整个 IT 生命周期时，现有的文化、流程，现有的组织结构都不得不慎重推敲下是否能够满足。所以，如何建设适合自己企业的 DevOps 平台，即使现有市场的 DevOps 理念已经基本普及开了，但是到落地的时候，却总会发现困难重重。到底该怎么去落地呢？
对于 DevOps 平台的定位还是要再明确下，DevOps 代表的含义早已不仅仅是简单的开发运维一体化，而是在此基础上，打通产品、项目的软件研发全生命周期，覆盖持续交付、持续改进等能力，在纵向打通应用的全生命周期（需求、设计、开发、编译、构建、测试、部署、运维等），横向打通架构、开发、测试、质量、运维、运营等部门。
我们把 DevOps 分为三大领域，敏捷过程、持续交付、持续改进，三者相互独立却又相辅相成。通过 DevOps 平台将企业软件研发的全生命周期管理起来，在保证质量、安全的前提下，通过一些自动化的手段不断提升软件交付的效率，通过不断精益度量对过程、对技术持续改进，最终支撑起企业的 IT 精益运营。
可能很多人对于 DevOps 的理念还存在这样的误解：DevOps 来源于互联网，也只适合互联网企业。但 DevOps 思维和互联网思维还是有着一定的区别的，不能简单的认为只有互联网公司才适合 DevOps。恰恰相反，其实 DevOps 理念的提出以及最初的发展并非是互联网公司而是传统企业。互联网公司强调的是快速、用户口碑，性能，并且对于上线的大部分应用具有一定的容错性，严重的错误可以快速的修改和再上线。而 DevOps 追求的是质量、效率、精益、价值、稳定，企业尤其是金融类的企业对于线上应用的问题容忍度其实很很低的，很难想象如果一个交易业务出现问题后，会给企业带来多大的损失。
所以，DevOps 绝不只是互联网企业可以实行，对于传统企业而言，更加适合。通过建设 DevOps 平台来大幅提升软件研发效率，提升对市场的响应速度，支撑企业的数字化转型，也许对于传统企业而言，DevOps 平台带来的价值才是更大的。
清楚了 DevOps 平台的定位，也明白了 DevOps 平台对于任何企业都是可以实现的，那么还是回归到自身上，需要结合企业自身的现状思考下：到底 DevOps 能给自己的企业带来什么样的业务价值呢？DevOps 平台的理念固然是将软件研发的全生命周期管理起来，但是并不意味着一定要做到全生命周期的管理，落实到企业内部，终究还是要结合企业的现状和实际的需求，有选择性有目标的去建设。比如某企业由于组织的问题无法打通整个生命周期，那么通过持续集成、自动化测试、自动化部署等能力，提升软件交付的效率也是极好的。
对于企业而言，不管是提升 IT 的运营效率 70%，还是做到开发测试环境的持续集成、自动化测试、自动化部署，亦或是一天部署 10 次这种 DevOps最初的目标，最重要的还是要结合现状，先认清 DevOps 能给企业带来什么样的业务价值。
Step 1 梳理企业的流程和规范：
梳理企业的流程和规范是企业建设 DevOps 的前提，甚至即使不建设 DevOps 平台，这也是一个必不可少的行为。只有统一了企业的流程和规范，才能建设出一个适用于企业的 DevOps 平台，否则到最后，有可能会让 DevOps 平台脱离实际，导致没有人会去使用。那么有哪些流程和规范是要提前梳理和统一呢？这里列举几个如下：
产品（应用）管理规范：包括版本管理、需求管理的规范等
项目管理规范：包括团队的角色构成、过程工作流模板（Agile,CMMI,Scrum）、计划 / 任务管理规范等
开发和编译规范：包括代码开发规范（分支主干的使用）、代码提交规范、构建规范（触发策略，是否需要代码提交时构建等）、介质管理规范等
部署相关的流程和规范：比如部署架构的规范，环境的管理规范、软硬件资产管理规范等...
Step 2 总结自身的痛点和需求，规划建设路线图（MVP）
完整的 DevOps 平台是个很庞大的体系，如果全都靠自己建设的话，很显然不可能短时间建设完成，那么就要结合自身的痛点，从痛点入手，认清自己最迫切的需求，规划出 DevOps 平台的建设路线图。基于 MVP的理念，一步步有序的推 Minimum Viable Product进整个平台建设。假如自己的企业目前主要的瓶颈在于如何提升研发效率，那么就可以从统一开发平台、打通持续集成作为切入点。如果目前的主要问题是软件交付速度太慢，那么可以优先考虑持续集成、自动化部署、自动化测试、交付流水线的建设。
Step 3 从组织、技术、流程、文化四个维度持续优化与改进
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 的一个 pipeline stage。在执行时，将所有构建任务结合构建定义的一些基础信息，创建 Jenkins 的 pipeline 进行执行。
Jenkins 的搭建采用 master/slave 集群模式，面对大量应用的编译压力时可以更好的分散压力，保证编译速度。如果想更灵活的话，可以考虑 Jenkins 集群部署在容器中，通过容器云的动态伸缩能力，可以更灵活的去使用资源。这里要提到一个关于异构环境的编译，如 ios 应用的编译，就必须在 mac os 系统中进行。这就要求编译机和其他的机器有所区别。我们是采用 Jenkins 的节点标签能力，如果是要进行 ios 编译任务的话，就会通过标签到 ios 的工作节点中执行任务。
4. 自动化部署在自动化部署模块中，为了更好的与实际结合，我们将部署分为三个阶段：设计、转换、运维。
设计阶段：将部署架构分为三层：部署装配（Assembly）、部署容器（Platform）、部署组件 (Component)。部署装配是对部署架构的描述，由多个部署容器组成，每个部署容器由若干个部署组件组成。
操作流程：
创建 Assembly
通过选择可用的系统模版 (Platform Template)，添加一个新的 Platform。
每一个 Platform 都对应一种应用（如 mysql，tomcat，springboot，nginx）。
每一个 Platform 都是有一组组件（Component）组成的，并且已定义好了组件之间的依赖关系。
管理 ComponentComponent 是最底层的部署（或者配置）单元，如 springboot 中的 secgroup, compute, os, jdk, fatjar, lb 都是一个组件每一个 Component 都有相应的配置模版。
提交设计提交的过程是将已经完成的设计做一次 Commit，做一次归档。
转换阶段：转换（Transition），是在 Assembly 内对应用 / 系统在某一具体部署环境内的部署过程。部署环境是配置、架构设计、运行资源、部署策略的结合。
操作流程：
创建部署环境（Deploy Environment）根据环境类型 (如 dev, test, prod 等)，添加属于某个 Assembly 的部署环境。
部署之前，部署环境是应用 / 系统用于部署的配置的抽象。
部署之后，部署环境就是管理和监控应用 / 系统的具体实例的集合。
配置部署环境设置每个 Platform 关联的资源（vm/container）、部署模式（单点，高可用）
选择 Assembly 内的一个或多个 Platform 生成并提交执行计划
根据部署策略不同，一个 Platform 的执行计划可能包含几个子计划
执行部署
每个 Assembly/Environment/Platform 下面的每个 Component 都有一个部署实例，这些实例可以进行单独操作
运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等
考虑到驱动的统一性以及 Jenkins2 插件的丰富性，DevOps 自动化部署框架底层同样使用了 Jenkins。采用 DevOps 平台（设计）＋Jenkins（执行）的方式完成。
DevOps 的职责：
完成部署架构设计；
根据部署架构设计和部署环境的配置创建生成相应的执行计划及子执行计划，每一个子计划对应一个 Jenkins pipelinejob 配置文件 (config.xml)；
查询 Jenkins 执行 job 的实时进度与结果。
Jenkins 的职责：
根据 config.xml 创建 Jenkins Pipeline Job；
执行 pipeline job；
Jenkins job 通过 pipeline script 中 ansible／openshift 命令进行相应的部署等执行操作；
提供查询 job 执行情况的 Rest API。
DevOps 平台中的部署架构设计和 Jenkins pipeline 的映射关系如下图所示：
可以看到每个组件都会对应 Jenkins 的一个 stage。所有的 stage 组装成一个完整的 pipeline 在通过 Jenkins 执行。
为什么选择 Jenkins pipeline? 主要是结合以下几点进行考虑的
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 等插件，不需要我们再单独实现集成。
Rest API：Jenkins 提供通过 Rest API 的方式获取每一个 stage 的执行情况。
有了持续集成、部署、测试的能力是否就足够了呢？其实还是不够，DevOps 的本质是 IT 生产线，交付流水线是持续交付的核心能力，它可以把分散的能力如构建、部署、测试等串联在一起，形成一个从代码提交到发布上线的流水线，通过流水线可以很直观的看到当前某个具体构建版本已经到了哪一个环节，从整体上对于软件交付进行更好的把控。
在设计流水线能力时，我们主要考虑到几点：
结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置
流程的每一个环节都要支持自动执行的配置
流程中每个环节的属性和配置信息可以自定义，灵活扩展
流程以构建开始，让 buildNumber 贯穿整个流程，方便追根溯源
要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是 SIT 还是 UAT，结果如何
要有一个看板，直观的看到每个环境下，有哪些介质在运行
以这些为基础准则，我们底层基于了普元的 BPS 流程引擎，支撑流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。整个流水线从构建开始，以代码的 buildNumber 贯穿全流程。便于问题、进度的追溯。看板的设计如下：
QA环节 Q1 ：实施DevOps过程中，持续集成上线有没有引入A/B测试？DevOps 如何开展主流程压力测试的？
A1： A/B测试现阶段我们还没有引进，压力测试我们是通过集成JMeter实现的，部署到LAB环境，调用JMeter实现压力测试。
Q2： 2009年就实现了CI CD和自动化测试，那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等角色。比如运维需要去管理和开通机器。如果是虚拟机和容器云的话，运维则只需要提供好相关的接口和保证资源充足，开发测试环境完全可以让开发和测试人员直接在平台去部署。平台会调用底层接口创建虚拟机和容器。
作者介绍
王海龙，普元信息云计算架构师，毕业于华东师范大学，曾参与和负责银联 Paas 云平台项目、兴业银行 CAP4J 项目、交通银行信用卡中心统一监控平台项目、神华灾备云平台、万达 DevOps 平台等项目。
欢迎扫描讲师个人微信二维码，加入由讲师主持的技术讨论微信群，与讲师一同交流、探讨DevOps相关问题。添加暗号：65
