一份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結構的適用性取決于如下幾個要素：
組織的產品集：如康威定理所說，更少的產品會讓合作更加容易，隔閡也更加少。
技術領導的能力和效率，開發和運維是否目標一致。
是否有能力或者意愿改變運營部門，是否認真地對待產品運營特性。
在運維關鍵點上是否有能力起到帶頭作用。
當然，這里提到的拓撲結構都是作為一種參考或者啟發。在現實中，多個模式的組合，或者一個模式轉換成另一個模式都是可以的，畢竟適合才是最好的。
