江苏移动以用户和业务为核心构建应急支撑保障体系(1).ppt

《江苏移动以用户和业务为核心构建应急支撑保障体系(1).ppt》由会员分享，可在线阅读，更多相关《江苏移动以用户和业务为核心构建应急支撑保障体系(1).ppt（36页珍藏版）》请在三一办公上搜索。

1、以用户和业务为核心构建应急支撑保障体系,中国移动江苏公司2010年3月,目录,1,2,3,保障体系建设背景,管理、流程、系统全面提升,应急系统介绍,应用场景和效果,下一步打算,4,5,背景,全业务运营,业务功能繁杂,业务支撑系统功能繁杂(功能点5000多个)，软件数量众多(数据库45套，应用系统23套)。,接触渠道多达12个，充值系统多达6个。新兴渠道(如:电子渠道、银联充值)功能不断丰富、业务量不断增加。,受理渠道众多,用户规模庞大,升级频繁,全业务运营环境下，业务、服务生命周期短，系统频繁升级(2009年累计升级97次)。,用户规模庞大(4700多万)，业务查询、办理量大(近4亿条/月)。

2、,全业务运营背景下的业务支撑系统功能繁杂、受理渠道众多、用户规模庞大、系统升级频繁，硬件、软件故障难免。系统的稳定运行，是支撑业务发展、提升客户满意度的重要保障。,背景,打造应急支撑保障体系,流程,管理,系统,人员组织 省市协同 制度完善,开发管控 应急演练 日常维护,功能扩充 快速切换 数据同步,为满足全业务运营环境下的业务支撑系统运营的需要，江苏公司2008年开始建设应急二期项目，以用户为出发点，以业务为切入点，从管理、流程、系统三个层面全面提升BOSS系统支撑能力。,应急支撑保障体系定位,充分利用生产系统、应急系统和容灾数据有效融合、贯通、相互补位，打造应急支撑保障体系，实现7 x 24

3、小时业务不中断、服务不中断的目标。,业务不中断,服务不中断,生产、应急、容灾数据(BCV),应急,生产,应急支撑保障,应急支撑保障体系,2004年江苏公司启动应急系统建设以来，经过不断完善，目前应急系统已支持营业前台、10086、电子渠道等所有渠道的应急业务受理和所有充值系统的应急充值，能够支撑生产系统86%的业务量。,2004年,2008年,2009年,营业前台10086电子渠道网营、掌营、短营充值 所有充值系统切换 无缝切换,充值 银联充值、空中充值切换 界面切换,营业前台 开户、补换卡10086 余额、套餐查询充值 省内、全国充值卡,发展历程,发展历程,应急二期项目-需求调研,为继续完善

4、应急系统功能，江苏公司信息技术中心于2009年初召集会议，与省公司市场经营部、集团客户部、品质管理部、客户服务中心，以及苏州、无锡、淮安、宿迁分公司的业务管理人员和一线三大员共同讨论应急系统功能需求，从业务发展和客户服务两个角度对应急系统需要实现的功能进行了分析。,从业务发展的角度分析,从客户服务的角度分析,经过与营业员、话务员、客户经理进行讨论，结合客户服务中心对生产系统故障期间投诉的分析情况，梳理出因用户需求急迫，容易引起升级投诉的业务。如：用户丢失手机后需要报停，出国需要开通国际长途、国际漫游。,对所有渠道的业务量进行了分类统计，发现业务量排名在前20%的业务种类，业务量占比超过80%。

5、按业务量从高到低进行业务梳理，明确了支撑业务发展需要实现的应急功能点。如：充值、营销方案办理、数据业务办理、附加功能变更等。,应急二期项目-建设思路,在需求调研的基础上，结合应急系统在管理、流程方面的需求，明确了应急系统的实现原则，根据实现原则整理出系统需要实现的功能。,实现原则,功能实现,以业务为切入点，实现业务受理量大的功能 以用户为切入点，解决用户急需，容易引起用户升级投诉的问题 缩短应急与生产数据差异，保证应急预约办理的业务有较高的成功率 应急预约办理的业务能够快速同步回生产系统 应急切换可通过界面操作完成，切换指令发出后系统可以自动完成切换 应急提示信息可以快速推送给内外部客户,公告

6、 告知应急切换原因，预计恢复时间，对用户的解释口径 功能点 营业前台:40个 10086人工:29个 网上营业厅:30个 掌上营业厅:26个 短信营业厅:16个 充值系统：6套系统 应急业务查询与统计 按营业员工号、时间段、用户号码等条件查询和统计应急业务办理情况 应急管理系统 实现切换管理界面化、流程化、自动化,目录,1,2,3,保障体系建设背景,管理、流程、系统全面提升,应急系统介绍,应用场景和效果,下一步打算,4,5,管理-省市一体化虚拟团队,建立了省市一体化的应急保障虚拟团队，明确职责，避免信息沟通不畅。,管理-强化省市协同能力,当前系统信息（生产、应急、容灾）,10086,营业前台,

7、银联充值,短信营业厅,充值卡系统,告知系统当前工作于（生产、应急）系统，提醒不能办理的业务种类，提醒能办理的业务种类成功与否以最终的短信提醒为准,告知系统当前工作于（生产、应急）系统，影响业务种类，影响范围，恢复时间，省公司联系人，联系电话等,切换时，个性化通知到内部客户,切换时，固化提醒信息到外部客户,生产、应急系统之间切换时，第一时间将当前系统信息推送到各个渠道，第一时间发送公告通知到三大员(营业员、话务员、客户经理)，第一时间反映到用户的短信提醒、免填单、界面。通过快捷的信息推送手段强化省市协同能力。,通过应急切换管理系统建设，实现了应急切换过程的界面化、流程化，实现了人员组织的最优化：

8、解决了生产与应急间的切换需要多个专业人员配合，登录主机、数据库手工切换的问题，应急流程执行只需1人即可完成；当生产系统出现故障时，值班人员通过简单的操作就可以切换至应急系统恢复业务受理。,多人配合,分拣,专业人员,值班人员,一人操作,管理-人员组织最优化,管理-全方位的制度完善,全方位的制度完善,应急系统例行维护制度,应急系统例行演练制度,应急系统开发管理规范,应急保障体系人员组织,开发管理,维护管理,应急保障管理,应急保障管理流程,在开发管理、维护管理、应急保障管理三个层面完善应急体系管理制度，确保应急系统同步开发、运行稳定、保障体系完善。,流程-全过程开发管控,为确保生产系统新增功能能够在

9、应急系统得到同步开发，确保后期应急系统正常使用，江苏公司通过新增开发管理控制点进行保障。,测试方案、测试报告中增加应急测试模块,测试阶段,在设计文档模板中增加应急设计模块,提供应急功能点列表，用于分析是否需要修改应急,需求阶段,设计阶段,设计、维护文档同步更新,交付阶段,流程-应急演练常态化,运维结合：我们把BOSS每月上线、例行维护、紧急故障处理（每月10次左右），当作是验证应急系统的理想场景；定期组织：每季度组织一次全系统应急切换演练，安排在白天营业时间，系统处于应急状态的时长不少于30分钟。,流程-维护与优化持续进行,为保障应急系统可用性，我们参照生产系统制定了完善的KPI监控指标、日巡

10、检表、数据库定期维护、性能定期评估等运维规范。并通过持续应急演练发现问题进行优化。,应急系统稳定高效,系统-全方位提升支撑能力,通过应急系统的二期建设，实现了全渠道、全业务应急，实现了生产系统与应急系统间的无缝切换，在应急系统办理的业务可以快速同步回生产系统，BOSS系统的应急支撑能力得到了显著提升。,功能扩充,快速切换,数据同步,渠道覆盖全：应急系统覆盖生产系统100%的渠道功能覆盖广：应急系统可支撑生产系统86%的业务量(重要业务全覆盖),无缝切换：由原来的人工操作、30分钟完成切换提高至10秒以内完成自动应急：实现了关键业务在生产执行失败后自动在应急系统重做,应急基础数据：应急与生产系统

11、间数据差异由1天缩小至5分钟同步回生产：100万笔的应急数据同步回生产的时间由初期的半小时缩短到5分钟,目录,1,2,3,保障体系建设背景,管理、流程、系统全面提升,应急系统介绍,应用场景和效果,下一步打算,4,5,功能特点,硬件架构,无锡中心,南京中心,应急系统的Weblogic、统一接口、中间件与生产系统共用主机，减少了设备投入，降低了硬件投资成本。,接入层,中间层,数据库,Weblogic,Weblogic,统一接口,统一接口,Tuxedo,Tuxedo,生产库,应急库,容灾库,生产/应急,生产/应急,生产/应急,生产/应急,生产/应急,生产/应急,软件架构,数据库,中间层,一级BOSS

12、,业务开通,电子渠道,充值系统,营业前台,客服10086,接入层,esdb,wxzwdb,容灾tuxedo,B-BOSS,客户在应急系统办理业务时，会先到容灾(BCV)库进行业务校验，之后再到应急库判断用户办理的业务与应急库中最新定购关系是否冲突。业务办理成功后，流水记录在应急库。连接容灾库校验的中间层代码完全复用生产代码连接应急库的中间层代码需要根据应急业务流程定制开发。,应急tuxedo,基础数据同步,生产库到容灾库(BCV)采用日全量同步方式；生产库到应急库采用物化视图准实时刷新（1-15分钟一次）。应急业务办理数据同步回生产系统采用文件方式，批量导入，缩短导入时间，减少回切后对生产的影

13、响。,应急系统,容灾系统,生产系统,物化视图,文件导入,SRDF日全量同步,数据库底层同步,基础数据同步,容灾系统(BCV),zwdb1,zwdb2,zwdb3,zwdb4,wxzwdb1,wxzwdb2,wxzwdb3,wxzwdb4,esdb,生产系统,SRDF同步,应急系统,物化视图,业务数据,业务规则,应急库只同步生产库中用户的产品、套餐、营销案等定购信息，因此应急库的体量很小(1.2T)利用容灾(BCV)库实现业务规则和历史数据的查询利用应急库实现用户最新数据的查询，保存业务办理数据,业务逻辑共享,切换实现机制,使用应急管理系统可以分地市、分渠道切换(如：可以单独将南京的营业前台切换

14、至应急)；各渠道接入层有独立的切换管理进程，切换指令发出后，管理进程可以在10秒以内更新内存中的状态标记并完成切换。由于每笔业务都会判断内存中的状态标记后再选择生产或应急受理业务，切换操作不会造成业务办理失败。,生产,应急,应急标记,容灾BCV,每5秒刷新1次,读取应急标记,开始业务办理,生产中间层逻辑,生产中间层逻辑,生产接入层逻辑,应急接入层逻辑,应急中间层逻辑,数据同步进程,应急界面,应急系统 切换中 生产系统,应急界面,使用应急管理系统可以实现分层(省、市)、分级(前台、电子渠道、后台)、分业务(充值、业务办理、查询)的精细化的切换管理，达到故障应用接管最小化，系统连续最大化的目标。,

15、应急系统 切换中 生产系统,区域,接入渠道,业务功能,目录,1,2,3,保障体系建设背景,管理、流程、系统全面提升,应急系统介绍,应用场景和效果,下一步打算,4,5,应用场景概述,接入层,中间件,数据库,上线/升级,调优/扩容,故障/维护,层次,场景,适用,适用,主机,适用,适用,存储,适用,适用,适用,适用,适用,适用,适用,适用,适用,适用,适用,应急系统可用于上线、系统调整、故障处理等各种场景，由于接入层在接受到业务请求后首先判断是否选择应急通道，生产应用、中间件、数据库、主机、存储不可用时都可以切换至应急系统。,应用场景 上线变更,上线变更,BOSS应用上线时，为避免上线期间业务中断对

16、用户的影响，切换至应急系统受理业务。,技术人员,营业员,营业应急,应急数据,营业/应急,营业生产,容灾数据,营业/应急,网上营业厅,客户,营业/应急,中间件,接入层,生产数据,应用场景 数据库扩容,2009年上半年BOSS五扩对核心数据库主机、存储进行了更换，并将数据库升级至oracle 10G。扩容期间生产系统不可用，切换至应急系统受理业务。,系统扩容,容灾数据库,zwdb1,zwdb2,zwdb3,zwdb4,wxzw1,wxzw2,wxzw3,wxzw4,应急数据库,中间件服务器,生产数据库,SRDFBCV,准实时同步关键资料,Web服务器,前台营业,(3)zwdb2扩容,(1)启动应急

17、，与生产服务器断开,(2)连接到应急系统,(4)应急回切后，数据同步回生产系统,应用场景 存储故障,故障处理,2009年6月27日晚21点左右，2、4库生产阵列扩容时发生故障，数据出现逻辑错误，容灾阵列数据同时被写坏。2、4库6地市切换至应急系统56小时，应急查询和受理业务1520万笔。30日凌晨4点使用磁带备份恢复了生产数据。应急业务办理数据同步回生产系统只用了15分钟。,生产中心故障阵列数据出现逻辑错,生产,容灾中心阵列数据同步出现逻辑错,容灾,应用效果,提高内部客户满意度应急支撑体系保障了业务支撑系统的健壮性，提高了公司内部业务部门对业务支撑系统的满意度。,提高外部客户满意度通过应急支撑

18、保障体系建设，江苏移动目前能够提供7天24小时不间断的业务办理服务，提高了客户满意度，提升了公司的企业形象。,经济效益通过构建应急支撑保障体系，真正实现业务连续性，2009年累计在应急系统受理业务830万笔。以每次业务收益5元计算，累计为公司运营减少4000万元损失。,2009年全年累计切换应急143次，保障了全业务环境下的业务支撑系统连续性，提升了内外部客户满意度。,客户层面,业务层面,社会效益,经济效益,目录,1,2,3,保障体系建设背景,管理、流程、系统全面提升,应急系统介绍,应用场景和效果,下一步打算,4,5,NGBOSS应急,对现有的应急切换管理系统与容灾切换管理系统进行融合，实现生产、容灾、应急系统间切换管理的三位一体化。,一体化切换管理,容灾切换管理系统,一体化切换管理系统,应急切换管理系统,配合NGBOSS建设，应急体系同步跟进，对CRM、BOSS应急解耦，CRM切换至应急时，BOSS可在生产状态，BOSS切换至应急时候，CRM可在生产状态，实现架构最优化，故障影响最小化。,NG-CRM、NG-BOSS应急解耦,谢谢！,