五種團隊的組織方式落地 DevOps

原文連接： https://blog.matthewskelton.n...
原做者：Matthew Skelton
翻譯君：CODING 戴維奧普斯

大部分組織對 DevOps 發起設立的初衷是改善客戶和業務之間的交付價值，而不是下降成本，加強自動化，或驅動組織架構；這意味着不一樣的組織可能須要不一樣的團隊結構才能進行有效的 Dev（開發）和 Ops（運維）協做。

因此關於問題 」什麼是能夠幫助 DevOps 發展的正確組織架構？「是沒有一個明確答案的。很顯然，沒有一種神奇的團隊結構能夠適用於任何組織。

不過，確實有少許的團隊結構模型對某些組織來講具備必定的參考價值。經過探索這些團隊結構的優缺點，同時考慮到康威定律的狀況下，或許能夠肯定最適合咱們組織的、並有利於 DevOps 實踐的團隊結構。

不少 DevOps 團隊結構以前已經被介紹過了，特別是 CollabNet 的 Lawrence Sweeney 在 Ben Kepes 的博客評論中詳細介紹了我將在本文說起的 Anti-Type B（獨立的 DevOps 穀倉：DevOps Silo）、Type 3（基礎設施服務：IaaS）和 Type 1（開發運維共同協做：Smooth Integration）。

DevOpsGuys 列出了十二個 DevOps 反類型，Jez Humble、Gene Kim、Damon Edwards（以及其餘許多人）也說過相似的事情。在這裏我增長三個額外的團隊結構，關於這三種類型我以前不多見過或聽過人說起：全嵌入式/共享運維（Fully Embedded），DevOps 即服務（DevOps-as-a-Service），和臨時 DevOps 團隊（Temporary DevOps Team）。

DevOps Anti-Types

首先，看待事物的一個有效方式是去觀察它很差的一面，這種方式咱們稱之爲「反類型」（在廣泛存在的「反模式」以後）。

Anti-Type A：獨立穀倉/Dev 和 Ops 分離

這是一種傳統的分裂了 Dev 和 Ops 的「拋過牆法」。這意味着 story point（需求點）能夠被提早估算（「DONE」意味着功能完整，可是不意味着能夠在生產中使用），同時軟件的可運維性受損，由於 Devs （開發人員）沒有足夠的上下文環境去了解功能操做，Ops （運維人員）也沒有時間或傾向參與到 Devs 中去共同解決軟件上線前的問題。

咱們可能都知道這種類型很糟糕，但我認爲不少的團隊結構實際上更糟糕；至少到目前爲止，咱們已經意識到這個反類型 A 的問題所在了。

Anti-Type B：獨立的 DevOps 穀倉

這種獨立的 DevOps 團隊一般狀況下來自經理或執行官，他們「須要一點 DevOps 的事情」，而後就啓動了一個「DevOps 團隊」（也有可能有一我的的名字叫作 「DevOp」）。這個 DevOps 的成員會迅速造成另外一個團體，讓 Dev 和 Ops 分得更開，由於他們要從「無知的 Devs」和「恐龍同樣的 Ops」手裏保衛本身的角色、技能和工具集。

惟一一個讓這種模式能夠被理解的狀況就是當團隊組織爲臨時的、時間短於十二或十八個月的時候。其目的是讓開發人員和運營人員更緊密地聯繫在一塊兒，並明確受權在這段時間以後，這個團隊將變得多餘。

這就成爲了我所稱的 Type 5 DevOps Topology（見下文）。

Anti-Type C：「咱們（開發）不須要 Ops（運維）」

這種團隊結構是由開發人員和開發經理的幼稚自大結合而來的，特別是當一些新項目啓動的時候。假設 Ops 如今已經成爲了過去式 （「咱們如今有云了，對吧？），開發人員嚴重低估運維技能和活動的複雜性及重要性，認爲沒有這些技能和活動他們仍能夠作到，或者只要花費一些空餘時間就能夠。

當他們的軟件變得更復雜，更多的運維活動開始淹沒「開發」（即編程）的時候，這種 Anti-Type C 的類型可能最終會須要 Type 3（IaaS）或者 Type 4 DevOps topology（DevOps-as-a-Service）。

只要這樣的團隊能認識到運維做爲一個規則的重要性和軟件開發同樣重要和有價值時，他們將可以避免許多痛苦和沒必要要的（以及很是基本的）錯誤。

DevOps 團隊結構

在已經瞭解了反類型的糟糕以後，咱們能夠看一些 DevOps 良好運做的團隊結構。

類型一：開發運維順暢協做

這是 DevOps 的「樂土」：開發團隊和運營團隊之間順暢協做，每個團隊都在須要的地方專業化工做，但也在須要的地方共享。

可能有許多獨立的開發團隊，但每一個團隊又會在一個單獨或半獨立的產品組合上工做。個人感受是，類型一的平滑協做模型須要至關大的組織變革來創建它，而且在管理團隊須要有較高的能力。

開發人員和運維人員必須有一個明確有效的共同目標（「高質量交付、快速迭代」或其餘）。運維人員必須與開發人員進行溫馨的合做，掌握測試驅動的編碼和 Git，開發人員必須認真對待運維特性，尋找運維人員以輸入日誌記錄等等，全部這些相比較過去都須要進行至關大的文化變革。

類型一適用性：具備強大技術領導類型的組織
潛在有效性：高

類型二：全嵌入式/共享運維

當運維人員徹底融入進產品開發團隊中的時候，咱們看到了這種類型。Dev 和 Ops 之間的分離不多，以致於全部人都共同高度關注一個目標，這能夠說是類型一的一種形式，不過它也具備必定特殊性。像 Netflix 和 Facebook 這樣的組織有效地實現了一個基於 Web 的產品，它已經實現了這種類型的結構。

但我認爲它可能不太適用於狹窄產品線模式以外，由於預算限制和多個產品線之間一般存在上下文切換，這可能會迫使 Dev 和 Ops 進一步分開（例如回到類型一模型）。這個模式也能夠被稱爲「NoOps」，由於沒有明顯的或可見的運維團隊（儘管 Netflix NoOps 也多是類型三）。

類型二適用性：基於單一 Web 的產品或服務的組織
潛在有效性：高

類型三：基礎設施即服務

對於具備至關傳統的 IT 運維部門的組織，他們沒法或不能（足夠）快速做出改變，和對於在公共雲（Amazon EC二、Rackspace、Azure 等）中運行全部應用程序的組織來講，將運維做爲一個只需提供應用程序部署和運行功能的彈性基礎設施團隊或許比較有幫助。這樣內部運維團隊直接等同於 Amazon EC2 或基礎架構即服務。而後 Dev 中的團隊（多是虛擬團隊）充當有關操做特性、度量、監控、服務器供應等方面的專業知識來源，而且可能與 Iaas 團隊進行大部分溝通。

然而這個團隊仍然是一個開發團隊，遵循諸如 TDD、CI、迭代開發、指導等標準實踐。IaaS 團隊結構具備一些潛在的有效性（失去與 Ops 人員直接協做），以便更容易實施，可能比類型一更快地得到價值。

類型三適用性：具備幾種不一樣產品和服務、具備傳統運營部門或其應用程序徹底在公共雲中運行的組織
潛在有效性：中等

類型四：DevOps 即服務

一些組織，特別是較小的組織，可能沒有資金、經驗或工做人員來領導他們的軟件運維。開發團隊可能會接觸到像 Rackspace 這樣的服務提供商，去幫助他們創建測試環境並自動化其基礎設施和監控，並就軟件開發週期中實現的各類運維功能提供建議。

能夠被稱之爲 DevOps-as-a-Service 的應該是幫助小型團隊瞭解自動化、監控和配置管理的一種有效務實的方法。隨着業務的發展和更多的員工加入，可能轉向第三類甚至第一類模式。

類型四適應性：運營經驗有限的小型團隊或組織
有效潛力：中

類型五：臨時 DevOps 團隊

這個類型看起來和反類型 B 有極大的類似，可是實際上其本質意圖和長遠性是徹底不一樣的。這個臨時團隊的任務是使 Dev 和 Ops 更緊密的聯合在一塊兒，理想目標是徹底轉型成類型一或二。臨時團隊成員將在 Dev-speak 和 Ops-speak 之間進行翻譯，並引入一些瘋狂的點子，例如爲 Ops 團隊介紹站立會和看板系統，還有一些吹毛求疵的細節，例如爲 Dev 團隊介紹負載均衡器，管理 NIC 和卸載 SSL。

若是有足夠多的人意識到 Dev 和 Ops 團隊結合後將帶來的價值，臨時團隊將有機會真正的實現它的目標。相當重要的一點是，對部署和生產分析的長期責任不該該被分配給臨時團隊，不然極可能會朝着反類型 B 的不利方向演進。

類型五適應性：想達成類型一的前身，可是要警戒演變成反類型 B 的可能
有效潛力：低至中

總結

究竟哪一個 DevOps 團隊結構適合一個組織取決於如下幾點：

1. 該組織的產品組合：較少的產品會使團隊協做更加容易，由於根據 Conway 定律，這種狀況下的獨立穀倉會比較少。
2. 技術領導的範圍力度和有效性；Dev 和 Ops 是否有清晰明確的共同目標。
3. 組織是否具備能力或慾望去該改變它的 IT 運維部門，從「服務器的組建和配置」轉變成真的能夠實現其價值流，以及軟件研發團隊認真對待運維團隊。
4. 組織是否具備能力和技能去解決運維問題。

固然，這裏描述的主題有所不一樣，團隊結構和類型做爲參考指南或啓發，或許能夠對評估哪種模式是適合的帶來一些幫助。實際上，將多種模式結合，或將兩種模式構成轉變和遞進的結構模式，每每能達到更好的效果。

活動預告

7 月 21 日本週日，CODING、騰訊雲、騰訊 TEG 技術工程事業羣將共同舉辦首屆騰訊運維技術開放日 活動，旨在分享和交流騰訊內部在運維方面的實踐經驗，打造騰訊內部與外部共同交流、共同進步的運維技術生態。

CODING 深耕 DevOps 市場，除騰訊外，也爲富士康、拉卡拉、國泰基金、天津大學等組織提供 DevOps 工具服務。CODING 創始人張海龍受邀參加本次活動，將與你們分享協助客戶進行 DevOps 轉型的經驗，以及在 DevOps 的大趨勢下開發與運維的新關係。

點擊此處報名活動
7 月 21 日期待你們的到來！