智慧旅游运营支撑中心建设方案.docx

智慧旅游运营支撑中心建设方案.docx

《智慧旅游运营支撑中心建设方案.docx》由会员分享，可在线阅读，更多相关《智慧旅游运营支撑中心建设方案.docx（13页珍藏版）》请在冰豆网上搜索。

智慧旅游运营支撑中心建设方案

智慧旅游运营支撑中心

建设方案

目录

第1章智慧旅游运营支撑中心方案-4-

1.1智慧旅游公共服务平台运营支撑基础架构的需求分析-4-

1.2智慧旅游公共服务平台的运营支撑中心-4-

1.3智慧旅游公共服务平台的核心基础架构整体设计-5-

1.4数据中心站点内的部署结构-7-

1.5数据中心外的部署结构-9-

1.6整体运维方案-10-

1.7安全架构设计-12-

1.8业务连续性的设计-14-

1.8.1业务连续性的需求-15-

1.8.2业务连续性的模式设计-15-

第1章智慧旅游运营支撑中心方案

1.1智慧旅游公共服务平台运营支撑基础架构的需求分析

为了快速构建以上各种平台以满足业务功能的建设，运营和扩张，更好的支撑智慧旅游业务的经营，需要高等级基础架构平台进行支撑。

根据旅游行业的特点，我们建议采用云化的基础架构进行支撑。

同时，采用双活/多活架构来满足业务连续性和客户体验的要求。

旅游产业自身是综合性服务产业，同时旅游产业与其他产业的正在不断的深度融合，这就要求要求智慧旅游的基础架构平台要能与未来城市与社会服务的对接能力要能够支撑未来20年的发展需求，根据最佳实践，按需建设的业务需要云化的基础架构。

旅游行业具有季节性、周期性，作为行业平台，需要按需扩展的计算能力进行支撑，这就必须采用先进的云化建设模式来满足业务高峰期的处理能力。

旅游行业的客户体验具有跨地域特点，同时考虑途体验和地域体验，需要平台能够为整个过程提供一致的漫游体验。

因此，需要考虑在全国进行业务能力的建设，初期计划使用双活的运营支撑中心设计来满足南北大区客户的需求。

后期采用多活的运营支撑中心及本地计算节点来进行扩展。

同时，我们也应充分考虑未来旅游业务模式的不断创新的必然性。

考虑平台必须具有扩展性。

体现在采用主流的技术平台，建设之初即具备良好的横向和纵向的扩展能力。

1.2智慧旅游公共服务平台的运营支撑中心

根据国家智慧旅游公共服务平台的总体建设规划，对运营支撑中心进行阶段性设计。

在北京和上海运营支撑的功能架构设计：

对应北京和上海两个站点，根据大型运营支撑中心的最佳实践，除了基础架构的建设外，对运营支撑的功能进行设计。

1.3智慧旅游公共服务平台的核心基础架构整体设计

智慧旅游基础架构平台的整体架构设计：

在初期建设中，采用南-北双活的运营支撑中心结构来满足整个中国的业务需求，具体的来说，根据项目建设方案，按照北京-上海的顺序建设基础架构平台，运营支撑的组织和相关制度流程，完成总控平台的建设。

在北京-上海的的支撑中心投产后，根据业务扩展的要求，在全国建立分布式的运营中心。

在大型景区和信息聚集区，建立网关式的信息节点，来满足近端计算和数据交换的要求。

•集中监控模块将各数据中心的运行状态进行汇总并实现部分自动化操作

•负载均衡模块将交易、浏览请求发送至正确的处理节点并将结果送回客户端

•数据复制模块在数据中心间维持数据的一致性

•数据中心间软硬件、网络配置一致，同时通过软件分发机制及工具维持版本管理

•跨中心的变更管理、问题管理流程和工具支持

技术构架模式上，采用以POD为建设单位的标准化建设机制，每个POD是一个标准的交付单元，便于建设，管理和运营：

1.4数据中心站点内的部署结构

多活数据中心的整体网络架构实现：

在数据中心的内部，根据业务要求，需要划分如下逻辑区域：

1）测试区

2）核心生产区域

3）DMZ区域

4）管理区域

5）存储区域

合理的逻辑分区保证了业务的有序开展。

1.5数据中心外的部署结构

CDN内容加速网络的建设也是保证海量客户体验的基础，拟在初期建设阶段完成后，在后续阶段完成国内CDN节点的部署。

CDN服务以多媒体视频为例：

考虑国外访问的需求，在国内CDN网络建成后，将前端业务平台扩展到国外。

同时完成与国际平台（B2B对接，O2O平台对接，支付平台与渠道对接，其他行业应用平台对接）的整合。

拟采用云平台完成国外的平台承载能力：

1.6整体运维方案

初期拟在在北京运营中心设立集中的运维管理中心，同时，在上海中心设立现场运维管理团队。

通过7*24*365的不间断运维，满足业务的安全稳定运行。

运维保障体系是运维工作是否能够满足未来业务快速扩张的必要建设内容，根据行业最佳实践，主要应该考虑四个方面：

●人员组织

●管理制度和流程

●技术平台和技术环境

●信息与管理

职能团队包括云管理平台管理岗、生产运行支持岗、服务台管理岗、值班经理岗、生产运行监控岗、运维体系管理岗、景点运行支持管理岗、流程管理岗、数据库管理岗、操作系统管理岗、备份与存储管理岗、中间件维护岗、硬件设备与配置管理岗、机房值班岗、网络规划岗、网络运维管理岗、运维平台开发维护岗、前端技术维护岗、基础设施管理岗、异地灾备运维岗、灾备演练管理岗

流程制度方面，完成业务交付支撑，应用管理，IT基础设施管理和产品支撑方面的建。

根据ISO20000标准的要求，建设13个标准的运维管理流程和职能：

技术平台和环境部分，建设包括“监，管，控，分析”的技术平台，建设控制中心的运营环境：

1.7安全架构设计

在云环境下，安全管控将发生如下变化：

在本解决方案中，将基于ISF（SecurityFramework）进行安全架构设计：

其中，“基于云的服务与管理”指智慧旅游公共云提供的公共云安全服务。

本项目将进行适当评估这些云服务的必要性，并进行整合分析。

具体而言，将在如下层面实现安全：

✓终端网络

✓业务接口

✓资源池：

✓云计算管理平台：

✓数据中心：

1.8业务连续性的设计

可以预见，智慧旅游公共服务平台将在未来融入中国社会的重要信息化支撑体系，其信息系统的安全将会直接影响到国民经济的正常运行，直接关系到社会稳定和群众生活。

我国信息安全的防护能力较弱，安全保障水平不高，就信息化平台来说，建立统一的灾难恢复和业务连续性管理机制，信息安全和灾难恢复工作是必须考虑的需求。

智慧旅游公共服务平台采用双活/多活的基础架构设计，在建设时，充分考虑了业务连续性的设计。

在业务连续和容灾备份建设中，以下几个概念非常重要，它们也是衡量业务持续以及容灾备份需求的指标。

恢复时间目标（RTO）

恢复时间目标（RecoveryTimeObjective，简称RTO）是指信息系统突发事件发生后，从信息系统故障导致业务停顿时刻开始，到信息系统恢复至可支持各部门运作、业务恢复运营之时，此两点之间的时间段称为RTO。

一般而言，RTO时间越短，即意味要求在更短的时间内恢复业务至可使用状态。

虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多成本的投入。

RTO目标的确定可以用下图来说明：

图RTO指标

恢复点目标（RPO）

恢复点目标（RecoveryPointObjective，简称RPO）是指对系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。

这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。

与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是取决于企业业务的性质和业务操作对数据的依赖程度。

因此，RPO目标对相同行业的企业而言会有些接近，而对于不同行业的企业来说仍可能会有较大差距。

1.8.1业务连续性的需求

业务连续性有如下的建设需求

Ø考虑资源整合和架构优化，逐步按照生产、查询、公共服务、交换等多种专业分区管理，形成南北中心一体化基础架构和运维支持专业体系；

Ø防范可能的不同级别的灾难的发生（设备、机房、区域性等）成为目前风险防范的重点；

Ø需要制定成体系的、规范的灾难恢复制度和计划；

Ø需要建设规范的、有清晰责任定义的灾难恢复管理组织；

Ø灾备机制需要针对核心生产进行有计划的演练，以确保灾备中心的真实可用。

1.8.2业务连续性的模式设计

1、灾备工作模式

常见的灾备工作模式主要有两种，即主备模式和双活模式；主备模式是灾备中心处于备份接管状态，不对外提供服务；双活模式是灾备中心承担对外服务功能，通常需要远程集群处理技术支持。

本次项目建设的模式的双活模式。

该模式在系统建设开始时同步考虑灾备的实现，即北方生产中心对客户提供服务的同时，南方生产中心同时为客户提供服务。

系统具有如下特点：

▪高可用性最佳实践

▪所有数据中心均为生产中心

▪无需计划停机维护窗口

▪完全杜绝数据中心灾难、网络故障对生产的停顿影响，无需通常意义上的灾难切换过程

▪所有数据中心完全配置一致

▪全局动态负载均衡

▪绝大部分非计划性停机故障可由双中心架构自行屏蔽对应用影响

▪与网银类似的B/S类型应用架构，三层模型

在计划内维护的场景下：

▪“滚动式计划停机”

▪对数据中心的重大计划内维护可以在正常工作时间完成-由最好的技术资源支持

▪广播通知计划停机信息

▪将计划维护的数据中心从生产处理候选列表摘除

▪停止应用、数据库等运行

▪实施所需的任何维护操作

▪应用重新启动

▪测试并确认维护结果

▪广播通知计划内维护结束信息

▪交易请求重新导向维护后的数据中心

2、运行管理模式

▪多中心并行架构对统一监控的要求

-统一监控平台或者ECC

-监控平台本身需要双中心冗余或者也为多中心并行架构

-7*24在线轮值

▪多中心并行架构对运维流程的要求

-统一日常运行维护，对一个中心的维护必须考虑到对另外一个中心的影响

-统一变更管理、问题管理、配置管理、版本管理和软件分发

-需要与一体化运维保持一个整体运行，与一体化运维有双向接口

▪多中心并行架构对组织架构的要求

-双中心间的关系为既独立又统一的关系

-基础设施管理、硬件维护等独立性较强的工作，可以设置为垂直管理

-涉及到多中心并行中心运作的其他运维工作，需要统一的组织架构以方便沟通提高效率

-需要便捷有效的沟通平台支持协调工作，IM是一个成熟可行的方式，沟通平台本身也需要双中心冗余