有容错还要灾备吗？

去年12月15日的“中国银行信用卡业务大机系统宕机”事件，重新引发了对关键业务信息系统安全性的关注。

整个事件闹得沸沸扬扬的，中国银行发官方微博表示道歉，但还是有很多人质疑：中国银行为什么没有启动灾备中心，以令系统宕机长达4小时。有文章分析指出：中国银行做了灾备，但没做业务连续性计划，以致不敢切换到备份中心；也有分析指出，系统宕机未必全是大机的事情，大机只是承担交易数据处理，外围平台故障也会导致业务系统中断，因为中国银行并没有公布有关故障报告，因此所有分析仅限于猜测，以中国银行的水平，不会没有有关业务连续性的应急预案。

对于承担关键业务的核心系统而言，是不会存在单一节点故障的，否则就太业余了。从硬件层次，针对系统故障通常的技术手段就是双机系统。借助集群软件实现系统容灾，但故障发生时，接替故障主机，保持业务连续性。但对于双机系统而言，进行容灾是没有办法做到无缝切换的，需要一个故障的恢复时间，可能长，也可能短。原因在于当故障出现时，系统宕机，这些系统CPU中正在处理的数据、内存中驻留的重要数据以及I/O中正在等待写入/写出的数据就会丢失，对于业务系统而言，这意味交易不完整，正在进行的交易失败。当我们用备份系统接替工作时，备份系统会对相关数据进行检测，对数据进行回滚，然后接替故障系统工作，实现平台切换。因此这个过程是一定会产生中断的，无论是大型机、小型机、还是X86双机服务器都是如此。（参见图1）

图1、双机系统切换流程

采用两地三中心是为了有效应对地震、火灾等突发性的故障，但灾害发生时，保持业务不中断。对于两地三中心而言，受地理空间上的限制，很难实现真正意义上的数据同步。如果要实现两地三中心数据的实时同步，对于业务系统而言，就会影响业务的相应时间，降低服务的满意度。对于银行而言，这是很难接受的，很难想象在取款机上取一笔钱要等10分钟。因此，对于两地三中心而言，一旦发生灾难性的事件，还是会损失一部分数据的。损失数据的多少取决数据同步的时间间隔。

有没有更好的方法应对业务系统故障？采用容错系统将是一个非常好的办法，容错方案和集群方案有很大不同。容错系统也是由两套独立的系统构成，包括处理器、芯片组、内存、I/O等全部是独立的系统，与集群不同的是，容错系统采用专用的ASIC芯片，对两套独立的系统在每一个时钟周期内的计算结果进行比对，进行纠错，这技术被称为“锁步技术（LockStep）”。当其中的一套设备发生故障的时候，专用ASIC系统检测到故障，并对其进行隔离，这时系统进入单系统模式，虽然失去了“容错”能力，但业务系统在单机支持下继续工作，业务保持连续不中断。对故障部件进行更换之后，系统恢复容错能力。

对于容错系统而言，只有在两个系统同时损坏的情况下，业务才会中断，但这样的概率是非常的低的。尽管如此，这种概率也还是存在的，因此从两地三中心的角度，灾备也是必不可少的。那么对于本地而言，需要构建基于集群的双机容错系统吗？应该说，这样做的话，可靠性将更有保障，但是从ROI（投资回报）的角度，成本代价是非常高的，应该根据业务的需要进行全面的考量。