在设计一个满足客户可用性需求的解决方案时，需要考虑多个方面。可能已经听说过三个缩写：SLA（服务等级协议）、RTO（恢复时间目标）和RPO（恢复点目标）。这些术语分别代表了什么，以及它们如何与高可用性解决方案相关联，是本文将要探讨的主题。
RTO，即恢复时间目标，指的是在某种事件发生后，系统恢复到正常状态所需的时间。以一个部署在多个区域的解决方案为例，如果该解决方案使用了流量管理器，并且将解决方案复制到另一个区域，那么如果流量管理器每5秒检查一次端点，并且3次失败导致故障转移，那么RTO就是15秒。通过双区域部署，能够保持相对较低的RTO。
记住，RTO是衡量业务连续性的一个重要指标，因此关注的是高可用性和灾难恢复。目标是尽可能减少服务停机时间。为了改善RTO，需要启用复制并采取措施加快恢复速度。监控是实现RTO目标的基石。如果不知道存在问题，就无法解决它。许多博客和文章会关注接下来的三个方面，但让诚实地说，如果不知道存在问题，就不能响应。如果日志操作有5分钟的延迟，那么需要将这5分钟考虑在RTO中。
接下来是响应时间。在这里指的是真正的意义上，可以多快触发到灾难恢复状态的故障转移。可以多快地诊断问题并响应情况？最好的RTO目标尽可能多地利用自动化。
然后，通过查看数据复制，可以确保能够快速恢复任何数据存储，并保持业务连续性。这很重要，因为每次不得不恢复数据存储，都需要时间，这会拉高RTO。如果可以在2分钟内进行故障转移，那么如果需要20分钟才能让数据库运行起来，那对来说并没有太大的帮助。
最后，是故障转移。如果处于需要进行故障转移的状态，那需要多长时间，可以采取哪些自动化和步骤来显著缩短这段时间。
RPO，即恢复点目标，主要关注的是提高从数据角度恢复的能力。如果在灾难发生时，会丢失多少数据？影响会是什么？
在查看RPO时，关键在于数据和潜在的数据丢失。如何最小化数据丢失的时间窗口，降低应用程序中丢失交易的机会？有几个关键元素可以帮助这一点，看看应用程序如何处理最终一致性。有可能达到RPO为0，因为解决方案中有持续的数据复制。
现在，复制的最重要部分是复制需要以同步方式执行，这意味着它必须在发送确认之前写入并复制数据。这意味着最终一致性将使RPO高于零，因为这意味着复制将“最终”到达。
这里最重要的因素是复制和数据一致性。所以真的需要确保事务的强度保持一致性规则得到执行。这就是为什么像Cosmos这样的数据存储在要求零RPO和低RTO方面越来越受欢迎，因为它支持可以执行这种逻辑的模型。