1. 故障原因：不明的人为操作导致的数据库崩溃。人们总是过分相信自己，而对机器这样冷冰冰的东西充满不信任。而实际上，我们经历的至少三分之二的灾难是由人为操作导致的。误删除、恶意攻击、或者一次失败的程序更新，等等。相比而言，硬件故障、火灾、地震、恐怖袭击发生的概率，要小得多。而不明的人为操作是最常见而且最棘手的灾难。某些容灾规划中仅依靠双活、集群或者远程数据中心同步来实现容灾是不正确的。所有的错误操作，都会同时复制到远端。双活就是双死，多活就是多死。不论有多少灾备站点，有一个算一个，要死大家一起死。双活面对本案例中的这个场景，完全束手无策，只有备份才能解决；
2. 容灾的第一步：故障定位。并不是所有的灾难都会出故障时马上崩溃。特别是人为故障更是如此。甚至于，很可能首先发现故障的系统并不是故障的本源，而只是表征。这时候，定位故障原因是第一位的，而不是迅速由容灾端接管。否则，灾难不能解决，反而往往会扩大。本案例中就是如此，下午2点发现故障，但中午12点时系统就已经不正常了。IT部门用了约2小时定位了故障点，在现实中，这个速度不算慢了。如果应用系统相互依赖关系错综复杂，很有可能需要更长的时间才能定位。
3. 自动化与人工：容灾离不开人工。容灾预案的启动，需要很多人工判断的决策，这是不能简单地交给容灾系统自动完成的。很多容灾厂商都向客户描述一个如同科幻电影般的理想场景，仿佛出现灾难后，只需要按下一个“灾难恢复”的红色按钮，自动化机制就会去处理，远端容灾系统一接管，就一切修复了。甚至于有的用户会希望连那个按钮都没有，系统应该可以自动判断系统故障，然后启动接管过程。也许对于一个简单的硬盘故障，这种自动化方法还可行，但是对于如今无比复杂的企业级IT系统，灾难恢复这么重大的事件，自动化的价值是十分有限的，人工的决策是必需的，甚至是决定性的。
4. RTO和RPO（恢复时间和恢复点）: 我们认为，RTO和RPO为零只是一个理想，特别是面对人为错误。所有的容灾系统都在追求RTO和RPO的最小化，一直趋近于零，也就是要在瞬间恢复到系统故障前那个状态。这是一个特别理想化的目标。任何容灾系统，也不可能保证在任何情况下，都能把系统瞬间恢复到那个状态。说到这里，可能大家发现，硬件故障，不论多么严重的硬件故障，即使是机房整个被炸掉，反倒都是比较容易解决的场景了，因为这种情况有一个很明确的故障点，我们只要恢复到那个时间点之前的状态，一定可以正常运行。而人为操作导致的崩溃，故障的时间点是未知的。这时候，容灾的决策实际上是在RTO和RPO之间进行取舍：是牺牲更多的停机时间来找到更近的恢复点；还是快速找到一个肯定可用的恢复点马上恢复系统，从而减少停机时间？怎样选择，都没有完美的答案。在本案例中，如果一开始就决策采用11点55分的快照点，可能可以减少近2小时的停机时间，但是这都是马后炮，决策的时候，你怎么可能事先知道呢？实际上如果IT部门从12点3分的快照点每隔1分钟开始逐个验证，可能要花多得多的时间才能轮到验证11点55分这个快照点。在这个案例中，总停机时间约7小时，IT部门在有限的资源面前，已经通过自己的经验和判断大大缩减停机时间了。同时16:25进行恢复前一刻的数据依然在CDP保护中，理论上依然可以通过该快照点分析并恢复 11:55 到14:00 之间丢失的所有业务数据。
5. 数据验证的重要性：在这个案例里，我们发现停机的绝大部分时间都是用来进行验证。恢复前进行数据验证和系统验证是完全必要的。我们试想一下，如果没有进行验证，就把12:00的快照点恢复完直接上线，会发生什么情况。刚一开始系统可以运行，大家都松了一口气以为大功告成，然而几个小时后系统再次崩溃。这时候IT团队所面临的压力要比前一次故障时大得多，因为系统的总停机时间可能已经超过10个小时，而一切都要重新开始。这时候IT团队还能对自己的经验和判断有信心吗？业务部门还能对IT团队的能力有信心吗？
6.容灾需要演练：在这个案例里，我们发现由于容灾预案没有得到很好的管理、维护和演练，导致老的预案没有价值：要么会丢失掉近4天的业务数据，理论最小总停机时间高达10小时；要么等待应用程序厂商进行数据修复，总停机时间以天为单位。此外预案中的备机也没有落实，导致操作过程中没有合适的物理主机进行数据验证，在恢复到虚拟机环境后才发现业务系统的启动需要依赖物理加密狗；由于快照点没有充分验证，导致总停机时间延长了100分钟。经过本次事件后，容灾预案也得到了更新，并且为容灾配置更多资源。新预案中支持同时验证多个时间点，能够在更短的时间内找到更加接近故障点的快照点。END
这个案例虽然不是如同产品演示一样完美，停机时间也比较长，但是就当时的条件和具体情况而言，就是一次成功的灾难恢复。试想如果同样的灾难发生在那些把希望寄托在双活和异地同步的用户，甚至可能根本无法恢复业务系统运行；如果使用传统的定时备份的磁带库和备份软件（功能）恢复，可能要花多得多的时间才能把故障发生的时候320GB的数据库备份下来，并恢复到更早的一个时间点，还要担心是否有关键的业务数据丢失。相比之下，在此案例中，依靠科力锐分钟级恢复技术和3级数据恢复技术，每次重启物理主机到业务系统可验证、可访问，实际花费时间仅仅需要15分钟即可。同时由于用户采用了CDP技术，才有可能获得距离故障点相对较近的快照点。虽然IT团队没能一开始就准确决策应该采用哪个快照点，但是发现问题后迅速调整，有效减少了停机时间。
以上就是一个容灾案例的分享与剖析，希望大家能够从中有所收获。END
可以搜索科力锐三个字进入官网进行了解