中国移动拓展思路，勇创新，实现应急保障早、快、小

1 拓展思路，勇创新， 实现应急保障“早、快、小” 2 汇报内容 Contents Contents 总体介绍 管理流程及组织方案 应急保障关键技术介绍 应急保障案例及成效 后续思路 3 应急保障系统的建设理念 应急保障系统的建设，首先要明确系统 “保什么、怎么保、追求什么” 。 我们认为一个完善、高效的应急系统应具备以下特点： 浙江公司应急保障系统具备处理故障时“ 发现 早 、响应 快 、影响 小 ”等能力 及时、快速 分层分级 重点业务 重点保障 总体能力 及时发现问题 快速定位问题 快速处理问题 系统快速恢复 分层 依据系统每层架构特点， 构建不同的应急保障方 案； 实现应急保障体系的多样 化、立体化 分级 不同重要等级的业务系 统，采用不同级别的应急 保障机制 实现资源使用效益的最大化 业务分类 根据不同业务特点及保障需求，制定不同的应急方案 实现前后台业务部署分离，单笔业务与批量业务部署分离 重点保证 重点保障前台业务、客户主动发起业务 实现业务应急保障 主次有序，重点突出，管理高效 4 应急保障系统建设现状 业务统一门户集群模式部署，由负载均衡设备实现主备节点自动切换 核心 CRM系统构建了数据级容灾；其应用分布式部署，并实现前后台、单笔与批量业务的分离部署 针对关键子系统：产品管理平台、综合查询子系统建设了应用级容灾系统 BOSS核心系统：计费系统、开通平台、帐务管理、充值系统均构建了从应用服务到数据层面的应急容灾系统 多中心间的公共数据库采用数据级容灾方案，增强公用类数据的应急保障能力 5 核心业务系统均建设了对等的同城异地应急容灾系统 核心系统组网现状 中 心 2 主应 用 服 务 器H P I S D 分 区数 据 库 服 务 器H P I S D 分 区阵 列H P X P 2 4 0 0 0 * 1B C 服 务 器应 用 服 务 器H P 9 0 0 0 S D * 4阵 列H P X P 2 4 0 0 0 * 1数 据 库 服 务 器应 用 服 务 器H P 9 0 0 0 S D * 2数 据 库 服 务 器H P I S D * 2 分 区阵 列H P X P 2 4 0 0 0 * 1滨江三层B C 服 务 器中 心 3 备学院路六层I PS A NI PS A NI PS A N阵 列H P X P 2 4 0 0 0 * 1中 心 3 主 中 心 1 备三墩机房3 - 2中 心 1 主应 用 服 务 器H P I S D 分 区数 据 库 服 务 器H P I S D 分 区B C 服 务 器应 用 服 务 器H P 9 0 0 0 S D * 2阵 列H P X P 2 4 0 0 0 * 1数 据 库 服 务 器中 心 2 备图 例 ：新 增B C 服 务 器H P I S D * 2 分 区数 据 库 服 务 器H P I S D * 2 分 区B C 服 务 器H P I S D * 2 分 区B C 服 务 器应 用 服 务 器H P 9 0 0 0 S D * 2三墩机房2 - 3应 用 服 务 器H P I S D 分 区数 据 库 服 务 器H P I S D 分 区数 据 库 服 务 器数 据 库 服 务 器H P I S D 分 区应 用 服 务 器H P I S D 分 区阵 列H P X P 2 4 0 0 0 * 16 采用的应急容灾核心技术方案 应急容灾 核心技术 应用服务集群部署技术： 借助智能 DNS，实现应用服务与前端 WEB服务间的多路访问模式（类似 TAF技术 ) 实现应用服务数据库访问的自动重连 存储底层数据复制技术 ：关键业务系统的数据库存储采用底层数据复制技术（ HP CA），保障数据准实时同步到容灾系统 数据库多节点集群技术 ： 数据库采用 ORACLE RAC + TAF集群模式，实现节点的自动切换，增强本地数据访问的高可用性 数据库系统容灾自动监测分析及切换技术 ： 采用突破性的创新理念及技术，实现系统健康度的自动监测，并依据结果实现容灾的自动切换 借助负载均衡器及智能 DNS，实现前端 WEB服务的集群部署，主备节点自动、快速切换 针对关键类业务，提供轻量级的应急系统，实现快速切换 7 汇报内容 Contents Contents 总体介绍 管理流程及组织方案 应急保障关键技术介绍 应急保障案例及成效 后续思路 8 依托完善的应急保障管理体系，确保系统的快速恢复 完善的组织职责设置 全面的业务影响性分析 完善的恢复策略设置 有效的计划测试、培训 和演习 标准的灾难恢复流程定义 浙江公司已构建了较为完善的应急保障管理体系；体系中的每个环节都有相应的执行文档，已经规范化的实施流程 评估各类应用系统和服务流程，决定其对公司的业务重要性 评估灾难或服务中断带来的成本损失 定义应用系统和业务服务流程的恢复优先级 清晰定义各类关键业务系统的 RTO、 RPO指标 明确规定备份的频率、方式 制定容灾点选择标准 按照高性价比的原则选择出最优的恢复策略 灾难恢复流程划分为以下阶段： 通知启动阶段 恢复阶段 重建阶段 关闭阶段 制定测试计划内容 定义测试计划类型 规范测试流程 制定培训计划 定义演习内容 规范演习流程 规划和建立应急保障管理团队 制定其组成结构和其相应的角色、职责、岗位人员 明确其灾难或重大故障是的沟通模式 9 应急保障组织的设置方案 角色 职责 信息技术部服务连续性主管领导 作为信息管理部的代表参加公司层面的业务连续性管理团队 IT服务连续性计划负责人，回顾和评审、批准对它的修改 领导信息技术部的服务连续性管理团队，宣布灾难，激活 IT服务连续性计划，指挥信息技术部经历灾难和服务恢复 与中国移动浙江公司层面的业务连续性管理团队进行沟通，成为业务连续性管理团队的成员 IT服务连续性经理 创建并维护一个合适的业务连续性计划，该计划需要明确在灾难发生时该如何发应 担当 IT服务连续性计划引入之后的单一联系人 在 IT服务恢复过程中协调 IT服务团队的活动与资源，并向服务连续性主管领导报告恢复状况 协助服务连续性主管领导制定决策或者升级 负责与公司业务连续性管理团队协调人进行沟通以得到对方的支持和 IT服务恢复状况的反馈 与客户和合作伙伴进行协调沟通，必要时请他们参与其中 IT服务连续性管理员 对损坏情况进行评估以判断损坏程度并估计恢复时间 将损坏程度和 IT服务恢复状况通知服务连续性主管领导和 IT服务连续性经理。协助连续性经理制定决策。 在整个灾难恢复过程中领导并协调 IT服务团队的活动，并遵循前期制定的灾难恢复计划 组织对灾难恢复计划进行开发，测试和维护 灾难恢复团队 负责恢复 IT服务计算机环境，以及连续性管理员管理下的所有应用软件 对灾难恢复计划进行测试和维护 在灾难恢复计划中定义详细的灾难恢复团队的信息 10 在规范的管理体系中，每个环节都有标准执行文档 通知启动阶段 恢复阶段 重建阶段 关闭阶段 1 2 3 4 灾难恢复流程 11 基于灾难恢复流程，科学有序的实施应急保障 信息技术中心根据集团公司和浙江公司业务连续性计划，充分支持业务的需求和需要来规划应急保障管理流程。设置了专门的应急组、应急角色 ，并制定了科学的灾难恢复流程 12 基于规范化流程，确立了与其他部门间的沟通机制 公司各部门间的应急保障主控流程 各部门职责： 市场部 ：危机应急方案的业务总调度；和信息技术部讨论后决定启用什么样的应急流程； 信息技术部 ：危机的准确诊断 ;危机诊断信息的及时报告； 涉及到技术层面的危机修复 客户服务部 ： 服务应急方案（包括营业厅通告、解释口径制定等）的及时调度 客户服务中心： 危机处理应急流程的执行（例如：为用户提供紧急复机、跟用户做好相关的解释工作等） 网管中心： 协调地市网络部对地市市场部门提供的投诉用户进行及时复机 涉及相关子流程： 危机信息上报流程； 危机诊断和应急处理流程 危机信息知会流程 处理进展信息知会流程 13 应急演练的常态化、规范化，有力保障了容灾切换的成功率 在应急保障管理体系中，制定了完善的应急演练计划，并编写了相应的演习方案，以及演习操作手册。从而大大规范了应急演练操作，使其常态化，保障了灾难发生时容灾切换的高成功率 演练原则 ：为确保 BOSS容灾系统层随时正常可用，需要增强操作人员对系统层容灾切换步骤的熟练程度，保证切换工作顺利，有序，高效的完成 演练范围 ：包括 BOSS系统中已建设容灾的相关系统，根据后期容灾系统建设情况，调整相应的演练范围 演练内容 ：抽查操作时，被抽查人根据指定的系统，可参照操作手册进行操作，要求被抽查人能在具体操作中做到正确、熟练的执行相关步骤 演练时间： 演练时间分为 月演练和周演练 月演练指每月执行一次 所有容灾系统的切换演练 ； 周演练指每周执行一次 指定容灾系统（演练范围中选定两个）的切换演练 演练人员 ： 演练人员范围包括系统优化室主机组所有成员 演练过程记录表 14 规范全面的演练方案，有力保证了应急演练的效果 应急演练执行方案 涉及到的相关文档 15 15 构建应急预案库，完善应急保障处理机制 针对每类故障类型、来源、以及业务场景，构建对应的预案关联信息，规范每种故障、灾难的处理流程、提升应急保障的响应效率，以及保障实施的准确性 目前预案库主要涵盖了安全 ,网络 ,硬件设备 ,应用软件 ,备份 ,机房 ,电源安全等 在定义应急预案时，也同时制定相应的演练措施，并定期实施应急演习 应急预案库包含的 应急方案及预案类别 应急预案 启动条件及执行人 16 汇报内容 Contents Contents 总体介绍 管理流程及组织方案 应急保障关键技术介绍 应急保障案例及成效 后续思路 17 借助 BAM系统，及时预见系统潜在故障 全路径全流程 -全地域全用户立体监控 业务层 ： IT部门管理者将重点关注 逻辑层 ：应用维护和优化人员关注整个应用系统的状态 物理层 ：配置管理员了解物理设备的存放位置和信息 性能数据 ：实时 KPI数据，帮助了解系统状态 配置数据 ：帮助了解配置信息以及变化 告警数据 ：按照设定阈值产生告警信息。帮助运维人员快速判断系统故障 18 借鉴 TAF实现机制，实现从应用层到数据层多通路间的透明切换 透明应用切换技术（ TAF)：是指 “ 应用程序数据库 ” 连接的自动切换和重新连接，而这一切对客户端应用均为透明。我们 创新性的将此理念运用到前端应用服务之间的访问连接上 WEB层到中间件服务器端配置多条访问路径，采用智能 DNS来实现中间件层的 TAF。由智能DNS来检测 Tuxedo的服务是否正常，从而支撑 服务层之间主备访问路径的自动切换 在 ORACLE RAC双节点模式下， 使用 TAF技术实现应用服务到数据库端的多条访问路径 ，并灵活支撑主备路径间的自动切换 通过成功整合 Oracle数据库和 Tuxedo中间件的 TAF技术，构建出了 “ 三层架构环境下的透明应用切换 ” 的高可用系统，大大增强系统应急容灾能力，减少了应用切换时间 19 构建数据库容灾自动监测分析及切换平台，实现电信级的业务连续性 生 产 存 储生 产 1 号 主 机 生 产 2 号 主 机容 灾 存 储容 灾 1 号 主 机 容 灾 2 号 主 机容 灾 自 动 切 换 控 制 服 务 器 端 部 署1 ： 完 成 对 生 产 系 统 和 容灾 系 统 的 运 行 指 标 的 采集 以 及 自 动 分 析 ；2 ： 完 成 对 生 产 系 统 环 境变 化 的 收 集 以 及 对 容 灾系 统 环 境 的 自 动 配 置 ；3 ： 完 成 切 换 时 的 所 有 操作 的 控 制 和 处 理容 灾 自 动 切 换 控 制 服 务 器容 灾 自 动 切 换 生 产 系 统 端 部 署 容 灾 自 动 切 换 容 灾 系 统 端 部 署1 ： 完 成 运 行 监 测 数据 的 收 集 上 发 ；2 ： 完 成 自 动 切 换 的具 体 操 作 命 令 的 执行 ；1 ： 完 成 运 行 监 测 数据 的 收 集 上 发 ；2 ： 完 成 自 动 切 换 的具 体 操 作 命 令 的 执行 ；3 ： 完 成 环 境 参 数 修改 的 执 行针对数据库系统的容灾，构建自动监控分析及切换控制平台，实现对生产系统和容灾系统运行状况的监测，以及故障发生时的指标数据采集，并最终依据容灾切换计算公式，给出切换概率及建议。同时能够自动实施容灾切换操作。 采用上述技术后，浙江公司 BOSS容灾切换时间 平均由 1.5小时缩短到 5分钟 平台监测功能： 对生产系统，主要监测其是否会产生需要进行容灾切换的故障的趋势 对容灾环境，主要监测系统的软硬件配置等，是否和生产环境相同，以保证在切换时，容灾系统完全具备切换条件 采集生产系统和容灾系统的运行指标，并综合分析整个系统需要切换容灾的可能性，容灾系统是否具有切换条件等综合因素，给出最终容灾切换的概率 自动切换功能 通过配置，支持自动或者手工启动来实施容灾切换 该平台向生产系统和容灾系统下发一系列的控制命令，并由生产系统和容灾系统进行自动的切换，所有操作均自动完成，降低对切换过程中工程师个人能力的依赖 20 应急子系统的建设情况 为了进一步提升 BOSS业务服务的连续性运营能力，构建了专业化的应急小系统，提供 充值卡充值、缴费、开户、补卡、 充值、缴费 开机 等前台业务的应急受理。 应急小系统的建设有效 完善了应急保障体系的阶梯化组成机制 ，提供各类应急处理流程，确保系统故障期间客户关键业务的不间断受理 主要建设方案 采用数据库 BCV技术，周期性（ 1天）复制生产数据到 BC数据库中，并以 BC库为应急数据库 根据每类业务的应急处理流程单独实现应用服务，并独立部署 为每类应急业务提供特殊的前台 WEB服务，并部署在 WEB集群主机上 提供应急业务数据修复功能，实现客户应急数据同步到生产库中 技术特点 应急服务与正常服务分离部署，相互影响较小 应急状态下，只需调整智能 DNS域名配置，将正常前台域名指向应急服务地址，即可完成应急切换， 其时间可控制在 1分钟之内 21 借助应急子系统，实现快速、轻量级的业务连续性保障 应急系统提供开户、补卡、充值、停复机和资料查询服务； 应急系统所有界面布局和操作风格完全同目前营业系统的界面风格； 使用应急系统前，准备工作： 给应急系统号码库存发放应急系统启用后需要使用的号码资源； 需要为营业厅准备实物的 SIM卡库存，以便应急情况下开户和补卡使用； 22 汇报内容 Contents Contents 总体介绍 管理流程及组织方案 应急保障关键技术介绍 应急保障案例及成效 后续思路 23 借助规范化管理以及创新技术应用，应急保障系统的总体实施成效 应急切换关键业务系统 应急保障方式 应急切换所需时长（小时） CRM系统的全部业务 容灾系统 切换耗时 =15分钟 帐务系统的全部功能 容灾系统 切换耗时 =30分钟 充值系统的全部功能 容灾系统 切换耗时 =30分钟 计费系统的全部功能 容灾系统 切换耗时 =2小时 统一开通系统的全部功能 容灾系统 切换耗时 =30分钟 客服系统的全部功能 容灾系统 切换耗时 =30分钟 缴费卡充值业务和复机业务、客户信息和定购信息查询业务、业务受理功能查询业务、应急开户业务、补卡业务、现金缴费业务、业务登记。 应急系统 5分钟之内 客服系统的话务接入功能 应急系统 5分钟之内 24 数据库多节点 TAF技术的运用，有力保障系统连续性运营能力 050100计划外停机时间 计划内停机时间优化前优化后节省时间28% 36% 采用 TAF技术，在故障发生时只要不是所有节点同时出现问题，业务就可以继续进行 如果是个别数据库节点出现问题，只有技术人员会通过监控系统发现问题，前台业务人员甚至毫无感觉，往往连报障都没有 根据统计，从改造上线以来，营业系统的计划外停机时间 降低了 28%，计划内停机时间 下降了 36% 在 TAF技术支撑下，进行系统维护时可以逐个重起数据库实例，该实例上的连接会透明切换到别的实例，对前台基本不造成影响 ,大大降低了维护操作的难度和代价 25 案例分析 综合查询子系统的应急保障流程 联 系 移 动 负 责 人 张皞 统 一 协 调 恢 复同 时 通 知 服 务 台发 送 故 障 信 息 通知 单由 张 皞 联 系 综 合 查询 应 急 专 家 确 定 应急 灾 难 恢 复 项 目 组由 专 家 组 确 定应 急 实 施 方 案确 定 产 生 灾 难 问题 根 源应 急 方 案实 施灾 难 恢 复 后 通知 Q A 进 行 回 归 测 试通 知 服 务