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