本文說明災難復原 (DR) 和業務持續性規劃，並以持續整合與持續推送軟體更新 (CI/CD) 為背景。此外，這份指南也提供指引，說明如何制定完整的業務續航力計畫 (BCP) 時，找出並減輕依附元件的影響。無論您使用哪些工具和程序，都可以將這份文件中的最佳做法套用至 BCP。本文假設您熟悉軟體發布和營運週期、CI/CD 和 DR 的基本概念。
持續整合/持續推送軟體更新管道負責建構及部署重要業務應用程式。因此，與應用程式基礎架構一樣，CI/CD 程序也需要規劃 DR 和業務持續性。思考 CI/CD 的 DR 和業務持續性時，請務必瞭解軟體交付和作業週期的每個階段，以及這些階段如何共同運作，形成整體程序。
下圖簡化了軟體開發和營運週期，包含下列三個階段：
- 開發內部迴圈：編寫程式碼、試用及提交
- 持續整合：建構、測試及安全性
- 持續推送軟體更新：升級、推出、復原及指標
這張圖也顯示，Google Kubernetes Engine (GKE)、Cloud Run 和 Google Distributed Cloud 都是軟體開發和作業週期的可能部署目標。
在整個軟體開發和營運週期中，您需要考量災難對團隊營運和維護重要業務應用程式能力的影響。這麼做有助於判斷 CI/CD 工具鍊中工具的復原時間目標 (RTO) 和復原點目標 (RPO)。
此外，大多數機構都有許多不同的 CI/CD 管道，適用於不同的應用程式和基礎架構集，每個管道都有獨特的 DR 和業務持續性規劃需求。您為管道選擇的復原策略，取決於工具的 RTO 和 RPO。舉例來說，有些管道比其他管道更重要，因此 RTO 和 RPO 需求較低。請務必在 BCP 中找出對業務至關重要的管道，並在實作測試和執行復原程序的最佳做法時，多加留意這些管道。
由於每個 CI/CD 程序及其工具鍊都不盡相同，本指南的目標是協助您找出 CI/CD 程序中的單點故障，並制定全面的 BCP。以下各節將協助您完成下列操作：
- 瞭解如何從影響 CI/CD 程序的 DR 事件中復原。
- 判斷 CI/CD 程序中工具的 RTO 和 RPO。
- 瞭解 CI/CD 程序的故障模式和依附元件。
- 為工具鍊中的工具選擇適當的復原策略。
- 瞭解為 CI/CD 程序導入 DR 復原計畫的一般最佳做法。
瞭解業務持續性程序
制定 BCP 至關重要，有助於確保貴機構在發生中斷和緊急情況時，仍能繼續營運。這項功能可協助貴機構的 CI/CD 程序迅速恢復正常運作。
以下各節將概略說明建立有效 BCP 的階段和步驟。雖然這些步驟大多適用於計畫管理和 DR，但某些步驟與規劃 CI/CD 程序的業務持續性更相關。以下各節會特別說明與規劃 CI/CD 業務持續性相關的步驟，這些步驟也是本文其餘指引的基礎。
啟動和規劃
在這個初期階段，技術和業務團隊會攜手合作，為營運持續規劃程序及其持續維護作業奠定基礎。這個階段的主要步驟包括：
- 主管階層支持：確保高階管理層支持並推動 BCP 的開發。指派專責團隊或個人負責監督計畫。
- 資源分配：分配開發及實施 BCP 所需的預算、人員和資源。
- 範圍和目標：定義 BCP 的範圍和目標。 判斷哪些業務程序至關重要，需要在計畫中處理。
- 風險評估：找出可能導致業務中斷的潛在風險和威脅，例如天災、網路安全漏洞或供應鏈中斷。
- 影響分析：評估這些風險評估結果對業務營運、財務、聲譽和顧客滿意度的潛在影響。
業務影響分析
在這個階段，業務和技術團隊會分析中斷對客戶和機構的業務影響，並優先復原重要業務功能。在建構和部署程序的不同階段，這些業務功能會由不同的工具執行。
業務影響分析是 CI/CD 業務持續性規劃流程的重要階段，特別是識別重要業務功能和工具依附元件的步驟。此外，瞭解 CI/CD 工具鍊 (包括其依附元件，以及在 DevOps 生命週期中的運作方式)，是為 CI/CD 程序開發 BCP 的基礎建構區塊。
業務影響分析階段的主要步驟包括：
- 重要功能：判斷必須優先復原的關鍵業務功能和程序。舉例來說，如果您認為部署應用程式比執行單元測試更重要，就會優先復原應用程式部署程序和工具。
- 依附元件：找出可能影響重要功能復原的內部和外部依附元件。依附元件對於確保 CI/CD 程序透過工具鍊持續運作，尤其重要。
- 復原時間目標 (RTO) 和復原點目標 (RPO)：為每個重要功能定義可接受的停機時間和資料遺失限制。這些 RTO 和 RPO 目標與業務功能對持續營運的重要性有關，且涉及業務功能順利運作所需的特定工具。
策略制定
在這個階段，技術團隊會為重要業務功能制定復原策略，例如還原作業和資料，以及與供應商和利害關係人溝通。制定策略也是規劃 CI/CD 程序業務持續性的重要環節，特別是為重要功能選擇高階復原策略的步驟。
策略開發階段的主要步驟包括：
- 復原策略：制定策略，以還原重要功能。這些策略可能包括替代地點、遠端工作或備份系統。這些策略與各項重要功能的 RTO 和 RPO 目標息息相關。
- 供應商和供應鏈關係：與主要供應商和供應鏈建立通訊和協調計畫，確保供應鏈在發生中斷時仍能運作。
- 資料和 IT 復原：制定資料備份、IT 系統復原和網路安全措施計畫。
- 溝通計畫：制定明確的溝通計畫，在服務中斷期間和中斷後，與內部和外部利害關係人溝通。
計畫開發
在這個階段，主要步驟是記錄 BCP。技術團隊會記錄各項重要功能的工具、程序、復原策略、基本原理和程序。此外，計畫開發也包括為員工編寫逐步操作說明，讓他們在發生中斷時遵循。在實施和持續維護期間，可能需要對計畫進行變更，因此應將計畫視為動態文件。
導入作業
在這個階段，您會使用技術團隊建立的 BCP，為機構實作計畫。實作包括員工訓練和 BCP 的初步測試。實作也包括在發生中斷時使用計畫，以恢復正常運作。主要實作步驟包括：
- 初步測試和訓練：記錄 BPC 後，透過模擬和演練進行測試，找出缺口並提升成效。訓練員工在發生中斷事件時的角色和職責。
- 啟動：發生中斷時，根據預先定義的觸發條件和程序啟動 BCP。
- 溝通：讓利害關係人掌握情況和復原工作進度。
維護與審查
這個階段並非只會發生一次的定義程序，而是持續進行的作業，應成為 CI/CD 作業的正常環節。請務必定期檢討、測試及更新貴機構的 BCP，確保在發生中斷時，BCP 仍能發揮作用。維護和審查的主要步驟包括：
- 定期更新：定期審查及更新 BCP，確保內容有效且符合現況。如果人員、技術或業務程序有異動，請務必更新。
- 經驗教訓：每次中斷或測試後，請進行簡報，找出經驗教訓和需要改進的領域。
- 法規遵循：確保 BCP 符合業界法規和標準。
- 員工意識：持續向員工說明 BCP，以及他們在執行 BCP 時的角色。
為 CI/CD 建構業務持續性程序
本節提供具體指引，協助您建構專門用於還原 CI/CD 作業的 BCP。規劃 CI/CD 的業務持續性流程時，首先要徹底瞭解 CI/CD 工具鍊，以及工具鍊與軟體交付和作業生命週期的關係。以這項瞭解為基礎，您就可以規劃貴機構如何從中斷中恢復 CI/CD 作業。
如要為 CI/CD 程序建立健全的業務持續性程序，請採取下列主要步驟：
以下各節將詳細說明每個步驟。
瞭解工具鍊
CI/CD 工具鍊是由許多不同的個別工具組成，工具的可能組合似乎無窮無盡。不過，瞭解 CI/CD 工具鍊及其依附元件，是規劃 CI/CD 業務持續性的關鍵。CI/CD 流程的核心任務是將程式碼交付給實際工作環境系統，供使用者使用。在整個過程中，會使用許多不同的系統和資料來源；瞭解這些資料來源和依附元件，對於制定 BCP 至關重要。如要開始制定 DR 策略，首先需要瞭解 CI/CD 程序中涉及的不同工具。
為協助您瞭解如何評估自己的工具鍊及制定 BCP，本文將以在 GKE 上執行的企業 Java 應用程式為例。下圖顯示工具鍊中的第一層資料和系統。第一層由您直接控管，包括：
- 應用程式的來源
- CI/CD 平台中的工具，例如 Cloud Build 或 Cloud Deploy
- 不同工具的基本互連
如圖所示，範例應用程式的主要流程如下：
- 開發內部迴圈中的程式碼開發事件會觸發 Cloud Build。
- Cloud Build 會從來源控管存放區提取應用程式原始碼。
- Cloud Build 會找出建構設定檔中指定的任何必要依附元件，例如 Artifact Registry 中 Java 存放區的第三方 JAR 檔案。接著，Cloud Build 會從來源位置提取這些依附元件。
- Cloud Build 會執行建構作業，並進行必要的驗證，例如靜態分析和單元測試。
- 如果建構成功，Cloud Build 會建立容器映像檔，並將其推送至 Artifact Registry 中的容器存放區。
- 系統會觸發 Cloud Deploy 管道，管道會從存放區提取容器映像檔，並將其部署至 GKE 環境。
如要瞭解 CI/CD 程序中使用的工具，建議您建立圖表，顯示 CI/CD 程序和使用的工具，類似於本文中的範例。然後使用圖表建立表格，擷取 CI/CD 工具鍊的重要資訊，例如程序階段、工具用途、工具本身，以及工具故障會影響的團隊。下表列出工具鍊中的工具，並指出這些工具對應的 CI/CD 程序階段。因此，這份表格有助於全面瞭解工具鍊及其運作方式。
下表將先前提及的企業應用程式範例，對應至圖表中的各項工具。為提供更完整的工具鍊對應範例，這些表格也包含圖表中未提及的其他工具，例如安全性工具或測試工具。
第一個表格對應於 CI/CD 流程的 CI 階段所使用的工具：
| 持續整合 | 來源 | 使用的工具 | 主要使用者 | 使用方式 |
|---|---|---|---|---|
| 階段：原始碼控管 |
|
|
|
|
| 階段：建構 |
|
開發人員 |
|
|
| 階段：測試 |
|
開發人員 |
在一致的隨選平台上執行單元測試和整合測試。 |
|
| 階段：安全性 |
|
|
掃描程式碼是否有安全性問題。 |
第二個表格著重於 CI/CD 程序 CD 階段使用的工具：
| 持續部署 | 來源 | 使用的工具 | 主要使用者 | 使用方式 |
|---|---|---|---|---|
| 階段：部署 | 部署設定檔 |
|
在安全一致的平台上，自動化部署作業，以升級、核准及管理流量。 |
|
| 階段：測試 |
|
|
開發人員 |
測試整合和效能，確保品質和實用性。 |
| 階段：記錄 |
|
|
保留記錄，以利觀察及排解問題。 |
|
| 階段：監控 | 監控設定檔，包括：
|
|
|
隨著您持續處理 BCP，並對 CI/CD 工具鍊有更深入的瞭解，可以更新圖表和對應表。
找出資料和依附元件
完成基礎目錄和 CI/CD 工具鍊的對應後，下一個步驟是擷取中繼資料或設定的任何依附元件。實作 BCP 時，請務必清楚瞭解 CI/CD 工具鍊中的依附元件。依附元件通常可分為兩類：內部 (一階) 依附元件和外部 (二階或三階) 依附元件。
內部依附元件
內部依附元件是工具鍊使用的系統，您可直接控管。團隊也會選取內部依附元件。 這些系統包括 CI 工具、金鑰管理儲存空間和來源控制系統。您可以將這些系統視為工具鍊本身的下一層。
舉例來說，下圖說明內部依附元件在工具鍊中的位置。這張圖是先前範例 Java 應用程式的第一層工具鍊圖的擴充版本，也包含工具鍊的內部依附元件：應用程式憑證、deploy.yaml 檔案和 cloudbuild.yaml 檔案。
這張圖表顯示，為了在範例 Java 應用程式中順利運作，Cloud Build、Cloud Deploy 和 GKE 等工具需要存取非工具鍊的依附元件，例如 cloudbuild.yaml、deploy.yaml 和應用程式憑證。分析自己的 CI/CD 工具鍊時，請評估工具是否能自行執行，或是否需要呼叫其他資源。
請考量範例 Java 應用程式的內部依附元件 (如文件所述)。憑證會儲存在 Secret Manager 中，但這並非工具鍊的一部分，應用程式必須有憑證才能在部署時啟動。因此，應用程式憑證會做為 GKE 的依附元件。此外，即使 deploy.yaml 和 cloudbuild.yaml 檔案與應用程式碼一起儲存在來源控管中，也請務必將這些檔案納入依附元件，因為這些檔案會定義該應用程式的 CI/CD 管道。
範例 Java 應用程式的 BCP 應考量這些對 deploy.yaml 和 cloudbuild.yaml 檔案的依附元件，因為在復原程序中，工具就位後會重新建立 CI/CD 管道。此外，如果這些依附元件遭到入侵，即使工具本身仍可運作，管道的整體功能也會受到影響。
外部依附元件
外部依附元件是工具鍊運作時所依賴的外部系統，您無法直接控管這些元件。外部依附元件是您選取的工具和程式設計架構所致。您可以將外部依附元件視為比內部依附元件低一層。外部依附元件的範例包括 npm 或 Maven 存放區，以及監控服務。
雖然外部依附元件不在您的控管範圍內，但您可以將其納入 BCP。下圖更新了 Java 應用程式範例，除了內部依附元件外，還包含外部依附元件：Maven Central 中的 Java 程式庫，以及 Docker Hub 中的 Docker 映像檔。Java 程式庫由 Artifact Registry 使用，Docker 映像檔則由 Cloud Build 使用。
從圖中可以看出，外部依附元件對 CI/CD 程序非常重要：Cloud Build 和 GKE 都依賴 Maven 和 Docker 這兩項外部服務，才能順利運作。評估自己的工具鍊時，請記錄工具需要存取的外部依附元件，以及處理依附元件中斷的程序。
在 Java 應用程式範例中，Java 程式庫和 Docker 映像檔無法直接控管，但您仍可將這些項目及其復原程序納入 BCP。舉例來說，請考慮 Maven 中的 Java 程式庫。雖然程式庫儲存在外部來源，但您可以建立程序，定期將 Java 程式庫下載並重新整理至本機 Maven 存放區或 Artifact Registry。這樣一來，復原程序就不必依賴第三方來源的可用性。
此外，請務必瞭解外部依附元件可能有多個層級。舉例來說，您可以將內部依附元件使用的系統視為二階依附元件。這些二階依附元件可能會有自己的依附元件，也就是三階依附元件。請注意，您可能需要在 BCP 中記錄並說明二階和三階外部依附元件，才能在發生中斷時恢復作業。
決定 RTO 和 RPO 目標
瞭解工具鍊和依附元件後，請為工具定義 RTO 和 RPO 目標。CI/CD 程序中的工具各自執行不同的動作，對業務產生不同的影響。因此，請務必根據業務影響程度，調整業務功能的 RTO 和 RPO 目標優先順序。舉例來說，透過 CI 階段建構新版應用程式的影響，可能比透過 CD 階段部署應用程式小。因此，部署工具的 RTO 和 RPO 目標可能比其他功能更長。
下方的四象限圖表是一般範例，說明如何為 CI/CD 工具鍊的每個元件決定 RTO 和 RPO 目標。這張圖表對應的工具鍊包含 IaC 管道和測試資料來源等工具。先前的 Java 應用程式圖表未提及這些工具，但這裡會納入，提供更完整的範例。
圖表會根據對開發人員和營運的影響程度，顯示四個象限。圖表中的元件位置如下：
- 開發人員影響程度中等，營運影響程度低：測試資料來源
- 對開發人員的影響中等，對作業的影響中等：Cloud Key Management Service、Cloud KMS
- 開發人員影響程度中等，營運影響程度高：部署管道
- 開發人員影響程度高，營運影響程度低：開發人員內部迴圈
- 對開發人員影響程度高，對作業影響程度中等：CI 管道、基礎架構即程式碼 (IaC) 管道
- 對開發人員影響重大，對作業影響重大：來源控管管理 (SCM)、構件登錄服務
原始碼控管管理和 Artifact Registry 等元件對開發人員和營運的影響最大，因此對業務的影響也最大。這些元件應具備最低的 RTO 和 RPO 目標。其他象限中的元件優先順序較低，因此 RTO 和 RPO 目標會較高。一般來說，工具鍊元件的 RTO 和 RPO 目標應根據可容許的資料或設定損失量，以及還原該元件服務所需的時間量來設定。
舉例來說，請考慮圖表中的 Artifact Registry 和 IaC 管道位置。比較這兩項工具後，您會發現 Artifact Registry 中斷服務對業務營運的影響，大於 IaC 管道中斷服務的影響。因為 Artifact Registry 服務中斷會大幅影響您部署或自動調整應用程式規模的能力，因此與其他工具相比，Artifact Registry 的 RTO 和 RPO 目標會較低。相較之下，圖表顯示 IaC 管道中斷對業務營運的影響，小於其他工具。這樣一來，IaC 管道的 RTO 和 RPO 目標就會提高，因為您可以在中斷期間使用其他方法部署或更新基礎架構。
選擇高階營運持續策略
生產應用程式的業務持續性程序通常會採用三種常見的災難復原策略之一。不過，對於 CI/CD，您可以選擇兩種高階策略，確保業務持續運作：主動/被動或備份/還原。您選擇的策略取決於需求和預算。每種策略在複雜度和成本方面都有取捨，且 CI/CD 程序考量因素也不同。以下各節將詳細說明每種策略及其優缺點。
此外，服務中斷事件發生時，可能不只會影響 CI/CD 實作，您也應考量所有需要的基礎架構，包括網路、運算和儲存空間。您應為這些建構區塊制定災難復原計畫，並定期測試，確保計畫有效。
主動/被動
採用主動/被動 (或暖待命) 策略時，應用程式和被動 CI/CD 管道會相互對應。不過，被動管道實際上並未處理客戶工作負載和任何建構或部署作業，因此處於縮減狀態。這項策略最適合業務關鍵應用程式，因為這類應用程式可容許少量停機時間。
下圖顯示本文件使用的 Java 應用程式範例，其主動/被動設定。被動管道會完整複製不同區域中的應用程式工具鍊。
在這個範例中，region1 會代管有效的 CI/CD 管道，而 region2 則有對應的被動管道。程式碼託管於外部 Git 服務供應商，例如 GitHub 或 GitLab。存放區事件 (例如從提取要求合併) 可以觸發 region1 中的 CI/CD 管道，以建構、測試及部署至多區域生產環境。
如果區域 1 管道發生重大問題 (例如產品區域性中斷)，可能會導致部署失敗或建構失敗。如要快速解決問題，可以更新 Git 存放區的觸發條件，並切換至 region2 管道，該管道就會成為作用中管道。在 region1 中解決問題後，您可以將管道保留在 region1 中，做為被動管道。
主動/被動策略的優點包括：
- 停機時間短：由於被動管道已部署但縮減規模，停機時間僅限於管道擴大規模所需的時間。
- 可設定的資料遺失容許度：採用這項策略時，必須定期同步設定和構件。不過，您可以根據需求設定金額，減少複雜度。
這項策略的缺點包括：
- 成本：基礎架構重複時，這項策略會增加 CI/CD 基礎架構的整體成本。
備份/還原
使用備份/還原策略時，您只會在事件復原期間需要時建立容錯移轉管道。這項策略最適合優先順序較低的使用案例。下圖顯示範例 Java 應用程式的備份/還原設定。備份設定只會在不同區域複製應用程式 CI/CD 管道的部分內容。
與上一個範例類似，region1 會代管有效的 CI/CD 管道。區域 2 不會採用被動式管道，只會備份必要的區域資料，例如 Maven 套件和容器映像檔。如果您在 region1 中託管來源存放區，也應將資料同步至 DR 位置。
同樣地，如果 region1 管道發生重大問題 (例如區域性產品服務中斷)，您可以在 region2 中還原 CI/CD 實作項目。如果基礎架構程式碼儲存在基礎架構程式碼存放區，您可以從存放區執行自動化指令碼，並在 region2 中重建 CI/CD 管道。
如果停機事件規模龐大，您可能會與其他客戶爭奪雲端資源。如要減輕這種情況的影響，其中一種方式是為 DR 位置提供多個選項。舉例來說，如果您的 region1 管道位於 us-east1，容錯移轉區域可以是 us-east4、us-central1 或 us-west1。
備份/還原策略的優點包括：
- 費用：這項策略的費用最低，因為您只會在 DR 情況下部署備份管道。
這項策略的缺點包括：
- 停機時間：這項策略需要較多時間才能實作，因為您必須在需要時建立容錯移轉管道。服務必須在事件復原期間建立及設定，而不是使用預先建構的管道。此外，擷取外部依附元件的時間和構件建構時間也可能會大幅延長。
記錄 BCP 並實施最佳做法
完成 CI/CD 工具鍊的對應作業、找出依附元件，並為重要功能設定 RTO 和 RPO 目標後，下一步就是將所有相關資訊記錄在書面 BCP 中。建立 BCP 時，請記錄還原各項重要功能的策略、程序和步驟。這項文件編寫程序包括為特定職責的員工編寫逐步程序，讓他們在發生中斷事件時遵循。
定義 BCP 後，請運用最佳做法部署或更新 CI/CD 工具鍊，以達成 RTO 和 RPO 目標。雖然 CI/CD 工具鍊可能大相逕庭，但無論使用哪種工具鍊，最佳做法都有兩個共通的關鍵模式：全面瞭解依附元件，以及導入自動化。
就依附元件而言，大多數 BCP 都會直接處理您可控管的系統。不過請注意，二階或三階外部依附元件的影響可能同樣重大，因此請務必針對這些重要依附元件，實施最佳做法和備援措施。範例應用程式中的外部 Java 程式庫是第三階依附元件的範例。如果沒有這些程式庫的本機存放區或備份，當您提取程式庫的外部來源中斷連線時，您可能無法建構應用程式。
就自動化而言，最佳做法的導入應納入整體雲端 IaC 策略。您的 IaC 解決方案應使用 Terraform 等工具，自動佈建 CI/CD 實作作業的必要資源，並設定相關程序。IaC 做法是相當有效的復原程序，因為這類做法已納入 CI/CD 管道的日常運作。此外，IaC 會將設定檔儲存在原始碼控管系統中，進而推動備份最佳做法的採用。
根據 BCP 和相依項目與自動化的最佳做法實作工具鍊後，CI/CD 程序和復原策略可能會有所變更。請務必記錄因審查 BCP 和實施最佳做法而對復原策略、程序和程序所做的任何變更。
測試失敗情境並維護計畫
請務必定期檢查、測試及更新 BCP。測試 BCP 和復原程序可驗證計畫是否仍有效，以及記錄的 RPO 和 RTO 目標是否可接受。但最重要的是，定期測試、更新及維護可讓 BCP 執行作業成為正常作業的一部分。使用 Google Cloud，您能夠以最低費用測試復原情境。建議您採取下列做法，以利進行測試：
- 使用 IaC 工具自動佈建基礎架構：您可以使用 Terraform 等工具，自動佈建 CI/CD 基礎架構。
- 使用 Cloud Logging 和 Cloud Monitoring 監控及偵錯測試：Google Cloud Observability 提供記錄和監控工具，您可以使用 API 呼叫存取這些工具，透過回應指標的方式自動部署復原情境。設計測試時，請確定您已設定適當的監控和快訊，可以觸發適當的復原動作。
- 在 BCP 中執行測試：舉例來說，您可以測試權限和使用者存取權在 DR 環境中的運作方式，是否和在實際工作環境中一樣。您可以在 DR 環境中進行整合和功能測試。您也可以在平常使用的存取路徑無法使用的情況下執行測試。 Google Cloud
Google 會定期透過「災難復原測試」(DiRT) 程序，測試業務持續性計畫。這項測試 有助於 Google 驗證影響、自動化，並揭露未計入的風險。需要導入的自動化和 BCP 變更，是 DiRT 的重要輸出內容。
最佳做法
在本節中，您將瞭解一些最佳做法，協助您達成 RTO 和 RPO 目標。這些最佳做法廣泛適用於 CI/CD 的 DR，而非特定工具。無論採用哪種做法，都應定期測試 BCP，確保高可用性、RTO 和 RPO 符合您的需求。如果發生事件或災害，您也應進行回顧並分析流程，以便加以改善。
高可用性
針對每項工具，您都應盡力實作高可用性最佳做法。遵循高可用性最佳做法，可讓 CI/CD 程序更積極主動，因為這些做法可讓 CI/CD 程序更具備故障復原能力。這些主動式策略應搭配更多反應式控制措施和程序，以利復原和備份。
以下列舉幾項最佳做法，協助您實現高可用性。不過，如要瞭解更詳細的最佳做法，請參閱 CI/CD 中各項工具的詳細說明文件：
- 代管服務：使用代管服務可將營運責任轉移至 Google Cloud。
- 自動調度資源：盡可能使用自動調度資源。自動調度資源的重要層面在於動態建立工作站執行個體，因此系統會自動復原失敗的節點。
- 全球和多區域部署：盡可能使用全球和多區域部署，而非區域部署。舉例來說，您可以設定 Artifact Registry 的多區域儲存空間。
- 依附元件：瞭解工具的所有依附元件，並確保這些依附元件具有高可用性。舉例來說，您可以將構件登錄檔中的所有第三方程式庫快取。
備份程序
實作 CI/CD 的 DR 時，部分工具和程序更適合備份/還原策略。完善的備份策略是有效反應控制措施的第一步。備份功能可讓您在發生惡意行為或災難時，以最少的中斷時間復原 CI/CD 管道。
首先，請實作下列三項最佳做法。 不過，如要瞭解更詳細的備份最佳做法，請參閱 CI/CD 程序中各項工具的說明文件。
- 來源控管：將設定檔和您編寫的任何內容 (例如自動化指令碼和政策) 儲存在來源控管中。例如
cloudbuild.yaml和 Kubernetes YAML 檔案。 - 備援：確保存取密碼、憑證和 API 金鑰等密鑰時，不會出現單點故障。舉例來說，請避免只有一人知道密碼，或只在特定區域的單一伺服器上儲存 API 金鑰。
- 備份：請經常驗證備份的完整性和準確度。使用 Backup for GKE 等受管理服務，有助於簡化驗證程序。
復原程序
災難復原也需要復原程序，才能補足備份程序。您的復原程序搭配完整備份，將決定您能多快因應災難情境。
依附元件管理
CI/CD 管道可能包含許多依附元件，這些依附元件也可能導致失敗。如要查看完整的依附元件清單，請參閱本文稍早的「找出資料和依附元件」一節。不過，最常見的兩種依附元件來源如下：
- 應用程式構件：例如套件、程式庫和圖片
- 外部系統：例如票務和通知系統
如要降低依附元件的風險，其中一種方法是採用「供應商」做法。供應商應用程式套件或映像檔是指在私人存放區中建立及儲存這些套件或映像檔副本的程序。供應商可移除這些套件或映像檔對外部來源的依附元件，也有助於防止惡意軟體插入軟體供應鏈。
供應應用程式套件或映像檔的好處包括：
- 安全性：供應商可移除應用程式套件或映像檔對外部來源的依附元件，有助於防範惡意軟體插入攻擊。
- 控管：機構可透過供應自己的套件或映像檔，進一步控管這些套件和映像檔的來源。
- 法規遵循：透過供應商服務，機構可以遵守產業法規，例如網路安全成熟度模型認證。
如果團隊決定向供應商採購應用程式套件或圖片，請按照下列主要步驟操作：
- 找出需要供應商提供的應用程式套件或映像檔。
- 建立私人存放區，用於儲存供應商提供的套件或映像檔。
- 從原始來源下載套件或映像檔，並儲存在私人存放區。
- 確認套件或映像檔是否完整。
- 視需要更新供應商提供的套件或映像檔。
CI/CD 管道通常會呼叫第三方系統來執行動作，例如執行掃描、記錄工單或傳送通知。在大多數情況下，這些外部系統都有自己的 DR 策略，因此應實作這些策略。不過，有時他們可能沒有合適的 DR 計畫，這些情況應清楚記錄在 BCP 中。接著，您必須決定是否可基於可用性考量略過管道中的這些階段，或是是否可接受造成 CI/CD 管道停機。
監控和通知
CI/CD 與應用程式生產系統類似，因此您也需要為 CI/CD 工具導入監控和通知技術。最佳做法是導入資訊主頁和警報通知。Cloud Monitoring 的 GitHub 範例存放區提供許多資訊主頁和快訊政策範例。
您也可以實作其他層級的監控，例如服務水準指標 (SLI) 和服務等級目標 (SLO)。這些監控層級有助於追蹤 CI/CD 管道的整體健康狀態和效能。舉例來說，您可以實作 SLO，追蹤建構和部署階段的延遲時間。這些 SLO 可協助團隊以您期望的速度和頻率建構及發布應用程式。
緊急存取程序
發生災難時，營運團隊可能需要採取標準程序以外的行動，並取得系統和工具的緊急存取權。這類緊急措施有時也稱為「破窗程序」。首先，請實作下列三項最佳做法：
- 制定明確的提報計畫和程序。明確的計畫可協助營運團隊瞭解何時需要使用緊急存取程序。
- 確保多位使用者都能存取重要資訊，例如設定和密碼。
- 開發自動稽核方法，追蹤緊急存取程序的使用時間和使用者。
後續步驟
- 進一步瞭解本文使用的 Google Cloud 產品：
- 請參閱「災難復原規劃指南」。
- 完成教學課程，試試其他 Google Cloud 功能。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：
- Ben Good | 解決方案架構師
- Xiang Shen | 解決方案架構師
其他貢獻者：
- Marco Ferrari | 雲端解決方案架構師
- Anuradha Bajpai | 解決方案架構師
- Rodd Zurcher | 解決方案架構師