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

以用户和业务为核心 构建应急支撑保障体系 中国移动江苏公司 2010年 3月 目录 1 2 3 保障体系建设背景 管理、流程、系统全面提升 应急系统介绍 应用场景 和 效果 下一步打算 4 5 背景 全业务运营 业务功能繁杂 业务支撑系统功能繁杂 (功能点 5000多个 )，软件数量众多 (数据库 45套，应用系统 23套 )。 接触渠道多达 12个，充值系统多达 6个。新兴渠道 (如 :电子渠道、银联充值 )功能不断丰富、业务量不断增加。 受理渠道众多 用户规模庞大 升级频繁 全业务运营环境下，业务、服务生命周期短，系统频繁升级 (2009年累计升级 97次 )。 用户规模庞大 (4700多万 )，业务查询、办理量大 (近 4亿条 /月 )。 全业务运营背景下的业务支撑系统功能繁杂、受理渠道众多、用户规模庞大、系统升级频繁，硬件、软件故障难免。 系统的稳定运行，是支撑业务发展、提升客户满意度的重要保障 。 背景 打造应急支撑保障体系 流程 管理 系统 人员组织 省市协同 制度完善 开发管控 应急演练 日常维护 功能扩充 快速切换 数据同步 为满足全业务运营环境下的业务支撑系统运营的需要，江苏公司 2008年开始建设应急二期项目， 以用户为出发点，以业务为切入点 ，从 管理、流程、系统 三个层面全面提升 应急支撑保障体系定位 充分利用 生产系统、应急系统和容灾数据 有效融合、贯通、相互补位，打造应急支撑保障体系，实现 7 x 24小时 业务不中断、服务不中断 的目标。 业务不中断 服务不中断 生产、应急、容灾数据 (应急 生产 应急支撑保障 应急支撑 保障体系 2004年江苏公司启动应急系统建设以来，经过不断完善，目前应急系统已支持营业前台、10086、电子渠道等所有渠道的应急业务受理和所有充值系统的应急充值，能够支撑生产系统 86%的业务量。 2004年 2008年 2009年 营业前台 10086 电子渠道 网营、掌营、短营 充值 所有充值系统 切换 无缝切换 充值 银联充值、空中充值 切换 界面切换 营业前台 开户、补换卡 10086 余额、套餐查询 充值 省内、全国充值卡 发展历程 发展历程应急二期项目 为继续完善应急系统功能，江苏公司信息技术中心于 2009年 初召集 会议，与 省公司市场经营部、集团客户部、 品质管理部、客户服务中心 ，以及 苏州、无锡 、 淮安、宿迁分公司 的 业务管理人员和 一线三大员 共同讨论应急系统功能需求 ， 从业务发展和客户服务两个角度对应急系统需要实现的功能进行了分析 。 从业务发展的角度分析 从客户服务的角度分析 经过与营业员、话务员、客户经理进行讨论，结合客户服务中心对生产系统故障期间投诉的分析情况，梳理出 因用户需求急迫，容易引起升级投诉的业务 。 如：用户丢失手机后需要报停，出 国需要开通国际长途、国际漫游。 对所有渠道的业务量进行了分类统计，发现业务量 排名在前 20%的业务种类，业务量占比超过 80%。按业务量从高到低进行业务梳理，明确了支撑业务发展需要实现的应急功能点。 如：充值、营销方案办理、数据业务办理、附加功能变更等。 应急二期项目 在需求调研的基础上，结合应急系统在管理、流程方面的需求 ， 明确了应急系统的实现原则，根据实现原则整理出系统需要实现的功能 。 实现原则 功能实现 以业务为切入点， 实现 业务受理量大的功能 以用户为切入点 ，解决用户急需，容易引起用户升级投诉的问题 缩短应急与生产数据差异，保证应急预约办理的业务有较高的成功率 应急预约办理的业务能够快速同步回生产系统 应急切换可通过界面操作完成，切换指令发出后系统可以自动完成切换 应急提示信息可以快速推送给内外部客户 公告 告知应急 切换原因 ， 预计恢复时间 ，对用户的 解释口径 功能点 营业前台 : 40个 10086人工 : 29个 网上营业厅 : 30个 掌上营业厅 : 26个 短信营业厅 : 16个 充值系统： 6套系统 应急 业务查询 与统计 按营业员工号、时间段、用户号码等条件查询和统计 应急 业务办理情况 应急管理系统 实现切换管理界面化、流程化、自动化 目录 1 2 3 保障体系建设背景 管理、流程、系统全面提升 应急系统介绍 应用场景 和 效果 下一步打算 4 5 管理 建立了省市一体化的应急保障 虚拟团队 ，明确职责，避免信息沟通不畅。 管理层 业务部门 应急管理人员组织 运维人员 10086 地市公司 部门 姓名 手机 备注 省公司 吴总 公司领导 耿时敏 1391390* 信息技术中心部门领导 马晓明 1390518 * 信息技术中心部门领导 王宏图 1390518 * 信息技术中心部门领导 施建华 1390518 * 信息技术中心联系人 王鑫信息技术中心联系人 常文峰省市场部联系人 左晴省市场部联系人 程玲省 10086联系人 施赛男省 10086联系人 南京分公司 李明远第一联系人 马福祥连云港分公司 李刚第一联系人 胡昌义。 管理 当前系统信息（生产、应急、容灾） 10086 营业前台 银联充值 短信营业厅 充值卡系统 告知系统当前工作于（生产、应急）系统，提醒不能办理的业务种类，提醒能办理的业务种类成功与否以最终的短信提醒为准 告知系统当前工作于（生产、应急）系统，影响业务种类，影响范围，恢复时间，省公司联系人，联系电话等 切换时，个性化通知到内部客户 切换时，固化提醒信息到外部客户 生产、应急系统之间切换时，第一时间将当前系统信息推送到各个渠道，第一时间发送公告通知到三大员 (营业员、话务员、客户经理 )，第一时间反映到用户的短信提醒、免填单、界面。通过快捷的信息推送手段强化省市协同能力。 通过应急切换管理系统建设，实现了应急切换过程的界面化、流程化，实现了人员组织的最优化： 解决了生产与应急间的切换需要多个专业人员配合，登录主机、数据库手工切换的问题， 应急流程执行只需 1人即可完成 ； 当生产系统出现故障时， 值班人员通过简单的操作就可以切换至应急系统恢复业务受理 。 多人配合 分拣 专业人员 值班人员 一人操作 管理 管理 全方位的制度完善 应急系统 例行维护制度 应急系统 例行演练制度 应急系统 开发管理规范 应急保障体系人员组织 开 发 管 理 维 护 管 理 应急保障管理 应急保障 管理流程 在开发管理、维护管理、应急保障管理三个层面完善应急体系管理制度，确保应急系统同步开发、运行稳定、保障体系完善。 流程 为确保生产系统新增功能能够在应急系统得到同步开发，确保后期应急系统正常使用，江苏公司通过新增开发管理控制点进行保障。 测试方案、测试报告中增加应急测试模块 测试阶段 在设计文档模板中增加应急设计模块 提供应急功能点列表，用于分析是否需要修改应急 需求阶段 设计阶段 设计、维护文档同步更新 交付阶段 流程 运维结合 ：我们把 行维护、紧急故障处理（每月 10次左右），当作是验证应急系统的理想场景； 定期组织 ：每季度组织一次全系统应急切换演练，安排在白天营业时间，系统处于应急状态的时长不少于 30分钟。 江苏移动 2009年 演练计划 演练记录 问题及解决情况 计划演练时间 切换地市 实际演练时间 应急 时长 存在问题 是否解决 2009通、扬州、 泰州、盐城 20092:31 32 空中充值能为 异地用户充值 是 2009京、连云港、徐 州 20093:16 36 营业前台 报停失败 是 2009锡、常州、镇江 20092:08 31 无 2009州、淮安、宿迁 20093:15 39 无 流程 为保障应急系统可用性，我们参照生产系统制定了完善的 巡检表、数据库定期维护、性能定期评估等运维规范。并通过持续应急演练发现问题进行优化。 改进 应急 演练 发现 问题 应急维护 应急演练 应急系统 稳定高效 系统 通过应急系统的二期建设，实现了全渠道、全业务应急， 实现了生产系统 与应急系统 间的无缝切换， 在应急系统办理的业务可以快速同步回生产系统， 功能扩充 快速切换 数据同步 渠道覆盖全 ：应急系统覆盖生产系统 100%的渠道 功能覆盖广 ：应急系统可支撑生产系统 86%的业务量 (重要业务全覆盖 ) 无缝切换 ：由原来的人工操作、 30分钟完成切换提高至 10秒以内完成 自动应急 ：实现了关键业务在生产执行失败后自动在应急系统重做 应急基础数据 ：应急与生产系统间数据差异由 1天缩小至 5分钟 同步回生产 ： 100万笔的应急数据同步回生产的时间由初期的半小时缩短到 5分钟 目录 1 2 3 保障体系建设背景 管理、流程、系统全面提升 应急系统介绍 应用场景 和 效果 下一步打算 4 5 功能特点 营业前台 10086 网上营业厅 短信营业厅 掌上营业厅 全国充值卡 空中充值 96669银联充值 省内充值卡 100%渠道覆盖 86%业务覆盖 应急覆盖 100%的渠道接入， 86%的业务办理、查询。故障发生时，客户不仅能够进行简单的充值、停复机，还可以进行复杂的套餐、营销案业务办理。 充值、缴费 营销案 增值业务 开户 积分、 套餐变更 亲情号码 补换卡 一级 助终端 后台管理 国际业务 语音业务 硬件架构 无锡中心 南京中心 应急系统的 一接口、中间件与生产系统共用主机，减少了设备投入，降低了硬件投资成本。 接入层 中间层 数据库 一接口 统一接口 产库 应急库 容灾库 生产 / 应急 生产 / 应急 生产 / 应急 生产 / 应急 生产 / 应急 生产 / 应急 软件架构 数据库 中间层 一级 务开通 电子渠道 充值系统 营业前台 客服 10086 接入层 灾 客户在应急系统办理业务时，会先到容灾 (进行业务校验，之后再到应急库判断用户办理的业务与应急库中最新定购关系是否冲突。业务办理成功后，流水记录在应急库。 连接容灾库校验的中间层代码完全复用生产代码 连接应急库的中间层代码需要根据应急业务流程定制开发。 应急 础数据同步 生产库到容灾库 (用日全量同步方式；生产库到应急库采用物化视图准实时刷新（ 1 应急业务办理数据同步回生产系统采用文件方式，批量导入，缩短导入时间，减少回切后对生产的影响。 应急系统 容灾系统 生产系统 物化视图 文件导入 数据库底层同步 基础数据同步 容灾系统 (产系统 应急系统 物化视图 数据库 数据完整度 数据时差 容灾 完整镜像 (生产 - 1天 应急 部分镜像 生产 - 15分钟 业务 数据 应急 容灾 业务 规则 容灾 应急库只同步生产库中用户的产品、套餐、营销案等定购信息，因此应急库的体量很小 (利用容灾 (实现业务规则和历史数据的查询 利用应急库实现用户最新数据的查询，保存业务办理数据 应急系统与生产系统共用部分采用同一套业务逻辑和配置信息，差异部分通过个性化业务逻辑和配置信息区分生产、应急的差异，降低应急系统开发工作量。 业务逻辑 营销方案 增值业务 套餐变更 国际业务 生产系统 应急系统 容灾系统 业务逻辑共享 配置信息共享 套餐配置表 营销活动配置表 业务功能配置表 业务逻辑共享 切换实现机制 使用应急管理系统可以分地市、分渠道切换 (如： 可以单独将南京的营业前台切换至应急 )； 各渠道接入层有独立的切换管理进程，切换指令发出后，管理进程可以在 10秒以内更新内存中的状态标记并完成切换。由于每笔业务都会判断内存中的状态标记后再选择生产或应急受理业务，切换操作不会造成业务办理失败。 生产 应急 应急标记 容灾 5秒 刷新 1次 读取应急标记 开始业务办理 生产 中间层逻辑 生产 中间层逻辑 生产 接入层逻辑 应急 接入层逻辑 应急 中间层逻辑 数据 同步 进程 应急界面 应急系统 切换中 生产系统 建设了应急管理系统，生产、应急系统间的切换过程全部通过可视化界面管理，切换前有切换检查界面，切换中有进度展示界面，切换后有成功与否展示界面。 应急界面 使用应急管理系统可以实现分层 (省、市 )、分级 (前台、电子渠道、后台 )、分业务 (充值、业务办理、查询 )的精细化的切换管理，达到故障应用接管最小化，系统连续最大化的目标。 应急系统 切换中 生产系统 区域 接入渠道 业务功能 渠道 业务功能 I 库 扬州 盐城 泰州 南通 前台 入网 增值业务 充值 国际业务 查询 空中充值 充值 网上营业厅 充值 业务办理 查询 短信营业厅 充值 业务办理 查询 后台管理 批量充值 业务批量办理 目录 1 2 3 保障体系建设背景 管理、流程、系统全面提升 应急系统介绍 应用场景 和 效果 下一步打算 4 5 应用场景概述 接入层 中间件 数据库 上线 / 升级 调优 / 扩容 故障 / 维护 层次 场景 适用 适用 主机 适用 适用 存储 适用 适用 适用 适用 适用 适用 适用 适用 适用 适用 适用 应急系统可用于上线、系统调整、故障处理等各种场景，由于接入层在接受到业务请求后首先判断是否选择应急通道，生产应用、中间件、数据库、主机、存储不可用时都可以切换至应急系统。 应用场景 上线变更 上线 变更 避免上线期间业务中断对用户的影响，切换至应急系统受理业务。 技术人员 营业员 营业应急 应急数据 营业 /应急 营业生产 容灾数据 营业 /应急 网上营业厅 客户 营业 /应急 中间件 接入层 生产数据 应用场景 数据库扩容 2009年上半年 储进行了更换，并将数据库升级至 0G。扩容期间生产系统不可用，切换至应急系统受理业务。 系统 扩容 容灾数据库 急数据库 中间件服务器 生产数据库 实时同步关键资料 前台营业 (3)(1)启动应急，与 生产服务器断开 (2)连接到应急系统 (4)应急回切后，数据同步回生产系统 应用场景 存储故障 故障 处理 2009年 6月 27日晚 21点左右， 2、 4库生产阵列扩容时发生 故障，数据出现逻辑错误，容灾阵列数据