新聞發(fā)布
管理系統(tǒng)類型一：開發(fā)運維順暢協(xié)作
這是 DevOps 的“樂土”：開發(fā)團(tuán)隊和運營團(tuán)隊之間順暢協(xié)作，每一個團(tuán)隊都在需要的地方專業(yè)化工作，但也在需要的地方共享。
可能有許多獨立的開發(fā)團(tuán)隊，但每個團(tuán)隊又會在一個單獨或半獨立的產(chǎn)品組合上工作。我的感覺是，類型一的平滑協(xié)作模型需要相當(dāng)大的組織變革來建立它，并且在管理團(tuán)隊需要有較高的能力。
開發(fā)人員和運維人員必須有一個明確有效的共同目標(biāo)（“高質(zhì)量交付、快速迭代”或其他）。運維人員必須與開發(fā)人員進(jìn)行舒適的合作，掌握測試驅(qū)動的編碼和 Git，開發(fā)人員必須認(rèn)真對待運維特性，尋找運維人員以輸入日志記錄等等，所有這些相比較過去都需要進(jìn)行相當(dāng)大的文化變革。
類型一適用性：具有強大技術(shù)領(lǐng)導(dǎo)類型的組織
潛在有效性：高
類型二：全嵌入式/共享運維
當(dāng)運維人員完全融入進(jìn)產(chǎn)品開發(fā)團(tuán)隊中的時候，我們看到了這種類型。Dev 和 Ops 之間的分離很少，以至于所有人都共同高度關(guān)注一個目標(biāo)，這可以說是類型一的一種形式，不過它也具有一定特殊性。像 Netflix 和 Facebook 這樣的組織有效地實現(xiàn)了一個基于 Web 的產(chǎn)品，它已經(jīng)實現(xiàn)了這種類型的結(jié)構(gòu)。
但我認(rèn)為它可能不太適用于狹窄產(chǎn)品線模式之外，因為預(yù)算限制和多個產(chǎn)品線之間通常存在上下文切換，這可能會迫使 Dev 和 Ops 進(jìn)一步分開（例如回到類型一模型）。這個模式也可以被稱為“NoOps”，因為沒有明顯的或可見的運維團(tuán)隊（盡管 Netflix NoOps 也可能是類型三）。
類型二適用性：基于單一 Web 的產(chǎn)品或服務(wù)的組織
潛在有效性：高
類型三：基礎(chǔ)設(shè)施即服務(wù)
對于具有相當(dāng)傳統(tǒng)的 IT 運維部門的組織，他們無法或不能（足夠）快速作出改變，和對于在公共云（Amazon EC2、Rackspace、Azure 等）中運行所有應(yīng)用程序的組織來說，將運維作為一個只需提供應(yīng)用程序部署和運行功能的彈性基礎(chǔ)設(shè)施團(tuán)隊或許比較有幫助。這樣內(nèi)部運維團(tuán)隊直接等同于 Amazon EC2 或基礎(chǔ)架構(gòu)即服務(wù)。然后 Dev 中的團(tuán)隊（可能是虛擬團(tuán)隊）充當(dāng)有關(guān)操作特性、度量、監(jiān)控、服務(wù)器供應(yīng)等方面的專業(yè)知識來源，并且可能與 Iaas 團(tuán)隊進(jìn)行大部分溝通。
然而這個團(tuán)隊仍然是一個開發(fā)團(tuán)隊，遵循諸如 TDD、CI、迭代開發(fā)、指導(dǎo)等標(biāo)準(zhǔn)實踐。IaaS 團(tuán)隊結(jié)構(gòu)具有一些潛在的有效性（失去與 Ops 人員直接協(xié)作），以便更容易實施，可能比類型一更快地獲得價值。
類型三適用性：具有幾種不同產(chǎn)品和服務(wù)、具有傳統(tǒng)運營部門或其應(yīng)用程序完全在公共云中運行的組織
潛在有效性：中等
類型四：DevOps 即服務(wù)
一些組織，特別是較小的組織，可能沒有資金、經(jīng)驗或工作人員來領(lǐng)導(dǎo)他們的軟件運維。開發(fā)團(tuán)隊可能會接觸到像 Rackspace 這樣的服務(wù)提供商，去幫助他們建立測試環(huán)境并自動化其基礎(chǔ)設(shè)施和監(jiān)控，并就軟件開發(fā)周期中實現(xiàn)的各種運維功能提供建議。
可以被稱之為 DevOps-as-a-Service 的應(yīng)該是幫助小型團(tuán)隊了解自動化、監(jiān)控和配置管理的一種有效務(wù)實的方法。隨著業(yè)務(wù)的發(fā)展和更多的員工加入，可能轉(zhuǎn)向第三類甚至第一類模式。
類型四適應(yīng)性：運營經(jīng)驗有限的小型團(tuán)隊或組織
有效潛力：中
類型五：臨時 DevOps 團(tuán)隊
這個類型看起來和反類型 B 有極大的相似，但是實際上其本質(zhì)意圖和長遠(yuǎn)性是完全不同的。這個臨時團(tuán)隊的任務(wù)是使 Dev 和 Ops 更緊密的聯(lián)合在一起，理想目標(biāo)是完全轉(zhuǎn)型成類型一或二。臨時團(tuán)隊成員將在 Dev-speak 和 Ops-speak 之間進(jìn)行翻譯，并引入一些瘋狂的點子，例如為 Ops 團(tuán)隊介紹站立會和看板系統(tǒng)，還有一些吹毛求疵的細(xì)節(jié)，例如為 Dev 團(tuán)隊介紹負(fù)載均衡器，管理 NIC 和卸載 SSL。
如果有足夠多的人意識到 Dev 和 Ops 團(tuán)隊結(jié)合后將帶來的價值，臨時團(tuán)隊將有機(jī)會真正的實現(xiàn)它的目標(biāo)。至關(guān)重要的一點是，對部署和生產(chǎn)分析的長期責(zé)任不應(yīng)該被分配給臨時團(tuán)隊，否則很可能會朝著反類型 B 的不利方向演進(jìn)。
類型五適應(yīng)性：想達(dá)成類型一的前身，但是要警惕演變成反類型 B 的可能
有效潛力：低至中
總結(jié)
究竟哪個 DevOps 團(tuán)隊結(jié)構(gòu)適合一個組織取決于以下幾點：
該組織的產(chǎn)品組合：較少的產(chǎn)品會使團(tuán)隊協(xié)作更加容易，因為根據(jù) Conway 定律，這種情況下的獨立谷倉會比較少。
技術(shù)領(lǐng)導(dǎo)的范圍力度和有效性；Dev 和 Ops 是否有清晰明確的共同目標(biāo)。
組織是否具有能力或欲望去該改變它的 IT 運維部門，從“服務(wù)器的組建和配置”轉(zhuǎn)變成真的可以實現(xiàn)其價值流，以及軟件研發(fā)團(tuán)隊認(rèn)真對待運維團(tuán)隊。
組織是否具有能力和技能去解決運維問題。
