天堂和地狱永远只有一墙之隔。当企业因为信息化带来快捷的服务决策和方便管理时，也必须面对数据丢失的危险。
泰坦是一家电信服务商。至于为什么起了这个名字，CEO倪克自有一套想法。虽然历史上最豪华的巨轮泰坦尼克沉没在冰冷的北大西洋，但是我们要取其精华，弃之糟粕。我们也要做巨人，但是我们将把好每一关，我们的泰坦不会沉没。
然而，计划总是不如变化快，人算总是赶不上天算……
第一次沉没的理由 病毒
泰坦从创立开始，已经有3年的时间了。3年来，用户群飞速增长，业务不断扩大，呈现一片繁荣的景象。CEO倪克虽然时不时成为空中飞人，忙得不着家，惹得妻小埋怨，但心里还是很欣喜。
存好是一家做容灾解决方案的IT厂商。存好的CEO吴忧很早就认识倪克。看泰坦业务迅速发展，但没有任何灾备措施，吴忧就找到倪克说，作为一个电信服务商，数据对于泰坦来说非常重要。泰坦要上一套容灾系统来保护自己的关键数据。正在春风得意的倪克随口问了问报价，一听到那么高的费用，倪克就不愿意了，一句“吉人自有天相”把吴忧挡了回去。
然而天有不测风云。2003年的3月8日，对于泰坦来说，简直是个黑色的日子。早上10点，泰坦主服务器由于病毒侵入，发生近两个小时的故障，尽管网管员拼命抢修，仍然造成业务、用户、经营数据的大量丢失，其中包括近一年来企业用户的电话费用统计。没有了数据自然无法讨回所欠费用，最后算下来，造成近400多万元的损失。除此之外，在系统发生故障维修的时间内，很多用户都受到影响无法正常办公，有用户急得几分钟来一个电话，怨声一片。灾难远没有结束。事故发生后，许多用户开始对泰坦失去信任，泰坦因此流失很多用户。
倪克非常困惑：企业平时非常重视安全问题，也建立了牢固的防火墙和企业版杀毒软件，对工作人员的要求也很严格—-为防止病毒干扰，规定工作机不能上网等，可是，病毒怎么还是入侵了呢？
任何东西都不是万能的，防火墙和杀毒软件并不是永远固若金汤。况且，再小心谨慎也不可避免会发生各种各样的灾难。除了病毒以外，系统硬件和网络故障、机房断电等，这些灾害也不是仅仅小心就可以避免的。
假如有一套备份的数据，损失就不会这么巨大了。倪克那个后悔啊。颓然了几天之后，倪克规定员工对重要数据一定要进行拷贝。但是，由于泰坦数据量巨大并处于变化中，要及时存储数据占用大量时间和磁带等存储资源，而且不太可能做得及时。CIO陈默陆续走访了其他电信和银行企业，发现有些企业有一套专用的容灾系统，备份与容灾所关注的对象有所不同，备份关系数据的安全，容灾关心业务应用的安全，备份是“数据保护”，而容灾称作“业务应用保护”。备份最多表现为通过备份软件使用磁带机或者磁带库将数据进行拷贝，也可以使用磁盘、光盘作为存储介质；容灾则表现为通过高可用方案将两个站点连接起来。陈默向倪克汇报了其他企业在发生灾难时的措施之后，倪克终于下决心，要给泰坦进行容灾保护。
找谁来建呢？泰坦不想自己承担，一是没那个人力，二是精力也不足。所以陈默主动找到吴忧，两人这次是一拍即合。
2003年8月，泰坦开始建自己的灾备系统。陈默在离办公大楼不远的地方建了一个机房作为容灾中心。这时的泰坦对灾备系统的要求比较简单：灾难发生后，重要数据可以恢复就行。存好公司承担了其灾备系统的建设任务。根据泰坦的要求，存好为其建设数据级容灾系统以对其数据进行保护。
泰坦数据级容灾采用三级备份，第一是数据的热备份，即采用复制软件实现源数据和目标数据实时同步。每次数据更新操作，同时在生产中心和灾备中心进行。第二是数据的冷备份。任何技术都会有其自身的局限性，复制软件可以实现高水平数据保护，发生链路故障或主阵列/辅助阵列处于不可达状态或遭自然或机械灾害损坏时，能够保护数据并及时实现再同步。但是，如果由于源数据的合法操作而导致数据库的失效、无法识别，目标数据的数据库将同样失效。因此，泰坦对数据源采取了数据的冷备份，每周六夜间进行定时的增量备份。该方案提供了人为和应用错误的数据保护。第三是数据的暖备份，即数据库复制技术。完整的数据拷贝保持在灾备中心，更新日志定期由生产中心经由网络传送到灾备中心。
数据容灾建成了，虽然3月份的那次病毒入侵还历历在目，不过，倪克相信这回可以高枕无忧了。
第二次沉没的理由火灾
就像是老天有意要考验泰坦的容灾一样，泰坦的数据容灾系统建成后，陆续出了几次小事故，一次是服务器突然宕机，还有一次工作人员操作失误将数据删除，启动容灾系统后都基本在24小时内恢复了。这下，倪克非常得意，钱没白花。为此陈默受到倪克的表扬，不受重视的信息中心增光不少。而且陈默还应邀到多家公司介绍经验。泰坦项目也成为存好公司典型案例而大为推广。
一天，陈默在公司楼下的餐厅吃午饭，突然看到外面非常喧闹，很多人惊惶失措地跑来跑去。很快，就有一个人冲进餐厅尖叫，“起火了！”吃饭的人匆匆忙忙丢掉碗筷，跑出餐厅。陈默也跑到外面去看火情。果然，浓浓的黑烟从楼房里面冒出来。不过，这一次的陈默并不是很担心。他有能力让公司的IT系统重新运转起来。陈默甚至认为大火又给了他表现的机会。
消防队来了，大火终于扑灭了。陈默发现，尽管数据在容灾中心完好无损，但是他要重新搭建系统，然后再重新把数据导入到新建的系统中。经过三天三夜的奋战，系统终于恢复了正常工作。而在这三天中，泰坦公司的竞争对手推出优惠促销活动，泰坦六成的客户都投到对手门下。倪克也差点愁白了头。
经过这场事故，泰坦公司大伤元气。但是万幸的是，凭借这几年电信业的快速发展，泰坦公司积累丰厚而没有彻底破产。倪克下了死命令，要求泰坦的容灾中心要在任何情况下，可以让系统在12小时内恢复工作。
陈默再次找来吴忧。吴忧听完陈默的诉苦之后，给陈默指出一条出路—-应用级容灾。
在容灾建设中，两个关键的指标是RTO(Recovery Time Objective ，使系统恢复所需要时间)和RPO(Recovery Point Objective，可接受的数据损失程度)。其中RPO代表了当灾难发生时允许丢失的数据量，而RTO则代表了系统恢复的时间。倪克要求在12小时内恢复系统，其实就是对RTO的要求。不同级别的容灾系统有不同的RTO和RPO。数据级别的RTO大于24小时，而应用级别的RTO小于24小时。
泰坦原来建的只是数据级别容灾。这个级别的容灾系统能够满足企业对RPO的要求。 但是该级别灾难恢复时间较长，尽管用户原有数据没有丢失，但是应用会被中断，用户业务也被迫停止。
对于系统需要保持7×24小时连续运行的企业来说，需要高级别的应用容灾系统来满足他们的需求。应用级容灾是在数据级容灾的基础上，不仅把数据复制了一份，而且把应用处理能力也复制了一份。应用级容灾系统可以使企业的多种应用在灾难发生时进行快速切换，确保业务的连续性。
容灾的级别越高，RPO与RTO越小，但是用户需要的投资也越大，业务恢复及操作流程也更复杂，投资成本和维护成本也要增加。
听到这里，陈默犹豫了。建设更高级别的容灾看起来很好，但到底是不是值得呢？泰坦一定要上成本高昂的应用级的容灾吗？
吴忧说，这就需要根据业务间断对企业造成的损失来判断应该用什么级别的容灾系统。在泰坦公司还比较小的时候，相对于应用级容灾的投资，中断一天的业务造成的损失还不算很大，因此数据级别容灾也就够了。但泰坦不断在发展，中断单位时间的业务系统造成的损失增加了，业务中断三天让泰坦损失了百分之六十的客户。这时应用级别容灾的投资就是值得的了。
陈默不敢擅作主张。他把以上情况写了一个可行性报告递交倪克。成本的确是很高，但想到三天损失六成的客户，倪克就没有什么可犹豫的了。他拍板，泰坦要建应用级别容灾系统，要实现12小时系统恢复。
第三次沉没的理由 地震
在原来数据级别的容灾中心基础上，泰坦建设了应用级容灾中心。陈默自得了相当一段时间。作为一个中等规模的电信行业厂商，在短期内建了一套比较高端的容灾系统，而且运行起来很顺利，泰坦没有理由不满足。这不，泰坦还找了部分媒体，专程来报道自家的容灾系统。
这个周末的晚上，已经连续阴了好多天的城市，又下起了大雨，外加闪电、雷鸣、大风。冬天怎么还打雷？陈默虽然嘀咕了一声，但也不以为意。有暖气的房间里还是春意融融。陈默再一次捧起报道泰坦容灾的报纸，端着一杯香浓的哥伦比亚咖啡，准备再研读研读。突然，放在桌子上的水晶花瓶倒下来，滚到地上摔个粉碎。还没来得及心疼，正弯下腰准备检视瓶子现状的陈默听到一种奇怪的声音，一种振动的声音，由远及近，由小变大，再定睛一看，身边的桌子、椅子都在振动，而且频率越来越快，衣柜门自己打开了，里面的东西都被抛了出来，放在高处的东西丁丁咣咣往下掉，灯光忽明忽暗。楼外开始喧嚣，有人在惊恐地喊：地震了！地震了！
脑子里嗡的一声，陈默穿上外衣就往空旷的地方跑。一个念头飞速掠过，我的数据，我的容灾设备……但此时，陈默什么也顾不上了。等到震波过去，风平浪静，陈默穿过到处是废墟的街道赶到公司。最糟糕的事情果然发生了。
很多地方倒塌，容灾中心一片狼藉。光缆断了，网断了，主机显然被破坏了，那套昂贵的容灾系统不但没有救灾，反而自身受灾。
陈默站在废墟前，脑子里一片空白。又一次数据丢失、系统瘫痪，泰坦的业务怎么办？难道这一次泰坦真要倒下了吗？
怀着一丝侥幸，陈默马上通知存好进行系统修复，希望能挽回数据，减少损失。经过连续几天几夜的修复，存好公司告诉陈默，系统受损不是很严重，数据大部分可以恢复。这个消息让陈默喜出望外，大大松了一口气。
但是惊魂未定的倪克还是不踏实。他和陈默一起，亲自找来吴忧，想了解到底怎样，泰坦的业务才能真正安全。
吴忧再一次侃侃而谈。在系统设计中，企业一般会考虑做数据备份和采用主机集群的结构,因为它们能解决本地数据的安全性和可用性。这是针对慢性容灾的本地解决方案，如果当某台主机出现故障，不能正常工作时，其他的主机可以替代该主机，继续进行正常的工作。目前人们所注意到的容灾，大部分也都只是停留在本地容灾的层面上。但对某些地区的某类企业来讲，光有本地容灾是远远不够的。其关键业务应用，必须要防范地震、洪水、战争等自然灾难。因此应该采用异地容灾的保护措施。一套完整的容灾方案应该包括本地容灾和异地容灾两套系统。
远程容灾系统具备应付各种灾难特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。其系统一般由生产系统、可接替运行的后备系统、数据备份系统、备用通信线路等部分组成。在正常生产和数据备份状态下，生产系统向备份系统传送需备份的数据。灾难发生后，当系统处于灾难恢复状态时，备份系统将接替生产系统继续运行。此时重要营业终端用户将从生产主机切换到备份中心主机，继续对外营业。
这种备份目前分为两种形式，一种是历史备份，一般采用每天凌晨备份的形式，出现问题可以恢复一天前的数据。如果对数据要求不是很高的话，可以采用三天，甚至一周备份的方式，可以节约很多成本。
那么我们泰坦要选择多远的距离来搭建异地容灾系统？几公里？几十公里？还是几千公里？陈默还是不太明白。
吴忧说，这就需要根据企业自身状况来定了。同样是容灾系统，如果容灾的目标只是在城市中防范火灾等较低级别的灾难事件，那么存储在与应用地距离几公里的地方就能较好地满足要求。如果是防水灾，则要求它们之间的距离在数公里以上。如果是预防地震，则需要保持几百公里的距离。基本来说，数据存储距离与应用地越远,容灾性也就越强，100公里以上的异地灾难备份将是未来的一种趋势。只要IP可达，并且网络带宽足够，数据不再惧怕自然灾害。吴忧总结道。
还在对刚刚结束的地震痛定思痛的倪克听完之后当场拍板，泰坦也要建异地容灾系统，而且地点要选得远一点，就在南方的沿海城市C城。隔着几百公里，这下总安全了吧？
第四次沉没Game Over
自从数据级、应用级和异地容灾系统建成后，陈默觉得自己终于可以高枕无忧了。就算地震再来一次，公司的全部数据和应用都可以实现异地切换。
不过，存好公司的咨询部门给陈默打来电话说，泰坦目前在硬件上是没有问题了，但做好容灾非一日之功，还需要进行一些“软件工作”。这个软件指的不是真正的软件，而是指系统的日常维护和管理、流程和人员组织、容灾演习、策略和知识培训等工作，当然，流程咨询、策略和知识培训是要收费的。
陈默把这个消息告诉了老板，并陈述了自己认为应该做好容灾系统维护管理的几条理由：第一，公司有上百个应用系统，不能停顿的关键业务就有40多个，系统很是复杂；第二，存好是容灾行业的领先公司，积累了大量的经验，给很多大企业做过容灾，他们结合ITSM的先进理念，并形成了自己的方法论。另外，陈默曾参加了金融行业的一个容灾论坛，一些用户的现身说法给他留下深刻的印象。所以，还是应该请存好公司的咨询部门来做顾问和培训。
让陈默感到高兴的是，倪克经过前几次事件的折腾，已经吃一堑长一智，让存好来辅助做服务的事很快就敲定了，费用马上就批了。
不过，倪克约法三章：第一，日常维护等一些偏技术的事还是自己来吧，先不外包，不然公司白养了这么多的技术人员；第二，咨询公司的费用照付，但要学到人家的策略和方法，培养自己在灾难恢复上的技术能力和管理能力，不能总是依靠外援，也不能总花冤枉钱；第三，要是培训完了再出问题，拿陈默是问。
一切进展还算顺利，灾难风险评估、业务影响分析、灾难恢复策略设计、详细方案设计、容灾方案实施、灾难恢复计划开发以及最后的灾难恢复测试和演习都按部就班。按照计划，员工以部门为单位和以流程为单位分成几个小组进行培训和演习。存好公司把整个咨询过程分为三个部分：技术、人和流程。
在人的方面，存好公司把泰坦公司的开发人员和运营维护人员分开培训。在流程方面，根据公司的情况引进了ITIL(IT服务管理)体系，并根据国外电信公司的经验，结合泰坦公司的实际，分为事故管理、问题管理、配置管理、变更管理和发布管理等五个方面进行培训。
在实战阶段，存好公司对泰坦公司的数据中心、整个公司的大楼分布以及分公司数据中心情况都做了详细的考察，包括网络系统、服务器数量和存储架构、楼梯通道、电源系统等多个环节。通过需求分析，最终制定了容灾实施对策演习方案，并以泰坦全部员工都能听懂的语言，从标准化管理、权限身份管理、通讯管理、迁移管理、预警管理等多个方面做了部署。
三个月下来，项目成功验收，倪克对这个环节的工作相当满意。存好公司咨询部门撤出了项目组，不过离开之前再三叮嘱陈默：“容灾成功的保障在于不断循环，在公司一定要形成制度，不断强化，并根据新情况不断演进和更新。千万不要让它成为只看不用的东西。”陈默点头答应。
接下来，陈默倒也按照存好公司的套路做了几件事：一是成立日常专门运营小组，二是规范流程，三是以季度为单位进行不同灾难级别的日常演习，四是把以上事项制度化。一年下来，泰坦公司果然平安无事。再后来，陈默由于业绩赫赫，跳槽到另一家世界500强企业了。公司原运维部门员工被抽调组成新的增值业务部门。
陈默走了以后，关于容灾的管理、演习和执行方案逐渐被淡忘。再半年之后，大家也都想不起来了。生意忙啊，别的事情先靠边站吧。再说，哪有那么多的不测风云。
2006年8月4日，历史上最强的台风“超级玛丽”登陆C城。“超级玛丽”带来了巨大的海啸，海浪有几十米高，铺天盖地扑向C城。C城短短时间内就成了暴风雨中飘摇的稻草。就在这同时，泰坦总部的信息中心因为雷雨天气起火，IT系统突然宕机，员工们由于平时疏于防范，事发后乱成一团。总部的人给C城灾备中心狂打电话，想启动异地灾备系统。但是，异地灾备系统再没有回音。所有业务停滞，数据毁于一旦。
倪克马上给存好公司打电话，吴忧只说了三句话，“容灾不是一劳永逸，没有后期管理的容灾系统形同虚设；世界上又少了一家公司；除了上帝，没有人有办法”。
Game Over!
链接：如何看待容灾的回报
一个容灾系统，需要从软件到硬件进行多方面的投入。一个完整的容灾方案，大概要投资几百万，甚至上千万元。对企业来说，花这笔钱是否值得呢？
这里有一个表格，是日用百货业的系统可用性与宕机时间、年宕机损失和金融业年宕机损失之间的关系。
在美国，如果某一家电信公司由于某种原因，业务需要中断一小时，即这一个小时不能打电话，那么用户会马上选择别的电信公司，成为其他公司的用户。因而，用户对可用性的要求越来越高，宕机一小时的损失越来越大。
系统可用性 宕机时间 年宕机损失 金融业年宕机损失
- 99.9999 30秒 950 53750
- 99.999 5分钟 9417 537500
- 99.99 52分钟 98000 5590000
- 99.9 8.75小时 988750 56000000
- 99.5 53.7小时 5000000 280000000
- 99.0 87.6小时 10000000 560000000
- 98.0 180小时 20000000 1000000000
- 95.0 450小时 50000000 3000000000
记者手记：自建、共建，还是外包？
容灾是自建、共建，还是外包？这一直是用户争议的问题。泰坦公司把容灾系统外包给了存好公司。这一选择对泰坦公司来说，很适合。
因为，灾备中心需要投入大量的人力、物力及财力。自建、共建和外包三种建设方式各有利弊。自建方式具有投资巨大、建设周期长、技术与实施难度大、管理与维护要求高、运营维护成本大等特点，比较适合对风险控制要求高、资产规模大、技术与管理实力强的企业。
共建方式具有投资少、技术与管理难度大、人员组织困难、责任不易界定、合作模式要求高等特点。
而外包是用户花钱购买第三方的服务，而不是自己企业内部员工完成灾备任务。这种模式最突出的特点是用户和IT企业各自能够充分发挥自己的专业特长。
泰坦并没有雄厚的资金，也没有专业的IT服务团队，从自身应用需求的角度来看，也没有必要独自建一个庞大的备份中心去应付小概率的灾难。因此，外包方式对泰坦这样的中等企业来说是可行的一种方式。
容灾是个必答题，只是要把握好时机。容灾又是个选择题，在决定建设之后，要选择合理的建设方式和建设方案，在节省开支的情况下，保证重要业务数据得到很好的灾备，能达到防灾于未然、未雨绸缪的目的。
