可靠和有效的操作必須基於 盡可能自動化 的原則，並以 代碼配置為基礎。 這種方法需要對 DevOps 流程進行大量的工程投資。 自動化管線可用來部署應用程式和基礎設施程式碼件。 這種方法的好處包括以最少的手動操作程序獲得一致且準確的操作結果。
此設計領域探討如何實作有效且一致的作業程序。
這很重要
本文是 Azure 架構完善框架中任務關鍵型工作負載 系列的一部分。 如果您不熟悉此系列，我們建議您從什麼是使命關鍵工作負載？開始。
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 原生自動縮放的服務。 對於不支援原生自動調整的服務，請使用自動化作業程序來調整服務。 使用具有多個服務的縮放單位來達到延展性。
使用平台原生功能進行備份和還原，確保它們符合您的 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 ID 可大幅減少作業額外負荷。 如果您確實使用秘密管理解決方案，它應該與其他服務整合、支援區域和區域備援，並提供與 Microsoft Entra ID 的整合以進行驗證和授權。 Key Vault 提供這些功能。
設計考量
秘密管理有三種常見的方法。 每種方法都會從秘密存放區讀取秘密，並在不同的時間將它們插入應用程式。
部署時擷取。 此方法的優點是，秘密管理解決方案只需要在部署時可用，因為該時間之後沒有直接相依性。 範例包括將密碼作為環境變數插入 Kubernetes 部署或 Kubernetes 密碼。
只有部署服務主體需要能夠存取秘密，這可簡化秘密管理系統內的 RBAC 權限。
然而，這種方法也有缺點。 它會在 DevOps 工具中引進 RBAC 複雜度，以控制服務主體存取，以及在應用程式中保護擷取的秘密。 此外，不會套用秘密管理解決方案的安全性優點，因為此方法僅依賴應用程式平台中的存取控制。
若要實作秘密更新或輪替，您需要執行完整的重新部署。
應用程式啟動時資料提取。 在這種方法中，會在應用程式啟動時擷取並注入秘密。 好處是您可以輕鬆更新或輪替秘密。 您不需要在應用程式平台上儲存秘密。 需要重新啟動應用程式才能取得最新值。
常見的儲存體選擇包括 Azure Key Vault Provider for Secrets Store CSI Driver 和 akv2k8s。 原生的 Azure 解決方案「Key Vault 參考的應用程式設定」也可使用。
此方法的缺點是它會建立對秘密管理解決方案的執行階段相依性。 如果密碼管理解決方案發生中斷，已執行的應用程式元件 可能 能夠繼續處理要求。 任何重新啟動或橫向擴充作業都可能導致失敗。
執行階段擷取。 在執行階段從應用程式本身內擷取密碼是最安全的方法，因為即使是應用程式平台也永遠無法存取密碼。 應用程式需要向秘密管理系統驗證自己。
不過，對於此方法，應用程式元件需要直接相依關係，以及與秘密管理系統的連線。 這使得單獨測試組件變得更加困難，並且通常需要使用 SDK。
設計建議
可能的話，請使用 Microsoft Entra 驗證來連線到服務，而不是使用連接字串或金鑰。 將此驗證方法與 Azure 受控識別搭配使用，因此您不需要在應用程式平臺上儲存秘密。
利用 Key Vault 中的到期設定，並設定即將到期的 警示 。 使用標準發行程序執行所有金鑰、秘密和憑證更新。
將 Key Vault 執行個體部署為區域戳記的一部分，以減輕失敗對單一部署戳記的潛在影響。 使用單獨的實例來管理全域性資源。 如需這些資源的相關資訊，請參閱關鍵任務工作負載的一般 架構模式 。
若要避免需要管理服務主體認證或 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 映像產生器 或其他工具，視需要將自訂映像的建置和維護程式自動化。
除了這些特定建議之外，請視需要套用關鍵任務應用程式案例的作業程序最佳實務。
後續步驟
檢閱任務關鍵性應用程式案例的架構模式：