本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 检测
<a name="detection"></a>

 请务必尽快了解您的工作负载并未实现应有的业务成果。通过这种方式，您可以快速宣布灾难并从事件中恢复。对于积极的恢复目标，这种响应时间加上适当的信息对于实现恢复目标至关重要。如果您的恢复时间目标为一小时，则需要检测事件，通知相关人员，参与上报流程，评估有关预计恢复时间的信息（如果有的话）（不执行灾难恢复计划），宣布灾难并在一小时内恢复。

**注意**  
如果利益相关者决定不调用 DR，即使 RTO 会面临风险，请重新评估灾难恢复计划和目标。之所以决定不援引灾难恢复计划，可能是因为计划不够充分，或者对执行缺乏信心。

 至关重要的是，要将事件检测、通知、上报、发现和申报纳入您的计划和目标，以提供具有商业价值的切合实际、可实现的目标。

 AWS 在 Service Healt [h Dashboard 上发布了我们最多的服务](https://status.aws.amazon.com/)可用性 up-to-the-minute信息。随时查看以获取当前状态信息，或订阅 RSS feed 以获得每项服务中断的通知。如果您遇到我们的一项服务的实时操作问题，但该问题未显示在 Service Health Dashboard 上，则可以创建[支持请求](https://console.aws.amazon.com/support/home#/case/create?issueType=technical)。

 [AWS Health Dashboard](https://phd.aws.amazon.com/phd/home#/)提供有关可能影响您账户 AWS Health 的事件的信息。信息会以两种方式显示：显示按类别组织的最近和未来事件的控制面板，以及显示过去 90 天内所有事件的完整事件日志。

 对于最严格的 RTO 要求，您可以根据[运行状况检查实现自动故障转移。](https://aws.amazon.com/builders-library/implementing-health-checks/)设计能够代表用户体验并基于关键绩效指标的健康检查。深度运行状况检查可以发挥工作负载的关键功能，而不仅仅是浅层的心跳检查。使用基于多个信号的深度健康检查。谨慎使用这种方法，以免触发虚假警报，因为在不需要时进行故障转移本身就会带来可用性风险。