文档库 最新最全的文档下载
当前位置:文档库 › 南京市城市智能门户运维服务托管招标要求0116

南京市城市智能门户运维服务托管招标要求0116

第四章招标清单、招标范围及技术要求

1项目背景

南京市城市智能门户是《南京市智慧城市“十二五”发展规划》的重点战略,是《智慧南京顶层设计总体方案》的重要组成部分,也是“智慧南京”建设在经历了以“云计算、无线城市”为代表的智慧城市1.0后,走向智慧城市2.0时代“大数据统筹、互联网+”的标志性项目。以“创新服务、信息惠民”为宗旨,整合政府部门和公共服务资源,构建的政府与公众信息交互的枢纽和云服务平台,打造的面向市民和企业服务的综合信息窗口、政府办事窗口、城市形象窗口和社交媒体窗口。

当前,“我的南京”城市智能门户项目在实现后台资源整合、个性化信息服务查询的基础上,加强信息资源的开发利用,进一步实现智慧生活的全过程掌上操作,依托实名认证身份识别特点,在政务服务、交通医疗、生活服务、咨询监督等方面实现从查询到支付、从线上到线下的端到端服务。

按照《南京市:“互联网+”实施方案(2015-2017年)》的文件精神,根据“智慧南京”推进的实际情况,通过加强政务管理与公众服务一体化体系的建设,从而促进政府的“体制创新、机制创新和职能转变”。为尽快实现“以南京本地智能手机标配APP为目标,发展300万以上实名用户,以广大市民能够足不出户、随时随地的享受优质服务和生活便利的目标,建设成为国内领先、世界一流、汇聚全市公共服务资源的综合信息服务平台。

目前,整个城市智能门户移动终端开发项目已经经过两期的建设。通过平台的搭建和应用服务的持续叠加,已经取得良好的社会效益,在践行“互联网+”益民服务方面更进一步。具体建设成果包括:

1)基于实名认证的服务体系不断完善

城市智能门户已构建了基于实名的认证机制,积累了社保、公积金、实有人口、实名卡拍照认证、线下窗口认证、支付宝实名认证、银联、社保及运营商等认证渠道,并建设完成面向各业务应用功能认证服务支撑体系,完成了统一的接入、比对、反馈等标准化的认证机制,支持并保障新增的第三方系统、平台和模块按规范要求即可实现与实名认证体系的自动集成,以解决各方移动应用之间的统一鉴权、统一登陆、统一入口,为逐步增加的各种应用整合以及信息整合提供

基础,对各平台用户的认证请求行为进行记录、跟踪等监控管理,进一步实现跨部门的实名制互认机制和共享实名认证资源,形成统一的实名认证信息服务运行支撑体系。

2)初步建设形成运维服务支撑

运营服务支撑是南京城市智能门户平台推广、高效运行的重要保证,通过城市智能门户移动终端开发项目的实施,建立了市场策划、开发及客服运维的良好工作互动机制,通过统一运营管理模式和标准,制定规范有序的管理方法和管理流程,实现城市智能门户用户数量的百万的增加,推进城市智能门户的良性发展发面发挥了重要的支撑作用。主要包括围绕应用规划及优化、应用内容采编、第三方应用接入、业务推广、客服支撑等方面开展。城市智能门户客服运维投标人需要与平台建设方紧密配合,协调一致,稳步、快速、有序的推动城市智能门户业务发展,加快问题的处理速度,减少对应用系统的影响,提高运维服务的自动化水平和应急保障能力,并适时给业主方提供应用服务优化和运营推广的良好建议。

3)应用服务功能的持续发展

目前,城市智能门户应用功能开发涵盖了政务、交通、环境、医疗、体育、教育、旅游、文化、公用事业等多个领域的50余项子功能, 均同时实现(android 和IOS)两个系统版本。提供的应用服务功能有:主干道监控、路况大数据、公交出行、预约挂号、社保11项险种接入、公积金查询、文艺演出、同名查询、医检报告、献血、金陵晚报、中国搜索、医保药品、南京资讯、市民学堂、12345、人脸识别、停车场信息地图查询、“我的南京”官方网站、手机版官方网站、消息通知推送、市民卡余额查询及后台帐户查询、120急救车应用、电费查询及帐单提醒、联通网厅应用嵌入、金陵图书馆借阅查询及续借、应用分享功能等等。通过与翼支付、支付宝等第三方支付平台对接,拓宽生活缴费服务范围和支付渠道,为用户提供违章代缴、水费、电费、燃气费在线缴费等功能。系统运行总体保持稳定,用户下载量、实名注册用户数和系统访问量都在稳步增长。

4)加强数据应用

城市智能门户项目通过实际运营和服务将汇聚来的用户数据、行为数据以及采集到的各部门专业数据,进一步整理、分析,充分挖掘数据的价值,实现了对

部门的专业数据进行反哺、并共享给有需要的其他部门使用,另一方面将数据经过深加工、智能化分析后形成对城市智能门户的发展有效的数据支撑体系。

2运维服务原则

运维服务应遵循以下原则:

(1)一致性

运维服务需要符合城市智能门户的服务定位思想,要考虑业务应用和平台之间的关联,保证业务应用和城市智能门户之间的统一和数据的一致。

(2)易用性

本着简单、实用、高效的设计原则,业务应用的设计不应复杂、臃肿,应以人为本,方便各种年龄层面、知识层次的用户使用。

(3)扩展性

为保证城市智能门户未来发展的需要,同时兼顾系统建设的阶段性,业务应用设计应尽量减少模块间的连动设计,便于今后系统扩展与升级;

(4)安全稳定性

在充分考虑业务应用服务功能的同时,应格外重视业务应用的安全和稳定性;业务应用的设计应严格遵循城市智能门户平台现有的数据交互标准规范和实名认证规范体系。

(5)可靠性

业务应用服务的设计应具备良好地可靠性,考虑到未来应用的用户数的增加,业务应用服务应具备良好可靠的访问性能。

3服务内容要求

结合城市智能门户的业务工作及信息化建设情况,完善客服及运维管理体系的建设,加强信息系统正常运行保障,“以流程为导向,以服务为核心”提高服务质量水平、转变服务理念、拓宽服务范围、提供服务效率、提升用户服务满意度。建立持续改进的客服及运维机制,保障城市智能门户的业务运维,同时为业务创新提供必要的数据分析和技术支持

3.1呼叫中心

3.1.1知识库

建立城市智能门户客服知识库系统的建设,包括:系统软件客户化开发、系统集成、技术支持、售后服务及技术培训等,客服人员需根据项目发展情况,建立和完善客服知识库内容,积累客服知识资产,为城市智能门户客户服务质量和效率提升,提供良好高效的服务支撑。

要求针对每个移动应用服务模块提供不少于20条的客服知识,新的服务上线同时完成该服务的知识积累工作,每半个月对知识库里的最新发布信息,进行信息归类。并对每月的客服团队培训内容,定期更新至知识库。

知识库系统的功能包括:

3.1.2响应要求

呼叫中心固定电话响应时间不得超过10秒,应保证7*14小时的响应能力,即每天8:00—22:00,达到100%的响应度。不能给予用户立即回复的事项应告知用户等待的时长(原则上3个工作日内),并通过电话回访告之用户处理结果。用户对回复表示不满意的,一个工作日内客服主管需再次回访并至用户满意。

负责城市智能门户运营管理平台的拍照实名认证审核要求当天完成,当天审核量超过1000条,可放宽至第二天完成。

3.1.3统计报告

有效利用收集的数据,将数据价值化是数据收集的目的。客服中心每天大量的数据信息,有些直接反映用户面临的问题,有些反映用户的需求或体现出我们需要改善的环节。要求收集的数据以报表的形式提交并能有效的反映目前的运营状况。呼叫中心的报表主要分为两部分,一部分是系统报表,即通过各系统直接

生成的报表。另外一部分则是通过系统报表和人工数据的收集相结合按统一格式提交的人工报表。

系统报表如呼入总量,座席呼入数,10秒接通率,咨询类型,报修数,报修类型等信息的直接生成。统计周期,统计步长等均可进行选择。系统报表的生成客观的反映了目前各项工作的运营情况。人工报表包括短信报表、工单和系统数据日报、投诉处理、呼叫业务等周报告并给予分析后的总结建议。

各类报表除规范的表格填写外,数据分析人员需根据报表内容进行信息的分析、总结与归纳。并将数据分析报告提交反馈至各负责人。收集的数据进行有效的分析将有利于挖掘用户的需求,提高我们的服务水平,在数据中发现问题,解决问题,创造利润。通过数据分析,最大化的利用数据信息,提高用户满意度,完善我们的服务。

3.1.4跟踪

对工单派发系统派发的工单应定时进行跟踪并对用户进行回访。对故障、缺陷、投诉类用户100%回访,对咨询、建议类用户30%回访。所有回访均需记录回访人工号、回访时间和成功与否。

故障、缺陷类用户在工单完成后回访,如问题一直未解决,也应在3个工作日内进行跟踪回访,以便了解最新问题。故障、缺陷类如回访正常了则销单;如还未能正常收看,则再通知相关团队查看,直至正常。

咨询、建议、投诉类用户在3个工作日内进行回访,如用户对回复内容不满意,则再通知上级处理人员1个工作日内重新进行回访。

3.1.5培训

要求对客服人员进行定期和不定期的客服知识库、移动互联网知识、移动终端等方面的培训、培训完成后提交培训签到表,包括培训主题、培训时间、培训地点、培训师、培训内容大纲、培训人员、参加人员签到等内容,并进行培训效果的考核。客服人员的考核成绩不能低于95分。

3.1.6质量监督

按照客服质量管理的要求,从用户的角度出发,准确把握用户需求,通过对用户满意度的跟踪分析,寻求影响用户户满意度的因素,并针对这些因素进行改

进,以提高用户满意度。因此,在将收集的客户满意度数据汇总后,更重要的工作是应用统计技术进行分析和评价,然后找出存在问题并制定和实施有效的改善措施。从而不断提高客户满意度。分析评价方法一般可以通过纵向分析和客户满意度数学模型分析进行。纵向分析是将客户满意度调查结果与前期比较,分析提高或下降的原因,以期进一步持续改进。

质检人员除每日进行话务监听外,需对客服人员的审核、工单提交、意见反馈处理等工作内容同样进行监控。并且对此提交如下报表:

1.按天填写“客服中心日监听情况一览表”;

2.按旬提交“话务质量分析报告”;

3.按月提交“服务质量提升措施表”;

4.按月提交“话务质量分析报告”。

3.2服务监控

3.2.1主机、中间件、数据库

(1)能够管理和监测Windows、Linux、IBM AIX、AS/400、HP-UX、SUN Solaris、SCO Unix等不同操作系统的服务器或集群的运行状态和性能数据,包括服务器的基本信息、CPU负载、内存利用率、应用进程、文件系统、磁盘空间和吞吐、事件与错误日志等信息的分析与监视。帮助业主及早发现服务器系统的性能瓶颈与故障隐患。

服务器监测项主要包括:

主机基本信息采集:主机的基本信息,包括:CPU数目、机器型号、系统名称、系统版本、IP地址、内存大小、总线程数目、磁盘名称等。

主机CPU使用率:监测主机系统的CPU使用率。

主机内存使用率:监测主机系统的内存使用量、内存使用率。

主机磁盘使用率:监测主机系统的指定磁盘使用率。

主机磁盘IO监测:监测主机系统的磁盘TPS数、磁盘写操作速率等、每秒完成IO读写次数、每秒读写扇区数、每秒读K字节数、平均I/O队列长度等。

应用进程监测:监测主机系统中指定应用进程的内存使用量、内存使用率、CPU 使用率。

系统服务监测:监测主机系统中指定服务的运行状态。

主机当前登陆用户信息:当前登录用户登陆的时间、终端IP、终端名称。

主机端口速率监测:监测主机系统中指定端口的入速率、出速率、入丢帧速、出丢帧速、单播入帧速、单播出帧速、非单播入帧速、非单播出帧速、入错误帧速、出错误帧速等。

主机重要文件监测:监测主机系统中指定的文件大小。

Job基本信息采集(AS/400):监测Job的名称、CPU使用率、类型、状态、所属用户等。

ICMP连通性监测:监测与主机的连通性。

HACMP集群状态监测:监测集群的可用状态及子节点的状态。

自定义指标监测:系统提供了通用监测器,用户可以通过编写shell或者groovy 脚本自定义监测指标。

(2)根据预定义的监测项目对Oracle数据库,按照属性相关性分为数据库工作状态、数据库表空间的利用情况、数据文件和数据设备的读写命中率、数据碎片的情况、数据库的进程状态、数据库内存利用状态等属性监测组,分组监测数据库系统的性能、事务、连接等性能数据。

Oracle数据库监测

基础监测:表空间使用率、连接会话数。

高级队列监测:ready消息数、错误的消息数、消息平均访问时间、消息总数。归档目的地监测:归档目的地类型、归档目的地状态、归档目的地可用空间、归档目的地可用空间百分比、归档目的地位置。

基本信息采集:使用spfile启动、只读模式、归档路径、例程开始时间、限制模式、归档模式、例程名、并行状态、位长、DB版本、DB名称、主机名、实例状态。

检查点监测:发生检查点数、完成检查点数。

数据文件监测:文件大小、读次数、写次数、读时间、写文件块数、读文件块数、读写文件块数、写时间。

全表扫描配置:RSRATIO值、LTSCANRATIO值。

资源锁定监测:锁定时长。

碎片监测:FSFI值。

PGA配置:PGA内存及各区域大小、实例处理性能等。

进程资源消耗监测:可用PGA百分比、可用PGA、已分配PGA、已使用PGA。命中率监测:共享区字典缓存区命中率、多次解析(重装)的条目比率、高速缓存区命中率、共享区库缓存区命中率、磁盘排序与内存排序比率、回退段等待次数与获取次数比率。

递归调用信息监测:递归调用百分比、时间间隔的递归调用百分比、用户调用数、递归调用数、递归-用户调用比率、递归调用速率。

Redo日志配置:重做条目的平台大小、多种请求成功/失败比率、错误次数等。Rman备份监测:增量备份大小、全备份大小。

回滚段:大小命中率、等待率、等待次数、活动事务数、翻转次数、扩展次数、一致更改率、收缩次数、用户回滚率。

会话监测:会话ID、用户名、CPU时间、排序次数、缓冲区命中率、读次数、写次数、提交次数、占用游标数、扫描次数。

SGA配置:共享库缓存大小、SQL缓存大小、数据字典缓存大小、共享池大小、重做日志缓冲区大小、高速缓冲区大小。

SQL监测:使用内存、执行时间、SQL语句、用户。

转存空间监测:转储空间使用率。

表空间监测:未使用Extent数量读时间、最大Extent数量、已使用率、已使用量、未使用量、未使用百分率、允许最大空间、是否自动扩展、写时间、Segment 管理方式、表空间类型、当前Extent数量、下一个Extent大小。

表状态监测:增长速度、索引大小、数据大小、表空间、用户。

撤销空间监测状态监测:快照太旧错误计数、无空间计数。

作业队列监测:破损作业数量、过期作业数量、失败作业数量。

(3)产品支持对Websphere、WebLogic、MQSeries、Tomcat、Tuxedo、Tibco、Resin、TongWeb、等各类不同中间件,提供包括配置信息、连接池、线程队列、负载监测、通道情况监测等多类监测组,分析与监测中间件的各项运行状态参数。中间件监测项主要包括:

系统信息采集:监测中间件基本信息,包括:操作系统、操作系统版本、当前可用堆栈及大小、当前目录、重启次数、开启线程数。

JVM使用监测:监测JVM的堆栈大小和使用率。

JDBC链接池监测:监测指定JDBC连接池资源连接情况。

JTA事务监测:监测中间件中数据处理事务的活动情况。

线程池监测:监测指定线程类的线程平均数、空闲线程平均数以及线程吞吐量。Servlet监测:监测指定Servlet执行和调用情况。

EJB监测:监测指定EJB激活次数、钝化次数、缓存个数、事务提交次数、事务回滚次数、事务超时次数、访问次数。

WEB应用监测:监测指定Web应用中Session的当前个数、最大值以及累积个数。JMS队列深度监测:监测中间件中JMS消息队列活动情况。

MQ通道情况监测:监测MQ的通道情况,包括:每秒接收字节、每秒发送字节、通道状态、发送间隔、事务数。

MQ队列深度监测:监测MQ服务的消息队列的队列深度。

3.2.2网络、访问

(1)开发方需对网络性能进行实时监测,能监测所有网络设备的当前运行负荷状况,包括:当前CPU利用率、当前内存利用率、入流速、出流速、入包速率、出包速率,通过监控网络设备的负荷情况,将被动管理化为主动预警,随时可发现网络的隐患。

结合网络设备的端口流量、丢包率、错包率、Ping延时和丢包等运行参数超过预设阈值时,并能在拓扑图上根据业主定义阈值以醒目颜色显示。通过系统能够设置性能的采样周期,能够以图形方式显示性能指标,并可根据业主的需要定义监测的指标。

(2)需要有严格的身份认证,实施对用户真实身份鉴别,采取分级用户结构,提供用户权限管理,防止未授权的用户访问。开启审计功能,并记录访问日志。

3.2.3应用服务

城市智能门户应用服务搭建在应用服务器集群上,通过负载均衡分发应用流量和会话。为确保应用最高性能的稳定运行,投标人须提供对F5、nginx及各类分布式服务治理和数据缓存均有良好实施经验的高级工程师,优化项目应用服务框架,指导对集群服务上的应用服务进行监控方法,并记录其服务响应时间、服务流量、服务状态、服务次数、服务告警事项、服务地址等信息,将其添加到报

表系统以便业主及开发团队查看。通过对应用服务的监控纠正服务异常状态,业务故障,并在发生服务事故时提高响应能力,从而降低对业务的影响。

3.2.4用户体验

良好的用户满意度结果是城市智能门户各业务应用验收成功的重要基准。用户体验要求是指用户使用城市智能门户时的全部体验,包含用户对城市智能门户中各种业务应用服务的印象和感觉、是否成功、是否享受、是否还想再使用等。为了让城市智能门户更易用,投标人应能够就用户体验度量和持续改善用户体验提供切实可行的方案。

通过对系统、用户操作日志分析等办法统计分析点击率、弃用率、可达性数据、停留时长、用户满意度等,并按照运营服务支撑要求在运维期内不断提出优化功能及提升用户体验。

3.3接口监控

城市智能门户作为智慧南京的重要组成之一,已经在数据获取、分析并提供服务方面取得良好的成果并将持续开展工作,项目拥有较大比重的自有应用服务接口和来自第三方的服务接口,需对项目的各类接口进行实时监控,提高接口监控的自动化水平,包括每个接口的状态、流量、响应时间,访问次数等,发现故障时第一时间联系相关干系人对接口进行恢复,最小化应用故障时间,对接口调用遇到服务瓶颈的发出预警报告并提供解决方案,业主方审核通过后完成自有接口升级工作,指导跟踪第三方服务接口提供者完成相关工作。

3.3.1自有应用接口

3.3.2第三方接口

相关文档
相关文档 最新文档