共用方式為

自動化

  • 發行項

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

平臺自動化考慮

  • 實施一切皆代碼（EaC）的方法可以讓團隊發揮關鍵優勢，建立強大的開發文化，並使每個小組的成員都能檢查資源的部署方式和具體項目。 EaC 也可協助平臺小組採用可改善其靈活度和效率的重要開發做法。 您的小組可以追蹤變更，並控制哪些變更會移至生產環境，方法是將程式代碼儲存在存放庫中，並使用版本控制系統來管理它。
  • Teams 可以遵循 四眼原則，並使用 結對程式設計 或 代碼審查，以確保程式碼變更不會單獨進行。 對等程式設計與對等檢閱可改善程式代碼品質、讓小組共同負責變更，以及增加小組對所同意和部署內容的知識。 程式代碼檢閱是小組成員學習編碼和自動化的新技術和方法的絕佳方式。
  • Teams 應該使用 Git 等版本控制系統，以及 Git 儲存庫，以促進對等檢閱。 Git 存放庫可讓您的小組定義重要的分支，並使用分支原則加以保護。 您可以使用政策來要求分支上的程式碼變更必須符合特定準則，例如需要至少取得小組成員的核准，才能在整合進入受保護分支之前完成合併。
  • 團隊應將 EaC 方法和變更檢閱流程透過 持續整合和持續交付（CI/CD） 流程連接在一起。 每個程式代碼變更都應該自動觸發 CI 程式，以執行靜態程式代碼分析、驗證和測試部署。 CI 可確保開發人員儘早檢查其程式代碼（通常稱為 快速失效，或 左移測試），找出可能導致未來問題的錯誤。 根據小組 使用哪些 分支策略，任何重要分支的變更都應該觸發部署至不同的 環境。 一旦核准變更並合併至 main，CD 程式會將這些變更部署到生產環境。 此程式代碼管理系統為您的小組提供 單一真實來源，以了解在每個環境中運行的內容。
  • 為了確保您的平台完全具備自我修復的能力，並為工作負載團隊提供自助服務，您的平台團隊必須努力將從資源布建、設定、平台管理到為工作負載團隊設置登陸區域訂閱的所有過程自動化（這通常稱為「極端自動化」）。 極端自動化可讓您的平臺小組專注於提供價值，而不是部署、設定和管理您的平臺。 極端自動化也會建立自我增強週期，讓您的小組有更多時間建置更多自動化。
  • 隨著您的平臺小組自動化作業活動並減少人為介入，他們應該將其焦點轉移到重要工作，以啟用和加速 Azure 上的工作負載小組創新。 為了達成此目的，您的平臺小組必須反覆進行多個建置和開發週期，實施平臺的工具、腳本和能力增強。
  • 有多個選項可協助您的小組開始使用其 Azure 登陸區域部署。 這些選項取決於您團隊目前的功能，而且隨著小組的發展而成長。 更具體來說，針對 平臺部署，您可以根據基礎結構即程序代碼 （IaC） 的熟練程度和個別小組的工具喜好設定，在入口網站、Bicep 或 Terraform 型體驗之間進行選擇。
    • 尚在了解 IaC 並熟悉使用入口網站來部署和管理資源的新興平臺團隊，可以使用 Azure 登陸區加速器。 此加速器支援目前使用 ClickOps 方法的小組。 ClickOps 是透過按兩下入口網站、管理主控台和精靈來布建、設定和管理資源的程式。 此加速器可讓您的小組使用入口網站作為初始部署工具。 隨著平臺工程成熟度的增長，您的小組可以逐漸納入 Azure CLI、PowerShell 或 IaC。
    • AzOps 解決方案 可讓團隊將其平台自動化和管理實踐從 ClickOps 驅動轉變為具備 DevOps 能力。 您的小組可以從使用其個人帳戶存取權轉換至使用僅依賴 CI/CD 與 AzOps 和 IaC 的 DevOps 原則和做法。 AzOps 可讓您的小組自備架構、使用 Azure 登陸區域入口網站加速器所部署的架構（在初始入口網站型部署之後，因為 AzOps 整合不屬於 ALZ 入口網站體驗的一部分）、與棕色地帶部署整合，或使用自定義範本 （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 原則 （通常稱為政策即代碼）
  • 為政策實施豁免流程。 規劃工作負載團隊請求政策豁免，並在需要時準備好解除小組的阻礙。
  • 當工作負載小組嘗試部署不符合安全性控制的資源時，請使用「原則驅動治理」來封鎖工作負載小組。 這有助於減少組態漂移，其中程式代碼宣告的狀態與最終部署的狀態不同。

閱讀更多