智慧景区设计及运营运维的合理化建议.docx
《智慧景区设计及运营运维的合理化建议.docx》由会员分享，可在线阅读，更多相关《智慧景区设计及运营运维的合理化建议.docx（20页珍藏版）》请在冰点文库上搜索。
智慧景区设计及运营运维的合理化建议
智慧景区设计及运营运维的合理化建议
1.旅游服务流程优化建议
1.1.管理业务数据流程设计
管理业务流程主要对景区日常工作中涉及的管理业务的流程进行设计，是智慧景区管理业务建设和运营的重要环节，以便提升景区管理能力和管理效率，具体业务流程设计如下：
图4.6.1.1.-1景区业务数据流向图
本次设计景区管理业务将以景区三维可视化管控平台为中心进行建设，其可使景区管理人员全面了解景区的总体运行情况，其可根据需要自定义可展示的内容，具体信息由各管理相关业务系统提供，获取方式包括三种：
一是通过数据中心获取（如车牌抓拍信息、停车位信息、车辆调度信息、票务信息及其他横向或纵向涉旅单位信息等），二是直接向具体业务系统提取（如视频监控相关的信息量巨大，不便于通过网络存储在数据中心的信息），三是由大数据分析系统分析出来的管理类相关结果，可发现景区可能存在的管理盲区以及以往管理事件存在的共同问题等。
景区三维可视化管控平台向景区管理人员或游客展示景区相关情况的方式主要有三种：
指挥中心大屏显示系统、景区公共广播系统和景区室外LED显示屏。
景区综合监管平台将景区整体运行情况信息、预警信息、报警信息及其他紧急突发信息都在智慧中心大屏显示系统上进行展示；而针对需向游客及工作人员发布的提示、预警、疏导等信息则通过公共广播系统和室外LED显示屏进行发布，工作人员可通过景区综合监管平台选择性发布渠道（也可是微信公众号或官网等）。
1.2.服务业务数据流程设计
服务业务流程主要对景区日常工作中涉及为游客提供服务业务的流程进行设计，是智慧景区服务业务建设和运营的重要关键，以便提升景区服务能力、减轻工作人员工作量及提升游客满意度，具体业务流程设计如下：
图4.6.1.2-1数据业务流程图
本次设计景区服务业务将以三维可视化管控平台为中心进行建设，其可使景区管理人员全面了解景区的总体运行情况，其可根据需要自定义可展示的内容，具体信息由各服务相关业务系统提供，获取方式包括三种：
一是景区通过主动发现游客所需服务（如通过视频监控轮询可发现是否有游客需帮助），二是由游客主动向景区提出服务需求（如呼叫中心、一键报警等），景区针对性的提供相关服务，三是由大数据分析系统分析出来的服务类相关结果，可发现景区可能存在的服务盲区以及以往游客反映较为不足的地方，景区可有方向的提升服务水平。
2.数据共享对接建议
2.1.数据共享
制定共享数据清单
明确共享数据内容，包括共享信息目录清单、更新频率。
提出所需数据清单
明确景区所需各个部门提供哪些数据，例如景区周边交通拥堵数据、应急部门应急数据、文化广播电视和旅游局日常分发数据、林业局有关本景区的数据、水务局有关本景区的历史数据等内容。
数据共享方式
明确数据共享方式，包括接口实时对接、数据库共享、文件共享服务器等方式。
2.2.数据对接
对接系统
与长沙城市超级大脑对接
本项目基于“政务云”建设相应的景区基础数据库、空间地理库及相关主题库用于各种服务应用；同时与长沙城市超级大脑进行数据采集和对接。
未来依托长沙城市超级大脑数据中台，进行数据的治理、清洗、挖掘后，为市级单位提供数据共享服务或根据文旅广电局需求进行数据交换和共享。
与长沙智慧文旅平台对接
本项目产生的所有业务数据可与长沙市智慧文旅平台进行对接。
通过政务云数据积累，在掌握市级部门的数据业务需求后补齐数据，支撑长沙市智慧文旅应用。
与省级智慧文旅平台对接
本项目产生的所有业务数据可与湖南省智慧文旅平台进行对接。
通过政务云数据积累，在掌握省级部门的数据业务需求后补齐数据，支撑湖南省智慧文旅应用。
与“我的长沙”APP对接
本项目建设的微信公众号和小程序可根据“我的长沙”APP入驻规范进行服务挂靠。
通过与工作人员沟通，可以实现微信小程序的入驻，本项目只建设移动端后台服务并按“我的长沙”APP入驻规范进行专区服务入驻。
与长沙市交通TOCC平台对接
与文旅相关的交通等部门进行数据对接，对接数据包括交通航班，铁路，公路，轨道等内容，方便景区能够预测客流，实施部署资源。
对接方式
XX山风景名胜区智慧景区平台与外部相关系统平台之间主要通过数据资源清单的形式进行数据共享，在梳理好数据资源清单后，将需求的数据资源通过数据服务接口进行交互。
接口设计
概述
坚持科学旅游观，为了保持此次项目的可扩展性，利于后期数据的丰富性。
鲜活度，利于后期更多应用系统建设，本次设计了统一数据接口方案，以实现各业务系统实现无缝对接，严防信息孤岛。
根据调研，需要对接的系统主要在两个方面：
①外部系统包括横向涉旅单位相关应用系统；②纵向自有业务系统、涉旅企业业务系统。
1）涉旅单位
a）气象局；
b）测绘地理信息局；
c）交通运输厅运输管理局；
d）旅游应急指挥中心；
2）景区自有业务系统
a）本次项目将建设的各软硬件系统；
b）预留其他应用接口。
3）涉旅企业
a）宾馆酒店；
b）乡村旅游点；
c）预留其他应用接口。
设计原则
针对本次项目所有系统的接口均遵循湖南省制定的标准进行设计，此接口可方便快速的实现与遵从相同标准的系统间对接工作，特别是可实现与省旅发委和市旅游局系统的无缝对接；而其它需从景区获取数据的系统，仅需遵循省旅发委的标准即可快速实现系统对接，获取到所需数据。
在实际对接过程中，将由业主方与需对接系统业主方协调对接事宜，达成对接共识后由各系统承建商共同制定对接方式、流程及工作分工等。
以下将从对接形式、对接流程、接口规范、接口技术及接入管理几个方面进行建议。
对接形式
对接各方应用标准WebService技术实现对接。
作为服务端提供相关接口方法，由其他系统或网站的开发公司或维护公司生成对应客户端，进行对应开发后，实现数据的交换。
对接流程
图4.6.2.2.3.4对接流程图
对接流程说明：
所有欲实现数据交换的外部系统，在交换前必须进行认证，对未通过认证的外部系统，将直接拒绝其连接；
数据从交换类型维度包括：
对外部系统数据的接收、外部系统获取应急事件信息或预警信息数据；
数据从业务属性维度包括：
涉旅部门信息、涉旅企业基础信息、应急或预警事件等公告类信息；
外部系统结合其自身特点，有选择性的选取数据进行交换。
接口规范
规范各接口的开发，提高业务和数据交互的合理、安全、稳定和高效；提供规划合理的接口，便于根据产业发展变化的系统扩展和二次开发；考虑到安全性的要求，提供内外网系统交互的方式。
一.2.2.1.1.1.基本要求
为了保证系统的完整性和健壮性，系统接口满足下列基本要求：
1）接口应实现对外部系统的接入提供系统级的支持，在系统的高并发和大容量的基础上提供安全可靠的接入；
2）提供完善的信息安全机制，以实现对信息的全面保护，保证系统的正常运行，应防止大量访问，以及大量占用资源的情况发生，保证系统的健壮性；
3）提供有效的系统的可监控机制，使得接口的运行情况可监控，便于及时发现错误及排除故障；
4）保证在充分利用系统资源的前提下，实现系统平滑的移植和扩展，同时在系统并发增加时提供系统资源的动态扩展，以保证系统的稳定性；
5）在进行扩容、新业务扩展时，应能提供快速、方便和准确的实现方式。
一.2.2.1.1.2.接口通讯方式
接口基本采用了同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等通讯方式：
1）同步请求/应答方式：
客户端向服务器端发送服务请求，客户端阻塞等待服务器端返回处理结果；
2）异步请求/应答方式：
客户端向服务器端发送服务请求，与同步方式不同的是，在此方式下，服务器端处理请求时，客户端继续运行；当服务器端处理结束时返回处理结果；
3）会话方式：
客户端与服务器端建立连接后，可以多次发送或接收数据，同时存储信息的上下文关系；
4）广播通知方式：
由服务器端主动向客户端以单个或批量方式发出未经客户端请求的广播或通知消息，客户端可在适当的时候检查是否收到消息并定义收到消息后所采取的动作；
5）事件订阅方式：
客户端可事先向服务器端订阅自定义的事件，当这些事件发生时，服务器端通知客户端事件发生，客户端可采取相应处理。
事件订阅方式使客户端拥有了个性化的事件触发功能，极大方便了客户端及时响应所订阅的事件；
6）文件传输：
客户端和服务器端通过文件的方式来传输消息，并采取相应处理；
7）可靠消息传输：
在接口通讯中，基于消息的传输处理方式，除了可采用以上几种通讯方式外，还可采用可靠消息传输方式，即通过存储队列方式，客户端和服务器端来传输消息，采取相应处理。
一.2.2.1.1.3.接口安全设计
为了保证系统的安全运行，各种接口方式都应该保证其接入的安全性。
接口的安全是系统安全的一个重要组成部分。
保证接口的自身安全，通过接口实现技术上的安全控制，做到对安全事件的“可知、可控、可预测”，是实现系统安全的一个重要基础。
根据接口连接特点与业务特色，制定专门的安全技术实施策略，保证接口的数据传输和数据处理的安全性。
系统应在接入点的网络边界实施接口安全控制。
接口的安全控制在逻辑上包括：
安全评估、访问控制、入侵检测、口令认证、安全审计、防恶意代码、加密等内容。
一.2.2.1.1.4.传输控制设计
传输控制利用高速数据通道技术实现把前端的大数据量并发请求分发到后端，从而保证应用系统在大量客户端同时请求服务时，能够保持快速、稳定的工作状态。
系统采用传输控制手段降低接口网络负担，提高接口吞吐能力，保证系统的整体处理能力。
具体手段包括负载均衡、伸缩性与动态配置管理、网络调度等功能：
1）负载均衡：
为了确保接口服务吞吐量最大，接口应自动地在系统中完成动态负载均衡调度；
2）伸缩性与动态配置管理：
由系统自动伸缩管理方式或动态配置管理方式实现队列管理、存取资源管理，以及接口应用的恢复处理等；
3）网络调度：
在双方接口之间设置多个网络通道，实现接口的多数据通道和容错性，保证当有一网络通道通讯失败时，进行自动的切换，实现接口连接的自动恢复。
一.2.2.1.1.5.接口类型分类
根据业务需要，相关接口分为业务类接口、数据类接口、安全类接口等三个类别。
1）业务类接口：
提供业务接入能力，整合不同子系统间的业务流。
2）数据类接口：
提供数据交换以及数据整合能力。
3）安全类接口：
提供管理员的安全访问和隔离的能力。
系统统一采用可信WebService技术实现应用交互。
所有基于可信WebService开发的服务型应用接口应采用WSDL标准写出描述文件。
以WSDL标准定义的服务接口描述可以在可信服务注册中心注册或直接提供给服务调用方。
应用服务调用方通过查询可信服务注册中心或从服务提供方取得所需Web服务的调用规范，通过可信SOAP客户端调用服务方提供的可信WebService服务接口，完成应用的交互。
通过以服务和API方式提供可信消息服务的调用接口，为应用开发中集成各种用户交流手段提供安全、方便的解决方案。
一.2.2.1.1.6.接口技术
包括WebService、消息中间件、文件、过程调用和共享数据表等多种方式。
需要对接的系统众多，将根据不同的系统，采用不同的接口技术实现数据对接。
WebService
技术描述
WebService是一种自包含、模块化的应用，是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使WebService能与其它兼容的组件进行互操作。
可以在网络上（一般是Internet）上被描述、发布、定位和调用。
WebService体系主要由以下三部分组成：
传输协议、服务描述和服务发现，由一系列标准组成，主要有：
XML（可扩展的标记语言）、SOAP（简单对象访问协议）等。
WebService通过使用标准协议（如HTTP）交换XML消息来与客户端和各种资源进行通信。
在WebServer上部署WebService后，由WebServer负责将传入的XML消息路由到WebService。
WebService将导出WSDL文件，以描述其接口，其它开发人员可以使用此文件来编写访问此WebService的组件。
技术特点
WebService使用标准技术，应用程序资源在各网络上均可用。
因为WebService基于HTTP、XML和SOAP等标准协议，所以即使以不同的语言编写并且在不同的操作系统上运行，它们也可以进行通信。
因此，WebService适用于网络上不同系统的分布式应用。
优点：
适用于网络上不同系统的分布式应用、标准性好、扩展性好、耦合度低；内容由标准文本组成，任何平台和程序语言都可以使用；格式的转换基本不受限制，可以满足不同应用系统的需求。
缺点：
当XML内容较大时，解释程序的执行效率较低，一般不适合用于实现大批量数据交互的接口。
消息中间件
技术描述
基于消息中间件的接口机制主要通过消息传递来完成系统之间的协作和通信。
通过消息中间件把应用扩展到不同的操作系统和不同的网络环境。
通过使用可靠的消息队列，提供支持消息传递所需的目录、安全和管理服务。
当一个事件发生时，消息中间件通知服务方应该进行何种操作。
其核心安装在需要进行消息传递的系统上，在它们之间建立逻辑通道，由消息中间件实现消息发送。
消息中间件可以支持同步方式和异步方式，实际上是一种点到点的机制，因而可以很好的适用于面向对象的编程方式。
消息中间件可以保证消息包传输过程的正确、可靠和及时。
消息中间件提供以下基本功能：
消息队列、触发器、信息传递、数据格式翻译、安全性控制、数据广播、错误恢复、资源定位、消息及请求的优先级设定、扩展的调试功能等。
技术特点
消息中间件能够在任何时刻将消息进行传送或者存储转发，不会占用大量的网络带宽，可以跟踪事务，并且通过将事务存储到磁盘上实现网络故障时系统的恢复。
优点：
为不同的应用系统提供了跨多平台的消息传输；除支持同步传输模式外，还支持异步传输，有助于在应用间可靠地进行消息传输。
缺点：
与其它中间件技术一样，存在高流量的性能瓶颈问题。
过程调用和共享数据表
技术描述
过程调用和共享数据表技术实现了服务端向客户端开放可直接调用的过程和可直接进行读写操作的共享数据表，客户端直接调用服务端过程和对共享数据表进行读写操作。
接口支持各种数据库连接方式，如Login、DBLink等。
接口的通讯过程包括两种：
1）客户端直接调用服务端开放的过程或对服务端开放的共享数据表进行增、删、改和查询操作，完成业务处理；
2）客户端向开放的共享数据表中写入服务请求数据，服务端定时扫描共享数据表并作出响应，根据服务请求数据中的接口服务类型代码，进行不同的业务逻辑处理，然后向共享数据表中写入处理结果数据；客户端定时扫描共享数据表，根据处理结果数据并作出响应，进行业务后续处理。
技术特点
此类接口不需要其它软件支持，只要接口双方做好相关约定即可；但接口没有统一标准，而且需要开放数据库权限，安全性差。
优点：
实现简单、传输批量数据效率较高。
缺点：
标准性差、适用场合有限、安全性差。
文件
技术描述
文件接口定义了服务端与客户端文件存放路径、文件名命名规则和文件格式，并开放相应的读/写操作权限。
接口的通讯过程包括三种：
1）同一主机内可以共享一个路径；
2）服务器端向客户端开放路径，客户端定时查看此路径下是否有新的文件，可以采用FTP等方式取走服务端开放的路径下的文件；
3）客户端向服务器端开放路径，由服务端将文件写入，客户端定时查看此路径下是否有新的文件。
网络传输方式应支持对通信机的IP地址、帐户、口令、存取目录的验证。
接口应支持以下主流网络协议：
FTP、FTAM等。
数据传输应支持：
1）实时、高效和安全可靠地传送批量数据；
2）断点续传功能；
3）数据压缩传输；
4）传输过程中的差错控制。
技术特点
优点：
文件接口不需要其它软件支持，只要接口双方约定好路径、格式、处理方式即可，实现简单、传输批量数据效率较高。
缺点：
格式没有统一标准，标准性差；需要开放文件系统权限，安全性差。
一.2.2.1.1.7.系统接入管理
实现对所有数据交换的外部系统的管理，确保对接系统间各自的数据安全和数据一致性。
功能概述
实现所有外部系统的管理，通过对这些系统的停、启用，实现不同系统间的数据隔离，保障不同系统间数据的独立性、安全性和一致性。
功能设计
新增外部系统：
包括外部系统名称、数据交换服务链接地址及端口、接入用户名、接入密码（DES加密）、联系人、联系电话。
完成新增后，默认状态为停用。
停、启用：
管理人员在日常运维过程中检查数据对接日志，对存在异常数据的外部系统进行停用，避免无效数据的接入给平台的稳定运行带来影响，同时也可以降低对服务器性能的消耗。
在外部系统运维人员完成系统自检和调整后，重新启用该系统，实现数据的安全管理。
数据对接日志：
外部系统的所有数据，进行数据格式校验，保证数据安全、有效。
通过对外部系统的数据格式校验，记录外部系统名称、错误分类（外部系统通信失败、数据格式错误）、错误描述。
链接维护：
在外部系统的数据交换服务发生变更时（包括服务器地址、端口变更和服务升级等），运维人员可以进行及时维护，维护系统数据交换服务链接时，必须停用该服务。
系统监控：
负责对外部系统的监控，通过TELNET方式检查外部系统连接状态，对异常外部系统进行告警，通过短信模块发送短信到运维人员，实现问题的快速定位、诊断和解决。
通用用户验证接口
用于外部系统接入系统时的验证。
提供统一的用户验证方式，对不在接入管理模块中的外部系统，将直接拒绝；仅限通过验证的用户，实现后续的各类数据信息交换。
3.标准体系设计建议
智慧景区标准体系设计主要从数据采集、使用、存储的过程来考虑，
3.1.数据采集标准
按照“统一编码、统一规范”原则，建立景区信息化数据采集编目及编码相关标准，规范景区文化和旅游资源数据建设；建立管理部门、涉旅企业、游客信息的数据采集编目及编码规范。
包括旅游信息资源分类标准、信息资源标识符编码、规范息资源核心元数据编码规范、目录编制指南。
3.2.数据对接共享标准
（1）智慧旅游信息化数据对接标准
按照“资源利用最大化、有效共享”原则，建立景区数据对接相关标准，景区现有或正在建设的信息化系统，按统一的标准实现与智慧景区大平台的数据接入，无须重新投入建设，达到节省资金、快速见效的目的。
包括技术平台的数据交换服务、目录服务接口及其调用方法，安全服务与各应用系统之间单点登录和信息服务的接口定义及其调用方法。
（2）数据共享交换标准
按照“资源融合、协同共享”原则，建立纵向的景区管理部门、涉旅企业及横向相关政府管理部门的数据交换共享标准，充实完善景区旅游信息数据，实现数据交换共享及共享发展。
包括旅游信息资源接口标准、信息资源接入内容、信息资源交换内容、信息资源交换规范以及交换数据标准。
3.3.数据库系统运维标准
根据景区的数据库及系统特性，以及平台的业务特性及运行要求，编制平台数据库及系统运行维护标准，并制定数据库及系统运行维护服务规范，确保平台的正常运行。
3.4.安全建设标准
遵照《保护等级划分准则》、《信息安全技术云计算服务安全能力要求》、《信息安全技术云计算服务安全指南》、GB/T22239-2019《网络安全技术·网络安全等级保护基本要求》建立景区信息化建设信息安全标准。
建议按照等保三级的标准，建设XX山智慧景区的信息化安全体系。
4.运营运维保障建议
4.1.运营建议
本项目建议采用本地第三方企业运营和自主运营相结合的模式。
第三方运营需要建立第三方运营服务体系的管理制度，界定第三方运营服务机构与景区主管部门及相关部门的职能划分，建立运营服务流程，明确第三方运营服务的服务成果形式和质量考核办法。
基于游客服务系统的建设，专注于游客服务及营销，联动景区内部和周边，通过产业整合、业态丰富、渠道连接、品牌营销等，建立以景区为核心的全域旅游产业生态圈。
首先，为景区提供内容解决方案，搭建基于微信公众号的资讯服务平台，主要提供景区旅游资讯服务及公共信息服务。
其次，为景区提供服务解决方案，帮助景区及游客快速搭建移动端的服务体系，将商品和服务直销给游客；同时，通过达人分销、精准营销、秒杀拼团等多样化的营销工具运营，帮助商品实现营销裂变。
最后，为景区提供宣传推广方案，构建传统媒体和新媒体结合的推广体系，定期进行线上线下活动宣传。
4.2.运维服务
运维组织机构和人员设置
成立运维工作部，负责系统部署与运维工作。
运维工作部以技术部为基础组建，业务系统工作由各业务部门负责。
运维工作部门下设系统组、网络组、应用组、数据库组、日常运维组和安全组等专业运维小组，负责日常运维工作，分工合作做好运维工作。
运维制度建设
制定相应的运维制度，包括应用管理、存储和备份管理、技术服务管理、安全管理、应急处置、文档管理以及人员管理等系列制度，其他机房管理、网络管理、资产管理、主机管理则沿用信息中心相关运维制度。
建立运维服务质量考核机制，促进运维质量提升。
建立制度完善机制，促进各类制度在执行中不断完善。
运维流程建设
依据运行维护管理要求、管理内容、管理环节等制定统一运行维护工作流程，实现运行维护工作的标准化、规范化和自动化，涵盖事件管理、问题管理、变更管理、配置管理等业务，全面覆盖运维工作的各个方面。
通过建立运行维护管理流程，可以使日常的运行维护工作流程化，职责角色更加清晰，从而使解决问题的速度和质量得到有效提高。
同时实现知识积累和知识管理，并可以帮助运行维护部门进行持续的服务改进，提高服务对象的满意度。
运行维护流程包含的环节主要有事件管理、问题管理、变更管理及配置管理。
运维技术服务平台建设
运行维护技术服务平台由运行维护监控平台、运行维护流程管理服务系统和运行维护辅助分析系统等构成。
（1）运行维护监控平台。
监控平台同时为各信息系统提供监控服务，通过短信、邮件等形式在第一时间报送监控。
（2）运行维护流程管理服务系统。
一方面使日常的运行维护工作有序化，职责角色清晰化，能够有效地提高解决问题的速度和质量，使运行维护部门内的相关支持信息更为畅通、透明、完整，实现知识的积累和管理，更好地进行量化管理和设定优化指标，进行持续地服务改进，最终提高整个运行维护工作的效率和质量。
另一方面为用户提供数据采集和系统应用的技术服务。
（3）运行维护辅助分析系统。
以运行维护监控平台和运行维护流程管理系统为基础，通过统计分析，分析运行维护服务能力与服务质量的现状，并进行趋势分析，故障预警，为运行维护管理提供支持。
运维模式
一、业主单位职责
项目信息化管理部门的维护职责主要为：
1、日常的应用和数据类运维，主要是数据录入、编辑、更新、管理、统计分析等数据相关的维护；网站内容信息服务；业务相关的内容信息服务（如生成业务报表）。
2、备品备件的采购，主要包括以下内容
备品备件采购表
序号
运维内容
备注
1
触摸屏设备备品备件的采购
包括备品备件的储存、管理和使用类的维护
2
景观照明控制系统设备备品备件的采购
包含备品备件的储存、管理和使用类的维护
3
服务器、磁盘阵列等主机和存储设备备品备件的采购
包含备品备件的储存、管理和使用类的维护
二、运营方职责
第三方运维机构运营维护的主要内容如下表所示：
运营维护主要内容
序号
运维类型
说明
1
硬件类运维
包括触摸屏、景观照明设备、网络通信设备、主机和存储设备等在使用期内正常运行，所必需的维护、保养、更换部件等人工维护
2
产品化软件类运维
如MySQL数据库的运维、W
升级会员 