本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 階段 1：設定目標
了解需要多少彈性層級，以及如何衡量它是*設定目標*階段的基礎。如果您沒有目標且無法測量，就很難改善。
並非所有應用程式都需要相同等級的彈性。當您設定目標時，請考慮所需的層級，以便進行正確的投資和權衡。一個很好的比喻是汽車：它有四個輪胎，但只攜帶一個備用輪胎。在乘車期間取得多個平面輪胎的機會很低，而擁有額外的備用設備可能會脫離其他功能，例如貨物空間或燃料效率，因此這是合理的取捨。
定義目標後，您會在稍後階段 ([階段 2：設計和實作](stage-2.md) 和[階段 4：操作） ](stage-4.md)實作可觀測性控制，以了解目標是否達成。
## 映射關鍵應用程式
定義彈性目標不應只是技術對話。相反地，請從業務導向的重點開始，以了解應用程式應該提供什麼，以及受損的後果。然後，對業務目標的這種理解會層疊到架構、工程和操作等領域。您定義的任何彈性目標都*可能*套用到所有應用程式，但目標的測量方式通常會根據應用程式的功能而有所不同。您可能正在執行對業務至關重要的應用程式，如果此應用程式受損，您的組織可能會損失重大收入或聲譽受損。或者，您可能有另一個不重要的應用程式，可以容忍一些停機時間，而不會對組織執行業務的能力產生負面影響。
例如，假設零售公司的訂單管理應用程式。如果訂單管理應用程式的元件受損且未正確執行，則新銷售將不會通過。此零售公司也為其位於其中一棟建築物的員工設有咖啡廳。咖啡廳有一個線上選單，員工可以在靜態網頁上存取。如果此網頁無法使用，有些員工可能會抱怨，但不一定會對公司造成財務損害。根據此範例，企業可能會選擇為訂單管理應用程式設定更積極的彈性目標，但不會進行重大投資以確保 Web 應用程式的彈性。
識別最關鍵的應用程式、最努力的領域，以及進行權衡的領域，與能夠測量應用程式在生產環境中的彈性一樣重要。若要進一步了解受損的影響，您可以執行[業務影響分析 (BIA)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/business-impact-analysis-and-risk-assessment.html)。BIA 提供結構化和系統性的方法，以識別關鍵業務應用程式並排定優先順序、評估潛在風險和影響，以及識別支援的相依性。BIA 可協助量化組織最重要應用程式的*停機時間成本*。此指標有助於概述如果特定應用程式受損且無法完成其函數，將花費多少費用。在上述範例中，如果訂單管理應用程式受損，零售業務可能會損失重大收入。
## 映射使用者案例
在 BIA 過程中，您可能會發現應用程式負責多個業務職能，或業務職能需要多個應用程式。使用先前的零售公司範例，訂單管理函數可能需要單獨的應用程式來結帳、提升和定價。如果一個應用程式失敗，業務和與公司互動的使用者可能會感受到影響。例如，公司可能無法新增新訂單、提供促銷和折扣的存取權，或更新其產品的價格。訂單管理函數所需的這些不同函數可能會依賴多個應用程式。這些函數也可能有多個外部相依性，這使得實現純粹以元件為中心的彈性的過程過於複雜。處理此案例的更好方法是專注於[使用者案例](https://en.wikipedia.org/wiki/User_story)，其中概述了使用者在與一個應用程式或一組應用程式互動時預期的體驗。
專注於使用者案例可協助您了解哪些客戶體驗部分最重要，因此您可以建立機制來防範特定威脅。在先前的範例中，一個使用者案例可能是結帳，這涉及結帳應用程式，並且與定價應用程式有相依性。另一個使用者案例可能是檢視涉及提升應用程式的提升。映射最關鍵的應用程式及其使用者案例後，您可以開始定義用於測量這些使用者案例彈性的指標。這些指標可以套用至整個產品組合或個別使用者案例。
## 定義測量
[復原點目標 RPOs)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/recovery-objectives.html)、[復原時間目標 RTOs)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/recovery-objectives.html) [和服務層級目標 (SLOs)](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-dependencies.html) 是標準產業測量，用於評估指定系統的彈性。RPO 是指企業在發生故障時可容忍的資料遺失量，而 RTO 是在中斷後必須再次提供應用程式的速度。這兩個指標是以時間單位測量：秒、分鐘和小時。您也可以測量應用程式正常運作的時間量；也就是說，它會依設計執行其函數，並可供其使用者存取。這些 SLOs會詳細說明客戶將接收的預期服務水準，並透過指標進行測量，例如在不到一秒的回應時間內 （例如，99.99% 的請求將每個月收到回應） 未發生錯誤的服務請求百分比 (%)。 RPO 和 RTO 與災難復原策略相關，假設應用程式操作和復原程序將會中斷，範圍從還原備份到重新導向使用者流量。透過實作高可用性控制來解決 SLOs，這通常會減少應用程式的停機時間。
SLO 指標通常用於服務層級協議 (SLAs) 的定義，這是服務提供者與最終使用者之間的合約。SLAs 通常附帶財務承諾，並概述如果不符合這些協議，供應商需要支付的處罰。不過，SLA 不是彈性狀態的測量，而提高 SLA 並不會讓您的應用程式更具彈性。
您可以開始根據 SLOs、RPOs 和 RTOs 設定目標。在您定義彈性目標並清楚了解 RPO 和 RTO 目標之後，您可以使用 [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/)來執行架構的評估，以發現與彈性相關的潛在弱點。 AWS Resilience Hub 會根據 AWS Well-Architected Framework 最佳實務評估應用程式架構，並在具體需要改進的內容中分享修補指引，以滿足您定義的 RTO 和 RPO 目標。
## 建立其他測量
RPO、RTO 和 SLOs 是彈性的良好指標，但您也可以從業務角度思考目標，並定義應用程式功能的目標。例如，您的目標是：*如果我的前端和後端之間的延遲增加 40%，每分鐘成功訂單將維持在 98% 以上。 *或者：*即使特定元件遺失，每秒啟動的串流仍會保持在與平均值的標準差內。*您也可以建立目標，以縮短所有已知故障類型的平均復原時間 (MTTR)；例如：*如果發生任何這些已知問題，復原時間將減少 x%*。建立符合業務需求的目標可協助您預測應用程式應容忍的失敗類型。它還可協助您識別方法來降低應用程式受損的可能性。
如果您考慮在遺失為應用程式提供動力的執行個體的 5% 時繼續運作的目標，您可以判斷應用程式應預先擴展，或能夠快速擴展，以支援在該事件期間造成的額外流量。或者，您可以判斷應該利用不同的架構模式，如[階段 2：設計和實作](stage-2.md)一節所述。
您也應該針對特定業務目標實作可觀測性措施。例如，您可以追蹤*平均訂單率*、*平均訂單價格*、*平均訂閱數量*或其他指標，這些指標可以根據您應用程式的行為，提供業務運作狀態的洞見。透過為您的應用程式實作可觀測性功能，您可以建立警示，並在這些指標超過您定義的界限時採取動作。可觀測性會在[階段 4：操作](stage-4.md)區段中詳細說明。