關於可靠與復原從屬端雲端拓樸實務
可靠的應用程式包括：
- 從失敗狀態恢復並正常復原，完全復原之前，它們會繼續以最短停止工作時間和資料遺失的方式運作。
- 高可用性 (HA)，並以狀況良好的狀態執行，不會有重大的停止工作時間。
- 透過良好的災害復原 (DR) 設計，受保護的區域失敗。
瞭解這些元素如何共同運作，以及它們如何影響成本，對於建置可靠的應用程式而言非常重要。它可以協助您判斷可接受多少停止工作時間、業務的潛在成本，以及復原期間所需的功能。
可靠度的 Architect
建立雲端應用程式時，請使用下列各項建立可靠性。
- 定義需求。
根據您對雲端和業務需求帶來的工作負載，定義可用性和復原需求。
- 套用架構最佳做法。
遵循經過認證的課堂練習、識別架構中可能的失敗點，以及判斷應用程式回應失敗的方式。
- 使用模擬測試並強制容錯移轉。
模擬錯誤、觸發程式強制容錯移轉，以及測試偵測和從這些失敗項目復原。
- 一致地部署應用程式。
使用可靠且可重複的程序釋出至生產環境，並儘可能自動化。
- 監督應用程式狀況。
偵測失敗項目、監督可能的失敗項目指標，以及測量應用程式的狀況。
- 管理失敗和災害。
識別失敗發生的時間，並根據建立的策略決定如何處理它。
定義需求
根據您對雲端和業務需求帶來的工作負載，定義可用性和復原需求。
識別您的業務需求，並將可靠性計劃與其相符時，請考慮下列事項：
- 識別工作負載及其需求
工作 負載是一種不同的功能或作業，會根據商業邏輯和資料儲存需求，以邏輯方式與其他工作負載區隔。每個工作負載都有不同的可用性、擴展性、資料一致性以及災害復原需求。
- 決定使用樣式
使用應用程式在要求中扮演角色的方式。識別嚴重和非重要期間的需求差異。例如，處理月底處理的應用程式不會在月底失敗，但可能會在其他時間處理失敗。為了確保正常運作時間，可以在重要期間新增額外的元件或冗餘，並在它們不再新增值時移除。
- 識別重要元件與路徑
並非系統的所有元件都很重要。例如，您可能有一個新增增增量值的選擇性元件，但工作負載可以在必要時執行。瞭解這些元件在您工作負載之重要部分的位置，反之亦然。這有助於設定可用性和可靠性測量結果的範圍，以及規劃復原策略來設定最高重要性元件的優先順序。
- 識別外部相依性和順流失敗的影響
如果您的工作負載相依於外部服務，這些相依性中的失敗可能會對工作負載的使用狀態造成負面影響。導入分離整合的方式以確保下游失敗。
- 判斷工作負載可用性需求
高可用性 (HA) 通常是根據正常運作時間目標來定義。執行處理的 99% HA 目標表示一年中的某個特定資源可供使用 3.65 天。建構 Oracle Cloud Infrastructure (OCI) 以提供高可用性的環境。OCI 會為其每個服務發布「服務層次協議 (SLA)」，此服務描述 Oracle 的正常運作時間承諾和這些服務的連線，您應該複查它們以瞭解它們如何符合您的需求。OCI 上的部分服務具有高層次的 HA 內建服務，尤其是 Oracle 管理的服務，例如自治式資料庫。若要確保應用程式架構符合您的業務需求，請為每個工作負載 (包括外部相依性) 定義目標 SLA。除了應用程式相依性之外，也說明符合可用性需求的成本與複雜性。
- 建立您的復原測量結果—復原時間目標 (RTO) 和復原點目標 (RPO)
RTO 是應用程式在災害事故之後可供使用的最長可接受時間。
RPO 是災害期間可接受的資料遺失持續時間上限。
若要衍生這些值，請進行風險評估，並確定您瞭解組織中停機時間或資料遺失的成本與風險。
- 定義災害
具備完善的災害復原計畫和需求非常重要，但這類事件的主席本質可以建立混淆。瞭解哪些情況構成您的業務災害、識別災害期間需要的主要角色，以及建立完善定義的通訊計畫以起始災害回應。
應用建築最佳做法
設計架構時，專注於實行符合您業務需求的實行範圍、識別失敗點，以及將失敗範圍降至最低。
請考量下列最佳作法：
- 判斷失敗發生的位置
分析架構以識別您的應用程式可能會經歷的失敗類型、每個應用程式的潛在效果以及可能的復原策略。
- 根據您的 HA 和 DR 需求，判斷所需的冗餘層次
每個工作負載所需的冗餘層次，視您的業務需求和因子而定，可達到應用程式的整體成本。
- 擴展性的設計
雲端應用程式必須能夠擴展以配合使用狀況的變更。從離散元件開始，並設計應用程式，儘可能自動回應以載入變更。在設計期間請記住縮放限制，以便日後輕鬆擴充。
- 使用負載平衡來分送要求
負載平衡會從循環移除狀況不良的執行處理，將應用程式的要求分配至狀況良好的服務執行處理。外部化狀態資訊會讓後端擴展對一般使用者成為透明。如果在階段作業中追蹤狀態，可能需要黏性。
- 將可用性和復原能力需求建置到您的設計中
復原能力是系統從失敗復原並繼續運作的能力。使用狀態是系統功能性和工作時間的比例。實行高可用性最佳做法，例如避免單點失敗，以及依服務層次目標分解工作負載。使用資料層的標準功能 (例如應用程式連續性和非同步交易) 來確保可用性和復原能力。
- 導入借方
設計您的解決方案以符合所識別的 RTO 與 RPO 需求。確定您可以在 RTO 內讓 DR 解決方案的所有元件上線。保護您的資料，讓您可以滿足 RPO。儲存、備份和複製資料的方式非常重要。
- 備份您的資料
即使使用完全複製的 DR 環境，一般備份仍然很重要。定期備份和驗證資料，並確定沒有單一使用者帳戶可以存取生產和備份資料。
- 選擇應用程式資料的複製方法
您的應用程式資料會儲存在各種資料存放區中，而且可能有不同的可用性需求。評估每種資料存放區類型的複製方法和位置，以確保它們符合您的 HA 需求和 RPO。
- 瞭解容錯移轉的影響以及對災害整備的影響
您是否需要為複製建立另一個區域，以符合您的工作負載需求？您是否需要擔心故障回復時的資料一致性？
- 記錄並測試您的容錯移轉和容錯回復處理作業
清楚記錄容錯移轉至新資料存放區的指示，並定期進行測試以確保它們正確且易於遵循。
- 確定您的資料復原計畫符合您的 RTO
請確定您的備份與複寫策略提供符合 RTO 的資料復原時間，以及 RPO。說明應用程式使用的所有資料類型，包括參照資料、檔案和資料庫。
- 備份您的資料
測試模擬與強制容錯移轉
測試可靠性需要測量端對端工作負載在僅間歇性發生之失敗狀況下的執行方式。
- 透過觸發實際失敗或模擬它們來測試常見的失敗案例
您可以使用錯誤插入測試來測試常見的分析藍本 (包括失敗組合) 和復原時間。
- 識別只在載入時發生的失敗
測試尖峰負載、使用儘可能接近實際環境執行資料的實際環境執行資料或綜合資料，以瞭解應用程式在真實條件下的行為。
- 執行災害復原鑽研
就地測試災害復原計畫，並定期進行測試以確保其運作。
- 執行容錯移轉和容錯回復測試
確定應用程式的相依服務容錯移轉，並以正確的順序容錯移轉。
- 執行模擬測試
測試真實安全案例可以反白需要處理的問題。情境應可控制且不受業務中斷。通知模擬測試計畫的管理。
- 測試健康探測
設定負載平衡器和流量管理程式的狀況探測，以檢查重要的系統元件。測試它們以確定它們正確回應。
- 測試監督系統
請確定監督系統可靠地報告重要資訊和準確的資料，以協助識別潛在的失敗。
- 在測試案例中包含第三方服務
除了復原之外，第三方服務中斷導致測試可能的失敗點。
- 瞭解測試期間發生的問題
如果測試揭露問題或差距，請透過新增其他監視或調整作業流程來確定已識別並解決這些問題或差距。
一致地部署應用程式
部署包括啟動設定 Oracle Cloud Infrastructure (OCI) 服務和資源、部署應用程式程式碼，以及套用組態設定值。更新可能涉及所有三個工作或這些工作的子集。
- 自動化應用程式部署程序
儘可能自動執行多項處理。儘可能消除生產環境中的手動部署，但這在較低的環境中可能可以提升速度和彈性。
- 在部署前運用自動化來測試您的程式碼
測試錯誤、安全漏洞、功能、效能以及整合對於將一般使用者發現的問題降到最低非常重要。測試失敗應防止將程式碼核發至生產環境。
- 設計您的釋出處理作業以達到最大可用性
如果您的釋出處理作業要求服務在建置期間離線，您的應用程式要等到重新上線後才能夠使用。充分利用平台暫存與生產功能。如果可能，請將新建置釋出至使用者的子集，以監督早一小時的失敗。
- 有倒回計畫可供建置
將倒回處理作業設計成返回上一個已知良好版本，並在部署失敗時將停止工作時間降到最低。部署失敗時將倒回自動化，可防止不必要的停止工作時間。
- 日誌和稽核部署
如果您使用暫存的部署技術，表示您的應用程式有多個版本在生產環境中執行。實行強大的記錄日誌策略，儘可能擷取版本特定的資訊。
- 記錄應用程式版本處理作業
清楚定義並記錄您的釋出處理作業，並確保整個作業小組都可以使用該處理作業。
監督應用程式狀況
在您的應用程式中實行監督和警示的最佳做法，以便偵測失敗並警示操作員進行修正。
- 實行服務呼叫追蹤
基準效能資料有助於提供趨勢資料，這些資料在影響使用者之前，可用來主動識別效能問題。
- 實行狀況探測
從應用程式外部定期執行它們，以識別應用程式狀況和效能的降低。這些探測不應只是靜態頁面測試，它們應該反映全方位的應用程式狀況。
- 檢查長時間執行的工作流程
提早擷取問題可將回復整個工作流程的需求降至最低，或執行多個補償異動。
- 維護系統、應用程式及稽核日誌
使用集中式記錄日誌服務來儲存日誌。
- 設定提前警告系統
識別應用程式狀況的關鍵績效指標 (KPI)，例如暫時異常狀況和遠端呼叫延遲，並為每個項目設定適當的臨界值。達到臨界值時傳送警示給作業。
- 訓練多個操作員以監督應用程式及執行手動復原步驟
確定至少有一個訓練的操作員在作用中。
管理故障與災害
建立復原計畫，並確定它涵蓋資料回復、網路中斷、相依服務失敗以及全區域服務中斷。請考量您的 VM、儲存體、資料庫以及您復原策略中的其他 OCI 服務。
- 規劃 OCI 支援互動
在需要之前，請先建立聯絡 OCI 支援的處理作業。
- 記錄和測試災害復原計畫
撰寫反映應用程式失敗之商業影響的災害復原計畫。儘可能自動執行復原處理作業，並記錄任何手動步驟。定期測試災害復原程序以驗證和改善計畫。
- 瞭解 DR 協調所需的主要角色
請確定 DR 投入力已正確協調，且應用程式已根據業務價值排列優先順序。
- 準備應用程式失敗
準備某個範圍的失敗項目，包括自動處理的錯誤、造成簡化功能的錯誤，以及造成應用程式無法使用的錯誤。應用程式應通知使用者暫時問題。
- 從資料損毀復原
如果資料存放區發生失敗，請在存放區再次可用時 (特別是複製資料時) 檢查資料不一致。從備份回復損毀的資料。
- 從網路中斷復原
您可以使用快取的資料，以簡化的應用程式功能在本機執行。如果沒有，請考慮應用程式停止工作時間或容錯移轉至另一個區域。將您的資料儲存在替代位置，直到還原連線為止。
- 從相依服務失敗復原
判斷哪些功能仍然可用，以及應用程式應如何回應。
- 從全區域服務中斷復原
全區域服務中斷未常見，但您應該策略解決這些問題，尤其是針對關鍵應用程式。您可以將應用程式重新建置到另一個區域或重新分配流量。
- 從 DR 測試瞭解並改善流程
請確定已擷取 DR 測試期間發生的任何問題，並在未來測試或容錯移轉中解決修正這些問題的計畫。