Share via

Automation

  • 發行項

在軟體定義的雲端基礎結構中，小組會使用各種工具和技術來布建、設定及管理基礎結構。 隨著您的小組發展及成長，他們可以從使用入口網站轉換，以及手動工作，以使用程式碼和自動化來布建、設定及管理基礎結構和服務。

平臺自動化考慮

  • 實作所有專案即程式碼 (EaC) 方法，可讓小組解除鎖定重要優點、建立強大的開發文化，並讓每個小組的每個人都能瞭解部署資源的方式和部署方式。 EaC 也可協助平臺小組採用重要的開發做法，以改善其靈活度和效率。 您的小組可以追蹤變更，並控制哪些變更會移至生產環境，方法是在存放庫中儲存程式碼，以及使用版本控制系統來管理它。
  • Teams 可以遵循4 眼準則，並使用對等程式設計或對等檢閱來確保永遠不會單獨進行程式碼變更。 對等程式設計與對等檢閱可改善程式碼品質、讓小組共同負責變更，以及增加小組對於同意和部署專案的知識。 程式碼檢閱是小組成員學習編碼和自動化的新技術和方法的絕佳方式。
  • Teams 應該使用 Git 之類的版本控制系統以及 Git 存放庫，以強制執行對等檢閱。 Git 存放庫可讓您的小組定義重要的分支，並使用 分支原則來保護它們。 您可以使用原則來要求這些分支上的程式碼變更，以符合特定準則，例如最少的小組成員核准，才能合併至受保護的分支。
  • Teams 應該將 EaC 方法和變更檢閱程式與 持續整合和持續傳遞 (CI/CD) 程式連接在一起。 每個程式碼變更都應該自動觸發 CI 程式，以執行靜態程式碼分析、驗證和測試部署。 CI 可確保開發人員在早期 (檢查其程式碼，通常稱為 快速 或 向左移測試) 是否有可能導致未來問題的錯誤。 根據小組所使用的 分支策略 ，任何重要分支的變更都應該觸發部署到不同的 環境。 一旦核准變更併合並到 main ，CD 程式就會將這些變更部署到生產環境。 此程式碼管理系統為您的小組提供每個環境中執行之專案 的單一事實來源 。
  • 為了確保您的平臺完全自我修復，並為工作負載小組提供自助，您的平臺小組必須努力將所有專案自動化， (通常稱為 「極端自動化 」) ，從布建、設定和平臺管理到工作負載小組的登陸區域訂用帳戶布建。 極端自動化可讓您的平臺小組專注于提供價值，而不是部署、設定及管理您的平臺。 極端自動化也會建立自我增強迴圈，讓您的小組有更多時間建置更多自動化。
  • 隨著您的平臺小組自動化營運活動並減少人為介入，他們應該將其焦點轉移到在 Azure 上啟用和加速工作負載小組創新的重要工作。 為了達成此目的，您的平臺小組必須逐一查看多個週期的建置和開發，因為它們會放置您平臺的工具、腳本和功能增強功能。
  • 有多個選項可協助您的小組開始使用其 Azure 登陸區域部署。 這些選項取決於目前的小組功能，而且隨著小組發展而成長。 更具體來說，針對 平臺部署，您可以根據個別 Teams 的 IaC 熟練度和工具喜好設定，在入口網站、Bicep 或 Terraform 型體驗之間進行選擇。
    • 仍在瞭解 基礎結構即程式碼的新和新興平臺小組 (IaC) ，且更熟悉使用入口網站來部署和管理資源，可以使用 Azure 登陸區域加速器 來啟動，這可支援仍使用 ClickOps 方法的團隊。 ClickOps 是透過按一下入口網站、管理主控台和精靈來布建、設定和管理資源的程式。 此加速器可讓您的小組使用入口網站作為初始部署工具，並隨著平臺工程成熟度成長，進一步使用 Azure CLI、PowerShell 或 IaC。
    • AzOps 解決方案可讓小組發展其平臺自動化和管理做法，從ClickOps驅動到支援 DevOps。 您的小組可以從使用其個人帳戶存取權轉換至使用 DevOps 原則和做法，只依賴 CI/CD 與 AzOps 和 IaC。 AzOps 可讓小組攜帶自己的架構、在初始入口網站型部署之後 (使用 Azure 登陸區域入口網站加速器所部署的架構，因為 AzOps 整合不屬於 ALZ 入口網站體驗) 、與 brownfield 部署整合，或使用自訂範本 (Bicep 或 ARM) 來建置及運作您的平臺。
    • 具有已建立技能和功能的平臺小組可以採用遵循 DevOps 原則和做法的已撰寫方法。 您的小組應該以 IaC 和新式開發作法為基礎，從在其個人帳戶上使用 Azure 存取，以及透過 CI/CD 管線執行所有作業。 您的小組應該使用以 IaC 為基礎的加速器，例如 ALZ-Bicep 或 Azure 登陸區域 Terraform 模組 來加速此轉換。
  • 以 IaC 為基礎的加速器具有有限的管理範圍。 新版本提供更多功能和增加的資源管理功能。 如果使用加速器，您的小組應該考慮以加速器開頭的分層方法，然後新增一層自動化。 自動化層提供小組所需的功能，以透過繼承應用程式的網域控制站部署等平臺功能，完全支援工作負載小組。
  • 當平臺小組轉換至 DevOps 方法時，他們必須建立處理緊急修正的程式。 他們可以使用Privileged Identity Management (PIM) 合格許可權來要求存取權以執行修正，稍後將它帶回程序代碼來限制設定漂移，或者可以使用程式碼來實作快速修正。 您的小組應該一律在其待辦專案中註冊快速修正程式，讓他們可以在稍後重新處理每個修正程式，並限制其技術債務。 由於某些平臺程式碼未完整檢閱，且不符合小組程式碼指導方針和原則，因此技術債務過多會導致未來的減速。
  • 您可以使用 Azure 原則 ，將一些自動化新增至您的平臺。 請考慮使用 IaC 來部署和管理 Azure 原則，通常稱為原則即程式碼 (PaC) 。 這些原則可讓您自動化記錄收集之類的活動。 許多 PaC 架構也會實作豁免程式，因此請規劃工作負載小組以要求原則豁免。
  • 當工作負載小組嘗試部署不符合安全性控制的資源時，請使用「原則驅動控管」向工作負載小組發出訊號。 請考慮部署 deny 具有這些情況之效果的原則，這可讓您的工作負載小組也將 [所有專案] 視為程式碼，並避免程式碼在部署時宣告一件事和原則變更設定的設定漂移。 避免使用 modify 效果，例如，如果工作負載小組部署在其程式碼中定義的儲存體帳戶 supportOnlyHttpsTraffic = false ，其中 modify 原則會在部署時間變更 true 為 ，使其符合規範。 這會導致程式碼偏離所部署的內容。

平臺自動化設計建議

  • 遵循 所有專案即程式碼 方法，以取得 Azure 平臺、檔、部署和測試程式的完整透明度和設定控制。
  • 使用 版本控制 來管理所有程式碼存放庫，包括：
    • 基礎結構即程式碼
    • 原則即程式碼
    • 設定即程式碼
    • 部署為程式碼
    • 檔即程式碼
  • 實 作 4 眼原則 和 對等程式 設計或 對等檢閱 的程式，以確保您的小組會先檢閱所有程式碼變更，再部署到生產環境。
  • 為您的小組採用 分支策略 ，並為您想要保護的 分支設定分支原則 。 使用分支原則時，小組必須使用 提取要求 來進行合併變更。
  • 使用 持續整合和持續傳遞 (CI/CD) ，將程式碼測試和部署自動化至不同的環境。
  • 工作以 自動化所有專案，例如您平臺的布建、設定和管理，以及為您的工作負載小組布建登陸區域訂用帳戶。
  • 使用符合您小組功能的其中一個可用加速器，開始部署 Azure 登陸區域。
  • 規劃使用分層部署方法來新增加速器未涵蓋的功能，但必須完全支援您的工作負載小組。
  • 建立程式，以使用程式碼來實作快速修正。 請一律在小組待辦專案中註冊快速修正程式，以便在稍後重新工作每個修正程式，而且您可以限制技術債務。
  • 使用 基礎結構即程式碼 來部署和管理 Azure 原則 (通常稱為原則即程式碼)
  • 實作原則的豁免程式。 規劃工作負載小組以要求豁免原則，並準備好在需要時解除封鎖小組。
  • 當工作負載小組嘗試部署不符合安全性控制的資源時，請使用「原則驅動治理」來封鎖工作負載小組。 這有助於減少設定漂移，其中程式碼會宣告與最終部署狀態不同的狀態。

閱讀更多資訊