开发测试云DevOps解决方案建议书.docx

1、开发测试云（DevOps） 解决方案建议书目 录1591开发测试行业现状及需求分析.31.1 开发测试现状31.2 传统开发测试架构和流程51.3 开发测试新需求72开发测试云(DevOps) 解决方案概述.92.1 方案概览92.1.1 平台架构112.1.2 功能特性132.2 产品组件162.2.1 持续交付 vRealize Code Stream162.2.2 服务调配 vRealize Automation182.2.3 软件定义的存储 VSAN262.2.4 软件定义的网络 NSX313开发测试云(DevOps) 解决方案技术详解.383.1 持续交付 vRealize Code

2、 Stream383.2 服务调配 vRealize Automation423.2.1 业务组成元素423.2.2 构成组件473.2.3 主要功能493.3 软件定义的存储 VSAN833.3.1 体系结构833.3.2 基于存储策略的管理853.4 软件定义的网络 NSX913.4.1 基本组件913.4.2 工作原理933.4.3 主要功能954VMware DevOps方法论.1084.1 总体指导原则1084.2 服务调配方法论1094.2.1 关于服务1094.2.2 服务的调配管理1124.2.3 服务设计和开发管理1155DevOps 部署建议.1205.1 服务调配部署建议

3、1205.1.1 基础架构服务调配规划1205.1.2 应用服务调配规划1345.2 软件定义存储部署建议1355.2.1 部署要求1355.2.2 规划设计细则1375.2.3 部署最佳实践1435.3 软件定义网络部署建议1435.3.1 逻辑交换1435.3.2 逻辑路由1465.3.3 逻辑负载均衡1486方案优势总结.1517DevOps 实施步骤与成功案例.1567.1 实施步骤1567.2 成功案例1568缩略语解释.1581开发测试行业现状及需求分析1.1 开发测试现状现在，人们越来越多的意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致 冲突和低效，正如李汤普森（Le

4、e Thompson ）和安德鲁谢福尔（Andrew Shafer ）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的 存在。图：开发与运维之间的“混乱之墙”以开发为中心的人通常认为，变化会带来回报，企业依靠他们来应对不断变化的需求，因 此他们被鼓励尽可能进行变革。而运维人员则往往视变化为敌人，企业依靠他们维持正常业务运维和实施让企业赚钱的服 务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们 多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变。更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同的管理者

5、 和竞争关系，而且通常工作在不同的地点。图：开发与运维通常工作在不同的地点此外，让混乱之墙更坚固的还包括开发和运维工具之间的错位。开发者要求和日常使用的 常见工具与系统管理员所使用的工具存在很大不同，开发人员没有兴趣使用运维人员的工具， 反之亦然。而且两部分工具之间也不存在重要的集成，即使在某些工具类型上有一些重叠之处， 使用方式也完全不同。图：开发与运维常用工具的不集成当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在将变得更加明显，如下 图所示。图：应用程序变动从开发到运维开发人员把一个软件版本“扔”给墙对面的运维人员，后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者

6、提供的部署脚本或创建自己的脚本，他们还需要修改配置 文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已 完成的工作，而糟糕的情况却是，他们将引入或发现新的漏洞。运维人员然后开始进行他们自认为正确的部署过程，但是由于开发和运维之间的脚本、配 置、过程和环境存在差别，这一部署过程实际上也是首次被执行。这一期间如果产生一个问题， 开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题，而开发人员则 会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。 由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。可见，

7、由于没有一个可靠的方式来把环境回滚到此前已知的正常状态，本来应该一帆风顺 的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。上述这 些状况在目前的开发测试行业极其普遍。可见，部署阶段已经非常明显的需要开发和运维之间的协作来解决问题，但需要这种协作 的绝不仅仅是这一阶段。正如约翰阿尔斯帕瓦（John Allspaw ）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。1.2 传统开发测试架构和流程传统开发测试架构和流程是导致上述状况的主要原因。传统的开发测试中，由于组织结构、 文化以及技术局限性的多种原因，开发、测试和运维

8、各自相互独立，每个阶段都需要一套复杂 繁琐的流程，如下图所示。图：传统开发、测试与生产在组织中，开发测试和运维管理往往属于不同的部门。开发测试部门的驱动力通常是“频 繁交付新特性”，而运维部门则更关注 IT 服务的可靠性和IT 成本投入的效率。两者目标的不匹配，就在开发测试与运维部门之间造成了鸿沟，从而减慢了IT 交付业务价值的速度，如下图所示。图：各部门之间的鸿沟上述开发测试架构和流程会在开发测试与系统运维中制造诸多的不协调与矛盾。u 开发人员经常不考虑自己写的代码会对运营造成什么影响，他们在交付代码之前， 并不邀请运营人员参与架构决策或代码评审。u 开发人员对配置或环境进行修改之后，经常没

9、有及时与运营人员沟通，导致新的代 码不能运行。u 开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要 的配置参数，通常需要尝试很多不同的参数，在得到一个可工作的状态后，往往很 难识别出通过哪些最小步骤就能到达该状态。u 开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存 消耗，等等。这样的工具集与运营人员面对的目标运行时环境非常不同：后者对稳 定性和性能的要求远胜于灵活性。u 由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生 产环境的运行时系统通常都运行服务器操作系统上。u 在开发过程中，系统在开发者的本地机器上运行。在运营过

10、程中，系统经常分布在多台服务器上，例如web 服务器、应用服务器、数据库服务器等等。u 开发是由功能性需求（通常与业务需求直接相关）驱动的。而运营是由非功能性需 求（例如可获得性、可靠性、性能等）驱动的。u 运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险u 如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模 就会变大u 变更规模越大，风险也越大，因为其中涉及的区域越多u 由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了 开发人员将特性交付给用户使用的速度。u 运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流 程

11、。u 开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。由于上述这些不协调与矛盾，现有开发测试架构存在如下问题。u 研发效率低, 应用上线速度慢u 开发测试环境搭建从资源申请、购买到使用手工配置需时较长，影响进度u 开发测试所需的IT 资源管理不灵活，申请分配环节多，且使用率不高u 开发测试资源申请周期长，影响工作效率u 大型软件企业各部门独立开发环境易形成孤岛，管理成本较高u 开发测试所需的硬件和软件环境对初创软件企业来说成本过高，使用开源软件的配 置和掌握需时较多影响效率1.3 开发测试新需求基于上述当前开发测试架构存在的诸多问题，开发测试行业的新需求如下所示。 业务层面u

12、如何快速业务创新u 如何快速占领市场u 如何获得竞争优势 产品研发层面u 如何快速交付应用u 如何让研发人员更专注于产品u 如何提高产品质量 架构和运维层面u 如何更好支撑应用u 如何提高运维效率u 如何降低IT 成本u 如何维护统一的IT 运维流程上述三方面的新需求是为了让企业在市场、成本与风险层面达到最大程度的协调与统一， 如下图所示。图：开发测试新需求2开发测试云(DevOps) 解决方案概述本章将对开发测试云(DevOps) 解决方案进行概述。2.1 方案概览从应用架构与基础架构的角度看，开发测试云(DevOps) 解决方案属于第三代开发测试平台，不同于以ERP 等传统应用为代表的第二代平台，第三代平台以社交、移动和云为特点。VMware 开发测试云平台基于软件定义的基础架构，并采用自动化的方式进行交付。同时， 应用的开发和部署也通过自动化的方式来完成，如下图所示。图：VMware DevOps 属于第三代平台开发测试云(DevOps) 平台通过如下方式实现。u 从应用开发与基础架构两个层面面向DevOps 进行转型u 打通研发与生产运维体系, 逐步推进构建DevOps 团队u 采用统一的工具vRealize Code