共用方式為

Azure 上任務關鍵性工作負載的操作程式

  • 發行項

可靠且有效的作業必須以 自動化 原則為基礎，並盡可能 設定為程式碼。 這種方法需要對 DevOps 程式進行大量工程投資。 自動化管線可用來部署應用程式和基礎結構程式碼成品。 此方法的優點包括一致且精確的操作結果，且最少的手動操作程式。

此設計區域會探索如何實作有效且一致的作業程式。

重要

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

DevOps 程序

DevOps 會將開發和作業流程和小組結合成單一工程功能。 它包含整個應用程式生命週期，並使用自動化和 DevOps 工具，以快速、有效率且可靠的方式執行部署作業。 DevOps 程式支援並持續整合和持續傳遞 (CI/CD) ，同時促進持續改善的文化。

任務關鍵性應用程式的 DevOps 小組必須負責下列工作：

  • 透過 CI/CD 自動化建立和管理應用程式和基礎結構資源。
  • 應用程式監視和可觀察性。
  • 應用程式元件的 Azure 角色型存取控制 (RBAC) 和身分識別管理。
  • 應用程式元件的網路管理。
  • 應用程式資源的成本管理。

DevSecOps 藉由整合安全性監視、應用程式稽核，以及整個應用程式生命週期中的開發和作業，來擴充 DevOps 模型。 對於安全性敏感性和高度管制的案例，DevOps 小組是必要的，以確保安全性會納入開發生命週期，而不是在特定發行階段或閘道中。

設計考量

  • 發行和更新程式。 避免對應用程式元件或基礎結構進行任何變更的手動程式。 手動程式可能會導致結果不一致。

  • 中央 IT 小組的相依性。 當集中式函式有硬式相依性時，DevOps 程式可能會難以套用，因為這些相依性會防止端對端作業。

  • 身分識別和存取管理。 DevOps 小組可以針對各種技術功能考慮細微的 Azure RBAC 角色，例如 AppDataOps 進行資料庫管理。 跨 DevOps 角色套用零信任模型。

設計建議

  • 將組態設定和更新定義為程式碼。 透過程式碼套用變更管理，以啟用一致的發行和更新程式，包括金鑰或秘密輪替和版權管理等工作。 使用管線管理的更新程式，例如排程的管線執行，而不是內建的自動更新機制。

  • 請勿使用中央進程或布建管線來具現化或管理應用程式資源。 這麼做會導入外部應用程式相依性和額外的風險向量，例如與雜訊鄰近案例相關聯的應用程式相依性。

    如果您需要使用集中式布建程式，請確定相依性的可用性需求完全符合任務關鍵性需求。 中央小組必須提供透明度，才能達成端對端應用程式的整體運作。

  • 在每個短期衝刺期間，指定一部分工程容量，以推動基本平臺改善並強化可靠性。 我們建議您為這些改善配置 20-40% 的容量。

  • 開發符合核心 設計原則的常見工程準則、參考架構和程式庫。 透過使用Azure 原則的原則驅動方法，強制執行可靠性、安全性和作業的一致基準組態。

    您也可以在組織更廣泛的應用程式生態系統內，使用常見的工程準則和相關聯的成品，例如 Azure 原則和 Terraform 資源，以用於通用設計模式。

  • 在重要的應用程式環境中套用零信任模型。 使用Microsoft Entra Privileged Identity Management等技術，以確保作業一致，而且只會透過 CI/CD 程式或自動化作業程式進行。

    小組成員不應具有任何環境的常設寫入權限。 您可能想要在開發環境中建立例外狀況，以簡化測試和偵錯。

  • 定義即時存取生產環境的緊急程式。 確定在驗證提供者發生嚴重問題時，有中斷帳戶存在。

  • 請考慮使用 AIOps 來持續改善作業程式和觸發程式。

應用程式作業

應用程式設計和平臺建議會影響作業程式。 也有各種 Azure 服務所提供的作業功能，特別是針對高可用性和復原。

設計考量

  • Azure 服務的內建作業。 Azure 服務預設會提供內建 (，) 和可設定的平臺功能，例如區域性備援和異地複寫。 應用程式的可靠性取決於這些作業。 某些可設定的功能會產生額外的成本，例如 Azure Cosmos DB 的多寫入部署設定。 除非您絕對需要，否則請避免建置自訂解決方案。

  • 作業存取和執行時間。 大部分的必要作業都是透過 Azure Resource Manager API 或Azure 入口網站公開和存取。 不過，某些作業需要支援工程師的協助。 例如，從 Azure Cosmos DB 資料庫的定期備份還原，或復原已刪除的資源，只能透過支援案例Azure 支援工程師來執行。 此相依性可能會影響應用程式的停機時間。 針對無狀態資源，建議您重新部署，而不是等待支援工程師嘗試復原已刪除的資源。

  • 強制執行原則。 Azure 原則提供一個架構來強制執行及稽核安全性和可靠性基準，以確保符合任務關鍵性應用程式的一般工程準則。 更具體來說，Azure 原則構成 Azure Resource Manager控制平面的重要部分，藉由限制授權使用者可以執行的動作來補充 RBAC。 您可以使用Azure 原則，跨平臺服務強制執行重要的安全性和可靠性慣例。

  • 修改和刪除資源。 您可以 鎖定 Azure 資源 ，以防止它們遭到修改或刪除。 不過，鎖定會在部署管線中引進管理額外負荷。 對於大部分的資源，我們建議使用緊密限制的強固 RBAC 程式，而不是資源鎖定。

設計建議

  • 自動化容錯移轉程式。 對於主動/主動模型，請使用健康情況模型和自動化調整作業，以確保不需要容錯移轉介入。 針對主動/被動模型，請確定容錯移轉程式已自動化，或至少在管線內進行編碼。

  • 針對支援 Azure 原生自動調整的服務，優先使用 Azure 原生自動調整。 對於不支援原生自動調整的服務，請使用自動化作業程式來調整服務。 使用具有多個服務的縮放單位來達成延展性。

  • 使用平臺原生功能進行備份和還原，確保它們符合 RTO/RPO 和資料保留需求。 視需要定義長期備份保留的策略。

  • 使用 SSL 憑證管理和更新的內建功能，例如 Azure Front Door 所提供的功能。

  • 對於外部小組，請為需要協助的資源建立復原程式。 例如，如果資料平臺未正確修改或刪除，則應該充分瞭解復原方法，而且應該就地復原程式。 同樣地，建立在登錄中管理已解除委任容器映射的程式。

  • 在標準商務持續性準備過程中，事先練習非生產資源和資料的復原作業。

  • 識別重大警示，並定義目標物件和系統。 定義清楚的通道，以觸達適當的專案關係人。 只傳送可採取動作的警示，以避免白色雜訊，並防止操作專案關係人忽略警示和遺漏重要資訊。 實作持續改善，以優化警示並移除觀察到的白色雜訊。

  • 套用原則導向的治理和Azure 原則，以確保在所有應用程式服務中使用適當的作業功能和可靠的設定基準。

  • 避免在暫時區域資源上使用資源鎖定。 相反地，請依賴適當的 RBAC 和 CI/CD 管線來控制作業更新。 您可以套用資源鎖定，以防止刪除長期全域資源。

更新管理

任務關鍵性設計強式背書暫時無狀態應用程式資源的原則。 如果您套用此原則，您通常可以使用新的部署和標準傳遞管線來執行更新。

設計考量

  • 與 Azure 藍圖一致。 將您的工作負載與 Azure 藍圖保持一致，讓平臺資源和執行時間相依性定期更新。

  • 自動偵測更新。 設定程式以監視並自動偵測更新。 使用 GitHub Dependabot之類的工具。

  • 測試和驗證。 在任何發行之前，測試及驗證生產內容中的新版本套件、元件和相依性。 新版本可能包含重大變更。

  • 執行時間相依性。 將執行時間相依性視為對應用程式所做的任何其他變更。 較舊的版本可能會造成安全性弱點，而且可能會對效能造成負面影響。 監視應用程式執行時間環境，並將其保持在最新狀態。

  • 元件清理和清理。 解除委任或移除未使用的資源。 例如，監視容器登錄，並刪除您未使用的舊映射版本。

設計建議

  • 監視這些資源，並使其保持在最新狀態：

    • 應用程式裝載平臺。 例如，您需要定期更新 Azure Kubernetes Service (AKS) 中的 Kubernetes 版本，特別是因為舊版的支援不會持續。 您也需要更新在 Kubernetes 上執行的元件，例如 cert-manager 和 Azure 金鑰保存庫 CSI，並將它們與 AKS 中的 Kubernetes 版本一致。
    • 外部程式庫和 SDK (.NET、JAVA、Python) 。
    • Terraform 提供者。

  • 避免手動變更更新元件。 請考慮只在緊急情況下使用手動變更。 請確定您有將任何手動變更重新協調回來源存放庫的程式，以避免漂移和問題週期。

  • 建立從Azure Container Registry移除舊版映射的自動化程式。

祕密管理

金鑰、秘密和憑證到期是應用程式中斷的常見原因。 任務關鍵性應用程式的秘密管理必須提供必要的安全性，並提供適當的可用性層級，以符合您最大的可靠性需求。 您必須使用受控服務或作為更新管理的一部分，定期執行金鑰、秘密和憑證輪替，並套用程式以進行程式碼和設定變更。

許多 Azure 服務都支援Microsoft Entra驗證，而不是依賴連接字串/金鑰。 使用Microsoft Entra識別碼可大幅降低作業額外負荷。 如果您使用秘密管理解決方案，它應該與其他服務整合、支援區域性和區域備援，並提供驗證和授權的Microsoft Entra識別碼整合。 金鑰保存庫提供這些功能。

設計考量

秘密管理的常見方法有三種。 每個方法都會從秘密存放區讀取秘密，並在不同的時間將它們插入應用程式。

  • 部署時間擷取。 這種方法的優點是秘密管理解決方案只有在部署時才能使用，因為該時間之後沒有直接相依性。 範例包括將秘密作為環境變數插入 Kubernetes 部署或 Kubernetes 秘密中。

    只有部署服務主體才能存取秘密，這可簡化秘密管理系統內的 RBAC 許可權。

    不過，這種方法有缺點。 它引進了 DevOps 工具中有關控制服務主體存取和應用程式中的 RBAC 複雜度，以及保護擷取的秘密。 此外，不會套用秘密管理解決方案的安全性優點，因為此方法只依賴應用程式平臺中的存取控制。

    若要實作秘密更新或輪替，您必須執行完整重新部署。

  • 應用程式啟動擷取。 在此方法中，會在應用程式啟動時擷取和插入秘密。 優點是您可以輕鬆地更新或輪替秘密。 您不需要在應用程式平臺上儲存秘密。 需要重新開機應用程式，才能擷取最新的值。

    常見的儲存體選擇包括Azure 金鑰保存庫 Provider for Secrets Store CSI Driver和akv2k8s。 您也可以使用原生 Azure 解決方案金鑰保存庫參考的應用程式設定。

    此方法的缺點是它會建立秘密管理解決方案的執行時間相依性。 如果秘密管理解決方案遇到中斷情況，應用程式元件可能仍可繼續處理要求。 任何重新開機或向外延展作業都可能導致失敗。

  • 執行時間擷取。 從應用程式本身的執行時間擷取秘密是最安全的方法，因為即使應用程式平臺永遠不會存取秘密也一樣。 應用程式必須向秘密管理系統驗證本身。

    不過，針對這種方法，應用程式元件需要直接相依性和秘密管理系統的連線。 這讓您難以個別測試元件，而且通常需要使用 SDK。

設計建議

  • 可能的話，請使用Microsoft Entra驗證來連線到服務，而不是使用連接字串或金鑰。 將此驗證方法與 Azure 受控識別搭配使用，因此您不需要將秘密儲存在應用程式平臺上。

  • 利用金鑰保存庫中的到期設定，並設定即將到期的警示。 使用標準發行程式執行所有金鑰、秘密和憑證更新。

  • 將金鑰保存庫實例部署為區域戳記的一部分，以減輕單一部署戳記失敗的潛在影響。 針對全域資源使用不同的實例。 如需這些資源的相關資訊，請參閱任務關鍵性工作負載的一般 架構模式 。

  • 若要避免需要管理服務主體認證或 API 金鑰，請盡可能使用受控識別，而不是服務主體來存取金鑰保存庫。

  • 實作程式碼撰寫模式，以確保在執行時間發生授權失敗時，會重新擷取秘密。

  • 套用在解決方案內定期執行的完全自動化金鑰輪替程式。

  • 使用Azure 金鑰保存庫中的金鑰即將到期通知，以取得即將到期的警示。

使用 VM 時的 IaaS 特定考慮

如果您需要使用 IaaS VM，本檔稍早所述的一些程式和做法可能會有所不同。 使用 VM 可提供更多彈性的組態選項、作業系統、驅動程式存取、低階作業系統存取，以及您可以安裝的軟體種類。 缺點是增加營運成本，以及當您使用 PaaS 服務時，通常會由雲端提供者執行的工作責任。

設計考量

  • 個別 VM 不提供高可用性、區域備援或異地備援。
  • 部署個別 VM 之後不會自動更新。 例如，在 Windows Server 2019 上部署的 SQL Server 2019 不會自動更新為較新版本。
  • 如果您想要透過基礎結構即程式碼部署和設定服務，在 VM 中執行的服務需要特殊處理和其他工具。
  • Azure 會定期更新其平臺。 這些更新可能需要重新開機 VM。 需要重新開機的匯報通常會事先宣佈。 請參閱 Azure 中的虛擬機器維護 及 處理計劃性維護通知。

設計建議

  • 避免在 VM 上進行手動作業，並實作適當的程式來部署和推出變更。

    • 使用 Azure Resource Manager (ARM) 範本、Bicep、Terraform 或其他解決方案等基礎結構即程式碼解決方案，自動布建 Azure 資源。

  • 請確定 VM、更新和備份和復原的部署作業程式已就緒並經過適當測試。 若要測試復原能力，請將錯誤插入應用程式、記下失敗，並減輕這些失敗。

  • 如果較新的版本無法正常運作，請確定策略已就緒，以回復到最後一個已知的狀況良好狀態。

  • 為具狀態工作負載建立頻繁的備份、確保備份工作有效運作，以及針對失敗的備份程式實作警示。

  • 監視 VM 並偵測失敗。 監視的原始資料可能來自各種來源。 分析問題的原因。

  • 請確定排定的備份如預期般執行，並視需要建立定期備份。 您可以使用 備份中心 來取得見解。

  • 優先使用虛擬機器擴展集，而不是 VM 來啟用規模、自動調整和區域備援等功能。

  • 優先使用來自Azure Marketplace的標準映射，而不是需要維護的自訂映射。

  • 使用 Azure VM 映射產生器 或其他工具，視需要將自訂映射的建置和維護程式自動化。

除了這些特定建議之外，請適當地針對任務關鍵性應用程式案例套用作業程式的最佳做法。

後續步驟

檢閱任務關鍵性應用程式案例的架構模式：

架構模式