一份DevOps結(jié)構(gòu)清單——請君慢用
DevOps最主要目的在于提高用戶和業(yè)務(wù)需求提高產(chǎn)品的交付能力與效率。不同的行業(yè)和企業(yè)需要規(guī)劃各種DevOps團(tuán)隊結(jié)構(gòu)來適應(yīng)開發(fā)和運(yùn)維的協(xié)作。數(shù)人云今天和大家討論的就是這些五花八門的團(tuán)隊結(jié)構(gòu)，首先，我們先請“反面教材”登場……
反例A：DevOps是啥?
這是典型的開發(fā)和運(yùn)維“各管一攤”。它意味著雖然能很早地聲明項目完成(這里的完成意思僅僅是功能上的完成，而不是交付到生產(chǎn)環(huán)境)，但是軟件的操作性卻無法保證，因?yàn)殚_發(fā)沒有為運(yùn)維考慮很多，運(yùn)維人員也沒有足夠的時間或者精力去敦促開發(fā)去修正這些問題。
大家都知道這個團(tuán)隊結(jié)構(gòu)很糟糕，但是顯然還有更壞的情況——至少這個結(jié)構(gòu)我們都知道它是有問題的。
反例B：被孤立的DevOps
這種形式通常來源于領(lǐng)導(dǎo)或者執(zhí)行官的決策——他們覺得他們需要一點(diǎn)DevOps，然后組建了一個“DevOps團(tuán)隊”。這個團(tuán)隊迅速地形成了一個新的壁壘，在他們眼中，開發(fā)是愚蠢的，運(yùn)維是落伍的，他們捍衛(wèi)著自己小團(tuán)體的知識、技能和工具，讓開發(fā)和運(yùn)維相隔得更遠(yuǎn)。
只有一種情況會讓這種結(jié)構(gòu)變得有意義，就是這個DevOps團(tuán)隊只是暫時的，存在時間低于12或者18個月，并且目的明確是讓開發(fā)和運(yùn)維更加緊密，一旦過了時間點(diǎn)這個團(tuán)隊就不再有用處，這種情況會在下文正例5中提到。
反例C：我們不帶運(yùn)維玩
這種團(tuán)隊組織的天真和傲慢來自于開發(fā)人員和開發(fā)部門的領(lǐng)導(dǎo)者，尤其是在開始一項新的項目或者系統(tǒng)的時候。開發(fā)們設(shè)想運(yùn)維已經(jīng)是過去式了(“我們現(xiàn)在有云了，不是嗎”)，輕視了運(yùn)維的復(fù)雜和重要性，認(rèn)為他們可以沒有運(yùn)維，或者用很少的時間來做運(yùn)維就可以。
當(dāng)他們的軟件變得更加復(fù)雜，運(yùn)維活動開始步入泥潭(哦漏開始編程了)，這種結(jié)構(gòu)就會終結(jié)，取而代之的是下文的正例3(IaaS)或者4(DevOps-as-a-Service)。團(tuán)隊會意識到軟件開發(fā)過程中運(yùn)維的重要性，就可以避免很多不必要的痛苦和低級的運(yùn)維錯誤。
看完了反面教材，我們再來看看DevOps中常見的一些可用的團(tuán)隊組織結(jié)構(gòu)。
正例1：相親相愛，其樂融融
這是DevOps的“樂土”：開發(fā)團(tuán)隊和運(yùn)維團(tuán)隊之間融洽的合作，在隔離或者半隔離的產(chǎn)品堆棧上工作，需要專攻的地方有專門的負(fù)責(zé)，需要共享的地方也有專門的分享。
但這種融洽的協(xié)作模型需要大量的變革，以及一個更高水平的技術(shù)領(lǐng)導(dǎo)團(tuán)隊。開發(fā)和運(yùn)維必須有一個清晰的溝通表達(dá)(來傳遞可靠、頻繁的變化)和明確有效的共同目標(biāo)，運(yùn)維人員必須和開發(fā)人員良好地配合，認(rèn)真處理測試驅(qū)動的代碼和Git，而開發(fā)必須認(rèn)真對待各種運(yùn)維特性，這都需要一個相當(dāng)大的文化層次上的變革。
適用于：有著強(qiáng)大技術(shù)領(lǐng)導(dǎo)力的團(tuán)隊組織
潛在效率：高
正例2：你中有我，我中有你
運(yùn)維人員已經(jīng)完全嵌入到產(chǎn)品開發(fā)的團(tuán)隊中。開發(fā)和運(yùn)維幾乎不分開，都高度地專注在一個共同的目標(biāo)里;這是一種正例1中比較有爭議的一種特殊形式，它有一些獨(dú)特之處。
Netflix 和 Facebook等組織因?yàn)橛袉为?dú)基于Web的產(chǎn)品，使用了這種結(jié)構(gòu)而非常有效率。但是這種結(jié)構(gòu)并不適用于狹窄產(chǎn)品帶以外的情況，因?yàn)橛邢薜念A(yù)算和多個產(chǎn)品線會導(dǎo)致開發(fā)運(yùn)維的隔離。這種完全嵌入的模式也可以叫做“NoOps”(無運(yùn)維)，因?yàn)闆]有明顯或者特定的運(yùn)維團(tuán)隊(Netflix的情況可能也歸結(jié)為下面的正例3，IaaS)。
適用于：單一為主、基于Web的產(chǎn)品或服務(wù)的組織
潛在效率：高
正例3：轉(zhuǎn)身困難，IaaS來幫忙
一個相當(dāng)傳統(tǒng)的IT運(yùn)營部門可能不愿或者不能迅速地做出改變，或者對于把所有應(yīng)用都跑在公有云之上的組織來說，這種結(jié)構(gòu)可以幫助組織的運(yùn)維部分只需要一個彈性的基礎(chǔ)設(shè)置供應(yīng)用程序部署和運(yùn)行，而內(nèi)部運(yùn)維團(tuán)隊則變成了例如亞馬遜的EC2，或者說IaaS。
這樣一個團(tuán)隊(可能只是虛擬的)包含在開發(fā)里面，在運(yùn)營上是專家——很懂操作特性、指標(biāo)、監(jiān)控和服務(wù)器配置等等，和IaaS團(tuán)隊有著非常多的交流。然而這個團(tuán)隊依然是一個開發(fā)團(tuán)隊，遵循著開發(fā)的標(biāo)準(zhǔn)實(shí)踐如TDD、CI、迭代開發(fā)和培訓(xùn)等。
IaaS的出現(xiàn)用失去和運(yùn)維人員直接合作的代價來換取了更簡單的實(shí)現(xiàn)高效率，其實(shí)現(xiàn)速度可能比正例1中更快。
適用于：有著幾個不同產(chǎn)品和服務(wù)，或有著傳統(tǒng)的運(yùn)維部門，或者完全將應(yīng)用部署在公有云的組織
潛在效率：中
正例4：當(dāng)DevOps也成為服務(wù)
一些小規(guī)模的公司沒有專門細(xì)分的運(yùn)維和開發(fā)，他們需要更專業(yè)的技術(shù)服務(wù)公司幫助構(gòu)建測試環(huán)境、自動化基礎(chǔ)設(shè)施和監(jiān)控，并為他們在軟件開發(fā)進(jìn)程中提供一些運(yùn)營方面的建議。
DevOps即服務(wù)可能會成為一種對小型組織或團(tuán)隊的自動化、監(jiān)控和配置管理非常有用的形式，然后隨著團(tuán)隊的成長，他們可以承擔(dān)更多運(yùn)維為主的員工，就會逐漸向正例3甚至正例1進(jìn)化。
適用于：經(jīng)驗(yàn)有限的小型團(tuán)隊或組織
潛在效率：中
正例5：擔(dān)任臨時演員的DevOps團(tuán)隊
臨時的DevOps團(tuán)隊看起來像大大的反例B，但是它的目的和存在時間都不盡相同。這種臨時的團(tuán)隊負(fù)責(zé)把開發(fā)和運(yùn)維聯(lián)系得更緊密，朝著正例1和2演進(jìn)，最終完成使命后消失。
臨時的團(tuán)隊將擔(dān)任“開發(fā)語言”和“運(yùn)維語言”之間的“翻譯”，將開發(fā)們瘋狂的想法傳達(dá)給運(yùn)維團(tuán)隊，把運(yùn)維的負(fù)載均衡、管理網(wǎng)卡和SSL卸載等想法傳遞給開發(fā)。如果有足夠多的人開始注意到讓開發(fā)和運(yùn)維一起合作的價值，那么臨時團(tuán)隊就實(shí)現(xiàn)了它的目的。至關(guān)重要的是，部署和生產(chǎn)診斷等長期工作不應(yīng)該分配給這個臨時團(tuán)隊，否則它可能會變成反例B。
適用性：正例1的先導(dǎo)模式，但是有轉(zhuǎn)變成反例B的風(fēng)險
潛在效率：低到高
敲黑板的總結(jié)
細(xì)數(shù)了上面的反例和正例，總結(jié)一下， DevOps結(jié)構(gòu)的適用性取決于如下幾個要素：
組織的產(chǎn)品集：如康威定理所說，更少的產(chǎn)品會讓合作更加容易，隔閡也更加少。
技術(shù)領(lǐng)導(dǎo)的能力和效率，開發(fā)和運(yùn)維是否目標(biāo)一致。
是否有能力或者意愿改變運(yùn)營部門，是否認(rèn)真地對待產(chǎn)品運(yùn)營特性。
在運(yùn)維關(guān)鍵點(diǎn)上是否有能力起到帶頭作用。
當(dāng)然，這里提到的拓?fù)浣Y(jié)構(gòu)都是作為一種參考或者啟發(fā)。在現(xiàn)實(shí)中，多個模式的組合，或者一個模式轉(zhuǎn)換成另一個模式都是可以的，畢竟適合才是最好的。
