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

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

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

策略應實作：

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

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

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

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

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

重要

本文是 Azure Well-Architected Framework 任務關鍵性工作負載 系列的一部分。 如果您不熟悉此系列，建議您從 什麼是任務關鍵性工作負載開始？。

零停機部署

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

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

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

Mission-Critical Online和Azure Mission-Critical Connected參考實作說明此部署方法，如下圖所示：

應用程式環境

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

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

有一些常見的考慮：

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

• 所有環境都應該使用基礎結構作為程式碼 (IaC) 成品，例如 Terraform 或 Azure Resource Manager (ARM) 範本。

開發環境

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

設計考量

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

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

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

設計建議

• 將環境保留在專用訂用帳戶中，並設定用於開發用途的內容集。

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

測試或預備環境

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

設計考量

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

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

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

注意

任務關鍵性應用程式應受限於嚴格的測試。

您可以在單一環境中執行不同的測試函式，在某些情況下，您將需要執行。 例如，若要讓混亂測試提供有意義的結果，您必須先將應用程式放在負載下，以便了解應用程式如何回應插入的錯誤。 這就是為什麼混亂測試和負載測試通常會以平行方式執行。

設計建議

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

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

  注意

  Mission Critical Online參考實作提供使用者負載產生器的範例。

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

生產環境

設計考量

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

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

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

設計建議

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

暫時藍色/綠色部署

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

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

設計考量

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

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

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

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

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

設計建議

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

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

• 若要轉換流量，請新增綠色後端端點，以使用低流量到磁片區權數，例如 10%。 確認綠色部署上的低流量可運作並提供預期的應用程式健康情況之後，請逐漸增加流量。 這麼做時，請套用短的向上坡形來攔截可能不會立即顯示的錯誤。

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

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

訂用帳戶範圍的部署

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

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

設計考量

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

  重要

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

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

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

設計建議

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

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

持續驗證和測試

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

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

本節著重于外部迴圈測試。 它會描述各種類型的測試。

測試	描述
單元測試	確認應用程式商務邏輯如預期般運作。 驗證程式代碼變更的整體效果。
氣氣測試	識別基礎結構和應用程式元件是否可用且如預期般運作。 一般而言，只會測試單一虛擬使用者會話。 結果應該是系統以預期的值和行為回應。 常見的噴氣測試案例包括到達 Web 應用程式的 HTTPS 端點、查詢資料庫，以及模擬應用程式中的使用者流程。
UI 測試	驗證是否已部署應用程式使用者介面，以及該使用者介面互動如預期般運作。 您應該使用 UI 自動化工具來推動自動化。 在 UI 測試期間，腳本應該模擬實際的使用者案例，並完成一系列的步驟，以執行動作並達成預定的結果。
負載測試	藉由快速增加負載和/或逐漸增加，以驗證延展性和應用程式作業，直到達到預先決定的臨界值為止。 負載測試通常是針對特定使用者流程所設計，以驗證在定義的負載下滿足應用程式需求。
壓力測試	套用多載現有資源的活動，以判斷解決方案限制，並確認系統能夠正常復原。 主要目標是找出潛在的效能瓶頸和規模限制。 相反地，相應減少系統的運算資源，並監視其在負載下的行為，並判斷是否可以復原。
效能測試	結合負載和壓力測試的各個層面，以驗證負載下的效能，並建立應用程式作業的效能評定行為。
混亂測試	將人工失敗插入系統，以評估其回應方式，以及驗證復原措施、作業程式和風險降低的有效性。 關閉基礎結構元件、以降低效能，並引進應用程式錯誤是測試的範例，可用來確認應用程式在實際發生案例時會如預期般回應。
滲透測試	確保應用程式及其環境符合預期的安全性狀態需求。 目標是識別安全性弱點。 安全性測試可以包含端對端軟體供應鏈和套件相依性，以及掃描和監視已知常見弱點和暴露 (CVE) 。

設計考量

• 自動化。 自動化測試是以及時且可重複的方式驗證應用程式或基礎結構變更不可或缺的。

• 測試順序。 由於各種相依性，因此執行測試的順序是重要的考慮，例如需要有執行中的應用程式環境。 測試持續時間也會影響順序。 盡可能提高測試效率時，應該在週期中稍早執行具有較短執行時間的測試。

• 延展性限制。 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，並確保符合更廣泛的應用程式可靠性需求。

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

分支策略

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

設計考量

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

• 加速處理流程。 分支策略應該允許 Hotfix 儘快合併成 main 。 如此一來，未來版本就會包含修正程式，並避免問題週期。 此程式僅適用于解決緊急問題的次要變更，並搭配使用。

設計建議

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

  重要

  建立分支策略，以詳細資料 功能 工作和 發行 ，並使用分支原則和許可權來確保適當地強制執行策略。

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

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

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

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

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

AI for DevOps

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

設計考量

• 遙測資料的數量。 CI/CD 管線和 DevOps 程式會針對機器學習模型發出各種遙測。 遙測範圍從測試結果和部署結果到來自複合部署階段之測試元件的運算元據。

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

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

設計建議

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

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

• 採用 MLOps 工作流程。

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

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

後續步驟

檢閱安全性考慮。

安全性