前言
組織中任何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了嗎，是怎樣的模式呢？歡迎大家在評論區一起談談。