在大多數的團隊中，開發、運維之間有著一系列沖突和博弈。

有人說，DevOps 的出現讓開發和運維不再相愛相殺，從此一起手牽手，開心得 coding 和捉 bug。

但也有人說，DevOps 就是開發吃掉運維。

是這樣的嗎，不同的團隊結構會對 DevOps 的發展有何影響？

請看下文，你會有自己的答案。

引言

組織中發起任何DevOps相關活動的首要目的是改善對客戶和業務的價值交付，而不是降低成本，提升自動化程度，或者從配置管理中驅動任何事情；這意味著不同的組織可能需要不同的團隊結構才能開展有效的開發和運維協作。

提要

哪些DevOps團隊結構或拓撲適合組織取決于幾件事情：

該組織的產品組合：較少的產品使得協作更加容易，因為根據康威定律，這種情況下各自獨立的小團隊較少。

技術領導力的范圍，力度和有效性；Dev和Ops是否有共同的目標。

一個組織是否具有將IT運維部門從“硬件機架”和“配置服務器”改變為與價值流實際一致的需求或能力，以及軟件研發團隊是否認真對待來自運維方面的要求。

該組織是否具備帶頭解決當前運維問題的能力或技能。

當然，這里描述的主題有所不同；拓撲和類型是作為參考指南或啟發，協助您來評估哪些模式可能是適合的。實際上，將多種模式或一種模式轉化為另一種模式的組合往往是最好的方法。

那么DevOps的團隊結構如何發展呢？ 顯然，沒有任何適合每個組織的理想結構或團隊拓撲。然而，對于團隊結構來說，參考少數不同的模型是有用的，其中一些模型與某些組織的適合度更高。通過探索這些團隊結構（或“拓撲”）的優缺點，考慮到康威定律，我們可以確定可能對我們自己組織中DevOps做法最有效的團隊結構。

這些DevOps拓撲中的大多數已經在其他地方描述過；特別是CollabNet的Lawrence Sweeney在對Ben Kepes博客的評論中談到了有關我在這里所描述的反類型B（獨立的DevOps團隊），

類型3（運維作為基礎設施服務）以及類型1（開發和運維協作）。DevOpsGuys列出了十二個DevOps反模式，Jez Humble，Gene Kim，Damon Edwards（以及許多其他人）也曾經說過類似的事情。我在這里添加了三個額外的“拓撲”，我沒有看到或聽到于此相關的一些討論（共享運維，DevOps-as-a-Service和臨時DevOps團隊）。

DevOps 反類型

看看一些不好的做法，我們可以稱之為“反類型”（在無處不在的“反模式”普及之后的說法）是有用的。

A: Dev和Ops分離 B: 單獨的DevOps團隊 C: 開發不需要運維 D: 工具團隊 E: 系統管理員 F: 開發包含運維 G: 開發和DBA分離

反類型 A：Dev和Ops分離

這是經典的“扔過墻去”式的Dev和Ops分離。這意味著需求點可以在前期被提取出來（DONE意味著“功能完整”，但不能在生產中使用），并且軟件的可運維性受到損害，因為開發者沒有運維相關的上下文信息，運維人員沒有時間或者動力參與到開發者中，在軟件上線之前解決問題。

我們都知道這種拓撲類型不好，但我認為有很多相似的拓撲結構很差；至少我們清楚反類型A（開發和運維分離）是一個問題。

反類型B：單獨的DevOps團隊

單獨的DevOps團隊（反類型B）通常來自經理或執行官，決定他們“需要一點這個DevOps的事情”，并啟動一個“DevOps團隊”（可能是被稱為“DevOp”的人）。DevOps團隊的成員迅速形成另一個團體，使Dev和Ops比以往任何時候都更加分開，因為他們需要捍衛自己的角色，技能和工具集，防止自己被“無知的Devs”和“恐龍般的Ops”所消滅。

單獨的DevOps團隊真的有意義的唯一的情況是，當團隊是暫時的，例如持續時間少于12或18個月，其明確目的是使Dev和Ops更緊密地結合在一起，并被明確地授權的時候，當這段時間過去，這個團隊是多余的。這就是我所說的類型5 DevOps拓撲。

反類型C：開發不需要運維

這種拓撲結構由開發人員和開發經理之間的天真和傲慢相結合，特別是在新項目或系統開始時。假設Ops現在是過時的事情（“我們現在有了Cloud，對嗎？”），開發人員大大低估了運維技能和活動的復雜性和重要性，并認為他們可以不需要運維，或者在閑暇時間就可以搞定運維做的事情。

這種反類型C DevOps拓撲可能最終需要Type 3（Ops as IaaS）或Type 4（DevOps-as-a-Service）拓撲，當他們的軟件變得更加深入和復雜，運維開始需要開發工作“（又稱編碼）”的時候。如果這樣的團隊認識到運維作為一個重要和有價值的學科，并且認可其對于軟件開發的重要性，他們將能夠避免許多痛苦和不必要的（和相當基本的）運維錯誤。

反類型D：DevOps作為工具團隊

在不影響當前開發團隊的速度（實現用戶故事）的情況下，成立一個DevOps團隊，負責部署管道，配置管理，環境管理等所需的工具。同時，Ops的人們繼續孤立工作，Dev團隊繼續將他們的應用程序“放在墻上”。

雖然這個專門團隊的成果在改進的工具鏈方面可能是有益的，但其影響是有限的。在應用程序開發生命周期中缺乏早期運維的參與和協作，根本問題依然存在。

反類型E：變相的SysAdmin

這種反類型在工程成熟度低的組織中是典型的。他們希望改善他們的做法并降低成本，但是他們不能將IT視為業務的核心驅動力。因為DevOps的行業成功現在顯而易見，他們也想“做DevOps”。不幸的是，他們并沒有反思目前的結構和關系的差距，而是為其Ops團隊聘請了“DevOps工程師”。

DevOps只是一個名為SysAdmin的角色的重塑，沒有真正的文化/組織變化發生。這種反型越來越廣泛，因為庸碌的招聘人員只是尋找具有自動化和工具技能的候選人。不幸的是，人際溝通技巧才能真正使DevOps在組織中茁壯成長。

反類型F：運維嵌入開發團隊

該組織不希望獨立的運維團隊，所以開發團隊負責基礎設施，管理環境，監控等。但是，這樣以項目或產品驅動的方式，意味著這些項目受到資源限制，優先次序導致了較差的運作方式和半成品的解決方案。

在這種反類型方面，該組織對于有效的IT運維所需的重要性和技能缺乏認識。

反類型G：Dev和DBA隔離

這是一種在中型到大型公司中突出的反類型A（開發和運維分離）的形式，其中多個遺留系統依賴于相同的核心數據集。由于這些數據庫對于業務至關重要，因此經常在業務范圍內的專門的DBA團隊負責維護，性能調整和災難恢復。這是可以理解的，但問題是當這個團隊成為任何數據庫變更的門戶時，有效成為小型和頻繁部署（DevOps和持續交付的核心宗旨）的障礙。

此外，就像在反類型A中的運維一樣，DBA團隊在應用開發早期也沒有涉及，因此數據問題（遷移，性能等）在交付周期的后期被發現。加上支持多個應用數據庫的過載，最終的結果是面臨持續的“救火”和部署壓力。

DevOps 團隊拓撲

站在反類型的對面，我們看一些適合DevOps的拓撲。

1: 開發和運維協作 2: 共享運維 3: 運維作為基礎設施服務 4: DevOps-as-a-Service 5: 臨時DevOps團隊 6: DevOps 布道者團隊 7: SRE 團隊 8: 容器驅動 9: 數據庫能力

類型1：開發和與運維協作

這是DevOps的“樂土”：開發團隊和運營團隊之間的順利協作，每個專業都在需要的地方，但也需要分享。可能有許多獨立的開發團隊，每個工作在一個單獨的或半獨立的產品堆棧。

我的意思是，這種1型模型需要相當大的組織變革才能建立起來，在技術管理團隊中具有較高的競爭力。開發者和運維部門必須有明確的表達和鮮明合理的共同目標（“高質量交付，擁抱變化”或其他）。運維人員必須與Devs配對，掌握測試驅動的編碼技能和Git工具，并且開發必須認真對待運維特性方面的要求，并尋找運維人員加入日志實現。從目前狀況到這個狀態，所有這些都需要相當的文化變革。

類型1適應性：一個技術驅動型的組織。

有效潛力：高

類型2：完全共享運維責任

在運維人員已經集成到產品開發團隊中的情況下，我們看到了類型2拓撲。Dev和Ops之間的分離很少，所有人都高度重視共同的目標；這是一種形式的類型1（開發和運維協作），但它有一些特殊的功能。

Netflix和Facebook等組織有效實現了一種基于Web的產品，已經實現了這種2型拓撲結構，但是我認為在單純的產品角度之外來看，它可能不是非常適用的，因為預算限制和多個產品線之間通常存在上下文切換，這可能會迫使Dev和Ops進一步分開（例如，回到類型1模型）。這個拓撲也可能被稱為“NoOps”，因為沒有明顯的或可見的運維團隊（盡管Netflix NoOps也可能是類型 3（作為IaaS的Ops））。

類型2適應性：組織只有一個簡單的基于web的產品或服務。

有效潛力：高

類型3：運維作為基礎設施服務

對于IT運維部門非常傳統的組織，不會或者不能（足夠）快地速擁抱變化，對于在公共云（Amazon EC2，Rackspace，Azure等）中運行所有應用程序的組織，它可能將運維作為一個只需提供應用程序部署和運行功能的彈性基礎設施團隊。因此，內部運維團隊直接等同于Amazon EC2或基礎架構即服務。

Dev內部的一個團隊（或許是一個虛擬團隊）將作為運維特性、指標、監控、服務器配置等方面的專業知識來源，并且可能與IaaS團隊進行大部分的溝通。然而，這個團隊仍然是一個開發團隊，遵循TDD，CI，迭代開發，人員指導等標準實踐。

IaaS拓撲結構具有一些潛在的有效性（與Ops人員直接協作），以便更容易實施，可能比通過嘗試稍后嘗試的類型1（開發和運營協作）更快地獲得價值。

類型3適應性：具有多種不同產品和服務，傳統的運維部門，或其應用程序完全在公有云中運行的組織。

有效潛力：中

類型4：DevOps作為外部服務

一些組織，特別是較小的組織可能沒有資金，經驗或工作人員來主導他們的軟件運維。開發團隊可能會接觸到像Rackspace這樣的服務提供商，以幫助他們建立測試環境并自動化其基礎設施和監控，并就軟件開發周期中實現的各種運維功能提供建議。可以稱之為DevOps-as-a-Serviced的可能是小型組織或團隊，他們了解自動化，監控和配置管理的用途和實現方式，然后隨著業務的發展和更多的員工，可能轉向第3類（作為IaaS的操作）或甚至第一類（開發和運維協作）模式。

類型4適應性：運營經驗較小的小型團隊或組織。

有效潛力：中

類型5：具有到期日的DevOps團隊

具有到期日的DevOps團隊（類型5）看起來像反類型B（DevOps Team Silo），但其意圖和壽命是完全不同的。這個臨時團隊的任務是使Dev和Ops更緊密地結合在一起，理想目標是面向類型1（開發和運營協作）或類型2（完全共享的Ops Reponsibility）模型，并最終使其自身過時。臨時小組的成員將在Dev-speak和Ops-talk之間進行“翻譯”，引入瘋狂的想法，如為Ops團隊引入站立會和看板，并考慮“骯臟”的細節，如負載均衡器，管理NIC和為Dev團隊卸載SSL。如果足夠多的人開始看到將Dev和Ops組合在一起的價值，那么臨時團隊就有實現其目標的真正機會；至關重要的是，部署和生產環境的長期分析診斷責任不應該提供給臨時團隊，否則可能會成為DevOps團隊隔離（反類型B）。

類型5適應性：運營經驗較小的小型團隊或組織。

有效潛力：低至中

類型6：DevOps“布道者”團隊

在Dev與Ops之間存在巨大差距（或者大的差距趨勢）的組織中，擁有一個“促進”DevOps團隊來保持Dev和Ops方面的交流是有效的。這是一個類型5（DevOps Team with Expirey Date）的版本，但DevOps團隊在持續的基礎上存在著具體的促進Dev與Ops團隊之間的協作與合作的職責。這個團隊的成員有時被稱為“DevOps 布道者”，因為它們有助于傳播DevOps實踐的意識。

“DevOps團隊”的目標應該是通過啟用組織的其余部分來實現自己的業務。— Twitter: EricMinick

類型6適應性：Dev和Ops趨勢分散的組織。小心類型B的危險。

有效潛力：中至高

類型7：SRE團隊（Google模型）

DevOps經常建議Dev團隊定期參加值班會議，但這不是必須的。事實上，一些組織（包括Google）運行不同的模式，從開發到運行該軟件的團隊（站點可靠性工程（SRE））團隊的明確“切換”。在這個模型中，開發團隊需要向SRE團隊提供測試證據（日志，指標等），表明他們的軟件具有足夠的標準，得到SRE團隊的支持。

最重要的是，SRE團隊可以拒絕在運維上不合標準的軟件，要求開發人員在將代碼投入生產之前對其進行改進。Dev和SRE之間的協作發生在運維標準上，但是一旦SRE團隊對代碼感到滿意，他們（而不是開發團隊）就在生產中支持它。

類型7適應性：類型7僅適用于具有高度工程和組織成熟度的組織。如果SRE/Ops團隊被告知“JFDI”部署，請小心返回反類型A。

有效潛力：低至高

類型8：容器驅動的協作

通過將應用程序的部署和運行時需求封裝到容器中，容器不再需要Dev和Ops之間的某些協作。這樣，容器就是開發和運維的責任界限。憑借良好的工程文化，容器驅動的協作模式運作良好，但如果開發者開始忽視運維需要考慮的一些事情，這種模式可以轉變為對抗“我們與他們”。

類型8適應性：容器可以工作得很好，但要注意反類型A，Ops團隊預計會運行Dev發出的任何內容。

有效潛力：中至高

類型9：開發和DBA協作

為了彌合Dev-DBA的鴻溝，一些組織已經嘗試過類似于類型9的數據庫功能，DBA團隊的數據庫功能與Dev團隊的數據庫功能（或專業）相稱。這似乎有助于在以開發為中心的數據庫（以本質上是應用程序的虛擬持久存儲）視圖和DBA為中心的數據庫（智能，豐富的業務價值來源）視圖之間進行轉換。

類型9適應性：適用于具有多個應用程序連接一個或多個大型中央數據庫的組織。

有效潛力：中

請記住：任何一個組織都沒有“正確的”團隊拓撲，但是有幾個“壞”拓撲。