新聞發布
管理系統類型一：開發運維順暢協作
這是 DevOps 的“樂土”：開發團隊和運營團隊之間順暢協作，每一個團隊都在需要的地方專業化工作，但也在需要的地方共享。
可能有許多獨立的開發團隊，但每個團隊又會在一個單獨或半獨立的產品組合上工作。我的感覺是，類型一的平滑協作模型需要相當大的組織變革來建立它，并且在管理團隊需要有較高的能力。
開發人員和運維人員必須有一個明確有效的共同目標（“高質量交付、快速迭代”或其他）。運維人員必須與開發人員進行舒適的合作，掌握測試驅動的編碼和 Git，開發人員必須認真對待運維特性，尋找運維人員以輸入日志記錄等等，所有這些相比較過去都需要進行相當大的文化變革。
類型一適用性：具有強大技術領導類型的組織
潛在有效性：高
類型二：全嵌入式/共享運維
當運維人員完全融入進產品開發團隊中的時候，我們看到了這種類型。Dev 和 Ops 之間的分離很少，以至于所有人都共同高度關注一個目標，這可以說是類型一的一種形式，不過它也具有一定特殊性。像 Netflix 和 Facebook 這樣的組織有效地實現了一個基于 Web 的產品，它已經實現了這種類型的結構。
但我認為它可能不太適用于狹窄產品線模式之外，因為預算限制和多個產品線之間通常存在上下文切換，這可能會迫使 Dev 和 Ops 進一步分開（例如回到類型一模型）。這個模式也可以被稱為“NoOps”，因為沒有明顯的或可見的運維團隊（盡管 Netflix NoOps 也可能是類型三）。
類型二適用性：基于單一 Web 的產品或服務的組織
潛在有效性：高
類型三：基礎設施即服務
對于具有相當傳統的 IT 運維部門的組織，他們無法或不能（足夠）快速作出改變，和對于在公共云（Amazon EC2、Rackspace、Azure 等）中運行所有應用程序的組織來說，將運維作為一個只需提供應用程序部署和運行功能的彈性基礎設施團隊或許比較有幫助。這樣內部運維團隊直接等同于 Amazon EC2 或基礎架構即服務。然后 Dev 中的團隊（可能是虛擬團隊）充當有關操作特性、度量、監控、服務器供應等方面的專業知識來源，并且可能與 Iaas 團隊進行大部分溝通。
然而這個團隊仍然是一個開發團隊，遵循諸如 TDD、CI、迭代開發、指導等標準實踐。IaaS 團隊結構具有一些潛在的有效性（失去與 Ops 人員直接協作），以便更容易實施，可能比類型一更快地獲得價值。
類型三適用性：具有幾種不同產品和服務、具有傳統運營部門或其應用程序完全在公共云中運行的組織
潛在有效性：中等
類型四：DevOps 即服務
一些組織，特別是較小的組織，可能沒有資金、經驗或工作人員來領導他們的軟件運維。開發團隊可能會接觸到像 Rackspace 這樣的服務提供商，去幫助他們建立測試環境并自動化其基礎設施和監控，并就軟件開發周期中實現的各種運維功能提供建議。
可以被稱之為 DevOps-as-a-Service 的應該是幫助小型團隊了解自動化、監控和配置管理的一種有效務實的方法。隨著業務的發展和更多的員工加入，可能轉向第三類甚至第一類模式。
類型四適應性：運營經驗有限的小型團隊或組織
有效潛力：中
類型五：臨時 DevOps 團隊
這個類型看起來和反類型 B 有極大的相似，但是實際上其本質意圖和長遠性是完全不同的。這個臨時團隊的任務是使 Dev 和 Ops 更緊密的聯合在一起，理想目標是完全轉型成類型一或二。臨時團隊成員將在 Dev-speak 和 Ops-speak 之間進行翻譯，并引入一些瘋狂的點子，例如為 Ops 團隊介紹站立會和看板系統，還有一些吹毛求疵的細節，例如為 Dev 團隊介紹負載均衡器，管理 NIC 和卸載 SSL。
如果有足夠多的人意識到 Dev 和 Ops 團隊結合后將帶來的價值，臨時團隊將有機會真正的實現它的目標。至關重要的一點是，對部署和生產分析的長期責任不應該被分配給臨時團隊，否則很可能會朝著反類型 B 的不利方向演進。
類型五適應性：想達成類型一的前身，但是要警惕演變成反類型 B 的可能
有效潛力：低至中
總結
究竟哪個 DevOps 團隊結構適合一個組織取決于以下幾點：
該組織的產品組合：較少的產品會使團隊協作更加容易，因為根據 Conway 定律，這種情況下的獨立谷倉會比較少。
技術領導的范圍力度和有效性；Dev 和 Ops 是否有清晰明確的共同目標。
組織是否具有能力或欲望去該改變它的 IT 運維部門，從“服務器的組建和配置”轉變成真的可以實現其價值流，以及軟件研發團隊認真對待運維團隊。
組織是否具有能力和技能去解決運維問題。
