DevOps 小組組織結構

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

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

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

圖表，說明康威的法律。

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

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

反向 Conway 機動操作圖表。

此原則導向了刻意設計的小組拓撲，小組需對其擁有的任何應用程式、系統或平台進行端到端責任管理，以達成 DevOps 的全面實踐。

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

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

設計考慮

建立跨功能平臺小組，以設計、建置、布建、管理和維護 Azure 登陸區域生命週期。此小組可以包含來自中央 IT 小組、安全性、合規性和業務單位的成員，以確保代表您企業的廣泛範圍。請務必避免反模式。
請考慮建立一個支援小組，以提供DevOps功能，用來支援那些沒有現有DevOps能力的應用程式和平臺，或缺乏建立DevOps能力商業理由的情況（例如，僅具最少開發能力的舊版應用程式）。
請勿將應用程式工作負載團隊限制在中心資源上，因為這可能會妨礙他們的靈活性。您可以使用政策驅動的治理和 Azure 角色型存取控制（Azure RBAC）來實施一致的基準設定，並確保應用程式（業務單位）團隊具有足夠的彈性以進行創新，同時仍然能夠利用一組預先定義的範本。
請勿強制應用程式小組針對應用程式資源具現化或管理使用中央程式或布建管線。已依賴DevOps管線進行應用程式傳遞的現有小組仍然可以使用其目前的工具。請記住，您可以使用 Azure 原則來協助強制執行組織標準，並大規模評估合規性，並解決 DevOps 程式安全性考慮。
DevOps 模型的全面應用不會立即建立可用的DevOps小組。
對工程功能和資源的投資至關重要。
某些舊版應用程式的應用程式小組可能不需要符合 DevOps 策略所需的工程資源。

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

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

建立營運適能評核的核心程序，讓您完全瞭解團隊結構可能出現的問題。

下列清單為負責 Azure 著陸區的平臺小組提供一組建議的功能：

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

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

下列清單為負責協助其他小組的提供支持的小組提供建議的一組功能：

小組之間的互動目標是：

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

互動模式	描述
共同作業	團隊密切合作。
X 即服務	各小組之間以最低限度的合作來取用或提供一些東西，這與第三方廠商的互動相似。
促進	小組協助或由另一個小組協助移除障礙。