前言

組織中任何DevOps工作的主要目標都是改進客戶和業務的價值交付，而不是降低成本、提升自動化或者通過配置管理驅動一切；這意味著，為了實現有效的Dev和Ops協同，不同的組織可能需要不同的團隊結構。

概述

具體哪種DevOps團隊結構或拓撲適合組織取決于以下幾個方面：

• 組織的產品集：產品越少協同越簡單，就像康威定律預言的那樣，自然形成的筒倉就越少；

• 技術領導者的職責范圍、實力和有效性；Dev和Ops是否有共同的目標；

• 組織是否有能力或意愿變革其IT運維部門，使其不再只是“上架硬件”和“配置服務器”，而是成為真正與價值流一致的部門，使運維特性為軟件團隊所重視；

• 組織是否有能力或技能主導運維。

當然，這里列出的主題有些差異；這些拓撲和類型可作為參考指南用于評估某個模式是否恰當。實際上，組合多個模式或將一個模式轉換為另一個模式通常是最好的方法。

那么，什么樣的團隊結構適合采用DevOps呢？顯然，不存在適合每個組織的神奇結構或團隊拓撲。然而，介紹幾種不同的團隊結構模型是有用處的，其中一些模型比其他模型更適合某些組織。通過探索這些團隊結構（或“拓撲”）的優缺點，我們可以確定自己的組織中最適合DevOps實踐的團隊結構，并考慮康威定律。

下面為你一一介紹DevOps實踐的各種團隊結構。

DevOps的反類型

了解一些糟糕的做法是有用處的，我們可以叫它們“反類型（anti-types）”（這個叫法源于我們常見的“反模式”）。

反類型A：Dev和Ops筒倉

這是典型的Dev和Ops“各管一攤”。這意味著可以盡早聲明故事點“完工”（意味著“特性完成”，但還沒應用到生產中），而軟件可操作性受損，因為Dev沒有足夠的有關運維特性的上下文信息，而Ops人員沒有時間或無意為了軟件上線前解決問題而參與開發。

我們可能都知道這種拓撲不好，但我認為，還有實際上更糟糕的拓撲；對于反類型A（Dev和Ops筒倉），我們至少知道這其中尋在問題。

反類型B：DevOps團隊筒倉

DevOps團隊筒倉（反類型B）的形成通常是因為經理或主管認定他們“需要一點DevOps的東西”并創建了一個“DevOps團隊”（可能其中全是被稱為“DevOp”的人）。DevOps團隊的成員迅速形成另一個筒倉，Dev和Ops遠比以往任何時候都注意保持距離，因為他們要捍衛自己的老窩、技能和工具集，不被那些“一無所知的Dev”和“守舊落伍的Ops”所破壞。

一個單獨的DevOps筒倉只在一種情況下是真正有意義的，就是該團隊為臨時團隊，存在時間不超過12或18個月，其目的是為了讓Dev和Ops團結起來，而且很明確，過了這段時間，該DevOps團隊就是多余的了；這是我下文所說的5型DevOps拓撲。

反類型C：Dev不需要Ops

這種拓撲誕生于開發人員和開發經理的天真和傲慢，特別是當開始新項目或系統時。假設Ops現在已經成為過去（“我們現在有云，對吧?”），開發人員嚴重低估了運維技能和活動的復雜性和重要性，并相信可以沒有他們，或者只在空閑時間涉及他們。

這種反類型C的DevOps拓撲可能最終需要下文說到的3型（Ops即IaaS）或4型 （DevOps即服務）的拓撲，因為他們的軟件變得更加復雜，并且運維活動開始占用“開發”（即編碼）時間。要是這樣的團隊認識到，運維作為一門學科的重要性與軟件開發同等重要和有價值，他們就能夠避免許多痛苦和不必要的（非常基本的）運維錯誤。

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

為了“成為DevOps”而又不影響當前Dev團隊的速度（或者說功能點交付），創建一個DevOps團隊致力于部署管道、配置管理、環境管理等所需的工具。同時，運維人員繼續孤立工作，而Dev團隊繼續把應用程序從“墻上”扔給他們。

盡管這個專門小組的成果就改進工具鏈而言可能是有好處的，但其影響很有限。在應用程序開發生命周期中Ops人員未能早期參與和協作的基本問題仍然沒有改變。

反類型E：換個名的SysAdmin

這種反類型在工程成熟度較低的組織中很典型。他們想要提高實踐并降低成本，然而，他們并沒有將IT視為業務的核心推動力。因為DevOps在行業內取得的成功現在已經顯而易見，所以他們想“做DevOps”。不幸的是，他們沒有反思當前的結構和關系存在什么差距就去為Ops團隊招聘“DevOps工程師”，這很難達到目的。

DevOps只是對以前的SysAdmin角色改了個名，沒有真正的文化/組織變革發生。這種反類型正變得越來越普遍，因為為了招攬人才而無所不為的招聘人員會趕時髦，尋找具有自動化和工具技能的求職者。遺憾的是，人類的溝通技巧可以讓DevOps在組織中茁壯成長。

反類型F：Ops嵌入到Dev團隊

組織不希望保留一個單獨的運維團隊，因此，開發團隊會負責基礎設施、管理環境、監控等。然而，在項目或產品導向的方式中，這樣做意味著這些工作會受到資源限制和優先級重排的影響，導致低于標準的方法和不成熟的解決方案。

這種反類型表明，組織對有效IT運維的重要性和所需的技能缺乏認識。特別地，開發人員將其視為一種煩惱，Ops的價值因此被貶低（Ops是由開發團隊的管理者管理的，而開發團隊往往有其他的優先級事項）。

反類型G：Dev和DBA筒倉

這是反類型A （Dev和Ops筒倉）的一種形式，在中大型公司中非常突出，在這些公司中，多個遺留系統依賴于相同的核心數據集。因為這些數據庫對于業務而言非常重要，在Ops保護傘下會有一個專門的DBA團隊，負責它們的維護、性能調優和災難恢復。這是可以理解的。問題是，當這個團隊成為任何數據庫變更的守門人時，它實際上就成為頻繁的小規模部署（DevOps和持續交付的核心原則）的障礙。

此外，就像反類型A中的Ops，DBA團隊并不參與應用程序的早期開發，因此，在交付周期中會發現數據問題（遷移、性能等）。再加上需要負責多個應用程序的數據庫，最終的結果是不斷地滅火和越來越大的交付壓力。

DevOps團隊拓撲

與反類型相反，讓我們看一些有效的DevOps拓撲。

1型：Dev與Ops協作

這是DevOps的“應許之地”：Dev團隊和Ops團隊之間順暢協作，各自專注于自己的工作，并在必要的時候互相分擔。可能有許多單獨的Dev團隊，每個團隊致力于一個獨立或半獨立的產品棧。

我的感覺是，這種1型模型的建立需要相當大量的組織變革，并且要求技術管理團隊的高層具有一定的能力。Dev和Ops必須有一個清晰描述且明顯有效的共同目標（提供可靠而頻繁的變更，諸如此類）。Ops人員必須適應與Dev人員搭配，掌握測試驅動編碼和Git，而Dev人員必須認真對待運維特性，從Ops人員那里獲得日志實現的輸入，等等，所有這些都需要相當大的文化變革。

1型適用于具有強力技術領導者的組織。
潛在有效性：高

2型：完全共擔Ops職責

運維人員已經被整合到產品開發團隊，我們看到了一個2型拓撲。Dev和Ops之間幾乎密不可分，所有人都高度關注同一個目標，這是一種有爭議的1型（Dev和Ops協作）形式，但它有一些自己的特點。

像Netflix和Facebook這種實際上只有一種Web產品的組織已經實現了這種2型拓撲，但我認為，如果不是只關注少量核心產品，這種模式可能不是非常適用，因為在擁有多個產品流的組織中，預算限制和上下文切換很可能會迫使Dev和Ops進一步分開（比如說回到1型模型）。由于沒有明顯的或可見的運維團隊，所以這種拓撲可能也被稱為“NoOps”，(盡管Netflix NoOps也可以是下文的3型（Ops即IaaS）)。

2型適用于具有單一主要Web產品或服務的組織。
潛在有效性：高

3型：Ops即IaaS（平臺）

對于具有傳統IT運維部門（不能或不愿做出足夠迅速的變更）的組織，以及將所有應用程序運行在公有云（Amazon EC2、Rackspace、Azure等等）上的組織，這可能有助于將運維視為一個團隊，他們只是提供了彈性基礎設施供應用程序在上面部署和運行；為此，內部Ops團隊直接就相當于Amazon EC2或“基礎設施即服務（IaaS）”。

然后，Dev中的一個團隊（也許是一個虛擬團隊）可以作為運維特性、指標、監控、服務器配置等方面的專家組，可能負責大部分與IaaS團隊的溝通。然而，這個團隊仍然是一個Dev團隊，遵循TDD、CI、迭代開發等標準實踐。

IaaS拓撲的潛在效益是實現更容易（不必和Ops人員直接協作）完成，可能比嘗試1型（Dev和Ops協作）拓撲更快地獲得價值，至于1型，可以后續再試。

3型適用于有多個不同的產品和服務以及傳統Ops部門的組織，或者應用程序全部在公有云上運行的組織。
潛在有效性：中

4型：DevOps作為外部服務

有些組織，特別是較小的組織，可能沒有財力、經驗或人力可以運維其開發的軟件。Dev團隊可能會聯系服務提供者，如Rackspace，幫助他們構建測試環境及自動化基礎設施和監控，并就他們在軟件開發周期中實現何種運維特性提供建議。

對于小型組織或團隊，如果他們想要學習自動化、監控和配置管理，然后隨著他們的發展，會有更多的人專注于運維，他們可能發展成3型（Ops即IaaS）甚至1型（Dev和Ops協作）模型，那么DevOps即服務可能是一個有效而務實的方式。

4型適用于運維問題相關經驗比較有限的小型團隊或組織。
潛在有效性：中

5型：具有截止日期的DevOps團隊

具有截止日期的DevOps團隊（5型）看上去非常像反類型B（DevOps團隊筒倉），但它的意圖和期限有很大的不同。這個臨時團隊的使命是讓Dev和Ops更緊密地聯系在一起，在理想的情況下向1型（Dev和Ops協作）或2型（完全共擔Ops職責）模型轉化，并最終會淘汰掉。

臨時團隊的成員將“翻譯”Dev語言和Ops語言，引入大膽的想法，像站立會議和運維團隊看板，考慮討人厭的細節，如負載均衡、管理NIC以及為Dev團隊進行SSL減負（offloading ）。如果有足夠多的人開始看到Dev和Ops一起協作帶來的價值，那么臨時團隊就真正獲得了一個達成目標的機會，至關重要的是，部署和生產診斷的長期職責不應該給臨時團隊，否則它就可能會成為一個DevOps團隊筒倉（反類型B）。

5型是1型拓撲的前身，但要注意反類型B的危險。
潛在有效性：低到高

6型：DevOps布道團隊

在Dev和Ops之間存在巨大鴻溝（或者差距有變得很大的趨勢）的組織里，它可以有效地“促進”DevOps團隊，保證Dev和Ops之間的對話。這是5型（具有截止日期的DevOps團隊）的一個版本，但這里的DevOps團隊是一直存在的，其具體職責是促進Dev團隊和Ops團隊之間的協作。這個團隊的成員有時也被稱作“DevOps布道者”，因為他們幫助宣傳DevOps實踐。

“DevOps團隊”的目標應該是通過賦能組織的其他部分來讓自己脫離業務。

——EricMinick

6型適用于Dev和Ops之間有疏遠趨勢的組織。注意反類型B的危險。
潛在有效性：中到高

7型：SRE團隊（谷歌模型）

DevOps經常建議Dev團隊加入值班輪換，但這不是必要的。事實上，有些組織（包括谷歌）運行一個不同的模型，軟件由開發團隊顯式“交接給”運行軟件的團隊，即網站可靠性工程團隊（SRE）。在這個模型中，Dev團隊需要向SRE團隊提供測試證據（日志、指標等），證明他們的軟件已經達到一個SRE團隊認為足夠好的標準。

至關重要的是，SRE團隊可以拒絕不符合運維標準的軟件，要求開發人員在投入生產之前改進代碼。Dev和SRE之間的協作圍繞著運維標準展開，但是，一旦SRE團隊對代碼滿意，他們（而不是Dev團隊）就會在生產環境中提供支持。

7型只適用于工程和組織成熟度較高的組織。如果SRE/Ops團隊被告知進行“JFDI”部署，則要注意不要回到反類型A。
潛在有效性：低到高

8型：容器驅動協作

容器將應用程序的部署和運行要求封裝到了容器中，消除了Dev和Ops之間的某些協作需求。在這種情況下，容器充當了Dev和Ops的責任邊界。在良好的工程文化中，容器驅動協作模型運轉良好，但是，如果Dev開始忽視運維注意事項，那么，這個模型就會向敵對的“我們和他們”回歸。

8型適用性：容器可以很好地發揮作用，但要注意反類型A，不要期望Ops團隊運行Dev扔給他們的任何東西。
潛在有效性：中到高

9型：Dev和DBA協作

為了消除Dev和DBA之間的鴻溝，有些組織已經嘗試使用類似9型的模型，DBA團隊的數據庫能力與Dev團隊的數據庫能力（或專長）可以很好地互補。這似乎有助于將以Dev為中心的數據庫視圖（基本上就是作為應用程序笨拙的持久性存儲）和以DBA為中心的數據庫視圖（智能豐富的業務價值源）之間的轉換。

9型只適用于有一個或多個大型中心數據庫連接多個應用程序的組織。
潛在有效性：中

你所在的團隊開始采用DevOps了嗎，是怎樣的模式呢？歡迎大家在評論區一起談談。

查看英文原文：https://web.devopstopologies.com/

總結

以上是生活随笔為你收集整理的DevOps团队结构类型汇总：总有一款适合你的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。