- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
新环境下面向业务的信息系统的业务连续性建设IBM 全球技术服务部苏翔 大中华区业务连续服务首席架构师议题1由真实灾难案例对灾备标准的解读2灾备建设目标策略分析3灾备技术架构说明4灾备管理与运维架构说明5灾难恢复计划与灾难演练6IBM灾备能力汇总灾备、IT连续与业务连续业务连续性管理(BCM)业务连续性计划(BCP)紧急响应计划(ERP)危机管理计划 (CMP) 风险管理 SecurityTakeover 业务 单位 恢复 计划(BRP) Insurance 灾难 恢复 计划(DRP) Product 本地高可用 本地应急计划 数据恢复计划 Vital RocordsContaminationBusiness KidnapImpact AnalysisStrikeIT连续性计划(ITCP)传统意义上的灾备由DRP与ERP构成,关注于灾难条件下的IT恢复ITCP关注由故障到灾难不同级别事件下IT的连续性业务连续性着眼于业务连续,关注于支持业务的所有IT与非IT组件的恢复能力情况风险应对模型低高区域性灾难对业务的影响和灾备机制投入异地灾备地震、雪灾导致区域性长时间停电等灾难发生的概率建筑物/机房内灾难同城灾备建筑物内外部火灾、机房内部火灾、长时间停电等机房电源故障、网络故障、机房漏水、存储设备硬件故障等高可用系统冗余设计完善管理制度机房内事件低高服务器故障、机房电源故障、网络故障、空调故障、存储设备硬件故障等软件故障、信息事故等典型灾难环境下RTO/RPO模型分析某客户大楼机房失火事件——媒体报道XX客户xx信息总部机房于xx月27日晚上9点时,疑似配电盘插座老旧引发火灾,火势虽然不到1小时就扑灭,但导致XX证券期货相关电子下单系统、金控网站、部分产险服务与投信网络交易和通路服务等系统停止,XX金控当晚也紧急召回IT部门和厂商进行系统抢救工作,相关服务xx月28日暂停1天,并于xx月29日恢复运作。 台北市消防局第x大队副大队长xxx表示,XX金控内湖信息总部机房在xx月27日晚上8点48分发生机房失火意外事故,消防局在xx月27日晚上9点接报,立即出动了15部消防、救灾和救护车,以及37名消防人员,赶赴位于台北市xx街xx金控机房。 xxx指出,由于xx金控信息总部的机房规模较大,相关的消防设备投资也足够,所以第一时间内,机房内FM 200自动气体灭火系统已经启动释放灭火惰性气体来阻绝氧气,避免火势继续燃烧,因而起火面积得以控制在10平方米范围内。但起火处温度很高,为避免持续闷烧,消防队员还是破坏产险机房玻璃门窗进行洒水降温。整起火灾事故火势在晚上9点46分完全扑灭,没有人员伤亡。 台北市消防局初步鉴定,x楼机房内的配电盘插座过于老旧导致电流超过负载而引发火灾,但确切的起火原因还需要消防电机专家进一步鉴识。 实际案例的启示:机房事故,主要设备与场地完全无法使用灾害起因:因机房部份区域起火,致使信息设备直接毁损或间接故障当时回复能力:部份系统虽然已切换至灾备中心,但 部份关键设备之灾备能力(Capacity) 较低尚有系统采用较低之灾备等级部份系统完全未纳入灾备规划中,严重影响业务运作在主要系统厂商的紧急人力与设备支持下,于一星期逐步回复运作灾害影响:机房与所有被波及的设备,完全无法运作;相关业务完全停摆耗费2-3小时人工操作重新输入前日交易数据当日交易改为人工操作当日某项业务市占率下降50%编列特别预算,紧急采购IT设备状况细部分析1:决策信息不足,指挥协调混乱,且关键设备无100%灾备CMT makes decisionwithin 30 minSystem Recovery /Data/Application/Biz Recoverywithin 60 minRPO ~ 0Recovery (RTO) within 2 hours原恢复计划实际恢复时间CMTmakes decisionaround 4 hoursSystem/Data/Application Recoverywithin 60 minSolving capacity problem within 2 days状况发现: 懂系统的就几个人,他们已经忙于了解现在状况,等一下还要和他们讨论回复程序; 但是现在所有的长官都来问「发生什么事,何时可以复原?」 几年来合作的许多协力厂商都到了,单是协调所有的步骤与临时需求,就超级复杂;更糟糕的是, 不知可以找「谁」来和这么多厂商统一事权 灾备进行到一半时发现,所需容量不足且设备无法一时到位,业务流程无法继续状况细部分析2:原灾备设计方式无法达到回复目标要求CMT makes decisionwithin 30 minSystem Recovery by tapewithin 12 hoursData
原创力文档


文档评论(0)