# REL13-BP01 定義停機和資料遺失的復原目標
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 故障可能會以多種形式影響您的業務。首先，故障可能會導致服務中斷 (停機時間)。其次，故障可能會導致資料遺失、不一致或過時。為了引導您回應故障並從故障中復原，請為每個工作負載定義復原時間點目標 (RTO) 和復原點目標 (RPO)。*復原時間點目標 (RTO)* 是服務中斷與服務還原之間的可接受延遲上限。*復原點目標 (RPO)* 是從上次資料復原點之後起算，可接受的最長時間。

 **預期成果：**每個工作負載都根據技術考量和業務影響指定了 RTO 和 RPO。

 **常見的反模式：**
+  您尚未指定復原目標。
+  您選取任意復原目標。
+  您選取的復原目標過於寬鬆且不符合業務目標。
+  您尚未評估停機時間和資料遺失的影響。
+  您選取的復原目標不切實際，例如零復原時間或零資料損失，這對於您的工作負載組態而言可能無法實現。
+  您選取的復原目標比實際業務目標更嚴格。這會強制進行比工作負載所需更昂貴和更複雜的復原實作。
+  您選取的復原目標與相依的工作負載不相容。
+  您未將法規和合規要求納入考量。

 **建立此最佳實務的優勢：**設定工作負載的 RTO 和 RPO 之後，您就可以根據業務需求訂定清楚且可衡量的復原目標。設定這些目標之後，您就可以制定專為實現這些目標所打造的災難復原 (DR) 計畫。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 建構對照表或工作表，以協助引導您的災難復原規劃。在對照表中，根據個別的業務影響 (例如嚴重、高、中和低) 以及要做為個別目標的相關聯 RTO 和 RPO，建立不同的工作負載類別或分級。下列對照表為您提供可遵循的範例 (請注意，您的 RTO 和 RPO 值可能不同)：

![\[顯示災難復原矩陣的圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)


 針對每個工作負載，調查並了解停機時間和資料遺失對業務造成的影響。影響通常會隨著停機時間和資料遺失而增強，但影響的程度會根據工作負載類型而有所不同。例如，長達一小時的停機時間可能會產生低程度的影響，但隨後影響可能會迅速增強。影響可能有多種形式，包括財務影響 (例如收益損失)、聲譽影響 (包括失去客戶信任)、營運影響 (例如發不出薪資或生產力降低)，以及法規風險。完成後，將工作負載指派至適當的分級。

 當您分析故障的影響時，請考慮下列問題：

1.  在對業務造成無法接受的影響之前，可以容忍的最長工作負載停機時間是多久？ 

1.  工作負載中斷會對業務產生多大程度的影響以及何種影響？ 請考慮各種影響，包括財務、聲譽、營運和法規。

1.  在對業務造成無法接受的影響之前，可以容忍的遺失或無法復原的最大資料量是多少？ 

1.  是否可從其他來源重新建立遺失的資料 (也稱為*衍生*資料)？ 如果可以，請同時考量用來重新建立工作負載資料的所有來源資料的 RPO。

1.  此工作負載所依賴的工作負載 (下游) 的復原目標和可用性期望為何？ 工作負載的目標必須在其下游相依的工作負載具有復原能力的情況下才能達成。請考慮可能改善此工作負載復原能力的下游相依性因應措施或緩解措施。

1.  依賴此工作負載的工作負載 (上游) 的復原目標和可用性期望為何？ 上游工作負載目標可能要求此工作負載具有比首次出現更嚴格的復原能力。

1.  是否取決於事件類型而有不同的復原目標？ 例如，根據事件影響的是可用區域或整個區域而定，您可能有不同的 RTO 和 RPO。

1.  您的復原目標是否在一年中的某些事件或某段時間改變？ 例如，您可能在節日購物季節、體育賽事、特別促銷和新產品推出時，採用不同的 RTO 和 RPO。

1.  復原目標如何與您可能擁有的任何業務範圍和組織災難復原策略保持一致？ 

1.  是否需要考慮任何法律或合約後果？ 例如，您是否在合約方面有義務要提供具有特定 RTO 或 RPO 的服務？ 若未履行義務，可能會受到哪些懲罰？ 

1.  是否需要維護資料完整性以符合法規或合規要求？ 

 下列工作表可協助您評估每個工作負載。您可以修改此工作表以滿足您的特定需求，例如新增其他問題。

<a name="worksheet"></a>![\[工作表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/worksheet.png)


### 實作步驟
<a name="implementation-steps"></a>

1.  確定負責每個工作負載的業務利害關係人和技術團隊，並與他們互動。

1.  在組織中建立工作負載影響的關鍵性類別或分級。範例類別包括：嚴重、高、中和低。為每個類別選擇合乎您業務目標和需求的 RTO 和 RPO。

1.  將您在上一個步驟中建立的其中一個影響類別指派給每個工作負載。若要決定工作負載對應至類別的方式，請考慮工作負載對業務的重要性，以及中斷或資料遺失的影響，並利用上述問題來引導您。這樣就能找到每個工作負載的 RTO 和 RPO。

1.  考慮上一個步驟中為每個工作負載確定的 RTO 和 RPO。讓工作負載的業務和技術團隊參與，以判斷是否應調整目標。例如，業務利害關係人可判斷是否需要更嚴格的目標。或者，技術團隊可以判斷應修改目標，以透過可用的資源和技術限制來實現目標。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [REL09-BP04 定期執行資料復原以驗證備份的完整性和程序](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html) 
+  [REL12-BP01 使用程序手冊調查失敗](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html) 
+  [REL13-BP02 使用定義的復原策略來滿足復原目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html) 
+  [REL13-BP03 測試災難復原實作以驗證實作](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html) 

 **相關文件：**
+  [AWS 架構部落格：災難復原系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS 上工作負載的災難復原：在雲端中復原 (AWS 白皮書)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [使用 AWS Resilience Hub 管理彈性政策](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) 
+  [APN 合作夥伴：可協助進行災難復原的合作夥伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace：可用於災難復原的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **相關影片：**
+  [AWS re:Invent 2018：適用於多區域主動-主動應用程式的架構模式](https://youtu.be/2e29I3dA8o4) 
+  [ 上工作負載的災難復原AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)