云享專家姚冬：9種DevOps團隊結構適用類型與7種反型

本文翻譯自：https://web.devopstopologies.com/

譯者：云享專家姚冬

前 言

什么樣的團隊結構適合DevOps蓬勃發展?

在一個組織內DevOps工作的主要目標是改善客戶和業務的價值交付，而不是為了降低成本、提高自動化或驅動配置管理;這意味著不同的組織可能需要不同的團隊結構才能進行有效的Dev和Ops協作。

總 結

究竟組織適合采取哪種DevOps團隊結構或拓撲取決于以下幾點：

組織的產品組合：更少的產品使得協作更容易，因為康威定律所預測的天然筒倉會更少。

技術領導的范圍，力量和有效性，決定了Dev和Ops是否擁有共同的目標。

組織是否具備能力或興趣，將IT運維部門的功能從“上架硬件”和“配置服務器”，變為真正與價值流保持一致，并且軟件研發團隊認真對待運維功能。

組織是否有能力或技能投入在運維所關心的問題上。

當然，下文列出了多種拓撲和類型，可以作為評估哪些模式可能適合的參考指南或啟示。實際上，超過一種模式的組合，或是從一種模式轉換為另一種模式是通常被采用的方式。

那么可以讓DevOps蓬勃發展的團隊結構是什么?顯然，沒有針對所有組織的普適的神奇結構或團隊拓撲。但是，列出少數不同的團隊結構模型是有用的，其中一些模型比起其他模型來說更適合于某些組織。通過探索這些團隊結構(或“拓撲”)的優點和缺點，我們可以在康威定律下，確定可能最適合我們自己組織DevOps實踐的團隊結構。

大多數的DevOps拓撲結構之前已在其他地方描述過;特別是，CollabNet的Lawrence Sweeney在Ben Kepes的博客評論中詳細介紹了我在這里稱為Anti-Type B(DevOps Team Silo)，Type 3(Ops as IaaS)和Type 1(Dev and Ops Collaboration)的特征。)。DevOpsGuys列出了十二個DevOps反模式，Jez Humble，Gene Kim，Damon Edwards(以及其他許多人)都說過類似的事情。我在這里添加了三個額外的'拓撲'，在別處沒有看到或很少聽到討論(Shared Ops，DevOps-as-a-Service和Temp DevOps Team)。

DevOps Anti-Types

我們先來看一些不好的做法，稱之為“反類型”(模仿無處不在的“反模式”)。

A：Dev vs Ops 對立

B：DevOps Silo筒倉

C：不需要Ops

D：DevOps工具團隊

E：SysAdmin 系統管理員

F：嵌入式Ops

G：Dev vs DBA

反型A：Dev和Ops筒倉

這是Dev和Ops之間的經典“扔過墻”模式。這意味著可以提前聲明故事點(DONE表示“功能完成”，但沒有在生產環境中運行)，軟件可運維性受到影響，因為Dev人員沒有足夠的運維工作上下文，而Ops人員沒有時間或傾向于拉開發人員在軟件上線之前解決問題。

我們可能都知道這種拓撲很糟糕，但我認為實際上存在更糟糕的拓撲; 至少，在使用Anti-Type A(Dev和Ops Silos)，我們都知道存在問題(而某些拓撲我們并不知道有問題)。

反型B：DevOps Team Silo 筒倉

DevOps Team Silo(Anti-Type B)通常來自于主管決定他們“需要一些這樣的DevOps事情”，并啟動了一個'DevOps團隊'(可能包含所謂的'DevOp'人員)。DevOps團隊的成員很快形成了另一個孤島，讓Dev和Ops比以往任何時候都更加分離，因為DevOps團隊要捍衛他們的角落：技能和工具集(對比那些“無能為力的Dev”和“恐龍Ops”)。

DevOps孤島模式唯一有意義的情況：DevOps團隊是臨時的，持續時間少于(比如說)12或18個月，明確定義目的是讓Dev和Ops更緊密地聯系在一起，并明確要求在此之后解散DevOps團隊。(這就是我后面要說的Type 5 DevOps Topology。)

反型C：Dev不需要Ops

這種拓撲結構因開發人員和開發經理的天真和傲慢而產生，特別是在新項目或系統開始時。開發人員假設Ops現在已成為過去(“我們現在擁有云，對嗎?”)，這大大低估了運維技能和活動的復雜性和重要性，并相信可以不使用它們，或只需要在閑暇時間來處理。

這樣的Anti-Type C DevOps拓撲結構可能最終需要Type 3(Ops as IaaS)或Type 4(DevOps-as-a-Service)拓撲，當他們的軟件變得更加復雜并且運維活動開始淹沒開發(又名編碼)時間。如果只有這樣的團隊才能認識到運維作為一門學科的重要性，就像軟件開發一樣的重要和有價值，他們就能避免很多痛苦和不必要的(而且非常基本的)運維錯誤。

反型D：DevOps作為工具團隊

為了“成為DevOps”同時又不失去當前開發團隊的速度(交付功能故事)，DevOps團隊被設置為處理部署流水線，配置管理，環境管理等所需的工具。同時Ops的人繼續孤立地工作，開發團隊繼續將他們的應用程序“拋過墻去”。

雖然這個專門團隊的成果在改進工具鏈方面可能是有益的，但其影響是有限的。在應用程序開發生命周期中，缺乏Ops的早期參與和協作這一基本問題并沒有被改變。

反型E：更名的SysAdmin

這種反型在工程成熟度較低的組織中很常見。他們希望改善自身實踐并降低成本，但卻未能將IT視為業務的核心驅動力。由于DevOps在行業有眾多的成功案例，他們也希望“做DevOps”。不幸的是，他們沒有反思當前組織結構和關系中的差距，而是選擇了為他們的Ops團隊招聘“DevOps工程師”這一前途未卜的道路。

DevOps只是對以前稱為SysAdmin的角色的重塑，沒有發生真正的文化/組織變化。隨著肆無忌憚的招聘人員開始尋找具有自動化和工具技能的候選人，這種反型正變得越來越普遍。不幸的是，只有人類的溝通技巧才可以使DevOps在組織中茁壯成長。

反型F：開發團隊中嵌入的Ops

組織不希望保留單獨的Ops團隊，因此開發團隊負責基礎設施，管理環境，監控等。但是，以項目或產品驅動的方式這樣做意味著這些項目受資源限制以及優先級排序，導致非標準的方式和半生不熟的解決方案。

在這種反類型中，組織表現出對IT運維的重要性和技能缺乏認識。特別是，Ops的價值減少了，因為它被視為Devs的煩惱(因為Ops由一個開發團隊經理管理，他同時又有其他優先事項)。

感謝Scott Prugh建議澄清Anti-Type F與Type 2的區別。

反型G：Dev和DBA筒倉

這是Anti-Type A(開發和Ops孤島)的一種形式，在中型到大型公司中很突出，其中多個遺留系統依賴于相同的核心數據集。由于這些數據庫對業務至關重要，因此有專門的DBA團隊(通常在Ops保護傘下)負責維護，性能調整和災難恢復。這是可以理解的。但問題是當這個團隊成為任何數據庫變更的守門員時，“有效地”成為了小的并且頻繁部署的障礙(DevOps和持續交付的核心原則)。

此外，就像Anti-Type A中的 Ops一樣，DBA團隊并未參與應用程序開發的早期階段，因此在交付周期的后期會發現數據問題(遷移，性能等)。再加上支持多個應用程序數據庫的過載，最終結果是持續的滅火和交付壓力。

DevOps團隊的拓撲

與反類型不同，我們可以看一些可以使DevOps工作的拓撲。

1：Dev + Ops

2：共享的Ops

3：Ops作為IaaS

4：DevOps-as-a-Service

5：臨時的DevOps團隊

6：DevOps倡導者

7：SRE團隊

8：容器驅動

9：數據庫能力

類型1：開發和運維協作

這是DevOps的“應允之地”：開發團隊和Ops團隊之間順暢合作，每個團隊各司其職，但也需要彼此分享。可能有許多獨立的開發團隊，每個團隊都在獨立或半獨立的產品技術棧上工作。

我的感覺是，這種類型1模型需要相當大的組織變革來建立，并且對技術管理團隊有更高的要求。Dev和Ops必須有明確表達并且有效的共同目標(例如“提供可靠，頻繁的變化”)。運維人員必須與Devs結對，并掌握測試驅動的開發和Git，Devs必須認真對待運維能力，并尋找Ops人員進行日志記錄等，所有這些都需要相當的文化變革。

第1類適用性：具有強大技術領導力的組織。

潛在效果：HIGH

類型2：完全共享的運維責任

如果運維人員已集成到產品開發團隊中，我們會看到Type 2拓撲。Dev和Ops之間的分別很小，所有人都高度專注于共同的目的; 這可以說是Type 1(Dev和Ops Collaboration)的一種形式，但它有一些特殊的特征。

Netflix和Facebook這樣的組織，事實上只有一個基于Web的核心產品，已經實現了這種類型2拓撲，但我認為它可能不適用于聚焦的產品之外，因為在具有多個產品流的組織中，通常存在預算限制和上下文切換，可能會使Dev和Ops進一步分開(例如，回到Type 1模型)。此拓撲也可稱為“NoOps”，因為沒有明顯或可見的運維團隊(盡管Netflix NoOps也可能是Type 3(Ops as IaaS))。

類型2適用性：具有單個基于Web的主要產品或服務的組織。

潛在效果：HIGH

類型3： Ops作為基礎設施即服務(平臺)

對于擁有相對傳統的IT運維部門的組織，無法或不會(足夠)快速變更;對于在公共云(Amazon EC2，Rackspace，Azure等)中運行所有應用程序的組織，它可能有助于將運維作為一個只提供部署和運行應用程序的彈性基礎架構的團隊; 因此，內部Ops團隊等同于Amazon EC2或Infrastructure-as-a-Service。

Dev中的團隊(可能是虛擬團隊)可以充當關于運維的功能，指標，監控，服務器配置等的專業知識來源，并且可能與IaaS團隊進行大部分的溝通。然而，該團隊仍然是開發團隊，遵循TDD，CI，迭代開發，教練等標準實踐。

這種IaaS拓撲以一些潛在的有效性為代價(失去了與Ops人員的直接協作)，來換取更容易的實現，可能比嘗試Type 1(Dev和Ops Collaboration)能夠更快地獲得價值，Type 1可以在未來進行嘗試。

Type 3適用性：具有多種不同產品和服務的組織，具有傳統Ops部門，或其應用程序完全在公共云中運行。

潛在的有效性：MEDIUM

類型4： DevOps作為外部服務

一些組織，特別是較小的組織，可能沒有財力，經驗或工作人員來領導所生產軟件的運維部分。開發團隊可以聯系Rackspace等服務提供商，幫助他們構建測試環境并自動化他們的基礎設施和監控，并就軟件開發周期中要實施的各種運維能力提供建議。

這種被稱為DevOps-as-a-Service的方式，對于小型組織或團隊來說可能是一種有用且實用的方式，可以了解自動化，監控和配置管理，然后隨著他們的發展和增長，需要更多的員工關注于運維，可能轉向類型3(Ops as IaaS)甚至 類型1(開發和Ops協作)。

第4類適用性：較小的團隊或運維經驗有限的組織。

潛在的有效性：MEDIUM

類型5：具有到期日的DevOps團隊

具有到期日(類型5)的DevOps團隊看起來與Anti-Type B(DevOps Team Silo)非常相似，但其意圖和壽命卻截然不同。這個臨時團隊的使命是將Dev和Ops更緊密地結合在一起，理想情況下是向Type 1(開發和Ops協作)或Type 2(完全共享的Ops職責)演進，并最終使其自身被廢棄。

臨時團隊的成員將在Dev-語言和Ops-語言之間進行“翻譯”，為Ops團隊引入瘋狂的想法，如站會和看板，以及考慮諸如引入負載均衡器，管理NIC和開發人員SSL卸載等臟活累活。如果有足夠多的人開始看到將Dev和Ops結合在一起的價值，那么臨時團隊就有可能實現其目標;至關重要的是，不應該要求臨時團隊承擔部署和生產診斷等長期責任，否則很可能成為DevOps Team Silo(Anti-Type B)。

5型適用性：作為1型拓撲結構的前身，但要注意抗B型的危險性。

潛在有效性：從 低到高

類型6：DevOps倡導團隊

在Dev和Ops之間存在巨大隔閡的組織中，擁有一個“引導”DevOps團隊可以有效地保持Dev和Ops之間的溝通。這是Type 5(具有到期日的DevOps團隊)的一種版本，但DevOps團隊持續存在，承擔促進Dev和Ops團隊之間協作和合作的特定職責。該團隊的成員有時被稱為“DevOps Advocates”，因為他們幫助進行DevOps實踐意識的傳播。

“DevOps團隊”的目標應該是通過賦能組織的其余部分來使自己消失。

感謝Eric Minick(@EricMinick)

6型適用性： 傾向于Dev和Ops分開的組織。注意反型B的危險性。

潛在的有效性： 中等至高

類型7：SRE團隊(Google模型)

DevOps經常建議Dev團隊加入on call輪換，但這并非必須。實際上，一些組織(包括谷歌)擁有不同的模型，從開發到運行軟件的團隊(即站點可靠性工程(SRE)團隊)有明確地“交接”。在此模型中，開發團隊需要向SRE團隊提供測試證據(日志，指標等)，以證明他們的軟件達到足夠好的標準以供SRE團隊來支持。

至關重要的是，SRE團隊可以拒絕運維標準不合格的軟件，要求開發人員在將代碼投入生產之前對其進行改進。Dev和SRE之間的基于運維標準進行協作，但是一旦SRE團隊對代碼感到滿意，他們(而不是開發團隊)就會在生產中支持它。

感謝Kevin Hinde (@kwdhinde)

類型7適用性：類型7僅適用于具有高度工程和組織成熟度的組織。如果SRE / Ops團隊被告知“JFDI”部署，請警惕Anti-Type A.

潛在有效性：從 低到高

類型8：容器驅動的協作

通過將應用程序的部署和運行時要求封裝到容器中，消除了Dev和Ops之間某些的協作需要。在這種方式中，容器充當了Dev和Ops職責的邊界。憑借良好的工程文化，容器驅動的協作模型可以運行良好，但如果Dev開始忽略運維需要考慮的因素，這個模型會回歸到 '我們和他們'。

感謝J Buchanan (@jascbu)

類型8適用性：容器可以很好地工作，但要注意反型A：Ops團隊應該運行Dev拋出的任何東西。

潛在的有效性： 中等至高

類型9：開發和DBA協作

為了彌合Dev-DBA的鴻溝，一些組織開始嘗試類型9，其中來自DBA團隊的數據庫能力與Dev團隊的數據庫能力(或專業)相匹配。這似乎有助于在以Dev為中心的數據庫視角(基本上是應用程序的啞持久性存儲)和以DBA為中心的數據庫視角(智能，豐富的業務價值來源)之間進行翻譯。

類型9適用性：適用于擁有一個或多個連接眾多應用程序的大型中央數據庫的組織。

潛在的有效性：MEDIUM

請記住：沒有“正確”的團隊拓撲結構，但對于任何一個組織而言，都有一些“不良”的拓撲結構。

華為云APP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。