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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有效潛力：高

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

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

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

有效潛力：高

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

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

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

有效潛力：中

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

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

有效潛力：中

具有到期日的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適應性：運營經驗較小的小型團隊或組織。

有效潛力：低至中

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

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

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

有效潛力：中至高

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

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

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

有效潛力：低至高

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

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

有效潛力：中至高

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

型別9適應性：適用於具有多個應用程式連線一個或多個大型中央資料庫的組織。

有效潛力：中

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