← 返回概念辨析

Concept Contrast Fable

恢复时间目标和恢复点目标

RTO 问的是「出故障之后多久恢复正常」,RPO 问的是「允许丢多少时间的数据」。RTO 决定你要备几台机器、要不要热备,RPO 决定你要多久做一次备份、能做增量还是必须实时同步。客户把两个目标当成同一个「恢复要求」提给你,你的架构成本可能差五倍。

寓言

救火队和档案馆

钱庄怕账房失火,掌柜问两件事。账房头管着两摊看似相近的事:一摊是多久能重新开门收付,另一摊是最多能丢失多久以前的账。新伙计嫌麻烦,把两本册子合成一本,觉得反正都和成败有关。

最初没人反对。伙计把两问合成“备份要好”,买了铁箱就安心,掌柜看见页数少了,还夸他们省事。可旺季一到,旧账忽然说不清:到底是前一摊没做完,还是后一摊没守住,谁也答不上来。

他们先补了更多章印和口号,要求每个人写得详细些。结果册子更厚,争执更多。出事时,每个人都能找到一句为自己开脱的话,却没人知道该先救哪一头。

老管事把众人叫到院里,让他们按真实经过重走一遍。凡是关心眼前动作的,放在第一本;凡是关心后续承担的,放在第二本。两本册子互相引用,却不再混成同一页。

火后铁箱保住三天前的账,可柜台半日搭不起,昨日交易也找不回。分开之后,很多旧结论改了:有些活看着热闹,其实没有挡住麻烦;有些安排平时不起眼,灾时却保住了全局。

为了防止新人再混,老管事让他们各办一件小案。只有当两本册子分别能回答自己的问题,又能在交界处互相接上,这件小案才算过关。若有人仍把两摊事写成一页,就必须回到现场重新看一遍谁先动手、谁最后担责;看不清时,宁可多问一次,也不让糊涂账过夜;因为真正出事那天,少一行分辨就会多一队人白忙。

掌柜分开定规矩:柜台一炷香内要能临时开,账本每半个时辰要抄一份到隔壁。后来新人入行,老管事只让他们记一句:恢复得快,和少丢旧账,是两把尺。

恢复时间目标

系统或服务从中断状态恢复到正常运行状态所能接受的最大时长。它定义的是「能等多久」,决定了灾备架构中是选择冷备、温备还是热备。

恢复点目标

系统在故障后所能接受的最大数据丢失窗口,通常以时间为单位。它定义的是「能丢多少」,决定了备份频率——每小时备份、实时同步还是每日备份。

故事对应

  • 救火队赶到现场的时间:RTO——衡量故障响应速度。
  • 档案馆备份覆盖的间隔:RPO——衡量数据丢失的上限。
  • 四小时恢复但丢了两小时数据:RTO 达标但 RPO 未被定义,灾备效果大打折扣。
  • 加热备服务器把 RTO 压到一小时:缩短恢复时间需要的技术投入。
  • 换准实时同步把 RPO 压到五分钟:缩短数据丢失窗口需要的技术投入。

落到项目里

接到灾备需求时,把 RTO 和 RPO 拆成两个独立参数问客户。同一个系统里不同模块可以有不同的 RTO/RPO——支付模块的 RPO 可能要求零丢失,报表模块的 RPO 可以接受一天。拆开之后架构师才能做差异化设计,避免用一个最严苛的数字覆盖所有模块、导致整体成本失控。