設計備份和復原
如 Tailwind Traders 這類的組織需要其任務關鍵性應用程式提供高度的可靠性。 為了達到內部部署型應用程式所需的可靠性，其通常會購買更多運算資源，例如伺服器和儲存體。 藉由購買更多運算資源，組織就可以在其內部部署基礎結構中建置備援。
任何任務關鍵性應用程式及其相關聯的資料能在失敗後復原 (理想情況是復原到失敗點) 也是不可或缺的。 此復原能力通常會透過備份、還原元件和程序來提供。 對於將應用程式裝載到 Azure 的組織，或使用混合式應用程式部署的組織，則還要考慮其他因素和選項。
可靠的應用程式具有以下特點：
能從元件失敗中復原。
有高度可用性，而且可以在狀況良好的狀態下執行，不會有顯著的停機時間。
若要實現所需的復原能力和高可用性，首先您必須定義需求。
注意
本課程模組會使用復原一詞，來表示系統能夠正常處理與復原意外和惡意的失敗。
定義需求
定義需求會牽涉到：
識別商務需求。
建置復原計畫以解決這些需求。
使用下列考量資料表來提供此處理序的指導。
| 考量 | 說明 |
|---|---|
| 您的工作負載及其使用量為何？ | 工作負載是指不同的功能或工作，可根據商務邏輯和資料儲存體需求，以邏輯方式與其他工作區隔。 每個工作負載在可用性、延展性、資料一致性和災害復原方面，可能都有不同的需求。 |
| 工作負載的使用模式為何？ | 使用模式可供判斷您的需求。 用來識別重要和非重要期間的需求差異。 若要確保執行時間不中斷，應在數個區域間規劃備援，以因應其中一個區域失敗的狀況。 相反地，若要在非關鍵期間降低成本，您可以在單一區域中執行應用程式。 |
| 可用性計量為何？ | 平均復原時間 (MTTR) 和平均故障間隔時間 (MTBF) 是常用的計量。 MTBF 是元件可在兩次中斷之間持續執行的合理預期時間長度。 MTTR 是失敗後還原元件所需的平均時間。 您可以使用這些計量來判斷需要新增備援的區域，以及判斷客戶的服務等級協定 (SLA)。 |
| 復原計量為何？ | 復原時間目標 (RTO) 是其中一個應用程式在發生事件後可以保持無法使用狀態的最大可接受時間。 復原點目標 (RPO) 是在災害期間可接受的最大資料遺失時間長度。 另請考慮復原層級目標 (RLO)。 此計量會決定復原的細微性。 換句話說，您是否必須能夠復原伺服器陣列、Web 應用程式、網站，還是僅復原特定項目。 若要判斷這些值，請進行風險評估。 請確定您了解組織中停機或資料遺失的成本和風險。 |
| 工作負載可用性目標為何？ | 若要確保應用程式架構符合您的業務需求，請定義每個工作負載的目標 SLA。 除了應用程式相依性之外，還必須有符合可用性需求的成本與複雜度。 |
| 您的 SLA 是什麼？ | 在 Azure 中，SLA 會描述 Microsoft 對執行時間與連線能力的承諾。 如果特定服務的 SLA 是 99.9%，則您可以預期 99.9% 的時間皆可提供服務。 |
提示
如果在高度可用的情況中，有任何重要元件的 MTTR 超過系統 RTO，則系統中的失敗可能會導致無法接受的業務中斷。 換句話說，您無法在定義的 RTO 內還原系統。
回答上述問題，以便為解決方案中的每個工作負載定義您自己的目標 SLA。 這有助於確保架構符合您的商務需求。 例如，如果工作負載需要 99.99% 的執行時間，但需依附 99.9% SLA 的服務，則該服務就不能是系統中的單一失敗點。
在定義好復原需求後，便可開始選取適當的復原技術。