原文鏈接：https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
原作者：Matthew Skelton
翻譯君：CODING 戴維奧普斯
大部分組織對 DevOps 發起設立的初衷是改善客戶和業務之間的交付價值，而不是降低成本，增強自動化，或驅動組織架構；這意味着不同的組織可能需要不同的團隊結構才能進行有效的 Dev（開發）和 Ops（運維）協作。
所以關於問題 ”什麼是可以幫助 DevOps 發展的正確組織架構？“是沒有一個明確答案的。很顯然，沒有一種神奇的團隊結構可以適用於任何組織。
不過，確實有少量的團隊結構模型對某些組織來說具有一定的參考價值。通過探索這些團隊結構的優缺點，同時考慮到康威定律的情況下，或許可以確定最適合我們組織的、並有利於 DevOps 實踐的團隊結構。
很多 DevOps 團隊結構之前已經被介紹過了，特別是 CollabNet 的 Lawrence Sweeney 在 Ben Kepes 的博客評論中詳細介紹了我將在本文提及的 Anti-Type B（獨立的 DevOps 穀倉：DevOps Silo）、Type 3（基礎設施服務：IaaS）和 Type 1（開發運維共同協作：Smooth Integration）。
DevOpsGuys 列出了十二個 DevOps 反類型，Jez Humble、Gene Kim、Damon Edwards（以及其他許多人）也說過類似的事情。在這裏我增加三個額外的團隊結構，關於這三種類型我之前很少見過或聽過人提及：全嵌入式/共享運維（Fully Embedded），DevOps 即服務（DevOps-as-a-Service），和臨時 DevOps 團隊（Temporary DevOps Team）。
DevOps Anti-Types
首先，看待事物的一個有效方式是去觀察它不好的一面，這種方式我們稱之爲“反類型”（在普遍存在的“反模式”之後）。
Anti-Type A：獨立穀倉/Dev 和 Ops 分離
這是一種傳統的分裂了 Dev 和 Ops 的“拋過牆法”。這意味着 story point（需求點）可以被提前估算（“DONE”意味着功能完整，但是不意味着可以在生產中使用），同時軟件的可運維性受損，因爲 Devs （開發人員）沒有足夠的上下文環境去了解功能操作，Ops （運維人員）也沒有時間或傾向參與到 Devs 中去共同解決軟件上線前的問題。
我們可能都知道這種類型很糟糕，但我認爲很多的團隊結構實際上更糟糕；至少到目前爲止，我們已經意識到這個反類型 A 的問題所在了。
Anti-Type B：獨立的 DevOps 穀倉
這種獨立的 DevOps 團隊通常情況下來自經理或執行官，他們“需要一點 DevOps 的事情”，然後就啓動了一個“DevOps 團隊”（也有可能有一個人的名字叫做 “DevOp”）。這個 DevOps 的成員會迅速形成另一個團體，讓 Dev 和 Ops 分得更開，因爲他們要從“無知的 Devs”和“恐龍一樣的 Ops”手裏保衛自己的角色、技能和工具集。
唯一一個讓這種模式可以被理解的情況就是當團隊組織爲臨時的、時間短於十二或十八個月的時候。其目的是讓開發人員和運營人員更緊密地聯繫在一起，並明確授權在這段時間之後，這個團隊將變得多餘。
這就成爲了我所稱的 Type 5 DevOps Topology（見下文）。
Anti-Type C：“我們（開發）不需要 Ops（運維）”
這種團隊結構是由開發人員和開發經理的幼稚自大結合而來的，特別是當一些新項目啓動的時候。假設 Ops 現在已經成爲了過去式 （“我們現在有云了，對吧？），開發人員嚴重低估運維技能和活動的複雜性及重要性，認爲沒有這些技能和活動他們仍可以做到，或者只要花費一些空餘時間就可以。
當他們的軟件變得更復雜，更多的運維活動開始淹沒“開發”（即編程）的時候，這種 Anti-Type C 的類型可能最終會需要 Type 3（IaaS）或者 Type 4 DevOps topology（DevOps-as-a-Service）。
只要這樣的團隊能認識到運維作爲一個規則的重要性和軟件開發一樣重要和有價值時，他們將能夠避免許多痛苦和不必要的（以及非常基本的）錯誤。
DevOps 團隊結構
在已經瞭解了反類型的糟糕之後，我們可以看一些 DevOps 良好運作的團隊結構。
類型一：開發運維順暢協作
這是 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 運維部門，從“服務器的組建和配置”轉變成真的可以實現其價值流，以及軟件研發團隊認真對待運維團隊。
- 組織是否具有能力和技能去解決運維問題。
當然，這裏描述的主題有所不同，團隊結構和類型作爲參考指南或啓發，或許可以對評估哪一種模式是適合的帶來一些幫助。實際上，將多種模式結合，或將兩種模式構成轉變和遞進的結構模式，往往能達到更好的效果。