在大多數(shù)的團(tuán)隊(duì)中，開發(fā)、運(yùn)維之間有著一系列沖突和博弈。

[[210928]]

有人說，DevOps 的出現(xiàn)讓開發(fā)和運(yùn)維不再相愛相殺，從此一起手牽手，開心得 Coding 和捉 Bug；但也有人說，DevOps 就是開發(fā)吃掉運(yùn)維。

是這樣的嗎，不同的團(tuán)隊(duì)結(jié)構(gòu)會(huì)對(duì) DevOps 的發(fā)展有何影響？請(qǐng)看下文，你會(huì)有自己的答案。

• 組織中發(fā)起任何 DevOps 相關(guān)活動(dòng)的首要目的是改善對(duì)客戶和業(yè)務(wù)的價(jià)值交付，而不是降低成本，提升自動(dòng)化程度，或者從配置管理中驅(qū)動(dòng)任何事情。
• 這意味著不同的組織可能需要不同的團(tuán)隊(duì)結(jié)構(gòu)才能開展有效的開發(fā)和運(yùn)維協(xié)作。
• 哪些 DevOps 團(tuán)隊(duì)結(jié)構(gòu)或拓?fù)溥m合組織，取決于幾件事情：
• 該組織的產(chǎn)品組合：較少的產(chǎn)品使得協(xié)作更加容易。因?yàn)楦鶕?jù)康威定律，這種情況下各自獨(dú)立的小團(tuán)隊(duì)較少。

技術(shù)領(lǐng)導(dǎo)力的范圍，力度和有效性；Dev 和 Ops 是否有共同的目標(biāo)。

一個(gè)組織是否具有將 IT 運(yùn)維部門從“硬件機(jī)架”和“配置服務(wù)器”改變?yōu)榕c價(jià)值流實(shí)際一致的需求或能力，以及軟件研發(fā)團(tuán)隊(duì)是否認(rèn)真對(duì)待來自運(yùn)維方面的要求。

該組織是否具備帶頭解決當(dāng)前運(yùn)維問題的能力或技能。

當(dāng)然，這里描述的主題有所不同；拓?fù)浜皖愋褪亲鳛閰⒖贾改匣騿l(fā)，協(xié)助您來評(píng)估哪些模式可能是適合的。實(shí)際上，將多種模式或一種模式轉(zhuǎn)化為另一種模式的組合往往是最好的方法。

那么 DevOps 的團(tuán)隊(duì)結(jié)構(gòu)如何發(fā)展呢？ 顯然，沒有任何適合每個(gè)組織的理想結(jié)構(gòu)或團(tuán)隊(duì)拓?fù)洹?/p>

然而，對(duì)于團(tuán)隊(duì)結(jié)構(gòu)來說，參考少數(shù)不同的模型是有用的，其中一些模型與某些組織的適合度更高。

通過探索這些團(tuán)隊(duì)結(jié)構(gòu)（或“拓?fù)?rdquo;）的優(yōu)缺點(diǎn)，考慮到康威定律，我們可以確定可能對(duì)我們自己組織中 DevOps 做法最有效的團(tuán)隊(duì)結(jié)構(gòu)。

這些 DevOps 拓?fù)渲械拇蠖鄶?shù)已經(jīng)在其他地方描述過；特別是 CollabNet 的 Lawrence Sweeney 在對(duì) Ben Kepes 博客的評(píng)論中談到了有關(guān)我在這里所描述的反類型 B（獨(dú)立的 DevOps 團(tuán)隊(duì)），類型3（運(yùn)維作為基礎(chǔ)設(shè)施服務(wù)）以及類型1（開發(fā)和運(yùn)維協(xié)作）。

DevOpsGuys列出了十二個(gè) DevOps 反模式，Jez Humble，Gene Kim，Damon Edwards（以及許多其他人）也曾經(jīng)說過類似的事情。

我在這里添加了三個(gè)額外的“拓?fù)?rdquo;，我沒有看到或聽到與此相關(guān)的一些討論（共享運(yùn)維，DevOps-as-a-Service 和臨時(shí) DevOps 團(tuán)隊(duì)）。

DevOps 反類型

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

• Dev 和Ops 分離 
• 單獨(dú)的 DevOps 團(tuán)隊(duì) 
• 開發(fā)不需要運(yùn)維 
• DevOps 作為工具團(tuán)隊(duì)
• 系統(tǒng)管理員 
• 開發(fā)包含運(yùn)維 
• 開發(fā)和 DBA 分離

反類型 A：Dev 和 Ops 分離

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

因?yàn)殚_發(fā)者沒有運(yùn)維相關(guān)的上下文信息，運(yùn)維人員沒有時(shí)間或者動(dòng)力參與到開發(fā)者中，在軟件上線之前解決問題。

我們都知道這種拓?fù)漕愋筒缓?，但我認(rèn)為有很多相似的拓?fù)浣Y(jié)構(gòu)很差；至少我們清楚反類型 A（開發(fā)和運(yùn)維分離）是一個(gè)問題。

反類型 B：?jiǎn)为?dú)的 DevOps 團(tuán)隊(duì)

單獨(dú)的 DevOps 團(tuán)隊(duì)通常來自經(jīng)理或執(zhí)行官，他們決定“需要一點(diǎn)這個(gè) DevOps 的事情”，并啟動(dòng)一個(gè)“DevOps 團(tuán)隊(duì)”（可能是被稱為“DevOp”的人）。

DevOps 團(tuán)隊(duì)的成員迅速形成另一個(gè)團(tuán)體，使 Dev 和 Ops 比以往任何時(shí)候都更加分開，因?yàn)樗麄冃枰葱l(wèi)自己的角色，技能和工具集，防止自己被“無知的 Devs”和“恐龍般的 Ops”所消滅。

單獨(dú)的 DevOps 團(tuán)隊(duì)真的有意義的唯一的情況是，當(dāng)團(tuán)隊(duì)是暫時(shí)的，例如持續(xù)時(shí)間少于 12 或 18 個(gè)月，其明確目的是使 Dev 和 Ops 更緊密地結(jié)合在一起，并被明確地授權(quán)的時(shí)候，當(dāng)這段時(shí)間過去，這個(gè)團(tuán)隊(duì)是多余的。

這就是我所說的類型 5 DevOps 拓?fù)洹?/p>

反類型 C：開發(fā)不需要運(yùn)維

這種拓?fù)浣Y(jié)構(gòu)由開發(fā)人員和開發(fā)經(jīng)理之間的天真和傲慢相結(jié)合，特別是在新項(xiàng)目或系統(tǒng)開始時(shí)。

假設(shè) Ops 現(xiàn)在是過時(shí)的事情（“我們現(xiàn)在有了 Cloud，對(duì)嗎？”），開發(fā)人員大大低估了運(yùn)維技能和活動(dòng)的復(fù)雜性和重要性，并認(rèn)為他們可以不需要運(yùn)維，或者在閑暇時(shí)間就可以搞定運(yùn)維做的事情。

這種反類型 C DevOps 拓?fù)淇赡茏罱K需要 Type 3（Ops as IaaS）或 Type 4（DevOps-as-a-Service）拓?fù)?，?dāng)他們的軟件變得更加深入和復(fù)雜，運(yùn)維開始需要開發(fā)工作（又稱編碼）的時(shí)候。

如果這樣的團(tuán)隊(duì)認(rèn)識(shí)到運(yùn)維作為一個(gè)重要和有價(jià)值的學(xué)科，并且認(rèn)可其對(duì)于軟件開發(fā)的重要性，他們將能夠避免許多痛苦和不必要的（和相當(dāng)基本的）運(yùn)維錯(cuò)誤。

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

在不影響當(dāng)前開發(fā)團(tuán)隊(duì)的速度（實(shí)現(xiàn)用戶故事）的情況下，成立一個(gè) DevOps 團(tuán)隊(duì)，負(fù)責(zé)部署管道，配置管理，環(huán)境管理等所需的工具。同時(shí)，Ops 的人們繼續(xù)孤立工作，Dev 團(tuán)隊(duì)繼續(xù)將他們的應(yīng)用程序“放在墻上”。

雖然這個(gè)專門團(tuán)隊(duì)的成果在改進(jìn)工具鏈方面可能是有益的，但其影響是有限的。在應(yīng)用程序開發(fā)生命周期中缺乏早期運(yùn)維的參與和協(xié)作，根本問題依然存在。

反類型 E：變相的 SysAdmin

這種反類型在工程成熟度低的組織中是典型的。他們希望改善他們的做法并降低成本，但是他們不能將 IT 視為業(yè)務(wù)的核心驅(qū)動(dòng)力。

因?yàn)?DevOps 的行業(yè)成功現(xiàn)在顯而易見，他們也想“做 DevOps”。不幸的是，他們并沒有反思目前的結(jié)構(gòu)和關(guān)系的差距，而是為其 Ops 團(tuán)隊(duì)聘請(qǐng)了“DevOps 工程師”。

DevOps 只是一個(gè)名為 SysAdmin 的角色的重塑，沒有真正的文化/組織變化發(fā)生。

這種反型越來越廣泛，因?yàn)橛孤档恼衅溉藛T只是尋找具有自動(dòng)化和工具技能的候選人。不幸的是，人際溝通技巧才能真正使 DevOps 在組織中茁壯成長(zhǎng)。

反類型 F：運(yùn)維嵌入開發(fā)團(tuán)隊(duì)

該組織不希望獨(dú)立的運(yùn)維團(tuán)隊(duì)，所以開發(fā)團(tuán)隊(duì)負(fù)責(zé)基礎(chǔ)設(shè)施，管理環(huán)境，監(jiān)控等。

但是，這樣以項(xiàng)目或產(chǎn)品驅(qū)動(dòng)的方式，意味著這些項(xiàng)目受到資源限制，優(yōu)先次序?qū)е铝溯^差的運(yùn)作方式和半成品的解決方案。

在這種反類型方面，該組織對(duì)于有效的 IT 運(yùn)維所需的重要性和技能缺乏認(rèn)識(shí)。

反類型 G：Dev 和 DBA 隔離

這是一種在中型到大型公司中突出的反類型 A（開發(fā)和運(yùn)維分離）的形式，其中多個(gè)遺留系統(tǒng)依賴于相同的核心數(shù)據(jù)集。

由于這些數(shù)據(jù)庫(kù)對(duì)于業(yè)務(wù)至關(guān)重要，因此經(jīng)常在業(yè)務(wù)范圍內(nèi)的專門的 DBA 團(tuán)隊(duì)負(fù)責(zé)維護(hù)，性能調(diào)整和災(zāi)難恢復(fù)。

這是可以理解的，但問題是當(dāng)這個(gè)團(tuán)隊(duì)成為任何數(shù)據(jù)庫(kù)變更的門戶時(shí)，有效成為小型和頻繁部署（DevOps 和持續(xù)交付的核心宗旨）的障礙。

此外，就像在反類型 A 中的運(yùn)維一樣，DBA 團(tuán)隊(duì)在應(yīng)用開發(fā)早期也沒有涉及，因此數(shù)據(jù)問題（遷移，性能等）在交付周期的后期被發(fā)現(xiàn)。

加上支持多個(gè)應(yīng)用數(shù)據(jù)庫(kù)的過載，最終的結(jié)果是面臨持續(xù)的“救火”和部署壓力。

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

站在反類型的對(duì)面，我們看一些適合 DevOps 的拓?fù)洌?/span>

• 開發(fā)和運(yùn)維協(xié)作 
• 完全共享運(yùn)維責(zé)任
• 運(yùn)維作為基礎(chǔ)設(shè)施服務(wù) 
• DevOps-as-a-Service 
• 臨時(shí) DevOps 團(tuán)隊(duì) 
• DevOps 布道者團(tuán)隊(duì) 
• SRE 團(tuán)隊(duì) 
• 容器驅(qū)動(dòng)的協(xié)作
• 數(shù)據(jù)庫(kù)能力

類型 1：開發(fā)和與運(yùn)維協(xié)作

這是 DevOps 的“樂土”：開發(fā)團(tuán)隊(duì)和運(yùn)營(yíng)團(tuán)隊(duì)之間的順利協(xié)作，每個(gè)專業(yè)都在需要的地方，但也需要分享?？赡苡性S多獨(dú)立的開發(fā)團(tuán)隊(duì)，每個(gè)工作在一個(gè)單獨(dú)的或半獨(dú)立的產(chǎn)品堆棧。

我的意思是，這種 1 型模型需要相當(dāng)大的組織變革才能建立起來，在技術(shù)管理團(tuán)隊(duì)中具有較高的競(jìng)爭(zhēng)力。

開發(fā)者和運(yùn)維部門必須有明確的表達(dá)和鮮明合理的共同目標(biāo)（“高質(zhì)量交付，擁抱變化”或其他）。

運(yùn)維人員必須與 Devs 配對(duì)，掌握測(cè)試驅(qū)動(dòng)的編碼技能和 Git 工具，并且開發(fā)必須認(rèn)真對(duì)待運(yùn)維特性方面的要求，并尋找運(yùn)維人員加入日志實(shí)現(xiàn)。從目前狀況到這個(gè)狀態(tài)，所有這些都需要相當(dāng)?shù)奈幕兏铩?/p>

類型 1 適應(yīng)性：一個(gè)技術(shù)驅(qū)動(dòng)型的組織。

有效潛力：高

類型 2：完全共享運(yùn)維責(zé)任

在運(yùn)維人員已經(jīng)集成到產(chǎn)品開發(fā)團(tuán)隊(duì)中的情況下，我們看到了類型 2 拓?fù)洹?/p>

Dev 和 Ops 之間的分離很少，所有人都高度重視共同的目標(biāo)；這是一種形式的類型 1（開發(fā)和運(yùn)維協(xié)作），但它有一些特殊的功能。

Netflix 和 Facebook 等組織有效實(shí)現(xiàn)了一種基于 Web 的產(chǎn)品，已經(jīng)實(shí)現(xiàn)了這種 2 型拓?fù)浣Y(jié)構(gòu)。

但是我認(rèn)為在單純的產(chǎn)品角度之外來看，它可能不是非常適用的，因?yàn)轭A(yù)算限制和多個(gè)產(chǎn)品線之間通常存在上下文切換，這可能會(huì)迫使 Dev 和 Ops 進(jìn)一步分開（例如，回到類型 1 模型）。

這個(gè)拓?fù)湟部赡鼙环Q為“NoOps”，因?yàn)闆]有明顯的或可見的運(yùn)維團(tuán)隊(duì)（盡管 Netflix NoOps 也可能是類型 3（作為 IaaS 的 Ops））。

類型 2 適應(yīng)性：組織只有一個(gè)簡(jiǎn)單的基于 Web 的產(chǎn)品或服務(wù)。

有效潛力：高

類型 3：運(yùn)維作為基礎(chǔ)設(shè)施服務(wù)

對(duì)于 IT 運(yùn)維部門非常傳統(tǒng)的組織，不會(huì)或者不能（足夠）快速地?fù)肀ё兓?，適合在公共云（Amazon EC2，Rackspace，Azure 等）中運(yùn)行所有應(yīng)用程序的組織。

它可能將運(yùn)維作為一個(gè)只需提供應(yīng)用程序部署和運(yùn)行功能的彈性基礎(chǔ)設(shè)施團(tuán)隊(duì)。因此，內(nèi)部運(yùn)維團(tuán)隊(duì)直接等同于 Amazon EC2 或基礎(chǔ)架構(gòu)即服務(wù)。

Dev 內(nèi)部的一個(gè)團(tuán)隊(duì)（或許是一個(gè)虛擬團(tuán)隊(duì)）將作為運(yùn)維特性、指標(biāo)、監(jiān)控、服務(wù)器配置等方面的專業(yè)知識(shí)來源，并且可能與 IaaS 團(tuán)隊(duì)進(jìn)行大部分的溝通。

然而，這個(gè)團(tuán)隊(duì)仍然是一個(gè)開發(fā)團(tuán)隊(duì)，遵循 TDD、CI、迭代開發(fā)、人員指導(dǎo)等標(biāo)準(zhǔn)實(shí)踐。

IaaS 拓?fù)浣Y(jié)構(gòu)具有一些潛在的有效性（與Ops 人員直接協(xié)作），以便更容易實(shí)施，可能比稍后嘗試的類型 1（開發(fā)和運(yùn)營(yíng)協(xié)作）更快地獲得價(jià)值。

類型 3 適應(yīng)性：具有多種不同產(chǎn)品和服務(wù)，傳統(tǒng)的運(yùn)維部門，或其應(yīng)用程序完全在公有云中運(yùn)行的組織。

有效潛力：中

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

一些組織，特別是較小的組織可能沒有資金，經(jīng)驗(yàn)或工作人員來主導(dǎo)他們的軟件運(yùn)維。

開發(fā)團(tuán)隊(duì)可能會(huì)接觸到像 Rackspace 這樣的服務(wù)提供商，以幫助他們建立測(cè)試環(huán)境并自動(dòng)化其基礎(chǔ)設(shè)施和監(jiān)控，并就軟件開發(fā)周期中實(shí)現(xiàn)的各種運(yùn)維功能提供建議。

可以稱之為 DevOps-as-a-Serviced 的可能是小型組織或團(tuán)隊(duì)，他們了解自動(dòng)化，監(jiān)控和配置管理的用途和實(shí)現(xiàn)方式。

隨著業(yè)務(wù)的發(fā)展和更多的員工加入，可能轉(zhuǎn)向第 3 類（作為 IaaS 的操作）或甚至第一類（開發(fā)和運(yùn)維協(xié)作）模式。

類型 4 適應(yīng)性：運(yùn)營(yíng)經(jīng)驗(yàn)較少的小型團(tuán)隊(duì)或組織。

有效潛力：中

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

具有到期日的 DevOps 團(tuán)隊(duì)（類型 5）看起來像反類型 B（DevOps Team Silo），但其意圖和壽命是完全不同的。

這個(gè)臨時(shí)團(tuán)隊(duì)的任務(wù)是使 Dev 和 Ops 更緊密地結(jié)合在一起，理想目標(biāo)是面向類型 1（開發(fā)和運(yùn)營(yíng)協(xié)作）或類型 2（完全共享的 Ops Reponsibility）模型，并最終使其自身過時(shí)。

臨時(shí)小組的成員將在 Dev-speak 和 Ops-talk 之間進(jìn)行“翻譯”，引入瘋狂的想法，如為 Ops 團(tuán)隊(duì)引入站立會(huì)和看板，并考慮“骯臟”的細(xì)節(jié)，如負(fù)載均衡器，管理 NIC 和為 Dev 團(tuán)隊(duì)卸載 SSL。

如果足夠多的人開始看到將 Dev 和 Ops 組合在一起的價(jià)值，那么臨時(shí)團(tuán)隊(duì)就有實(shí)現(xiàn)其目標(biāo)的真正機(jī)會(huì)。

至關(guān)重要的是，部署和生產(chǎn)環(huán)境的長(zhǎng)期分析診斷責(zé)任不應(yīng)該提供給臨時(shí)團(tuán)隊(duì)，否則可能會(huì)造成 DevOps 團(tuán)隊(duì)隔離（反類型 B）。

類型 5 適應(yīng)性：運(yùn)營(yíng)經(jīng)驗(yàn)較少的小型團(tuán)隊(duì)或組織。

有效潛力：低至中

類型 6：DevOps“布道者”團(tuán)隊(duì)

在 Dev 與 Ops 之間存在巨大差距（或者大的差距趨勢(shì)）的組織中，擁有一個(gè)“促進(jìn)”DevOps 團(tuán)隊(duì)來保持 Dev 和 Ops 方面的交流是有效的。

這是一個(gè)類型 5（DevOps Team with Expirey Date）的版本，但 DevOps 團(tuán)隊(duì)在持續(xù)的基礎(chǔ)上存在著具體的促進(jìn) Dev 與 Ops 團(tuán)隊(duì)之間的協(xié)作與合作的職責(zé)。

這個(gè)團(tuán)隊(duì)的成員有時(shí)被稱為“DevOps 布道者”，因?yàn)樗鼈冇兄趥鞑?DevOps 實(shí)踐的意識(shí)。

“DevOps團(tuán)隊(duì)”的目標(biāo)應(yīng)該是通過啟用組織的其余部分來實(shí)現(xiàn)自己的業(yè)務(wù)。— Twitter: EricMinick

類型 6 適應(yīng)性：Dev 和 Ops 趨勢(shì)分散的組織，小心類型 B 的危險(xiǎn)。

有效潛力：中至高

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

DevOps 經(jīng)常建議 Dev 團(tuán)隊(duì)定期參加值班會(huì)議，但這不是必須的。

事實(shí)上，一些組織（包括 Google）運(yùn)行不同的模式，從開發(fā)到運(yùn)行該軟件的團(tuán)隊(duì)（站點(diǎn)可靠性工程（SRE））可以實(shí)現(xiàn)明確“切換”。

在這個(gè)模型中，開發(fā)團(tuán)隊(duì)需要向 SRE 團(tuán)隊(duì)提供測(cè)試證據(jù)（日志，指標(biāo)等），表明他們的軟件具有足夠的標(biāo)準(zhǔn)，得到 SRE 團(tuán)隊(duì)的支持。

最重要的是，SRE 團(tuán)隊(duì)可以拒絕在運(yùn)維上不合標(biāo)準(zhǔn)的軟件，要求開發(fā)人員在將代碼投入生產(chǎn)之前對(duì)其進(jìn)行改進(jìn)。

Dev 和 SRE 之間的協(xié)作發(fā)生在運(yùn)維標(biāo)準(zhǔn)上，但是一旦 SRE 團(tuán)隊(duì)對(duì)代碼感到滿意，他們（而不是開發(fā)團(tuán)隊(duì)）就在生產(chǎn)中支持它。

類型 7 適應(yīng)性：類型 7 僅適用于具有高度工程和組織成熟度的組織。如果 SRE/Ops 團(tuán)隊(duì)被告知“JFDI”部署，請(qǐng)小心返回反類型 A。

有效潛力：低至高

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

通過將應(yīng)用程序的部署和運(yùn)行時(shí)需求封裝到容器中，容器不再需要 Dev 和 Ops 之間的某些協(xié)作。

這樣，容器就成為開發(fā)和運(yùn)維的責(zé)任界限。憑借良好的工程文化，容器驅(qū)動(dòng)的協(xié)作模式運(yùn)作良好，但如果開發(fā)者開始忽視運(yùn)維需要考慮的一些事情，這種模式可以轉(zhuǎn)變?yōu)閷?duì)抗的“我們與他們”。

類型 8 適應(yīng)性：容器可以工作得很好，但要注意反類型 A，Ops 團(tuán)隊(duì)預(yù)計(jì)會(huì)運(yùn)行 Dev 發(fā)出的任何內(nèi)容。

有效潛力：中至高

類型 9：開發(fā)和 DBA 協(xié)作

為了彌合 Dev-DBA 的鴻溝，一些組織已經(jīng)嘗試過類似于類型9的數(shù)據(jù)庫(kù)功能，DBA 團(tuán)隊(duì)的數(shù)據(jù)庫(kù)功能與 Dev 團(tuán)隊(duì)的數(shù)據(jù)庫(kù)功能（或?qū)I(yè)）相稱。

這似乎有助于在以開發(fā)為中心的數(shù)據(jù)庫(kù)（本質(zhì)上是應(yīng)用程序的虛擬持久存儲(chǔ)）視圖和 DBA 為中心的數(shù)據(jù)庫(kù)（智能，豐富的業(yè)務(wù)價(jià)值來源）視圖之間進(jìn)行轉(zhuǎn)換。

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

有效潛力：中

請(qǐng)記?。喝魏我粋€(gè)組織都沒有“正確的”團(tuán)隊(duì)拓?fù)?，但是有幾個(gè)“壞”拓?fù)洹?/span>