RTO & RPO

在故障恢复方面,目前业界公认有三个目标值得努力。

  • 恢复时间:企业能忍受多长时间没有 IT,处于停业状态。
  • 网络多长时间能够恢复
  • 业务层面的恢复

整个恢复过程中,最关键的衡量指标有两个:一个是 RTO,另一个是 RPO。

所谓 RTO,Recovery Time Objective,是指故障发生后,从 IT 系统宕机导致业务停顿之时开始,到 IT 系统恢复至可以支持各部门运作、恢复运营之时,此两点之间的时间段称为 RTO。

所谓 RPO,Recovery Point Objective,是指对系统和应用数据而言,要实现能够恢复至可以支持各部门业务运作,系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据,也可以是上一次交易的实时数据。

选择标准

对故障恢复而言,RTO 与 RPO 哪个衡量指标更合适呢?

在考虑采用哪个指标之前,IT 人首先要弄清楚一个基本概念,企业的容灾系统预防的是什么灾害,是多少年一遇的,能忍受多少损失,需要算出一个大概的成本,当然不一定很精确。其次,无论企业容灾系统是采用冷备、热备、温备、还是磁盘备份,几分钟恢复业务和几天恢复业务效果是完全不一样的。企业需要明确对恢复时间的容忍底限是多少。

再从灾备本身的意义来讲,无论采用哪种衡量指标,最终目的是要能够很好地检验灾备系统的实用性能,否则就失去建立灾备的意义了。而灾备最核心的作用就是确保灾难发生后业务能够连续运行,交易中的数据完整保存,丢失越少越好。因此业务层面的恢复,企业要有一个底限。参考世界范围内一系列灾难恢复经验,国家之间的差别非常大。比如在美国,政府是第一位的,警察局对数据的恢复要求特别高。而在中国,无论什么性质,银行始终是排在第一位的。

综合平衡

作为银行,除开展自身业务之外,更多数据来自上下级银行间的财务汇兑与结算。

站在管理者的位置上,一旦灾难发生,最重要的是在尽可能短的时间内排除障碍,恢复业务,保证系统做到连续运行。因此,从这个角度出发,银行容许系统停滞的时间应当越短越好。选择 RTO 刚好合适。

但是,RTO 对成本要求太高,与回报似乎不成正比。企业资金不可能无限制地投入到一个灾备系统中。对于银行证券这样的联机交易事故处理非常紧密的金融机构而言,可能每一笔、每一单、每一分钱都很重要,所以都需要恢复。RPO 显然更为合适。

许多时候进行选择并不意味着非此即彼,这与现实婚姻中一夫一妻的限制还是有差别的。RTO 和 RPO 对银行来讲都很重要。RTO 越短、RPO 越新,银行面临的损失就越小,但这也意味着系统开发成本将会急剧上升。许多时候,最佳的容灾解决方案却不一定是效益最好的。反之亦是。如何去平衡这中间的关系,不仅是门学问,更像是艺术。

根据国际经验,在选择“你”还是“她”的时候,企业应当考虑灾难发生后会在多大层面上冲击业务,这涉及到企业形象,商业机密,信誉评级,品牌竞争力等等方面,各个企业的情况不同,要根据自己的情况选择合适的“对象”。灾难恢复的目的是业务连续进行,因此无论采用 RTO 还是 RPO,都要朝着这个核心靠拢。

评论