開發(fā)和運(yùn)維的關(guān)系一直很“微妙”，他聽我的， 他不聽我的，哦他開口了，哦好吧我聽不懂他說了啥……開發(fā)和運(yùn)維的恩怨情仇由來已久，由此誕生的DevOps卻是解決他們之間關(guān)系的一劑良藥。

DevOps最主要目的在于提高用戶和業(yè)務(wù)需求提高產(chǎn)品的交付能力與效率。不同的行業(yè)和企業(yè)需要規(guī)劃各種DevOps團(tuán)隊(duì)結(jié)構(gòu)來適應(yīng)開發(fā)和運(yùn)維的協(xié)作。數(shù)人云今天和大家討論的就是這些五花八門的團(tuán)隊(duì)結(jié)構(gòu)，首先，我們先請(qǐng)“反面教材”登場(chǎng)……

反例A：DevOps是啥?

這是典型的開發(fā)和運(yùn)維“各管一攤”。它意味著雖然能很早地聲明項(xiàng)目完成(這里的完成意思僅僅是功能上的完成，而不是交付到生產(chǎn)環(huán)境)，但是軟件的操作性卻無法保證，因?yàn)殚_發(fā)沒有為運(yùn)維考慮很多，運(yùn)維人員也沒有足夠的時(shí)間或者精力去敦促開發(fā)去修正這些問題。

大家都知道這個(gè)團(tuán)隊(duì)結(jié)構(gòu)很糟糕，但是顯然還有更壞的情況——至少這個(gè)結(jié)構(gòu)我們都知道它是有問題的。

反例B：被孤立的DevOps

這種形式通常來源于領(lǐng)導(dǎo)或者執(zhí)行官的決策——他們覺得他們需要一點(diǎn)DevOps，然后組建了一個(gè)“DevOps團(tuán)隊(duì)”。這個(gè)團(tuán)隊(duì)迅速地形成了一個(gè)新的壁壘，在他們眼中，開發(fā)是愚蠢的，運(yùn)維是落伍的，他們捍衛(wèi)著自己小團(tuán)體的知識(shí)、技能和工具，讓開發(fā)和運(yùn)維相隔得更遠(yuǎn)。

只有一種情況會(huì)讓這種結(jié)構(gòu)變得有意義，就是這個(gè)DevOps團(tuán)隊(duì)只是暫時(shí)的，存在時(shí)間低于12或者18個(gè)月，并且目的明確是讓開發(fā)和運(yùn)維更加緊密，一旦過了時(shí)間點(diǎn)這個(gè)團(tuán)隊(duì)就不再有用處，這種情況會(huì)在下文正例5中提到。

反例C：我們不帶運(yùn)維玩

這種團(tuán)隊(duì)組織的天真和傲慢來自于開發(fā)人員和開發(fā)部門的領(lǐng)導(dǎo)者，尤其是在開始一項(xiàng)新的項(xiàng)目或者系統(tǒng)的時(shí)候。開發(fā)們?cè)O(shè)想運(yùn)維已經(jīng)是過去式了(“我們現(xiàn)在有云了，不是嗎”)，輕視了運(yùn)維的復(fù)雜和重要性，認(rèn)為他們可以沒有運(yùn)維，或者用很少的時(shí)間來做運(yùn)維就可以。

當(dāng)他們的軟件變得更加復(fù)雜，運(yùn)維活動(dòng)開始步入泥潭(哦漏開始編程了)，這種結(jié)構(gòu)就會(huì)終結(jié)，取而代之的是下文的正例3(IaaS)或者4(DevOps-as-a-Service)。團(tuán)隊(duì)會(huì)意識(shí)到軟件開發(fā)過程中運(yùn)維的重要性，就可以避免很多不必要的痛苦和低級(jí)的運(yùn)維錯(cuò)誤。

看完了反面教材，我們?cè)賮砜纯碊evOps中常見的一些可用的團(tuán)隊(duì)組織結(jié)構(gòu)。

正例1：相親相愛，其樂融融

這是DevOps的“樂土”：開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)之間融洽的合作，在隔離或者半隔離的產(chǎn)品堆棧上工作，需要專攻的地方有專門的負(fù)責(zé)，需要共享的地方也有專門的分享。

但這種融洽的協(xié)作模型需要大量的變革，以及一個(gè)更高水平的技術(shù)領(lǐng)導(dǎo)團(tuán)隊(duì)。開發(fā)和運(yùn)維必須有一個(gè)清晰的溝通表達(dá)(來傳遞可靠、頻繁的變化)和明確有效的共同目標(biāo)，運(yùn)維人員必須和開發(fā)人員良好地配合，認(rèn)真處理測(cè)試驅(qū)動(dòng)的代碼和Git，而開發(fā)必須認(rèn)真對(duì)待各種運(yùn)維特性，這都需要一個(gè)相當(dāng)大的文化層次上的變革。

適用于：有著強(qiáng)大技術(shù)領(lǐng)導(dǎo)力的團(tuán)隊(duì)組織

潛在效率：高

正例2：你中有我，我中有你

運(yùn)維人員已經(jīng)完全嵌入到產(chǎn)品開發(fā)的團(tuán)隊(duì)中。開發(fā)和運(yùn)維幾乎不分開，都高度地專注在一個(gè)共同的目標(biāo)里;這是一種正例1中比較有爭(zhēng)議的一種特殊形式，它有一些獨(dú)特之處。

Netflix 和 Facebook等組織因?yàn)橛袉为?dú)基于Web的產(chǎn)品，使用了這種結(jié)構(gòu)而非常有效率。但是這種結(jié)構(gòu)并不適用于狹窄產(chǎn)品帶以外的情況，因?yàn)橛邢薜念A(yù)算和多個(gè)產(chǎn)品線會(huì)導(dǎo)致開發(fā)運(yùn)維的隔離。這種完全嵌入的模式也可以叫做“NoOps”(無運(yùn)維)，因?yàn)闆]有明顯或者特定的運(yùn)維團(tuán)隊(duì)(Netflix的情況可能也歸結(jié)為下面的正例3，IaaS)。

適用于：?jiǎn)我粸橹鳌⒒赪eb的產(chǎn)品或服務(wù)的組織

潛在效率：高

正例3：轉(zhuǎn)身困難，IaaS來幫忙

一個(gè)相當(dāng)傳統(tǒng)的IT運(yùn)營(yíng)部門可能不愿或者不能迅速地做出改變，或者對(duì)于把所有應(yīng)用都跑在公有云之上的組織來說，這種結(jié)構(gòu)可以幫助組織的運(yùn)維部分只需要一個(gè)彈性的基礎(chǔ)設(shè)置供應(yīng)用程序部署和運(yùn)行，而內(nèi)部運(yùn)維團(tuán)隊(duì)則變成了例如亞馬遜的EC2，或者說IaaS。

這樣一個(gè)團(tuán)隊(duì)(可能只是虛擬的)包含在開發(fā)里面，在運(yùn)營(yíng)上是專家——很懂操作特性、指標(biāo)、監(jiān)控和服務(wù)器配置等等，和IaaS團(tuán)隊(duì)有著非常多的交流。然而這個(gè)團(tuán)隊(duì)依然是一個(gè)開發(fā)團(tuán)隊(duì)，遵循著開發(fā)的標(biāo)準(zhǔn)實(shí)踐如TDD、CI、迭代開發(fā)和培訓(xùn)等。

IaaS的出現(xiàn)用失去和運(yùn)維人員直接合作的代價(jià)來?yè)Q取了更簡(jiǎn)單的實(shí)現(xiàn)高效率，其實(shí)現(xiàn)速度可能比正例1中更快。

適用于：有著幾個(gè)不同產(chǎn)品和服務(wù)，或有著傳統(tǒng)的運(yùn)維部門，或者完全將應(yīng)用部署在公有云的組織

潛在效率：中

正例4：當(dāng)DevOps也成為服務(wù)

一些小規(guī)模的公司沒有專門細(xì)分的運(yùn)維和開發(fā)，他們需要更專業(yè)的技術(shù)服務(wù)公司幫助構(gòu)建測(cè)試環(huán)境、自動(dòng)化基礎(chǔ)設(shè)施和監(jiān)控，并為他們?cè)谲浖_發(fā)進(jìn)程中提供一些運(yùn)營(yíng)方面的建議。

DevOps即服務(wù)可能會(huì)成為一種對(duì)小型組織或團(tuán)隊(duì)的自動(dòng)化、監(jiān)控和配置管理非常有用的形式，然后隨著團(tuán)隊(duì)的成長(zhǎng)，他們可以承擔(dān)更多運(yùn)維為主的員工，就會(huì)逐漸向正例3甚至正例1進(jìn)化。

適用于：經(jīng)驗(yàn)有限的小型團(tuán)隊(duì)或組織

潛在效率：中

正例5：擔(dān)任臨時(shí)演員的DevOps團(tuán)隊(duì)

臨時(shí)的DevOps團(tuán)隊(duì)看起來像大大的反例B，但是它的目的和存在時(shí)間都不盡相同。這種臨時(shí)的團(tuán)隊(duì)負(fù)責(zé)把開發(fā)和運(yùn)維聯(lián)系得更緊密，朝著正例1和2演進(jìn)，最終完成使命后消失。

臨時(shí)的團(tuán)隊(duì)將擔(dān)任“開發(fā)語言”和“運(yùn)維語言”之間的“翻譯”，將開發(fā)們瘋狂的想法傳達(dá)給運(yùn)維團(tuán)隊(duì)，把運(yùn)維的負(fù)載均衡、管理網(wǎng)卡和SSL卸載等想法傳遞給開發(fā)。如果有足夠多的人開始注意到讓開發(fā)和運(yùn)維一起合作的價(jià)值，那么臨時(shí)團(tuán)隊(duì)就實(shí)現(xiàn)了它的目的。至關(guān)重要的是，部署和生產(chǎn)診斷等長(zhǎng)期工作不應(yīng)該分配給這個(gè)臨時(shí)團(tuán)隊(duì)，否則它可能會(huì)變成反例B。

適用性：正例1的先導(dǎo)模式，但是有轉(zhuǎn)變成反例B的風(fēng)險(xiǎn)

潛在效率：低到高

敲黑板的總結(jié)

細(xì)數(shù)了上面的反例和正例，總結(jié)一下， DevOps結(jié)構(gòu)的適用性取決于如下幾個(gè)要素：

組織的產(chǎn)品集：如康威定理所說，更少的產(chǎn)品會(huì)讓合作更加容易，隔閡也更加少。

技術(shù)領(lǐng)導(dǎo)的能力和效率，開發(fā)和運(yùn)維是否目標(biāo)一致。

是否有能力或者意愿改變運(yùn)營(yíng)部門，是否認(rèn)真地對(duì)待產(chǎn)品運(yùn)營(yíng)特性。

在運(yùn)維關(guān)鍵點(diǎn)上是否有能力起到帶頭作用。

當(dāng)然，這里提到的拓?fù)浣Y(jié)構(gòu)都是作為一種參考或者啟發(fā)。在現(xiàn)實(shí)中，多個(gè)模式的組合，或者一個(gè)模式轉(zhuǎn)換成另一個(gè)模式都是可以的，畢竟適合才是最好的。