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

[[210928]]

有人說，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 反類型

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

• Dev 和Ops 分離 
• 單獨的 DevOps 團隊 
• 開發不需要運維 
• DevOps 作為工具團隊
• 系統管理員 
• 開發包含運維 
• 開發和 DBA 分離

反類型 A：Dev 和 Ops 分離

這是經典的“扔過墻去”式的 Dev 和 Ops 分離。這意味著需求點可以在前期被提取出來（DONE 意味著“功能完整”，但不能在生產中使用），并且軟件的可運維性受到損害。

因為開發者沒有運維相關的上下文信息，運維人員沒有時間或者動力參與到開發者中，在軟件上線之前解決問題。

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

反類型 B：單獨的 DevOps 團隊

單獨的 DevOps 團隊通常來自經理或執行官，他們決定“需要一點這個 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 的拓撲：

• 開發和運維協作 
• 完全共享運維責任
• 運維作為基礎設施服務 
• DevOps-as-a-Service 
• 臨時 DevOps 團隊 
• DevOps 布道者團隊 
• SRE 團隊 
• 容器驅動的協作
• 數據庫能力

類型 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 適應性：適用于具有多個應用程序連接一個或多個大型中央數據庫的組織。

有效潛力：中

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