一份DevOps結構清單——請君慢用

開發和運維的關係一直很「微妙」，他聽個人， 他不聽個人，哦他開口了，哦好吧我聽不懂他說了啥……開發和運維的恩怨情仇由來已久，由此誕生的DevOps倒是解決他們之間關係的一劑良藥。

DevOps最主要目的在於提升用戶和業務需求提升產品的交付能力與效率。不一樣的行業和企業須要規劃各類DevOps團隊結構來適應開發和運維的協做。數人云今天和你們討論的就是這些五花八門的團隊結構，首先，咱們先請「反面教材」登場……

反例A：DevOps是啥？

這是典型的開發和運維「各管一攤」。它意味着雖然能很早地聲明項目完成（這裏的完成意思僅僅是功能上的完成，而不是交付到生產環境），可是軟件的操做性卻沒法保證，由於開發沒有爲運維考慮不少，運維人員也沒有足夠的時間或者精力去敦促開發去修正這些問題。

你們都知道這個團隊結構很糟糕，可是顯然還有更壞的狀況——至少這個結構咱們都知道它是有問題的。


反例B：被孤立的DevOps

這種形式一般來源於領導或者執行官的決策——他們以爲他們須要一點DevOps，而後組建了一個「DevOps團隊」。這個團隊迅速地造成了一個新的壁壘，在他們眼中，開發是愚蠢的，運維是落伍的，他們捍衛着本身小團體的知識、技能和工具，讓開發和運維相隔得更遠。

只有一種狀況會讓這種結構變得有意義，就是這個DevOps團隊只是暫時的，存在時間低於12或者18個月，而且目的明確是讓開發和運維更加緊密，一旦過了時間點這個團隊就再也不有用處，這種狀況會在下文正例5中提到。

反例C：咱們不帶運維玩

這種團隊組織的天真和傲慢來自於開發人員和開發部門的領導者，尤爲是在開始一項新的項目或者系統的時候。開發們設想運維已是過去式了（「咱們如今有云了，不是嗎」），輕視了運維的複雜和重要性，認爲他們能夠沒有運維，或者用不多的時間來作運維就能夠。

當他們的軟件變得更加複雜，運維活動開始步入泥潭（哦漏開始編程了），這種結構就會終結，取而代之的是下文的正例3（IaaS）或者4（DevOps-as-a-Service）。團隊會意識到軟件開發過程當中運維的重要性，就能夠避免不少沒必要要的痛苦和低級的運維錯誤。

看完了反面教材，咱們再來看看DevOps中常見的一些可用的團隊組織結構。

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

這是DevOps的「樂土」：開發團隊和運維團隊之間融洽的合做，在隔離或者半隔離的產品堆棧上工做，須要專攻的地方有專門的負責，須要共享的地方也有專門的分享。

但這種融洽的協做模型須要大量的變革，以及一個更高水平的技術領導團隊。開發和運維必須有一個清晰的溝通表達（來傳遞可靠、頻繁的變化）和明確有效的共同目標，運維人員必須和開發人員良好地配合，認真處理測試驅動的代碼和Git，而開發必須認真對待各類運維特性，這都須要一個至關大的文化層次上的變革。

適用於：有着強大技術領導力的團隊組織
潛在效率：高


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

運維人員已經徹底嵌入到產品開發的團隊中。開發和運維幾乎不分開，都高度地專一在一個共同的目標裏；這是一種正例1中比較有爭議的一種特殊形式，它有一些獨特之處。

Netflix 和 Facebook等組織由於有單獨基於Web的產品，使用了這種結構而很是有效率。可是這種結構並不適用於狹窄產品帶之外的狀況，由於有限的預算和多個產品線會致使開發運維的隔離。這種徹底嵌入的模式也能夠叫作「NoOps」（無運維），由於沒有明顯或者特定的運維團隊（Netflix的狀況可能也歸結爲下面的正例3，IaaS）。

適用於：單一爲主、基於Web的產品或服務的組織
潛在效率：高


正例3：轉身困難，IaaS來幫忙

一個至關傳統的IT運營部門可能不肯或者不能迅速地作出改變，或者對於把全部應用都跑在公有云之上的組織來講，這種結構能夠幫助組織的運維部分只須要一個彈性的基礎設置供應用程序部署和運行，而內部運維團隊則變成了例如亞馬遜的EC2，或者說IaaS。

這樣一個團隊（可能只是虛擬的）包含在開發裏面，在運營上是專家——很懂操做特性、指標、監控和服務器配置等等，和IaaS團隊有着很是多的交流。然而這個團隊依然是一個開發團隊，遵循着開發的標準實踐如TDD、CI、迭代開發和培訓等。

IaaS的出現用失去和運維人員直接合做的代價來換取了更簡單的實現高效率，其實現速度可能比正例1中更快。

適用於：有着幾個不一樣產品和服務，或有着傳統的運維部門，或者徹底將應用部署在公有云的組織
潛在效率：中

正例4：當DevOps也成爲服務

一些小規模的公司沒有專門細分的運維和開發，他們須要更專業的技術服務公司幫助構建測試環境、自動化基礎設施和監控，併爲他們在軟件開發進程中提供一些運營方面的建議。

DevOps即服務可能會成爲一種對小型組織或團隊的自動化、監控和配置管理很是有用的形式，而後隨着團隊的成長，他們能夠承擔更多運維爲主的員工，就會逐漸向正例3甚至正例1進化。

適用於：經驗有限的小型團隊或組織
潛在效率：中

正例5：擔任臨時演員的DevOps團隊

臨時的DevOps團隊看起來像大大的反例B，可是它的目的和存在時間都不盡相同。這種臨時的團隊負責把開發和運維聯繫得更緊密，朝着正例1和2演進，最終完成使命後消失。

臨時的團隊將擔任「開發語言」和「運維語言」之間的「翻譯」，將開發們瘋狂的想法傳達給運維團隊，把運維的負載均衡、管理網卡和SSL卸載等想法傳遞給開發。若是有足夠多的人開始注意到讓開發和運維一塊兒合做的價值，那麼臨時團隊就實現了它的目的。相當重要的是，部署和生產診斷等長期工做不該該分配給這個臨時團隊，不然它可能會變成反例B。

適用性：正例1的先導模式，可是有轉變成反例B的風險
潛在效率：低到高

敲黑板的總結

細數了上面的反例和正例，總結一下， DevOps結構的適用性取決於以下幾個要素：

組織的產品集：如康威定理所說，更少的產品會讓合做更加容易，隔閡也更加少。
技術領導的能力和效率，開發和運維是否目標一致。
是否有能力或者意願改變運營部門，是否定真地對待產品運營特性。
在運維關鍵點上是否有能力起到帶頭做用。

固然，這裏提到的拓撲結構都是做爲一種參考或者啓發。在現實中，多個模式的組合，或者一個模式轉換成另外一個模式都是能夠的，畢竟適合纔是最好的。