【容灾真相】真案解剖
容灾的话题一直很热，但是可供分析的实际案例却往往很少，往往是由于各种原因，相关人相互推诿，知情人讳言莫深，外人根据流出的只言片语胡乱猜测，往往与事实相差甚远，其结论往往反而误导了大众，以至于对这个重要问题的探索和研究变得十分困难。
既然如此，我们就拿出一些我们亲身经历的实际案例，当做小白鼠与大家分享，希望能够对大家研究规划和管理自己的容灾系统有所帮助。这个案例从很多角度看并不算一个特别完美的宣传样板，但是正因如此，才更具有实际的代表性，更有分享的价值。
特别要声明，为了避免不必要的麻烦，本文隐去当事人和单位名称，除此以外，完全真实。
“案情”
今年4月21日，14:00左右，一家列入世界500强的大型国企，业务部门反映人力资源系统无法办理业务。IT部门马上开始故障排查，发现故障原因是由于误删除导致了数据库故障，导致相关系统无法运行。数据库容量约1.4TB。于是17:30左右开始启动灾难恢复机制。
17:30：首先，IT主管决定提取了上午10点的历史时间点快照进行数据验证。结论是数据库可以正常启动。于是开始向主存储上恢复数据。
20:30左右：数据恢复完成。
21:00：启动数据库，数据库可以正常启动。然后应用厂商调试相关的应用软件。
23:30：应用厂商验证数据时，发现数据库有一个表的索引仍然存在问题，需要手动对索引进行调整。调整所需要的时间很难确定，为了减少恢复时间，IT主管决定重新提取CDP快照数据，改为提取上午9:00的快照。
0:00左右：验证了9点快照数据库可以启动。
0:00-1:45：对9:00的快照进行验证，验证结果正常。
凌晨2:00左右：快照数据恢复到主存储。数据库正常运行，业务系统恢复运行，系统恢复完成。
这是一个通过容灾系统成功恢复数据的典型场景。由于人为错误导致的停机，通过CDP进行恢复，首次恢复时的时间点选择不对，但是直到恢复之后才发现，于是选择了更早的时间点终于恢复成功。整个系统停机时间约12个小时。
分析
下面我们对这个案例的一些特别值得关注的细节进行一下分析：
1. 故障原因：不明的人为操作导致的数据库崩溃。人们总是过分相信自己，而对机器这样冷冰冰的东西充满不信任。而实际上，我们经历的至少三分之二的灾难是由人为操作导致的。误删除、恶意攻击、或者一次失败的程序更新，等等。相比而言，硬件故障、火灾、地震、恐怖袭击发生的概率，要小得多。而不明的人为操作是最常见而且最棘手的灾难。这样看来，现在国内大量的容灾项目以双活或者多活为基础，就是个错误了。所有的错误操作，都会同时复制到远端。双活就是双死，多活就是多死。不论有多少灾备站点，有一个算一个，要死大家一起死。双活面对本案例中的这个场景，完全束手无策，只有CDP才能解决；
2. 容灾的第一步：故障定位。并不是所有的灾难都会出故障时马上崩溃。特别是人为故障更是如此。甚至于，很可能首先发现故障的系统并不是故障的本源，而只是表征。这时候，定位故障原因是第一位的，而不是迅速由容灾端接管。否则，灾难不能解决，反而往往会扩大。本案例中就是如此，下午2点发现故障，但上午10点时系统就已经不正常了。IT部门用了约三个半小时定位了故障点，在现实中，这个速度不算慢了。如果应用系统相互依赖关系错综复杂，很有可能需要更长的时间才能定位。
3. 自动化与人工：容灾离不开人工。容灾预案的启动，需要很多人工判断的决策，这是不能简单地交给容灾系统自动完成的。很多容灾厂商都向客户描述一个如同科幻电影般的理想场景，仿佛出现灾难后，只需要按下一个“灾难恢复”的红色按钮，自动化机制就会去处理，远端容灾系统一接管，就一切修复了。甚至于有的用户会希望连那个按钮都没有，系统应该可以自动判断系统故障，然后启动接管过程。也许对于一个简单的硬盘故障，这种自动化方法还可行，但是对于如今无比复杂的企业级IT系统，灾难恢复这么重大的事件，自动化的价值是十分有限的，人工的决策是必需的，甚至是决定性的。
4. RTO和RPO（恢复时间和恢复点）: 我们认为，RTO和RPO为零只是一个理想，特别是面对人为错误。所有的容灾系统都在追求RTO和RPO的最小化，一直趋近于零，也就是要在瞬间恢复到系统故障前那个状态。这是一个特别理想化的目标。任何容灾系统，也不可能保证在任何情况下，都能把系统瞬间恢复到那个状态。说到这里，可能大家发现，硬件故障，不论多么严重的硬件故障，即使是机房整个被炸掉，反倒都是比较容易解决的场景了，因为这种情况有一个很明确的故障点，我们只要恢复到那个时间点之前的状态，一定可以正常运行。而人为操作导致的崩溃，故障的时间点是未知的。这时候，容灾的决策实际上是在RTO和RPO之间进行取舍：是牺牲更多的停机时间来找到更近的恢复点；还是快速找到一个肯定可用的恢复点马上恢复系统，从而减少停机时间？怎样选择，都没有完美的答案。在本案例中，如果一开始就决策采用9点的快照，可能可以减少好几个小时的停机时间，但是这都是马后炮，决策的时候，你怎么可能事先知道呢？实际上如果IT部门从13点的快照开始逐个验证，可能要花多得多的时间才能轮到验证9点这个快照。在这个案例中，总停机时间约12小时，恢复点在上午9点，IT部门已经通过自己的经验和判断大大缩减停机时间了。
5. 数据验证的重要性。在这个案例里，我们发现停机的绝大部分时间都是用来进行验证。系统是2点钟发现故障的，但是上午10点时数据库就已经不正常了。IT团队花了两个多小时验证10点的快照，但是这个错误还很难发现，因为用10点的快照，数据库是可以启动的，只是有一个表不正常。恢复和比对分析需要大量的时间，而且是完全必要的。我们试想一下，如果没有进行验证，就把10点的快照恢复完直接上线，会发生什么情况。刚一开始系统可以运行，大家都松了一口气以为大功告成，然而几个小时后系统再次崩溃。这时候IT团队所面临的压力要比前一次故障时大得多，因为系统的总停机时间已经超过10个小时，而一切都要重新开始。而他还能对自己的经验和判断有信心吗？
结论
这个案例虽然不是如同产品演示一样完美，停机时间也比较长，但是就当时的条件和具体情况而言，算是一次成功的灾难恢复。试想如果同样的灾难发生在那些把希望寄托在双活和异地容灾上的用户，很有可能根本无法恢复系统运行；如果使用磁带库和备份软件恢复，可能要花多得多的时间才能把1.4TB的数据库恢复到更早的一个时间点。相比之下，在此案例中，因为采用了CDP，每次实际数据恢复的时间只有15分钟左右。也正因为用户把CDP的快照频率设为一小时，才有可能相对较快地恢复到相对较近的时间点。虽然IT没能一开始就准确决策应该采用哪个快照，但是发现问题后迅速调整，有效减少了停机时间。因此，我们觉得，这是一次成功的案例，而且遇到了很多典型的困难，特别值得拿出来和大家分享。希望大家能够从中有所收获。
etsme是采用云计算原生技术打造的个人私有云/小型私有云产品，即刻入手etsme，探索更多贴心功能，掌控自己的数字世界。