在 Azure 上部署和測試任務關鍵性工作負載

失敗的部署和錯誤版本是應用程式中斷的常見原因。 部署和測試的方法在任務關鍵性應用程式的整體可靠性中扮演重要角色。

部署和測試應形成所有應用程式和基礎結構作業的基礎，以確保任務關鍵性工作負載的結果一致。 準備每周、每天或更頻繁地部署。 設計持續整合和持續部署 （CI/CD） 管線以支援這些目標。

策略應實作：

• 嚴格的發行前測試。 更新不應造成可能危及應用程式健康情況的瑕疵、弱點或其他因素。

• 透明部署。 應該隨時推出更新，而不會影響使用者。 用戶應該能夠繼續與應用程式互動，而不會中斷。

• 高可用性作業。 部署和測試程式和工具必須具有高可用性，才能支援整體應用程式可靠性。

• 一致的部署程式。 應該使用相同的應用程式成品和程式，在不同的環境中部署基礎結構和應用程式程序代碼。 端對端自動化是必要的。 必須避免手動干預，因為它們可能會帶來可靠性風險。

此設計區域提供如何優化部署和測試程序的建議，目標是將停機時間降到最低，並維護應用程式健康情況和可用性。

零停機部署

如需零停機部署的概觀，請檢視下列影片。

達成零停機部署是任務關鍵性應用程式的基本目標。 即使您在上班時間推出新版本，您仍必須整天使用您的應用程式。 先投入心力來定義和規劃部署程式，以推動關鍵設計決策，例如是否將資源視為暫時性。

若要達到零停機部署，請在現有基礎結構旁邊部署新的基礎結構、徹底測試、轉換終端使用者流量，然後才解除委任先前的基礎結構。 其他做法，例如 縮放單位架構，也是關鍵。

任務 關鍵在線 和 Azure 任務關鍵連線 參考實作說明此部署方法，如下圖所示：

應用程式環境

如需應用程式環境的建議概觀，請檢視下列影片。

您需要各種類型的環境來驗證和暫存部署作業。 這些類型具有不同的功能和生命週期。 某些環境可能會反映生產環境且壽命很長，而有些環境可能很短，且功能比生產環境少。 在開發週期早期設定這些環境有助於確保靈活度、將生產和生產前資產分離，以及在發行至生產環境之前徹底測試作業。 所有環境都應該盡可能反映生產環境，不過您可以視需要將簡化套用至較低的環境。 下圖顯示工作關鍵架構：

有一些常見的考慮：

• 元件不應該跨環境共用。 可能的例外狀況是下游安全性設備，例如綜合測試數據的防火牆和來源位置。

• 所有環境都應該使用基礎結構即程序代碼 （IaC） 成品，例如 Terraform 或 Azure Resource Manager （ARM） 範本。

開發環境

如需暫時開發環境和自動化功能驗證的相關信息，請檢視下列影片。

設計考量

• 功能。 開發環境可接受的可靠性、容量和安全性需求較低。

• 生命週期。 開發環境應視需要建立，並短暫存在。 較短的生命週期有助於防止設定偏離程式代碼基底並降低成本。 此外，開發環境通常會共用功能分支的生命週期。

• 密度。 Teams 需要多個環境來支援平行功能開發。 他們可以共存於單一訂用帳戶內。

設計建議

• 將環境保留在專用訂用帳戶中，並設定內容集以供開發之用。

• 使用自動化程式，將程式代碼從功能分支部署至開發環境。

測試或預備環境

這些環境用於測試和驗證。 會執行許多測試週期，以確保無 Bug 部署至生產環境。 持續驗證和測試一節會 說明任務關鍵性工作負載的適當測試 。

設計考量

• 功能。 這些環境應反映生產環境的可靠性、容量和安全性。 如果沒有生產負載，請使用綜合用戶負載來提供實際計量和寶貴的健康情況模型化輸入。

• 生命週期。 這些環境是短暫的。 測試驗證完成之後，應該終結它們。

• 密度。 您可以在一個訂用帳戶中執行許多獨立環境。 您也應該考慮使用多個環境，每個環境都位於專用的訂用帳戶中。

設計建議

• 請確定至少有一個預備環境會完整反映生產環境，以啟用類似生產環境的測試和驗證。 此環境內的容量可以根據測試活動的執行而彈性。

• 產生綜合用戶負載，以提供一個環境變更的實際測試案例。

  注意

  任務 關鍵在線 參考實作 提供用戶負載產生器的範例。

• 定義開發與發行週期內的預備環境數目及其用途。

實際執行環境

設計考量

• 功能。 應用程式需要最高層級的可靠性、容量和安全性功能。

• 生命週期。 雖然工作負載和基礎結構的生命週期保持不變，但所有數據，包括監視和記錄，都需要特殊管理。 例如，備份和復原需要管理。

• 密度。 對於某些應用程式，您可能想要考慮使用不同的生產環境來迎合不同的用戶端、用戶或商務功能。

設計建議

針對生產環境與較低環境具有明確的治理界限。 將每個環境類型放在專用訂用帳戶中，以達成該目標。 此分割可確保較低環境中的資源使用率不會影響生產配額。 專用訂用帳戶也會設定存取界限。

暫時藍色/綠色部署

藍/綠部署模型至少需要兩個相同的部署。 藍色部署是提供生產環境中使用者流量的作用中部署。 綠色部署是準備並測試接收流量的新部署。 綠色部署完成並測試之後，流量會逐漸從藍色導向到綠色。 如果負載傳輸成功，綠色部署會變成新的作用中部署。 然後，您可以透過階段式程式解除委任舊的藍色部署。 不過，如果新部署發生問題，可能會中止，而且流量可以保留在舊的藍色部署中，或重新導向至該部署。

Azure Mission-Critical 建議使用藍色/綠色部署方法，其中基礎結構 和應用程式 會一起部署為部署戳記的一部分。 因此，對基礎結構或應用程式的變更一律會導致包含這兩層的綠色部署。 這種方法可讓您在將使用者流量重新導向至基礎結構和應用程式之前，先對基礎結構和應用程式端對端進行變更的完整測試和驗證。 因為可以驗證與 Azure 平臺、資源提供者和 IaC 模組等下游相依性的相容性，因此此方法會增加釋放變更並啟用零停機升級的信心。

設計考量

• 技術功能。 利用 Azure 服務中的內建部署功能。 例如，Azure App 服務 提供可在部署之後交換的次要部署位置。 使用 Azure Kubernetes Service （AKS），您可以在每個節點上使用不同的 Pod 部署，並更新服務定義。

• 部署持續時間。 部署可能需要較長的時間才能完成，因為戳記包含基礎結構和應用程式，而不只是變更的元件。 不過，這是可以接受的，因為所有元件未如預期般運作的風險會覆寫時間考慮。

• 成本影響。 額外的成本是因為兩個並存部署，這必須共存，直到部署完成為止。

• 流量轉換。 驗證新部署之後，流量必須從藍色環境轉換為綠色環境。 此轉換需要環境之間的使用者流量協調流程。 轉換應該完全自動化。

• 生命週期。 任務關鍵性部署戳記應該視為暫時性。 在布建資源之前，使用短期戳記每次都會建立新的開始。

設計建議

• 採用藍色/綠色部署方法來釋放所有生產變更。 每次針對任何類型的變更部署所有基礎結構和應用程式，以達到一致的狀態和零停機時間。 雖然您可以重複使用環境，但我們不建議用於任務關鍵性工作負載。 將每個區域部署戳記視為暫時的，其生命週期會系結至單一版本的版本。

• 使用全域負載平衡器，例如 Azure Front Door，協調藍綠環境之間的使用者流量自動轉換。

• 若要轉換流量，請新增綠色後端端點，以使用低流量到磁碟區權數，例如 10%。 確認綠色部署上的流量較低且提供預期的應用程式健康情況之後，請逐漸增加流量。 這樣做時，請套用較短的加速期間來攔截可能不立即明顯的錯誤。

  轉換所有流量之後，請從現有的連線中移除藍色後端。 例如，從全域負載平衡器服務中移除後端、清空佇列，以及中斷連結其他關聯。 這樣做有助於將維護次要生產基礎結構的成本優化，並確保新的環境沒有設定漂移。

  此時，解除委任舊的和非作用中的藍色環境。 在下一個部署中，使用藍色和綠色反轉重複此程式。

訂用帳戶範圍的部署

視應用程式的規模需求而定，您可能需要多個生產訂用帳戶作為縮放單位。

檢視下列影片，以取得針對任務關鍵性應用程式界定訂用帳戶的建議概觀。

設計考量

• 延展性。 針對具有大量流量的高規模應用程式案例，請設計可跨多個 Azure 訂用帳戶進行調整的解決方案，讓單一訂用帳戶的規模限制不會限制延展性。

  重要

  使用多個訂用帳戶需要額外的 CI/CD 複雜度，這必須適當地管理。 因此，只有在極端規模的案例中，我們建議使用多個訂用帳戶，其中單一訂用帳戶的限制可能會成為限制。

• 環境界限。 將生產、開發和測試環境部署到不同的訂用帳戶。 這種做法可確保較低的環境不會對規模限制造成貢獻。 它也會藉由提供明確的管理和身分識別界限，降低環境更新污染生產的風險。

• 治理。 當您需要多個生產訂用帳戶時，請考慮使用專用的應用程式管理群組，透過原則匯總界限簡化原則指派。

設計建議

• 在專用訂用帳戶中部署每個區域部署戳記，以確保訂用帳戶限制僅適用於單一部署戳記的內容，而不是整個應用程式。 在適當情況下，您可能會考慮在單一區域內使用多個部署戳記，但您應該跨獨立訂用帳戶進行部署。

• 將全域共用資源放在專用訂用帳戶中，以啟用一致的區域訂用帳戶部署。 避免針對主要區域使用特製化部署。

持續驗證和測試

測試是一項重要活動，可讓您完整驗證應用程式程式代碼和基礎結構的健康情況。 更具體來說，測試可讓您符合可靠性、效能、可用性、安全性、品質和規模的標準。 測試必須妥善定義並套用為應用程式設計和 DevOps 策略的一部分。 測試是本機開發人員程式（ 內部迴圈）期間的重要考慮，也是完整 DevOps 生命週期（ 外部迴圈）的一部分，也就是程式代碼從發行管線程序開始到生產環境的路徑時。

檢視下列影片，以取得持續驗證和測試的概觀。

本節著重於外部循環測試。 它描述各種類型的測試。

設計考量

• 自動化。 自動化測試對於以及時且可重複的方式驗證應用程式或基礎結構變更至關重要。

• 測試順序。 執行測試的順序是一個重要考慮，因為各種相依性，例如需要有執行中的應用程式環境。 測試持續時間也會影響順序。 使用較短運行時間的測試應盡可能早於迴圈中執行，以提高測試效率。

• 延展性限制。 Azure 服務有不同的軟式和硬性限制。 請考慮使用負載測試來判斷系統是否在預期的生產負載期間超過它們。 負載測試也可用於設定適當的自動調整閾值。 對於不支援自動調整的服務，負載測試可協助您微調自動化作業程式。

  無法適當調整系統元件，例如主動/被動網路元件或資料庫，可能會受到限制。 壓力測試有助於識別限制。

• 失敗模式分析。 將錯誤引入應用程式和基礎結構，並評估效果對於評估解決方案的備援機制至關重要。 在此分析期間，找出影響的風險、影響和廣度（部分或完整中斷）。 如需針對任務關鍵在線參考實作所建立的範例分析，請參閱個別元件的中斷風險。

• 監視。 您應該個別擷取和分析測試結果，並匯總它們以評估一段時間的趨勢。 您應該持續評估測試結果的精確度和涵蓋範圍。

設計建議

觀看下列影片，以了解復原測試如何與 Azure DevOps CI/CD 管線整合。

• 藉由自動化基礎結構和應用程式元件上的所有測試，以確保一致性。 整合 CI/CD 管線中的測試，以協調並在適用的情況下加以執行。 如需技術選項的相關信息，請參閱 DevOps工具。

• 將所有測試成品視為程序代碼。 它們應該與其他應用程式程式代碼成品一起維護及控制版本。

• 將測試基礎結構的 SLA 與部署和測試週期的 SLA 對齊。

• 在每個部署中執行煙霧測試。 同時執行廣泛的負載測試以及壓力和混亂測試，以驗證應用程式效能和操作性是否已維護。

  • 使用反映實際尖峰使用模式的負載配置檔。
  • 在負載測試的同時執行混亂實驗和失敗插入測試。

  提示

  Azure Chaos Studio 是混亂實驗工具的原生套件。 這些工具可讓您輕鬆地進行混亂實驗，並在 Azure 服務和應用程式元件中插入錯誤。

  Chaos Studio 提供常見錯誤案例的內建混亂實驗，並支援以基礎結構和應用程式元件為目標的自定義實驗。

• 如果負載或煙霧測試需要資料庫互動，例如建立記錄，請使用具有降低許可權的測試帳戶，並讓測試數據與實際用戶內容分開。

• 掃描及監視已知 CVE 的端對端軟體供應鏈和套件相依性。

  • 使用 Dependabot for GitHub 存放庫，以確保存放庫會隨著其相依的套件和應用程式最新版本自動更新。

基礎結構即程式代碼部署

基礎結構即程式代碼 （IaC） 會將基礎結構定義視為與其他應用程式成品一起控制版本的原始程式碼。 使用 IaC 可跨環境提升程式代碼一致性、在自動化部署期間消除人為錯誤的風險，並提供可追蹤性和復原。 對於藍/綠部署，使用 IaC 與完全自動化部署是勢在必行的。

任務關鍵性 IaC 存放庫有兩個不同的定義，這些定義會對應至全域和區域資源。 如需這些類型資源的相關信息，請參閱 核心架構模式。

設計考量

• 可重複的基礎結構。 以每次產生相同環境的方式部署任務關鍵性工作負載。 IaC 應該是主要模型。

• 自動化。 所有部署都必須完全自動化。 人為程式容易出錯。

設計建議

• 套用 IaC，確保宣告式範本中定義所有 Azure 資源，並在原始檔控制存放庫中維護。 範本會部署，而且會透過 CI/CD 管線自動從原始檔控制布建資源。 不建議使用命令式腳本。

• 禁止對所有環境進行手動作業。 唯一的例外狀況是完全獨立的開發人員環境。

DevOps 工具

有效使用部署工具對於整體可靠性至關重要，因為 DevOps 程式會影響整體函式和應用程式設計。 例如，故障轉移和調整作業可能取決於 DevOps 工具所提供的自動化。 工程小組必須瞭解部署服務在整體工作負載上無法使用的效果。 部署工具必須可靠且高可用性。

Microsoft 提供兩個 Azure 原生工具組 GitHub Actions 和 Azure Pipelines，可有效地部署和管理任務關鍵性應用程式。

設計考量

• 技術功能。 GitHub 和 Azure DevOps 的功能重疊。 您可以一起使用它們來充分利用這兩者。 常見的方法是在使用 Azure Pipelines 進行部署時，將程式代碼存放庫儲存在 GitHub.com 或 GitHub AE 中。

  請注意當您使用多個技術時所新增的複雜度。 根據整體可靠性評估豐富的功能集。

• 區域可用性。 就可靠性上限而言，單一 Azure 區域的相依性代表作業風險。

  例如，假設流量分散在兩個區域：區域 1 和區域 2。 區域 2 裝載 Azure DevOps 工具實例。 假設區域 2 發生中斷，且實例無法使用。 區域 1 會自動處理所有流量，而且需要部署額外的縮放單位，以提供良好的故障轉移體驗。 但是因為區域 2 中的 Azure DevOps 相依性，所以無法進行。

• 數據複寫。 數據，包括元數據、管線和原始程式碼，應該跨區域複寫。

設計建議

• 這兩種技術都裝載在單一 Azure 區域中，這可能會讓您的災害復原策略受到限制。

  GitHub Actions 非常適合建置工作（持續整合），但可能缺少複雜部署工作（持續部署）的功能。 假設 Azure DevOps 的豐富功能集，建議您將其用於任務關鍵部署。 不過，在評估取捨之後，您應該做出選擇。

• 定義部署工具的可用性 SLA，並確保與更廣泛的應用程式可靠性需求一致。

• 針對使用主動/被動或主動/主動部署設定的多區域案例，請確定即使主要區域裝載部署工具組無法使用，故障轉移協調流程和調整作業仍可繼續運作。

分支策略

分支有許多有效的方法。 您應該選擇可確保最大可靠性的策略。 良好的策略可讓平行開發、提供從開發到生產環境的完整路徑，並支援快速發行。

設計考量

• 將存取降至最低。 開發人員應該在和 fix/* 分支中feature/*執行其工作。 這些分支會變成變更的進入點。 角色型限制應套用至分支，作為分支策略的一部分。 例如，只允許系統管理員建立發行分支或強制執行分支的命名慣例。

• 緊急情況的加速程式。 分支策略應允許 Hotfix 盡快合併成 main 。 如此一來，未來版本就會包含修正，並避免問題週期。 請只針對解決緊急問題的次要變更使用此程式，並加以限制使用。

設計建議

• 優先使用 GitHub 進行原始檔控制。

  重要

  建立分支策略，以將功能工作和版本詳述為最小值，並使用分支原則和許可權來確保策略已適當強制執行。

• 觸發自動化測試程式，在程式碼變更貢獻被接受之前先驗證其貢獻。 小組成員也必須檢閱變更。

• 將 main 分支視為持續向前移動且穩定的分支，主要用於整合測試。

  • 請確定只透過PR進行 main 變更。 使用分支原則來禁止直接認可。
  • 每次合併 mainPR時，應該會自動開始針對整合環境進行部署。
  • 分支 main 應該視為穩定。 在任何指定時間建立發行 main 應該很安全。

• 使用從main分支建立的專用release/*分支，並用來部署到生產環境。 release/* 分支應該會保留在存放庫中，而且可用來修補發行。

• 記錄 Hotfix 程式，並只在需要時才使用它。 在 fix/* 分支中建立 Hotfix，以便後續合併至發行分支和部署到生產環境。

適用於 DevOps 的 AI

您可以在 CI/CD 管線中套用 AIOps 方法，以補充傳統的測試方法。 這樣做可偵測潛在的回歸或降級，並允許預先停止部署，以防止潛在的負面影響。

設計考量

• 遙測數據的數量。 CI/CD 管線和 DevOps 程式會針對機器學習模型發出各種不同的遙測。 遙測範圍從測試結果和部署結果到複合部署階段中測試元件的相關作業數據。

• 延展性。 傳統的數據處理方法，例如擷取、轉換、載入（ETL）可能無法調整輸送量，以跟上部署遙測和應用程式可觀察性數據的成長。 您可以使用不需要 ETL 和數據移動的新式分析方法，例如數據虛擬化，來啟用 AIOps 模型的持續分析。

• 部署變更。 部署中的變更必須儲存，才能自動化分析和與部署結果的相互關聯。

設計建議

• 定義要收集的 DevOps 程式數據，以及如何分析數據。 遙測，例如測試執行計量，以及每個部署內變更的時間序列數據，都很重要。

  • 從預備、測試和生產環境公開應用程式可檢視性數據，以在 AIOps 模型中分析和相互關聯。

• 採用 MLOps 工作流程。

• 開發內容感知和相依性感知的分析模型，以提供自動化特徵工程的預測，以解決架構和行為變更。

• 在部署管線中註冊和部署最佳定型模型，以運作模型。

後續步驟

檢閱安全性考慮。