前言

組織中任何DevOps工作的主要目標(biāo)都是改進(jìn)客戶(hù)和業(yè)務(wù)的價(jià)值交付，而不是降低成本、提升自動(dòng)化或者通過(guò)配置管理驅(qū)動(dòng)一切；這意味著，為了實(shí)現(xiàn)有效的Dev和Ops協(xié)同，不同的組織可能需要不同的團(tuán)隊(duì)結(jié)構(gòu)。

概述

具體哪種DevOps團(tuán)隊(duì)結(jié)構(gòu)或拓?fù)溥m合組織取決于以下幾個(gè)方面：

• 組織的產(chǎn)品集：產(chǎn)品越少協(xié)同越簡(jiǎn)單，就像康威定律預(yù)言的那樣，自然形成的筒倉(cāng)就越少；

• 技術(shù)領(lǐng)導(dǎo)者的職責(zé)范圍、實(shí)力和有效性；Dev和Ops是否有共同的目標(biāo)；

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

• 組織是否有能力或技能主導(dǎo)運(yùn)維。

當(dāng)然，這里列出的主題有些差異；這些拓?fù)浜皖?lèi)型可作為參考指南用于評(píng)估某個(gè)模式是否恰當(dāng)。實(shí)際上，組合多個(gè)模式或?qū)⒁粋€(gè)模式轉(zhuǎn)換為另一個(gè)模式通常是最好的方法。

那么，什么樣的團(tuán)隊(duì)結(jié)構(gòu)適合采用DevOps呢？顯然，不存在適合每個(gè)組織的神奇結(jié)構(gòu)或團(tuán)隊(duì)拓?fù)洹Ｈ欢?#xff0c;介紹幾種不同的團(tuán)隊(duì)結(jié)構(gòu)模型是有用處的，其中一些模型比其他模型更適合某些組織。通過(guò)探索這些團(tuán)隊(duì)結(jié)構(gòu)（或“拓?fù)洹?#xff09;的優(yōu)缺點(diǎn)，我們可以確定自己的組織中最適合DevOps實(shí)踐的團(tuán)隊(duì)結(jié)構(gòu)，并考慮康威定律。

下面為你一一介紹DevOps實(shí)踐的各種團(tuán)隊(duì)結(jié)構(gòu)。

DevOps的反類(lèi)型

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

反類(lèi)型A：Dev和Ops筒倉(cāng)

這是典型的Dev和Ops“各管一攤”。這意味著可以盡早聲明故事點(diǎn)“完工”（意味著“特性完成”，但還沒(méi)應(yīng)用到生產(chǎn)中），而軟件可操作性受損，因?yàn)镈ev沒(méi)有足夠的有關(guān)運(yùn)維特性的上下文信息，而Ops人員沒(méi)有時(shí)間或無(wú)意為了軟件上線(xiàn)前解決問(wèn)題而參與開(kāi)發(fā)。

我們可能都知道這種拓?fù)洳缓?#xff0c;但我認(rèn)為，還有實(shí)際上更糟糕的拓?fù)?#xff1b;對(duì)于反類(lèi)型A（Dev和Ops筒倉(cāng)），我們至少知道這其中尋在問(wèn)題。

反類(lèi)型B：DevOps團(tuán)隊(duì)筒倉(cāng)

DevOps團(tuán)隊(duì)筒倉(cāng)（反類(lèi)型B）的形成通常是因?yàn)榻?jīng)理或主管認(rèn)定他們“需要一點(diǎn)DevOps的東西”并創(chuàng)建了一個(gè)“DevOps團(tuán)隊(duì)”（可能其中全是被稱(chēng)為“DevOp”的人）。DevOps團(tuán)隊(duì)的成員迅速形成另一個(gè)筒倉(cāng)，Dev和Ops遠(yuǎn)比以往任何時(shí)候都注意保持距離，因?yàn)樗麄円葱l(wèi)自己的老窩、技能和工具集，不被那些“一無(wú)所知的Dev”和“守舊落伍的Ops”所破壞。

一個(gè)單獨(dú)的DevOps筒倉(cāng)只在一種情況下是真正有意義的，就是該團(tuán)隊(duì)為臨時(shí)團(tuán)隊(duì)，存在時(shí)間不超過(guò)12或18個(gè)月，其目的是為了讓Dev和Ops團(tuán)結(jié)起來(lái)，而且很明確，過(guò)了這段時(shí)間，該DevOps團(tuán)隊(duì)就是多余的了；這是我下文所說(shuō)的5型DevOps拓?fù)洹?/p>

反類(lèi)型C：Dev不需要Ops

這種拓?fù)湔Q生于開(kāi)發(fā)人員和開(kāi)發(fā)經(jīng)理的天真和傲慢，特別是當(dāng)開(kāi)始新項(xiàng)目或系統(tǒng)時(shí)。假設(shè)Ops現(xiàn)在已經(jīng)成為過(guò)去（“我們現(xiàn)在有云，對(duì)吧?”），開(kāi)發(fā)人員嚴(yán)重低估了運(yùn)維技能和活動(dòng)的復(fù)雜性和重要性，并相信可以沒(méi)有他們，或者只在空閑時(shí)間涉及他們。

這種反類(lèi)型C的DevOps拓?fù)淇赡茏罱K需要下文說(shuō)到的3型（Ops即IaaS）或4型 （DevOps即服務(wù)）的拓?fù)?#xff0c;因?yàn)樗麄兊能浖兊酶訌?fù)雜，并且運(yùn)維活動(dòng)開(kāi)始占用“開(kāi)發(fā)”（即編碼）時(shí)間。要是這樣的團(tuán)隊(duì)認(rèn)識(shí)到，運(yùn)維作為一門(mén)學(xué)科的重要性與軟件開(kāi)發(fā)同等重要和有價(jià)值，他們就能夠避免許多痛苦和不必要的（非常基本的）運(yùn)維錯(cuò)誤。

反類(lèi)型D：DevOps作為工具團(tuán)隊(duì)

為了“成為DevOps”而又不影響當(dāng)前Dev團(tuán)隊(duì)的速度（或者說(shuō)功能點(diǎn)交付），創(chuàng)建一個(gè)DevOps團(tuán)隊(duì)致力于部署管道、配置管理、環(huán)境管理等所需的工具。同時(shí)，運(yùn)維人員繼續(xù)孤立工作，而Dev團(tuán)隊(duì)繼續(xù)把應(yīng)用程序從“墻上”扔給他們。

盡管這個(gè)專(zhuān)門(mén)小組的成果就改進(jìn)工具鏈而言可能是有好處的，但其影響很有限。在應(yīng)用程序開(kāi)發(fā)生命周期中Ops人員未能早期參與和協(xié)作的基本問(wèn)題仍然沒(méi)有改變。

反類(lèi)型E：換個(gè)名的SysAdmin

這種反類(lèi)型在工程成熟度較低的組織中很典型。他們想要提高實(shí)踐并降低成本，然而，他們并沒(méi)有將IT視為業(yè)務(wù)的核心推動(dòng)力。因?yàn)镈evOps在行業(yè)內(nèi)取得的成功現(xiàn)在已經(jīng)顯而易見(jiàn)，所以他們想“做DevOps”。不幸的是，他們沒(méi)有反思當(dāng)前的結(jié)構(gòu)和關(guān)系存在什么差距就去為Ops團(tuán)隊(duì)招聘“DevOps工程師”，這很難達(dá)到目的。

DevOps只是對(duì)以前的SysAdmin角色改了個(gè)名，沒(méi)有真正的文化/組織變革發(fā)生。這種反類(lèi)型正變得越來(lái)越普遍，因?yàn)闉榱苏袛埲瞬哦鵁o(wú)所不為的招聘人員會(huì)趕時(shí)髦，尋找具有自動(dòng)化和工具技能的求職者。遺憾的是，人類(lèi)的溝通技巧可以讓DevOps在組織中茁壯成長(zhǎng)。

反類(lèi)型F：Ops嵌入到Dev團(tuán)隊(duì)

組織不希望保留一個(gè)單獨(dú)的運(yùn)維團(tuán)隊(duì)，因此，開(kāi)發(fā)團(tuán)隊(duì)會(huì)負(fù)責(zé)基礎(chǔ)設(shè)施、管理環(huán)境、監(jiān)控等。然而，在項(xiàng)目或產(chǎn)品導(dǎo)向的方式中，這樣做意味著這些工作會(huì)受到資源限制和優(yōu)先級(jí)重排的影響，導(dǎo)致低于標(biāo)準(zhǔn)的方法和不成熟的解決方案。

這種反類(lèi)型表明，組織對(duì)有效IT運(yùn)維的重要性和所需的技能缺乏認(rèn)識(shí)。特別地，開(kāi)發(fā)人員將其視為一種煩惱，Ops的價(jià)值因此被貶低（Ops是由開(kāi)發(fā)團(tuán)隊(duì)的管理者管理的，而開(kāi)發(fā)團(tuán)隊(duì)往往有其他的優(yōu)先級(jí)事項(xiàng)）。

反類(lèi)型G：Dev和DBA筒倉(cāng)

這是反類(lèi)型A （Dev和Ops筒倉(cāng)）的一種形式，在中大型公司中非常突出，在這些公司中，多個(gè)遺留系統(tǒng)依賴(lài)于相同的核心數(shù)據(jù)集。因?yàn)檫@些數(shù)據(jù)庫(kù)對(duì)于業(yè)務(wù)而言非常重要，在Ops保護(hù)傘下會(huì)有一個(gè)專(zhuān)門(mén)的DBA團(tuán)隊(duì)，負(fù)責(zé)它們的維護(hù)、性能調(diào)優(yōu)和災(zāi)難恢復(fù)。這是可以理解的。問(wèn)題是，當(dāng)這個(gè)團(tuán)隊(duì)成為任何數(shù)據(jù)庫(kù)變更的守門(mén)人時(shí)，它實(shí)際上就成為頻繁的小規(guī)模部署（DevOps和持續(xù)交付的核心原則）的障礙。

此外，就像反類(lèi)型A中的Ops，DBA團(tuán)隊(duì)并不參與應(yīng)用程序的早期開(kāi)發(fā)，因此，在交付周期中會(huì)發(fā)現(xiàn)數(shù)據(jù)問(wèn)題（遷移、性能等）。再加上需要負(fù)責(zé)多個(gè)應(yīng)用程序的數(shù)據(jù)庫(kù)，最終的結(jié)果是不斷地滅火和越來(lái)越大的交付壓力。

DevOps團(tuán)隊(duì)拓?fù)?/h3>

與反類(lèi)型相反，讓我們看一些有效的DevOps拓?fù)洹?/p>

1型：Dev與Ops協(xié)作

這是DevOps的“應(yīng)許之地”：Dev團(tuán)隊(duì)和Ops團(tuán)隊(duì)之間順暢協(xié)作，各自專(zhuān)注于自己的工作，并在必要的時(shí)候互相分擔(dān)。可能有許多單獨(dú)的Dev團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)致力于一個(gè)獨(dú)立或半獨(dú)立的產(chǎn)品棧。

我的感覺(jué)是，這種1型模型的建立需要相當(dāng)大量的組織變革，并且要求技術(shù)管理團(tuán)隊(duì)的高層具有一定的能力。Dev和Ops必須有一個(gè)清晰描述且明顯有效的共同目標(biāo)（提供可靠而頻繁的變更，諸如此類(lèi)）。Ops人員必須適應(yīng)與Dev人員搭配，掌握測(cè)試驅(qū)動(dòng)編碼和Git，而Dev人員必須認(rèn)真對(duì)待運(yùn)維特性，從Ops人員那里獲得日志實(shí)現(xiàn)的輸入，等等，所有這些都需要相當(dāng)大的文化變革。

1型適用于具有強(qiáng)力技術(shù)領(lǐng)導(dǎo)者的組織。
潛在有效性：高

2型：完全共擔(dān)Ops職責(zé)

運(yùn)維人員已經(jīng)被整合到產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)，我們看到了一個(gè)2型拓?fù)洹ev和Ops之間幾乎密不可分，所有人都高度關(guān)注同一個(gè)目標(biāo)，這是一種有爭(zhēng)議的1型（Dev和Ops協(xié)作）形式，但它有一些自己的特點(diǎn)。

像Netflix和Facebook這種實(shí)際上只有一種Web產(chǎn)品的組織已經(jīng)實(shí)現(xiàn)了這種2型拓?fù)?#xff0c;但我認(rèn)為，如果不是只關(guān)注少量核心產(chǎn)品，這種模式可能不是非常適用，因?yàn)樵趽碛卸鄠€(gè)產(chǎn)品流的組織中，預(yù)算限制和上下文切換很可能會(huì)迫使Dev和Ops進(jìn)一步分開(kāi)（比如說(shuō)回到1型模型）。由于沒(méi)有明顯的或可見(jiàn)的運(yùn)維團(tuán)隊(duì)，所以這種拓?fù)淇赡芤脖环Q(chēng)為“NoOps”，(盡管Netflix NoOps也可以是下文的3型（Ops即IaaS）)。

2型適用于具有單一主要Web產(chǎn)品或服務(wù)的組織。
潛在有效性：高

3型：Ops即IaaS（平臺(tái)）

對(duì)于具有傳統(tǒng)IT運(yùn)維部門(mén)（不能或不愿做出足夠迅速的變更）的組織，以及將所有應(yīng)用程序運(yùn)行在公有云（Amazon EC2、Rackspace、Azure等等）上的組織，這可能有助于將運(yùn)維視為一個(gè)團(tuán)隊(duì)，他們只是提供了彈性基礎(chǔ)設(shè)施供應(yīng)用程序在上面部署和運(yùn)行；為此，內(nèi)部Ops團(tuán)隊(duì)直接就相當(dāng)于Amazon EC2或“基礎(chǔ)設(shè)施即服務(wù)（IaaS）”。

然后，Dev中的一個(gè)團(tuán)隊(duì)（也許是一個(gè)虛擬團(tuán)隊(duì)）可以作為運(yùn)維特性、指標(biāo)、監(jiān)控、服務(wù)器配置等方面的專(zhuān)家組，可能負(fù)責(zé)大部分與IaaS團(tuán)隊(duì)的溝通。然而，這個(gè)團(tuán)隊(duì)仍然是一個(gè)Dev團(tuán)隊(duì)，遵循TDD、CI、迭代開(kāi)發(fā)等標(biāo)準(zhǔn)實(shí)踐。

IaaS拓?fù)涞臐撛谛б媸菍?shí)現(xiàn)更容易（不必和Ops人員直接協(xié)作）完成，可能比嘗試1型（Dev和Ops協(xié)作）拓?fù)涓斓孬@得價(jià)值，至于1型，可以后續(xù)再試。

3型適用于有多個(gè)不同的產(chǎn)品和服務(wù)以及傳統(tǒng)Ops部門(mén)的組織，或者應(yīng)用程序全部在公有云上運(yùn)行的組織。
潛在有效性：中

4型：DevOps作為外部服務(wù)

有些組織，特別是較小的組織，可能沒(méi)有財(cái)力、經(jīng)驗(yàn)或人力可以運(yùn)維其開(kāi)發(fā)的軟件。Dev團(tuán)隊(duì)可能會(huì)聯(lián)系服務(wù)提供者，如Rackspace，幫助他們構(gòu)建測(cè)試環(huán)境及自動(dòng)化基礎(chǔ)設(shè)施和監(jiān)控，并就他們?cè)谲浖_(kāi)發(fā)周期中實(shí)現(xiàn)何種運(yùn)維特性提供建議。

對(duì)于小型組織或團(tuán)隊(duì)，如果他們想要學(xué)習(xí)自動(dòng)化、監(jiān)控和配置管理，然后隨著他們的發(fā)展，會(huì)有更多的人專(zhuān)注于運(yùn)維，他們可能發(fā)展成3型（Ops即IaaS）甚至1型（Dev和Ops協(xié)作）模型，那么DevOps即服務(wù)可能是一個(gè)有效而務(wù)實(shí)的方式。

4型適用于運(yùn)維問(wèn)題相關(guān)經(jīng)驗(yàn)比較有限的小型團(tuán)隊(duì)或組織。
潛在有效性：中

5型：具有截止日期的DevOps團(tuán)隊(duì)

具有截止日期的DevOps團(tuán)隊(duì)（5型）看上去非常像反類(lèi)型B（DevOps團(tuán)隊(duì)筒倉(cāng)），但它的意圖和期限有很大的不同。這個(gè)臨時(shí)團(tuán)隊(duì)的使命是讓Dev和Ops更緊密地聯(lián)系在一起，在理想的情況下向1型（Dev和Ops協(xié)作）或2型（完全共擔(dān)Ops職責(zé)）模型轉(zhuǎn)化，并最終會(huì)淘汰掉。

臨時(shí)團(tuán)隊(duì)的成員將“翻譯”Dev語(yǔ)言和Ops語(yǔ)言，引入大膽的想法，像站立會(huì)議和運(yùn)維團(tuán)隊(duì)看板，考慮討人厭的細(xì)節(jié)，如負(fù)載均衡、管理NIC以及為Dev團(tuán)隊(duì)進(jìn)行SSL減負(fù)（offloading ）。如果有足夠多的人開(kāi)始看到Dev和Ops一起協(xié)作帶來(lái)的價(jià)值，那么臨時(shí)團(tuán)隊(duì)就真正獲得了一個(gè)達(dá)成目標(biāo)的機(jī)會(huì)，至關(guān)重要的是，部署和生產(chǎn)診斷的長(zhǎng)期職責(zé)不應(yīng)該給臨時(shí)團(tuán)隊(duì)，否則它就可能會(huì)成為一個(gè)DevOps團(tuán)隊(duì)筒倉(cāng)（反類(lèi)型B）。

5型是1型拓?fù)涞那吧?#xff0c;但要注意反類(lèi)型B的危險(xiǎn)。
潛在有效性：低到高

6型：DevOps布道團(tuán)隊(duì)

在Dev和Ops之間存在巨大鴻溝（或者差距有變得很大的趨勢(shì)）的組織里，它可以有效地“促進(jìn)”DevOps團(tuán)隊(duì)，保證Dev和Ops之間的對(duì)話(huà)。這是5型（具有截止日期的DevOps團(tuán)隊(duì)）的一個(gè)版本，但這里的DevOps團(tuán)隊(duì)是一直存在的，其具體職責(zé)是促進(jìn)Dev團(tuán)隊(duì)和Ops團(tuán)隊(duì)之間的協(xié)作。這個(gè)團(tuán)隊(duì)的成員有時(shí)也被稱(chēng)作“DevOps布道者”，因?yàn)樗麄儙椭麄鱀evOps實(shí)踐。

“DevOps團(tuán)隊(duì)”的目標(biāo)應(yīng)該是通過(guò)賦能組織的其他部分來(lái)讓自己脫離業(yè)務(wù)。

——EricMinick

6型適用于Dev和Ops之間有疏遠(yuǎn)趨勢(shì)的組織。注意反類(lèi)型B的危險(xiǎn)。
潛在有效性：中到高

7型：SRE團(tuán)隊(duì)（谷歌模型）

DevOps經(jīng)常建議Dev團(tuán)隊(duì)加入值班輪換，但這不是必要的。事實(shí)上，有些組織（包括谷歌）運(yùn)行一個(gè)不同的模型，軟件由開(kāi)發(fā)團(tuán)隊(duì)顯式“交接給”運(yùn)行軟件的團(tuán)隊(duì)，即網(wǎng)站可靠性工程團(tuán)隊(duì)（SRE）。在這個(gè)模型中，Dev團(tuán)隊(duì)需要向SRE團(tuán)隊(duì)提供測(cè)試證據(jù)（日志、指標(biāo)等），證明他們的軟件已經(jīng)達(dá)到一個(gè)SRE團(tuán)隊(duì)認(rèn)為足夠好的標(biāo)準(zhǔn)。

至關(guān)重要的是，SRE團(tuán)隊(duì)可以拒絕不符合運(yùn)維標(biāo)準(zhǔn)的軟件，要求開(kāi)發(fā)人員在投入生產(chǎn)之前改進(jìn)代碼。Dev和SRE之間的協(xié)作圍繞著運(yùn)維標(biāo)準(zhǔn)展開(kāi)，但是，一旦SRE團(tuán)隊(duì)對(duì)代碼滿(mǎn)意，他們（而不是Dev團(tuán)隊(duì)）就會(huì)在生產(chǎn)環(huán)境中提供支持。

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

8型：容器驅(qū)動(dòng)協(xié)作

容器將應(yīng)用程序的部署和運(yùn)行要求封裝到了容器中，消除了Dev和Ops之間的某些協(xié)作需求。在這種情況下，容器充當(dāng)了Dev和Ops的責(zé)任邊界。在良好的工程文化中，容器驅(qū)動(dòng)協(xié)作模型運(yùn)轉(zhuǎn)良好，但是，如果Dev開(kāi)始忽視運(yùn)維注意事項(xiàng)，那么，這個(gè)模型就會(huì)向敵對(duì)的“我們和他們”回歸。

8型適用性：容器可以很好地發(fā)揮作用，但要注意反類(lèi)型A，不要期望Ops團(tuán)隊(duì)運(yùn)行Dev扔給他們的任何東西。
潛在有效性：中到高

9型：Dev和DBA協(xié)作

為了消除Dev和DBA之間的鴻溝，有些組織已經(jīng)嘗試使用類(lèi)似9型的模型，DBA團(tuán)隊(duì)的數(shù)據(jù)庫(kù)能力與Dev團(tuán)隊(duì)的數(shù)據(jù)庫(kù)能力（或?qū)ｉL(zhǎng)）可以很好地互補(bǔ)。這似乎有助于將以Dev為中心的數(shù)據(jù)庫(kù)視圖（基本上就是作為應(yīng)用程序笨拙的持久性存儲(chǔ)）和以DBA為中心的數(shù)據(jù)庫(kù)視圖（智能豐富的業(yè)務(wù)價(jià)值源）之間的轉(zhuǎn)換。

9型只適用于有一個(gè)或多個(gè)大型中心數(shù)據(jù)庫(kù)連接多個(gè)應(yīng)用程序的組織。
潛在有效性：中

你所在的團(tuán)隊(duì)開(kāi)始采用DevOps了嗎，是怎樣的模式呢？歡迎大家在評(píng)論區(qū)一起談?wù)劇?/p>

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。