分享方式：

DevOps 小組拓撲

  • 文章

IT 小組與應用程式小組之間角色、責任和信任的分佈，對於大規模雲端採用所涉及的作業轉換至關重要。

IT 小組致力於維護控制。 應用程式擁有者會尋求最大化靈活度。 您在這兩個目標之間最終建立的平衡，會大幅影響雲端作業模型的成功。

根據康威的法律，團隊會根據其溝通結構產生架構。 當您努力實現自主與控制之間的必要平衡時，瞭解這一原則非常重要。 任何設計系統的組織（廣泛定義）都會產生設計結構，該結構是該組織通訊結構的複本。

說明康威法的圖表。

從 DevOps 的觀點來看，組織必須優化以快速回應客戶需求。 在具有下列特性的架構中，擁有、設計和實作其應用程式和系統的 Teams 會尋找其最高層級的自主性：

  • 支援常數變更的進化架構
  • 可部署性
  • 可測試性

康威的解決方案是擺脫康威的法律。 如果您的組織遵循特定結構來產生服務和產品，而且想要優化，您需要重新思考您的組織結構。 發展您的小組和組織結構，以達成您所需的架構。

反向康威機動圖。

此原則會導致刻意設計 小組拓撲 ，讓小組負責其擁有的任何應用程式、系統或平臺的端對端，以達成 DevOps 的完整專業領域。

下表提供這些小組的簡化分類。

團隊類型 定義
應用程式工作負載小組 這些小組會建置應用程式，以推動業務領域區段的直接業務成果。 在 Azure 登陸區域的內容中，這些小組負責應用程式工作負載的端對端生命週期。
平臺小組 這些小組會建置吸引人的內部平臺，以加速傳遞，並減少應用程式工作負載小組的認知負載。 在 Azure 登陸區域的內容中，這些小組負責 Azure 登陸區域的端對端生命週期。
啟用小組 這些小組可協助其他具有 DevOps 等特殊功能的小組，協助克服技能差距。

設計考量

  • 建立跨功能平臺小組，以設計、建置、布建、管理和維護 Azure 登陸區域生命週期。 此小組可以包含來自中央 IT 小組、安全性、合規性和業務單位的成員，以確保代表您企業的廣泛範圍。 請確定您避免 反模式。

  • 請考慮建立啟用小組，以提供DevOps函式來支援沒有現有DevOps功能的應用程式和平臺，或建立一個商務案例（例如，具有最少開發功能的舊版應用程式）。

  • 請勿將應用程式工作負載小組限制為中央成品，因為它可能會阻礙其靈活度。 您可以使用原則驅動的治理和 Azure 角色型訪問控制（Azure RBAC）來強制執行一致的基準設定，並確保應用程式（業務單位）小組具有足夠的彈性，以創新，但仍能夠從一組預先定義的範本中繪製。

  • 請勿強制應用程式小組針對應用程式資源具現化或管理使用中央程式或布建管線。 已依賴DevOps管線進行應用程式傳遞的現有小組仍然可以使用其目前的工具。 請記住，您可以使用 Azure 原則 協助強制執行組織標準，並大規模評估合規性，並解決DevOps程式的安全性考慮。

  • DevOps 模型的全面應用不會立即建立可用的DevOps小組。

  • 對工程功能和資源的投資至關重要。

  • 某些舊版應用程式的應用程式小組可能不需要符合 DevOps 策略所需的工程資源。

設計建議

下列各節包含設計建議，可引導您設計小組拓撲。

讓小組拓撲與您的雲端作業模型保持一致

請確定您已將小組拓撲與所需的 雲端作業模型對齊。

建立操作健身檢閱的核心程式，讓您完全瞭解小組結構所產生的問題。

定義平臺小組的函式

下列清單為負責 Azure 登陸區域的平臺小組提供一組建議的函式：

  • 架構治理
  • 必要網路、身分識別和存取管理原則的訂用帳戶布建和委派
  • 平臺管理和監視 （整體）
  • 成本管理（整體）
  • 平台即程式代碼 （樣本、腳稿和其他資產的管理）
  • Microsoft Entra 租使用者內 Microsoft Azure 的整體作業（服務主體管理、Microsoft Graph API 註冊和角色定義）
  • Azure RBAC （整體）
  • 中央服務的金鑰管理（簡單的郵件傳輸通訊協定和域控制器）
  • 原則管理和強制執行（整體）
  • 安全性監視和稽核 （整體）
  • 網路管理（整體）

定義應用程式工作負載小組的函式

下列清單為負責應用程式工作負載的應用程式小組提供一組建議的函式：

  • 透過 DevOps 模型建立和管理應用程式資源
  • 資料庫管理
  • 應用程式移轉或轉換
  • 應用程式管理和監視 （應用程式資源）
  • Azure RBAC （應用程式資源）
  • 安全性監控和稽核 （應用程式資源）
  • 秘密與金鑰管理（應用程式金鑰 ）
  • 成本管理（應用程式資源）
  • 網路管理（應用程式資源）

定義啟用小組的函式

下列清單為負責協助其他小組的啟用小組提供一組建議的函式：

  • 定義水準（跨函式）指引和功能，以協助在整個組織中取得正確的專業知識，以確保與您的整體目標雲端作業模型保持一致（例如 DevOps）
  • 支援、訓練和指導其他團隊，以達到必要的專業知識水準
  • 為您的應用程式或平臺小組建立一組通用的可重複使用範本和連結庫，以及培養 InnerSourcing，例如 Azure 已驗證的模組。

定義小組之間的互動模式

小組之間的互動目標是：

  • 實現自主性
  • 解除封鎖相依性
  • 將浪費時間降至最低
  • 避免瓶頸

小組拓撲 概述三種小組互動模式：

互動模式 描述
共同作業 Teams 密切合作。
X 即服務 Teams 會取用或提供其他小組的最小共同作業，類似於第三方廠商互動。
促進 小組協助或由另一個小組協助移除障礙。