智慧开发测试云平台方案建议书Word格式文档下载.docx
《智慧开发测试云平台方案建议书Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《智慧开发测试云平台方案建议书Word格式文档下载.docx（63页珍藏版）》请在冰点文库上搜索。
6 成功案例 60
6.1 广东移动南方基地VDC 61
6.2 浙江移动增值业务私有云 62
6.3 澳洲电讯（Telstra）私有云 63
1项目建设需求理解
近年来，无处不在的互联网化深刻的颠覆着用户对金融服务的消费方式和金融服务组织向用户提供服务及与用户交互的方式。
快速捕获用户需求的敏捷业务功能发布、快捷的服务交付、体验良好的自服务、无对外中断的连续服务能力、对日益严格的监管要求更高程度的合规……等等这些使得IT组织承受着来自业务团队的巨大压力，但同时也让IT组织面临推动业务蓬勃发展的契机。
随着业务发展，业务部门对广东省农信开发测试团队提出了越来越高的挑战，而目前广东省农信IT中心的测试环境均由开发室在管理，而测试室在执行测试的过程中，存在着测试环境不稳定，版本在测试过程不可控，测试环境众多且不完善，部署测试环境工作繁琐，工作量大等问题。
采用云计算的模式管理开发测试资源，促进资源部署的敏捷性是大势所趋。
开发测试云的建设将促进敏捷开发，及时响应业务需求，加快开发、测试、上线的周期。
从管理目标来看，此次广东省农信的开发测试云平台的搭建源于外部及内部业务（转型）驱动：
外部业务驱动：
外部业务的敏捷性诉求直接转化为对IT组织的应用生产（开发-测试）、上线（发布）及运行维护的敏捷性和稳定性要求。
1） 敏捷性：
业务功能交付的敏捷性含义在于业务需求确认后，IT团队以多快的速度完成向业务团队的交付，端（业务需求受理）到端（业务应用运行）的总时间消耗越短，敏捷性越强。
从IT团队看，在这其中，一部分时间是应用开发人员的创造性投入，包括需求分析、架构分析、代码开发、测试实现等等；
另外一部分时间则是附属性的配套管理支持，包括开发、测试及准生产、生产等环境的基础环境准备、标准组件部署、标准化应用部署（包括发布更新、备份、恢复等）等重复性工作。
如何压缩后者的时间消耗，提升这部分工作的运行管理效率，并将技术人员从重复性工作中解放到创造性工作中，是有效支撑业务敏捷性实现的重要途径。
2） 稳定性：
在每次快速准确的应用迭代后段（即应用生产环境的成功发布后，到下一次发布前），为确保业务持续稳定的运行，在微观的系统应用上，需要以该次成功发布部署为起点，确保该配置状态不发生异常的漂移：
构建应用的状态基线；
主动比对；
在发现基线不符时及时获知、乃至强制修复。
因此，面向应用系统整体，实现常规性检查、稽核及差异追踪定位的能力，是有效支撑业务敏捷性实现的又一有效途径。
内部转型驱动：
在有效支撑业务运行的基础上，以虚拟化平台和云计算管理平台为代表的建设动作体现了广东省农信IT团队自我更新的强烈诉求。
尤其是在云计算模式逐渐被广大IT消费者和IT管理者认可并付诸实践的大环境、大趋势下，如何实现由成本中心向服务中心转变，从而提升用户的服务体验及优化运行成本和效率，是云计算管理平台建设中重要的管理课题。
3） 资源利用效率：
在开发、测试环境中，项目组习惯按照理想化的标准申请并长期占用计算资源，这种情况造成开发、测试环境的总体资源利用率偏低，资源扩展压力偏大。
在新的云计算管理平台上，应引入资源管理的新模式，形成更为科学的资源消费和管理机制，优化资源的复用率和计算能力，并减轻资源采购的压力。
——有效的时间片维度、计算能力（运算、IO、存储、带宽等）维度以及管理操作（审批、部署、变更、回收等）维度的池化共享和复用是获得这种模式转变的关键能力。
4） 运行维护负荷&
成本：
对于开发、测试环境的资源和业务应用，管理团队都需要投入相当的人力和时间进行支持维护。
其中最显著的消耗热点包括：
资源申请的审批、部署、交付；
应用版本的切换调整；
应用更新的发布、校验；
应用上线前的检查、修复；
应用的日常跟踪、巡检等。
通过标准化的建设和自动化的实现，可以提高支持工作的执行效率、配置操作的一致性水平、版本管理的精细化水准和吻合度、应用在开发-测试环境的转换效率，从而降低总体运维成本，平滑应用各阶段团队的协作，并将宝贵的技术人员从繁冗的重复性工作和手工错误修复工作中解放出来，而投入到真正有创造性的工作中。
5） 管理透明度：
基于大量手工操作的管理实现下，团队流程的运行情况难以颗粒化、实时化和可视化，从而难以对团队组织的自我运行情况进行治理层面的客观审视。
也因而，管理层难以获得管理提升的洞见，微观层面的改进目标也往往陷于相对盲目。
减少全手工操作的工作比例，落实管理信息的自动跟踪记录，量化资源、应用维度的运行情况等等措施，可以革新管理的方法，提升管理透明度，促进操作-管控-决策各层的共识，从而使高层决策真正基于微观运行情况，获得更为科学、及时的决策。
6） 技术方向自主性：
随着管理规模的不断增长，对基础性资源和技术的需求也不断增长；
另一方面，新技术的成熟速度越来越快，技术更替的速度逐渐加速。
在这种情况下，依赖单一厂商和技术，对后续管理建设成本和持续技术改造造成较大的负担，——对于非开放性的、基础环节的技术尤其如此。
在云计算管理平台及其它类似的基础性建设中，充分考虑开放性、异构性、兼容性是确保未来技术方向自主性的重要保障；
尤其在公有云、混合云渐行渐近的大环境下，更是如此。
2方案说明
2.1整体方案
BMC开发测试云平台包含2个层次：
上层为发布流程/过程管理模块，支持托团队的协作和外部管理系统的衔接；
下层为云生命周期管理模块，支持云环境中对于各资源池的自动化部署动作实现。
作为可灵活扩展的管理平台，随着管理需求的演进，其它自动化工具可以随需引入。
如服务于复杂数据库操作的数据库自动化组件，服务于细粒度中间件配置操作的中间件自动化组件，服务于开发/测试环境系统自动化部署的云生命周期组件，服务与网络配置操作的网络自动化组件以及串联负责操作过程的调度组件。
2.2方案组成
2.2.1发布流程管理
在应用发布流程管理上，BMC通过应用发布管理模块实现，主要包括以下功能：
n确定需要做哪些以完成发布（whatneedstobedone）
n确定哪些部分可以被自动化（howmuchofitwecanautomate）
n确定各步骤分别由谁负责执行（whoneedstodoit）
n创建排期（createaschedulefordoingit）
在每个可能发生的请求中，可以定义具体的步骤，每个步骤都有对应的执行负责人，以实现协作，并实现自动化关联。
在运行时，特定用户以自己的帐号登录平台，平台会根据其预定义的角色提供协作。
下图中，该用户能够启动和暂停流程；
被暂停的流程可以让前述步骤重做，以满足当前步骤的前提。
平台通过应用建模的方式刻画应用、环境、系统、人员等发布管理要素。
n应用的组件形态（应用由哪些可分离部件构成）
n部署的目标环境（本次发布周期历经的环境）
n组件与环境的对应关系（哪些组件存在于哪些环境中）
n组件与服务器的对应关系（部署组件存在于哪些服务器上）
n属性/参数与组件的对应关系（属性/参数在不同环境的部署组件上有哪些差异）
n属性版本与环境的对应关系（各环境上运行的组件版本是什么）
2.2.2云生命周期管理
BMC云生命周期管理平台支持客户以结构化的方式部署云计算基础架构，使用已被证明有效的解决方案和技术，涉及云计算的各个环节，确保用户的云计算解决方案能够正确覆盖云基础架构的所有关键要素，同时也允许用户定制其结构以满足某些业务的特殊需求。
BMC整合了高效运维、自动化服务交付模式，并将其与云计算的动态特性相互集成，代表着业界的最佳实践。
云生命周期管理平台的总体架构如上图，总体包含以下几个层次：
1）服务门户层
该层由前端服务门户和结构化的服务目录系统组成。
该层实现如下功能。
n管理员定义面向各类用户的各类服务，包括从单个服务器实例的简单服务到由多个服务器系统叠加不同应用软件及互联配置的复杂多层应用环境服务。
n最终用户根据其可见性浏览和选取相关服务，并根据需求设定服务选项，提交服务申请，跟踪服务申请状态及接入服务所包含的计算资源，查看资源的用量和计费信息。
n整合日常运维的相关功能，如性能监控，容量管理等。
n整合其它扩展运维功能的综合前端展现，如配置管理仪表盘及基线，自动化作业运行分析，服务请求总体状态，灾备切换状态等等。
n在该层次中，可实现用户访问权限和角色的管理，使不同用户查看和申请不同的服务。
2）服务交付层
n该层由变更管理流程，服务蓝图，服务策略及运维管理组成。
n基于业务和技术需求的策略化资源分配；
管理员则可以动态的定义资源部署策略。
n面向服务提供流程化的变更管理及审批流程定义及控制，使资源申请-审批流程符合用户的业务要求并不断演进。
n基于基础架构实时容量的智能化资源分配策略，确保交付的服务处于良好的运行状态。
3）资源管理层
该层包含对各种基础架构资源的管理抽象和封装，向上提供标准化的管理操作方法，向下实际驱动基础架构的配置、操作和总体调度。
n容纳并支撑异构混杂环境的云环境，包括物理资源，虚拟化资源，外部资源管理工具（如桌面云）甚至公有云：
IBMP系列服务器及分区技术，x86物理机服务器，基于x86的VMWare虚拟化平台，基于IBM主机的计算资源，桌面云的端到端生命周期管理接入，网络设备，防火墙设备，负载均衡设备。
n抽象和纳管三类资源——计算资源，网络资源及存储资源，对这些资源提供统一化的操作方式。
n支持中间件、数据库以及私有应用的软件资源，根据前端用户的需求完成软件对象服务的交付，如OracleRAC、特定实例名的数据库、特定端口开放的中间件、特定cell名称的WAS集群等待。
n提供开放的接口以实现灵活和插拔的资源操作接口，保持平台的扩展性，支持新的基础架构设备而无需重构平台上层。
2.3方案功能介绍
2.3.1发布流程管理
2.3.1.1发布环境解耦
通过发布环境进行应用系统的业务组件，服务器的管理，将发布模板和具体发布的环境分开，只在生成具体发布请求时引用相应的发布环境，从而实现发布环境的解耦。
具体的，在自动化发布平台可定义一系列应用发布相关参数集合，并在发布包中直接引用。
2.3.1.2发布操作自动化
1.脚本管理
可集中管理服务器脚本，比如服务启停、日志提取、数据库查询等，排定脚本执行计划，批量将脚本推送至目标服务器，并自动执行，搜集脚本执行结果。
2.自定义命令
可基于自动化操作平台编写远端（被管服务器）、本地（服务器端）的命令行，自动调用本地或服务器端的脚本，并搜集脚本执行结果。
3.交互性系统管理
授权用户通过自动化平台查看允许管理的对象，比如用户信息、服务信息、进程等，并可进行授权的配置操作；
对于常用操作提供快速入口，如日志查询、数据备份-恢复、各类数据维护操作等。
如下图：
图形化停止Linux某进程
图形化停止Windows某服务
4.文件部署
能支持将各种介质、文件自动批量推送。
如下图，将某Linux服务器的文件图形化批量推送至某服务器组
5.日常巡检
BMC的自动化平台为业界领先的第三代智能自动化平台，基于全面对象化为核心技术，通过简便的智能化逻辑判断，能够实现强大的巡检工作。
系统提供大量开箱即用的国际规范，并支持灵活导入各种业内的自定义规范，能够为实施和维护节省大量的时间。
系统的报表系自带大量各类报表，同时支持迅速、便捷的拖拽生成各种自定义报表，能够实现各种下钻、扩展等方式，能够扩展到最底层的错误日志信息。
日常合规检查功能分为定义规则，执行检查，查看结果，报表与修复。
6.一键备份与回退
针对应用，数据库及系统均有特定的备份，回退指令，发布平台通过定义备份请求及相应的备份步骤调用，可实现一键式备份，如下图所示：
2.3.1.3版本管理
平台提供对发布包的版本管理功能，实现了可视化的上传、下载、查询、对发布包的文件的大小、变更时间、版本号、变更编号等信息存储在数据库中，并可实现和生产环境中的版本对比功能。
1.发布包上传
首先通过解析Excel模板数据，获取上传变更包信息；
再通过JMS+MDB+MQ的异步提交方式，将指定的变更包批量导入到SVN版本库；
上传的同时把每个变更包的信息（如文件名称、保存SVN路径、文件时间、文件大小等）保存到数据库表中，方便以后进行变更信息查询。
上传页面同时提供依据唯一的“登录ID”进行上传状态查询的功能，其中“登录ID”在点上传按钮后自动返回此次ID值，供用户进行状态查询。
变更包Excel模版视图如下：
变更包上传截图:
2.变更包查询
通过查询上传操作时入库的变更包信息实现变更包的查询功能。
根据指定的系统、文件名、路径、版本进行查询，上传操作时入库的变更包信息。
3.变更包下载
通过变更包查询页面的“下载链接”下载变更包。
根据指定的系统、文件名、路径、版本进行查询，下载。
4.变更包版本对比
应用系统发布完成后，通过执行变更包上传操作时保存至SVN版本库与数据库中的变更包信息，如文件修改时间、大小，与指定生产环境下部署的变更包进行对比，并生成对比统计报告。
对变更包的发布情况进行检查，有效防止变更包发布的遗漏与错误。
2.3.1.4应用发布
如前所说，应用发布自动化包含2个层次：
上层为发布流程/过程管理，支持托团队的协作和外部管理系统的衔接；
下层为发布配置动作自动化管理（包括云环境自动化管理），支持各环境基础架构资源上自动化部署动作的实现。
1.关联与解耦
为实现“一次定义，多环境，多次发布“的目标，应用发布模块通过应用建模的方式刻画应用、环境、系统、人员等发布管理要素。
• 应用的组件形态（应用由哪些可分离部件构成）
• 部署的目标环境（本次发布周期历经的环境）
• 组件与环境的对应关系（哪些组件存在于哪些环境中）
• 组件与服务器的对应关系（部署组件存在于哪些服务器上）
• 属性/参数与组件的对应关系（属性/参数在不同环境的部署组件上有哪些差异）
• 属性版本与环境的对应关系（各环境上运行的组件版本是什么）
同时，应用的自动发布通过发布流程管理功能实现，平台通过定义应用、应用组件、环境、服务器、人员/分组以及定义发布计划、阶段及步骤来实现团队协作和有序管理，并在步骤节点与自动化对接。
如下图所示：
2.主要管理对象
综合以上，应用发布至少包含如下管理对象：
管理对象
典型操作
应用发布模板
将常用的发布流程固化下来，实现发布过程的重用
应用发布请求
一系列的发布流程的定义，包含：
包含应用、环境、权限控制
发布过程
一组发布步骤的组合，实现发布流程的模块化
发布步骤
一个原子的发布执行步骤，包含：
组件、目标服务器、权限控制、自动化作业绑定
组件
实现发布流程和目标服务器的解耦、绑定多个目标服务器实现负载均衡场景的并发发布
3.版本管理
发布包版本
提供介质仓库集中存放应用发布介质，以及对应的发布脚本，发布参数等信息
部署环境版本
针对已经发布到目标系统的应用文件，目录及配置的版本管理，具体场景包括定义版本基线，版本备份，版本比对，回滚等
镜像备份版本
针对以操作系统为单位的系统镜像的制作，注册和恢复等场景
4.参数管理
发布参数
提供发布参数的统一维护界面，包括创建，更新，应用发布参数等操作
环境参数
提供环境参数的统一维护界面，包括创建，更新，应用发布参数等操作
配置参数
无须编写脚本，直接对配置文件中的有效配置进行操作
5.发布模块化
平台支持将发布步骤序列保存为模板，模板可多次重用，对应具体发布步骤驱动底层自动化工具执行相应的操作，支持以可视化展现发布过程，操作执行结果，LOG输出，如下图所示：
2.3.2云生命周期管理
2.3.2.1服务门户层
在服务门户中，用户根据设定的服务可见性浏览/搜索可用服务，并选择申请服务。
不同角色的用户，所看到的服务以及服务的描述可能是不同的；
在申请时，可以选择的服务选项也可能不同。
平台实现了标准化层次化的服务模型，并且支持细化的服务成本/费用组合，使得服务能够被很好的管理和消费。
一个单一的服务模板（如Windows2008服务器），通过加载不同的服务选项（2CPU/4CPU/6CPU/8CPU、1GMem/2GMem/3GMem/4GMem、……）和服务参数（启用自监控、加载合规巡检、……），可以演化出各种用户所需要的服务实例。
更特别强大的功能在于（被低层的服务交付层和资源管理层支持），用户申请服务时，不仅仅可以选择资源尺寸类的参数（如虚机CPU/内存），还可以选择非常细粒度的服务参数。
例如：
当用户选择应用服务器类的服务时，可以让用户指定WAS集群的Cell名称、应用服务端口、应用服务器管理员密码等；
当用户选择数据库服务器类的服务器时，可以让用户指定数据库的实例名、开放端口等。
通过这种参数化的实现方式，用户消费服务的感受大大提高，而又无需付出额外服务模板的管理代价。
下图是用户申请IBMLPAR资源时，根据所需资源的情况输入特定的配置参数（参数暴露的程度可以灵活配置）。
在服务门户中，用户可以看到已属于自己的服务及服务内的基础架构资源。
对拥有的服务，授权用户可以进行一定范围的服务操作，如为系统增加额外的磁盘、为系统增加内存等；
通过底层资源管理层和服务交付层的支持，可以设计非常丰富的操作选项给用户。
作为平台管理员，在门户中可以快速查看平台的运行状况。
在云计算管理中，管理员特别关心资源的使用容量，平台提供了直观的容量视图。
此外，用户视角及服务视角的用量报告也被提供。
这些信息可以被作为内部分析之用，也可以在未来作为内部计费的基础。
平台的服务门户层，提供API，以供用户实现定制化，并可将定制化门户作为企业数据中心的管理门户及统一管理入口。
2.3.2.2服务交付层
服务交付层作为平台服务的中间层，提供了几大块服务功能：
变更管理流程，服务蓝图，服务策略及运维管理。
变更管理流程对接前端的服务请求管理，实现用户所需的业务审批和变更流程，确保用户的服务请求被纳入有序的管理中。
不同的服务，可以使用不同的变更-审批策略。
在平台上，用户可以对既有流程进行编辑和更改，并对服务重新发布。
本层的服务蓝图使BMC云管理平台真正区别于传统云计算管理平台。
服务蓝图给出了一种定义服务的全新方式。
n提供服务的部署态视图——定义部署服务的一种或多种方式（如虚拟部署形态、物理部署形态、甚至公有云部署形态）。
n说明服务运行所需的资源。
n由服务器对象、存储对象和网络对象（含负载均衡/防火墙规则）组成。
服务蓝图的构成包括组件定义、组件OS及软件定义、网络配置定义等。
以下是一个服务蓝图的简化范例。
“手机支付基础环境”服务是一种三层架构应用，服务蓝图的功能组件包含WEB层组件、应用服务器层组件和数据库层组件。
而在不同需求情况下，可以有不同的部署方式，如：
n开发环境（一体化小型环境）：
平台部署在单台VM/2vCPU/4GBMemory/500GBNAS
n功能测试环境（中型环境）[平台部署在3台VM上]：
WEB层：
1vCPU/2GBMemory/20GBNAS
应用服务器层：
2vCPU/4GBMemory/100GBNAS
数据服务器层：
4vCPU/8GBMemory/1TBNAS
n性能测试环境（大型分布式环境）[平台部署在2台VM+1台物理机]：
4CPU/8GBMemory/1TBNAS
通过服务蓝图，可以简化服务的维护，并对各服务组成方式进行单独无耦合的管理和实现。
特别的，当未来需要增加新的部署模式时，如对于上述范例，需要新的“集群环境（集群部署架构）”时，仅需要对该部署模式进行定义，并挂接到同一个“手机支付基础环境”服务下即可。
送耦合的服务定义方式，大大提高了服务管理的能力。
同时，服务蓝图的参数化支持了服务前端的高度灵活性。
如服务蓝图中可以将数据库组件的数据库实例名及服务端口参数化，前端用户就可以在请求该服务时，输入期望的值。
服务蓝图的管理方式，分割了后端实现与前端界面的紧密依赖。
事实上，该参数化在服务蓝图上实现后，平台将自动对接更低层的资源管理层，以实现资源部署时的动态逻辑——在本范例中，即在用户请求被确认后，平台发起数据库部署时，动态的将用户给定的值传入，作为创建出数据库服务的实例名和服务端口。
基于服务蓝图的特性，用户具备了实现端到端灵活化服务的能力。
本层的另外一项重要功能是服务策略管理。
在复杂的云计算环境中，用户的请求多种多样，如何保持一致性的按照既定规则选取特定特性的资源来交付服务尤为重要。
CLM平台通过标签机制和实时容量测量实现灵活动态和容量优化的策略化资源分配。
1） 资源分配首先确定目标资源池（如多个相同配置esx组成的计算机组），该过程由基于标签机制的策略管理实现。
资源池的策略化分配实现原理如下。
平台在用户/组织和资源池（含网络池+计算机池+存储池）上添加标签，同时在服务蓝图的部署方式上（含网络池+计算机池+存储池）添加标签。
当服务请求发生时，根据标签的匹配选定资源。
这种方式保证资源选择的一致性，从而实现灵活的策略化管理。
该机制将用户/组织、部署方式与资源池关联起来，以动态灵活的在运行时确定合适的资源目标。
管理员可以自定义多种特性进行策略制定，如服务级别、地域位置、数据安全性、技术分类条件等。
这种方式不依赖任何hardcode的方式，并且保持后续更新的充裕空间。
2） 确定资源池之后，平台根据池内计算节点的容量给出优化的资源摆放建议，该过程由容量管理组件支持完成。
在第一步中，资源池已被选定，在本步骤中，平台在目标资源池中确定唯一资源——该过程基于容量的资源建议。
平台通过基于性能监控的容量管理技术确定最优容量的资源；
平台收集并分析/预测资源的性能变化情况/趋势，并对资源目标选择请求调用给出返回。
动态的，基于历史性能容量波动选取的资源，最大程度的确保了交付服务的可用性，减少了未来服务迁移的可能性。
特别的，基于该容量管理组件，用户还可以扩展的进行自主的持续的容量管理。
本层的另外一部分功能是运维支持，主要包含性能持续监控以及基于自动化作业的持续合规巡检的实现。
平台构建时充分考虑服务交付后持续IT运维的需求并具备相关能力，如下。
n主动性能监控确保已交付基础架构资源的可用性
升级会员 