开发测试云解决方案建议书_.docxVIP

VMware开发测试云（DevOps）解决方案建议书目录1开发测试行业现状及需求分析41.1开发测试现状41.2传统开发测试架构和流程61.3开发测试新需求72VMware 开发测试云(DevOps)解决方案概述92.1方案概览92.1.1平台架构102.1.2功能特性132.2产品组件152.2.1持续交付vRealize Code Stream162.2.2服务调配vRealize Automation172.2.3软件定义的存储VSAN232.2.4软件定义的网络NSX283VMware 开发测试云(DevOps)解决方案技术详解343.1持续交付vRealize Code Stream343.2服务调配vRealize Automation373.2.1业务组成元素373.2.2构成组件413.2.3主要功能433.3软件定义的存储VSAN733.3.1体系结构743.3.2基于存储策略的管理753.4软件定义的网络NSX803.4.1基本组件803.4.2工作原理823.4.3主要功能834VMware DevOps方法论954.1总体指导原则954.2服务调配方法论964.2.1关于服务964.2.2服务的调配管理984.2.3服务设计和开发管理1005VMware DevOps部署建议1045.1服务调配部署建议1045.1.1基础架构服务调配规划1045.1.2应用服务调配规划1175.2软件定义存储部署建议1185.2.1部署要求1185.2.2规划设计细则1205.2.3部署最佳实践1245.3软件定义网络部署建议1255.3.1逻辑交换1255.3.2逻辑路由1275.3.3逻辑负载均衡1296方案优势总结1317DevOps实施步骤与成功案例1357.1实施步骤1357.2成功案例1358缩略语解释137开发测试现状现在，人们越来越多的意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。图：开发与运维之间的“混乱之墙”以开发为中心的人通常认为，变化会带来回报，企业依靠他们来应对不断变化的需求，因此他们被鼓励尽可能进行变革。而运维人员则往往视变化为敌人，企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变。更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同的管理者和竞争关系，而且通常工作在不同的地点。图：开发与运维通常工作在不同的地点此外，让混乱之墙更坚固的还包括开发和运维工具之间的错位。开发者要求和日常使用的常见工具与系统管理员所使用的工具存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然。而且两部分工具之间也不存在重要的集成，即使在某些工具类型上有一些重叠之处，使用方式也完全不同。图：开发与运维常用工具的不集成当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在将变得更加明显，如下图所示。图：应用程序变动从开发到运维开发人员把一个软件版本“扔”给墙对面的运维人员，后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本，他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已完成的工作，而糟糕的情况却是，他们将引入或发现新的漏洞。运维人员然后开始进行他们自认为正确的部署过程，但是由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。这一期间如果产生一个问题，开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题，而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。可见，由于没有一个可靠的方式来把环境回滚到此前已知的正常状态，本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。上述这些状况在目前的开发测试行业极其普遍。可见，部署阶段已经非常明显的需要开发和运维之间的协作来解决问题，但需要这种协作的绝不仅仅是这一阶段。正如约翰·阿尔斯帕瓦（John Allspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。传统开发测试架构和流程传统开发测试架构和流程是导致上述状况的主要原因。传统的开发测试中，由于组织结构、文化以及技术局限性