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

1: 開(kāi)發(fā)和運(yùn)維協(xié)作 2: 共享運(yùn)維 3: 運(yùn)維作為基礎(chǔ)設(shè)施服務(wù) 4: DevOps-as-a-Service 5: 臨時(shí)DevOps團(tuán)隊(duì) 6: DevOps 布道者團(tuán)隊(duì) 7: SRE 團(tuán)隊(duì) 8: 容器驅(qū)動(dòng) 9: 數(shù)據(jù)庫(kù)能力

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

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

我的意思是，這種1型模型需要相當(dāng)大的組織變革才能建立起來(lái)，在技術(shù)管理團(tuán)隊(duì)中具有較高的競(jìng)爭(zhēng)力。開(kāi)發(fā)者和運(yùn)維部門必須有明確的表達(dá)和鮮明合理的共同目標(biāo)(“高質(zhì)量交付，擁抱變化”或其他)。運(yùn)維人員必須與Devs配對(duì)，掌握測(cè)試驅(qū)動(dòng)的編碼技能和Git工具，并且開(kāi)發(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)品開(kāi)發(fā)團(tuán)隊(duì)中的情況下，我們看到了類型2拓?fù)?。Dev和Ops之間的分離很少，所有人都高度重視共同的目標(biāo);這是一種形式的類型1(開(kāi)發(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)品角度之外來(lái)看，它可能不是非常適用的，因?yàn)轭A(yù)算限制和多個(gè)產(chǎn)品線之間通常存在上下文切換，這可能會(huì)迫使Dev和Ops進(jìn)一步分開(kāi)(例如，回到類型1模型)。這個(gè)拓?fù)湟部赡鼙环Q為“NoOps”，因?yàn)闆](méi)有明顯的或可見(jià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ì)或者不能(足夠)快地速擁抱變化，對(duì)于在公共云(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í)來(lái)源，并且可能與IaaS團(tuán)隊(duì)進(jìn)行大部分的溝通。然而，這個(gè)團(tuán)隊(duì)仍然是一個(gè)開(kāi)發(fā)團(tuán)隊(duì)，遵循TDD，CI，迭代開(kāi)發(fā)，人員指導(dǎo)等標(biāo)準(zhǔn)實(shí)踐。

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

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

有效潛力：中

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

一些組織，特別是較小的組織可能沒(méi)有資金，經(jīng)驗(yàn)或工作人員來(lái)主導(dǎo)他們的軟件運(yùn)維。開(kāi)發(fā)團(tuán)隊(duì)可能會(huì)接觸到像Rackspace這樣的服務(wù)提供商，以幫助他們建立測(cè)試環(huán)境并自動(dòng)化其基礎(chǔ)設(shè)施和監(jiān)控，并就軟件開(kāi)發(fā)周期中實(shí)現(xiàn)的各種運(yùn)維功能提供建議?？梢苑Q之為DevOps-as-a-Serviced的可能是小型組織或團(tuán)隊(duì)，他們了解自動(dòng)化，監(jiān)控和配置管理的用途和實(shí)現(xiàn)方式，然后隨著業(yè)務(wù)的發(fā)展和更多的員工，可能轉(zhuǎn)向第3類(作為IaaS的操作)或甚至第一類(開(kāi)發(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)看起來(lái)像反類型B(DevOps Team Silo)，但其意圖和壽命是完全不同的。這個(gè)臨時(shí)團(tuán)隊(duì)的任務(wù)是使Dev和Ops更緊密地結(jié)合在一起，理想目標(biāo)是面向類型1(開(kāi)發(fā)和運(yùn)營(yíng)協(xié)作)或類型2(完全共享的Ops Reponsibility)模型，并最終使其自身過(guò)時(shí)。臨時(shí)小組的成員將在Dev-speak和Ops-talk之間進(jìn)行“翻譯”，引入瘋狂的想法，如為Ops團(tuán)隊(duì)引入站立會(huì)和看板，并考慮“骯臟”的細(xì)節(jié)，如負(fù)載均衡器，管理NIC和為Dev團(tuán)隊(duì)卸載SSL。如果足夠多的人開(kāi)始看到將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ì)來(lái)保持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)樗鼈冇兄趥鞑evOps實(shí)踐的意識(shí)。

“DevOps團(tuán)隊(duì)”的目標(biāo)應(yīng)該是通過(guò)啟用組織的其余部分來(lái)實(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)行不同的模式，從開(kāi)發(fā)到運(yùn)行該軟件的團(tuán)隊(duì)(站點(diǎn)可靠性工程(SRE))團(tuán)隊(duì)的明確“切換”。在這個(gè)模型中，開(kāi)發(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)的軟件，要求開(kāi)發(fā)人員在將代碼投入生產(chǎn)之前對(duì)其進(jìn)行改進(jìn)。Dev和SRE之間的協(xié)作發(fā)生在運(yùn)維標(biāo)準(zhǔn)上，但是一旦SRE團(tuán)隊(duì)對(duì)代碼感到滿意，他們(而不是開(kāi)發(fā)團(tuán)隊(duì))就在生產(chǎn)中支持它。

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

有效潛力：低至高

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

通過(guò)將應(yīng)用程序的部署和運(yùn)行時(shí)需求封裝到容器中，容器不再需要Dev和Ops之間的某些協(xié)作。這樣，容器就是開(kāi)發(fā)和運(yùn)維的責(zé)任界限。憑借良好的工程文化，容器驅(qū)動(dòng)的協(xié)作模式運(yùn)作良好，但如果開(kāi)發(fā)者開(kāi)始忽視運(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：開(kāi)發(fā)和DBA協(xié)作

為了彌合Dev-DBA的鴻溝，一些組織已經(jīng)嘗試過(guò)類似于類型9的數(shù)據(jù)庫(kù)功能，DBA團(tuán)隊(duì)的數(shù)據(jù)庫(kù)功能與Dev團(tuán)隊(duì)的數(shù)據(jù)庫(kù)功能(或?qū)I(yè))相稱。這似乎有助于在以開(kāi)發(fā)為中心的數(shù)據(jù)庫(kù)(以本質(zhì)上是應(yīng)用程序的虛擬持久存儲(chǔ))視圖和DBA為中心的數(shù)據(jù)庫(kù)(智能，豐富的業(yè)務(wù)價(jià)值來(lái)源)視圖之間進(jìn)行轉(zhuǎn)換。

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

有效潛力：中

請(qǐng)記?。喝魏我粋€(gè)組織都沒(méi)有“正確的”團(tuán)隊(duì)拓?fù)洌怯袔讉€(gè)“壞”拓?fù)洹?/p>