Azure 上任務關鍵性工作負載的作業
就像任何應用程式一樣，變更會發生在任務關鍵性工作負載中。 應用程式會隨著時間演進、金鑰到期、修補程式將會發行等等。 所有變更和維護都應該使用部署管線來套用。 本文提供進行常見變更和更新的操作指引。
組織一致性對於作業程序同樣重要。 對於任務關鍵工作負載的運營成功至關重要，端到端的責任應落在一個小組，即 DevOps 小組。
技術執行應利用 Azure 原生平臺功能，以及使用自動化 Azure Pipelines 將變更部署至應用程式、基礎結構和組態。 同樣地，應該自動化維護工作，並避免手動工作。
下列各節說明處理不同類型的變更的方法。
應用程式自動化
持續整合與持續部署 （CI/CD） 可讓您正確部署和驗證任務關鍵性工作負載。 CI/CD 是將變更部署到任何環境、開發/測試、生產和其他環境的慣用方法。 對於關鍵任務的工作負載，下一節所列的變更應該會導致全新標記的部署。 在流量透過藍色/綠色部署策略路由傳送至戳記之前，應該在發行程式中徹底測試新的戳記。
下列各節說明應該在可能的情況下透過 CI/CD 實現的變更。
應用程式變更
應用程式程式代碼的所有變更都應該透過 CI/CD 來部署。 程式代碼應該建置、規範化，並測試以防止退化。 應監視應用程式相依性，例如運行時間環境或套件，並透過CI/CD部署更新。
基礎結構變更
基礎結構應建立模型並布建為程序代碼。 這種做法通常稱為基礎結構即程序代碼（IaC）。 IaC 的所有變更都應該透過 CI/CD 管線進行部署。 基礎結構的更新，例如修補OS也應該透過CI/CD管線進行管理。
組態變更
設定變更是應用程式中斷的常見原因。 為了對抗這些中斷，應以程序代碼的形式擷取應用程式或基礎結構的設定。 這種做法稱為「配置即代碼」（CaC）。 CAC 變更應該透過 CI/CD 管線進行部署。
程式庫/SDK 更新
對於任務關鍵的應用程式，當新版本可供使用時，更新原始程式碼和相依性是至關重要的。 建議的方法是利用原始程式碼存放庫中的組態管理變更程式。 它應該設定為自動建立各種相依性更新的提取要求，例如：
- .NET NuGet 套件
- JavaScript節點套件管理員套件
- Terraform 提供者
下列案例是使用 GitHub 存放庫中的 dependabot 自動更新程式庫的範例。
Dependabot 會偵測應用程式代碼中使用的函式庫和 SDK 更新
Dependabot 會更新分支中的應用程式代碼，並以這些變更建立針對主要分支的拉取請求（PR）。 PR 包含所有相關信息，並準備好進行最終檢閱。
完成程式代碼檢閱和測試時，PR 可以合併至主要分支。
對於相依性 dependabot 無法監視，請確定您有程式可偵測新版本。
密鑰/秘密/憑證輪替
定期更換（更新）金鑰和密鑰應該是任何工作流程中的標準流程。 如果秘密在被暴露後或是為了安全考量而定期地進行更換，可能需要在短時間內做變更。
由於過期或無效的秘密可能會導致應用程式 中斷（請參閱失敗分析），因此必須有明確定義且經過證實的程式。 針對 Azure 任務關鍵，戳記只預期會存上幾個星期。 因此，輪換戳記資源的秘密無需擔心。 如果一個戳記中的秘密過期，整個應用程式會繼續運作。
不過，管理存取長期全球資源的秘密非常重要。 值得注意的範例是 Azure Cosmos DB API 密鑰。 如果 Azure Cosmos DB API 金鑰過期，所有戳記都會同時受到影響，並導致應用程式完全中斷。
下列方法是 Azure 經過任務關鍵性測試與記錄的方式，用於在不造成執行於 Azure Kubernetes Service 中之服務中斷的情況下，輪替 Azure Cosmos DB 的密鑰。
使用次要金鑰更新戳記。 預設情況下，Azure Cosmos DB 的主要 API 金鑰會作為秘密儲存在每個部署中的 Azure Key Vault 中。 建立 PR，以更新使用次要 Azure Cosmos DB API 金鑰的 IaC 範本程式碼。 透過一般的PR檢閱和更新程序執行這項變更，以部署為新版本或作為一次Hotfix。
（選擇性）如果將更新部署為熱修復至現有的版本，Pod 會在幾分鐘後自動從 Azure Key Vault 獲取新的密鑰。 不過，Azure Cosmos DB 用戶端程式代碼目前不會使用變更的密鑰重新初始化。 若要解決此問題，請使用叢集上的下列命令手動重新啟動所有 Pod：
kubectl rollout restart deployment/CatalogService-deploy -n workload kubectl rollout restart deployment/BackgroundProcessor-deploy -n workload kubectl rollout restart deployment/healthservice-deploy -n workload新部署或重新啟動的 Pod 現在會使用次要 API 金鑰來連線至 Azure Cosmos DB。
重新啟動所有戳記上的所有 Pod，或部署新的戳記之後，請重新產生 Azure Cosmos DB 的主要 API 金鑰。 以下是命令的範例：
az cosmosdb keys regenerate --key-kind primary --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup將 IaC 模板變更為使用主要 API 金鑰，以便未來的部署。 或者，您可以繼續使用次要金鑰，並在更新次要金鑰時切換回主要 API 金鑰。
警報
警示是瞭解您的環境是否有問題及何時發生問題的關鍵。 警示和/或動作群組的變更應該透過 CI/CD 管線實作。 如需有關警示的詳細資訊，請參閱 Azure上任務關鍵性工作負載的健康情況模型化和可觀察性。
自動化
在 Azure 上執行的許多平臺和服務都為常見的作業活動提供自動化。 此自動化包括自動調整和金鑰和憑證的自動化處理。
縮放
在應用程式設計中，應該確定定義整體郵戳縮放單位的縮放需求。 印章中的各個服務必須能夠擴展以滿足尖峰需求，或縮減以節省金錢或資源。
沒有足夠的資源的服務可能會顯示不同的副作用，包括下列清單：
- 處理佇列/發行項/分割區訊息的 Pod 數目不足，導致未處理的訊息數目不斷增加。 有時此結果被稱為增加的佇列深度。
- Azure Kubernetes Service 節點上的資源不足可能會導致 Pod 無法執行。
- 下列情況會導致限流請求：
- Azure Cosmos DB 的要求單位 （RU） 不足
- 事件中樞進階的處理單元或標準的輸送量單元（TU）不足
- Service Bus 進階層的傳訊單位不足
盡可能利用服務的自動調整功能，以確保您有足夠的資源來滿足需求。 以下是您可以利用的自動調整功能：
- 水平 Pod 自動調整 可讓您視需求增加或減少執行工作負載的 Pod 數目。
- AKS 叢集自動調整程式 可讓您視需求增加或減少叢集中的節點數目。
- 您可以 自動化調整 Azure 事件中樞的輸送量單位（標準層）
- 您可以 自動更新 Azure 服務總線命名空間的傳訊單位
管理金鑰、秘密和憑證
盡可能使用受控識別，以避免必須管理 API 金鑰或密碼，例如密碼。
當您使用金鑰、秘密或憑證時，請盡可能使用 Azure 原生平臺功能。 以下是這些平台層級功能的一些範例：
- Azure Front Door 具有 TLS 憑證管理和更新的內建功能。
- Azure Key Vault 支援自動密鑰輪替。
手動作業
有需要手動介入的作業活動。 這些程式應該經過測試。
寄不出的信件訊息
無法處理的訊息應路由至死信佇列，並為該佇列配置警示。 這些訊息通常需要手動介入，才能瞭解並減輕問題。 您應該建置檢視、更新及重新執行死信訊息的能力。
Azure Cosmos DB 還原
當 Azure Cosmos DB 數據意外刪除、更新或損毀時，您需要從定期備份執行還原。 從定期備份還原只能透過支援請求來完成。 此流程應該被記錄並定期測試。
配額增加
Azure 訂用帳戶具有配額限制。 達到這些限制時，部署可能會失敗。 某些配額是可調整的。 針對可調整的配額，您可以從 Azure 入口網站上 [我的配額] 頁面要求增加配額。 針對無法調整的配額，您必須提交支援要求。 Azure 支援小組會與您合作尋找解決方案。
重要
如需操作設計考慮和建議，請參閱 Azure 上任務關鍵性工作負載
貢獻者
Microsoft維護本文。 下列參與者撰寫本文。
主要作者：
若要查看非公開的 LinkedIn 配置檔，請登入 LinkedIn。
後續步驟
部署參考實作，以充分瞭解此架構中使用的資源及其組態。