DevOps適用於小團隊嗎？-知識星球

正如我最近在Twitter[1]上寫的那樣，我最近花了相當多的時間來思考“DevOps”的人員可擴充套件性。（將DevOps打上引號是因為它有各種不同的定義，在下麵將會講到。）我最終得出的結論是，雖然DevOps可以很好地適用於小型工程組織，但這種做法如果沒有仔細考慮和管理的話可能會導致相當大的人力/組織規模問題。

什麼是DevOps？

DevOps對不同的人來說有不同的意義。在深入思考這個主題之前，我認為明確DevOps對我的意義非常重要。

維基百科將DevOps定義為：

DevOps（區分開的“開發”與“運營”的複合體）是一種軟體工程文化和實踐，旨在統一軟體開發（Dev）和軟體運營（Ops）。DevOps運動的主要特點是在軟體構建的所有步驟（從整合，測試，釋出到部署和基礎架構管理）中大力提倡自動化和監控。DevOps旨在縮短開發週期，增加部署頻率和更可靠的版本，與業務標的緊密結合。

DevOps的定義對於我來說更狹義且稍有不同：

DevOps是開發人員負責在生產中全天候運營服務的實踐。這包括使用共享基礎架構原語進行開發，測試，待命，可靠性工程，災難恢復，定義SLO，監控設定和告警，除錯和效能分析，事件根本原因分析，準備和部署等。

維基百科與我對DevOps的定義（開發理念與運營策略）之間的區別很重要，這是我在個人的行業經驗中得出的。DevOps“運動”的一部分是將前進緩慢的“遺留”企業引入現代高度自動化基礎設施和開發實踐，其中包括：鬆散耦合的服務，API和團隊；持續整合；小型迭代部署；敏捷的溝通和規劃；雲原生彈性基礎設施等等。

在我職業生涯的最後10年裡，我曾在超快速發展的網際網路公司工作過，包括AWS EC2，上市前的推特和Lyft。此外，由於建立和探討Envoy的緣故，我花了兩年時間與無數超速發展的網際網路公司的技術架構和組織進行會面和交流。對於所有這些公司而言，擁抱自動化，敏捷開發/規劃以及其他DevOps“最佳實踐”是一個既定的因素，能很好地解釋生產力的提高。相反，這些工程組織面臨的挑戰是如何平衡系統可靠性與業務增長，人員增長和競爭（業務和招聘）的極端壓力。本文的其餘部分均基於我的個人經驗，可能並不適用於所有情況，尤其是那些習慣了每季度僅全量釋出一次和正在被引入更快速和敏捷的開發實踐的緩慢前進的企業。

運營網際網路應用程式的簡史

在我稱之為現代網際網路時代的過去大約三十年中，網際網路應用程式的開發和運營已經經歷了（在我看來）三個不同的階段。

在第一階段，網際網路應用程式的構建和部署與“伸縮包裝”軟體的運輸方式類似。三個不同的工作角色（開發，QA和運營）相互協作，經過很長的工程週期將應用程式從開發轉移到生產。在此階段，每個應用程式都部署在專用資料中心或託管設施中，這進一步需要熟悉特定站點網路，硬體和系統管理的操作人員。
在第二階段，主要由亞馬遜和谷歌在90年代末和00年代初帶頭，網際網路應用程式在超高速發展的公司中開始採用類似於現代DevOps運動的做法（鬆散耦合的服務，敏捷開發和部署，自動化等等）。這些公司仍然執行私有的（大型）資料中心，但由於涉及的規模，他們開始開發集中式基礎架構團隊去解決所有服務所需的常見問題（網路，監控，部署，配置，資料儲存，快取，物理基礎設施等）。然而亞馬遜和谷歌從未完全統一開發工作角色（亞馬遜稱之系統工程師，谷歌稱之網站可靠性工程師）以及認識到每個人所涉及的不同技能和興趣。
在第三階段或雲原生階段，網際網路應用程式現在依賴託管彈性架構以從頭開始構建，通常這由“三大”公有雲服務商之一提供。盡可能快地將產品推向市場的主要原因一直是因為產品失敗的可能性高，但是在雲原生時代，“開箱即用”的基礎技術允許一種比以前更加笨重的迭代速度。在這個時代開始的公司的另一個定義特徵是避免聘用非軟體工程師角色。可用的基礎設施基礎是如此相當強大，他們認為創業資金應更好地花在可以同時進行工程和運營（DevOps）的軟體開發人員身上。

在第三階段此型別公司不僱用專職運營人員的變化至關重要。雖然，很顯然這樣的公司不需要全職系統管理員來管理託管設施中的機器，但是之前從事這類工作的人通常也具備其他20％的技能，例如系統除錯，效能分析，運營的直覺力等。新公司成立需要那些缺乏關鍵性、不易替換的技能的“勞動力”。

為什麼DevOps適用於現代網際網路初創公司？

DevOps，正如我所定義的那樣（開發和運營各自服務的工程師），對於現代網際網路初創公司來說效果非常好，原因有以下：

根據我的經驗，成功的早期創業公司工程師是一個特殊的工程師。他們具有風險承受能力，學習速度極快，無論發生何種技術債務都能儘快完成工作，通常可以在多種系統和語言中工作，並且通常具有操作和系統管理的先前經驗，或者願意學習所需知識。簡而言之，典型的創業工程師非常適合成為DevOps工程師，無論他們是否想這樣子稱呼自己。
如上所述，現代公有雲為構建提供了令人難以置信的基礎架構。過去的大多數基本操作任務都已自動化，剩餘的底層足以發行最小的可行產品去驗證是否有適合的產品市場。
我堅信，當開發人員被迫on-call並對他們編寫的程式碼負責時，系統的質量將會提高。沒有人喜歡經常被尋呼。這個反饋迴圈構建了一個更好的產品，正如我在（1）中所描述的那樣，吸引到早期初創產品工作的工程師非常願意學習和完成操作工作。鑒於對可靠性差的初創產品通常幾乎沒有反響，這一點尤為如此。可靠性需要足夠好以使產品找到適合市場併進入超高速發展階段。

當現代網際網路初創公司經歷過度增長時會發生什麼？

事實是大多數創業公司都失敗了。因此，任何花費大量時間在Google中建立基礎架構的早期創業公司都是在浪費時間。我總是告訴人們堅持他們的單體架構，除了人力可擴充套件性問題（通訊，規劃，緊耦合等）需要向更加分離的架構邁進之外，不要擔心任何其他問題。

那麼當現代（第三階段）網際網路初創公司獲得成功併進入高速增長時會發生什麼？一些有趣的事情將同時開始發生：

人員增長率迅速增加，對通訊和工程效率造成嚴重壓力。我強烈推薦閱讀The Mythical Man-Month[2]（在最初出版近50年後仍然具有相關性），以獲取有關此主題的更多資訊。
上述幾乎總是導致從單體架構向微服務架構轉變，這是一種解耦開發團隊並提高通訊和工程效率的方法。
從單體到微服務架構的轉變將系統基礎架構的複雜性提高了幾個數量級。網路，可觀察性，部署，庫管理，安全性以及以前不難解決的數百個其他問題，這些現在都是急需解決的主要問題。
與此同時，超高速發展意味著流量增長和由此產生的技術擴充套件問題，以及對完全失敗和次要使用者體驗問題的更大影響。

核心基礎設施團隊

普遍大部分遵循早期創業特徵，現代網際網路超高速發展公司最終都以類似的方式構建其工程組織。這種通用組織結構由一個集中的基礎架構團隊組成，該團隊支援一組實施DevOps的垂直產品團隊。

核心基礎架構團隊如此普遍的原因在於，正如我上面所討論的那樣，超高速增長帶來了一系列相關的變化，包括人員和底層技術，現實情況是，如果每個產品工程團隊都必須單獨解決有關網路，可觀察性，部署，配置，快取，資料儲存等方面的常見問題的話，那先進的雲原生技術就太難應用了。作為一個行業，我們與“Serverless”技術差距已有數十年，它足以完全支援高可靠，大規模和實時的網際網路應用，且可以讓整個工程組織可以在很大程度上關註業務邏輯。

因此，核心基礎架構團隊的誕生是為瞭解決大型工程組織的問題，而不僅僅是基於雲原生基礎架構原語存在的問題。顯然，谷歌的基礎設施團隊比Lyft這樣的公司的規模要大幾個數量級，因為谷歌正在從資料中心層面開始解決基礎問題，而Lyft依賴於大量公開可用的原語。但是，建立核心基礎架構組織的根本原因在兩種情況下都是相同的：抽象盡可能多的基礎架構，以便應用程式/產品開發人員可以專註於業務邏輯。

（人員）可替代性的謬誤

最後，我們得出了“可替代性”的概念，這是純粹的DevOps模型失敗的關鍵，當組織超出一定數量的工程師時。可替代性表示所有工程師都是平等的，他們都可以做所有事情。無論是作為一個明確的招聘標的（至少是亞馬遜或許還有其他的公司），或者透過“訓練營”的方式（明確表示在沒有團隊或角色的情況下）招聘工程師，可替代性已成為許多公司在過去10到15年間的現代工程的一個流行組成部分理念。什麼原因導致這樣？

正如我以上描述，現代雲原生技術和大量抽象允許使用越來越複雜的基礎設施來構建功能非常豐富的應用程式。自然而然，大多數公司將不再需要一些專業技能，如資料中心設計和運營。
在過去的15年中，業界一直專註於軟體工程是所有學科的根本。例如，微軟淘汰了傳統的QA工程師，並將其替換為軟體測試工程師，其理念是手動QA效率不高，所有測試都應該自動化。同樣，傳統的運營角色已經被站點可靠性工程師或類似的所取代，其理念是手動操作效率不高，並且擴充套件的唯一方法是透過軟體自動化。首先宣告我是同意這些趨勢的，自動化是一種更有效的擴充套件方式。

然而，正如許多新的網際網路初創公司所做的那樣，這種想法已經發揮到極致，導致只聘請全能型（全棧）工程師，期望這些（DevOps）工程師能夠處理開發，QA和運營。

對於早期初創公司而言，可替代以及通用型人才招聘通常都很好。然而當超出一定的規模，所有工程師都可替代的想法就變得幾近荒謬，原因如下：

通用型與專家。更複雜的應用程式和體系結構需要更多的專業技能才能成功，無論是前端，基礎架構，客戶端，操作，測試，資料科學等。這並不意味著全能型不再有用，或者全能型不能學會併成為專家，它只是意味著更大的工程組織需要不同型別的工程師才能取得成功。
所有工程師都不喜歡去做所有的事情。有些工程師喜歡做全棧。有些人喜歡專業化。有些人喜歡編寫程式碼。有些人喜歡除錯。有些喜歡UI。有些喜歡系統。一個支援各型別專家不斷發展的工程組織必須解決這樣一個事實，即員工的幸福感有時涉及某些具體型別的問題，而非其他。
所有工程師也不都擅長做所有事情。在我的整個職業生涯中，我遇到了很多很棒的人。某些人可以從IDE中的空檔案開始，從頭開始建立一個令人難以置信的系統。與此同時，這些人對如何執行可靠系統，如何除錯它們，如何監控它們等等幾乎沒有直覺經驗。相反，我一直在進行許多令人激動的訪談迴圈，其中一個真正令人難以置信的是運營工程師可以純粹透過除錯方面的專業知識和如何執行可靠系統的天生直覺，對整個組織產生巨大好處，但他們被拒絕僅是因為沒有展示“足夠的編碼技能”。

具有諷刺意味的是像亞馬遜和Facebook這樣的組織也優先考慮軟體工程角色的可替代性，但他們同樣重視開發和運營之間的技能區分，繼續為每個人提供不同的職業道路。

失敗

純DevOps如何以及在何種組織規模下失敗？出了什麼問題呢？

遷移到微服務。當一個工程組織達到約75人時，幾乎可以肯定有一個核心基礎設施團隊開始開發構建產品團隊構建微服務所需的基礎通用功能。
純粹的DevOps。與此同時，產品團隊被告知要做DevOps。
可靠性顧問。在這種組織規模上，那些傾向於從事基礎設施工作的工程師很可能是那些在該領域具有先前運營經驗或良好直覺的工程師。這些工程師不可避免地成為事實上的SRE/生產工程師，並作為顧問來幫助組織內的其他成員，同時繼續開發業務執行所需的基礎架構。
缺乏教導。作為一個行業，我們現在希望僱用可以介入開發和運營網際網路服務的人。然而，我們普遍在新員工以及執行這項任務所需的繼續教育方面做得很糟糕。當我們從不教授技能時，我們怎能指望工程師具備操作直覺？
支援失敗。隨著工程組織招聘率的不斷提高，核心基礎架構團隊不再能夠在繼續構建和運營對業務成功至關重要的基礎架構的同時還要保持支援幫助產品團隊完成運營任務。基礎設施工程師在其現有工作量的基礎上，作為組織範圍的SRE顧問，承擔雙重責任。每個人都明白培訓和檔案是至關重要的，但是很少有人優先安排去完成這兩件事的時間。
職業倦怠。更糟糕的是之前描述的情況造成了人員流失並降低了整個組織計程車氣。產品工程師覺得他們被要求做他們不想做或者沒有被教過的事情。基礎設施工程師在提供支援的重壓下開始倦怠，雖然知道培訓和檔案迫切需要但卻無法優先處理它，當同時在保持整個公司的現有系統以高可靠性執行。

在什麼規模下工程技術組織裡的某些環節會開始掉鏈子，因基礎設施團隊為支援純粹的DevOps模型讓組織開始出現人為擴充套件問題。我認為這個大小取決於當前公有雲原生技術的成熟度，這篇文章說的是總共有幾百名工程師這樣子的規模。

“老方式”和DevOps方式之間是否存在中間立場？

對於成立已超過10年的公司，網站可靠性或生產工程模型已經很普遍。雖然各公司的實施情況各不相同，但我們的想法是聘請能夠完全專註於可靠性工程而不受產品經理影響的工程師。但是有些實施細節非常相關，其中包括：

僅是SRE需時刻待命還是軟體工程師也分擔待命職責？
SRE是否實施實際工程以及自動化，還是他們僅需要執行手動和重覆性任務，例如部署，重覆頁面解析等？
SRE是屬於核心諮詢機構還是嵌入到產品團隊？

該實施計劃的成功及其對整個工程組織的影響往往取決於上述問題的答案。但是，我堅信在一定規模的情況下，SRE模型是將工程組織擴充套件到許多工程師的唯一有效方式，超出了純粹DevOps模型發生故障的程度。事實上，我認為在本文概述的人員擴充套件限制之前成功引導SRE計劃是現代超高速發展型網際網路公司的工程領導的關鍵責任。

什麼是正確的SRE模型？

鑒於目前業內實施的案例過多，這個問題沒有正確的答案，所有模型都存在問題。我將根據我過去十年的觀察概述我認為的最佳點：

認識到運營和可靠性工程是一個獨立且極具價值的技能組合。我們急於實現一切自動化以及軟體工程師可互換的想法，使得與軟體工程師同等價值的工程人員的一部分邊緣化。運營工程師和軟體工程師是合作伙伴，而不是可互換的齒輪。
SRE不是隨叫隨到的，監控儀錶面板或是隻會部署的猴子。他們是專註於可靠性任務而非產品任務的軟體工程師。理想的結構要求所有工程師會執行基本的運營任務，包括待命on-call，部署和監控等。我認為這非常重要，因為它有助於避免可靠性和軟體工程師之間的類/工作分層，並使軟體工程師更直接地對產品質量。
SRE應該嵌入到產品團隊中，而不是向產品團隊工程經理報告。這允許SRE與他們的團隊融合，獲得相互信任，並且仍然具有適當的核查與平衡，以便在嘗試權衡可靠性與功能時可以進行真正的對話。
嵌入式SRE的標的是透過實施面向可靠性的功能和自動化，指導和教育團隊其他人員的運營最佳實踐來提高產品的可靠性，並充當產品團隊和基礎架構團隊之間的聯絡人（檔案反饋，痛點，所需功能等）。

如上所述，在成長階段早期實施的成功的SRE計劃，以及對新員工和繼續教育和檔案的實際投資，可以提高整個工程組織的門檻，同時減輕之前描述的許多人員擴充套件問題。

結論

很少有公司能達到超快速發展階段，那麼這篇文章表達的能直接適用。對於許多公司而言，因為涉及的工程師數量，所需的系統可靠性以及業務所需的產品迭代率，基於現代雲原生基元的純DevOps模型可能完全足夠。

適用於這篇文章的相對較少的那些公司，關鍵的要點是：

任何希望參與競爭的新技術公司都需要DevOps風格的敏捷開發和自動化。
公有雲原生基元以及一個小型的核心基礎架構團隊可以允許工程組織在由於缺乏教導和角色特性而開始出現運營損失之前擴充套件到數百名工程師。
想要在可掌控的人員擴充套件問題上獲得成功，需要對新員工和繼續教育，檔案以及嵌入式SRE團隊的開發進行真正的投資，這些團隊可以在產品團隊和基礎架構團隊之間架起橋梁。

現代超高速發展的網際網路公司（在我看來）存在極大的倦怠，這主要是由於嚴苛的產品需求以及對運營基礎設施的投資不足。我認為領導層可以在組織的穩定性成為主要障礙之前先採取行動以逆轉這一趨勢。

雖然較新的公司可能會認為雲原生自動化的進步正在使傳統的運營工程師過時，但事實並非如此。在可預見的未來，即使在利用最新技術的同時，也應該認識和重視專門從事運營和可靠性的工程師，以提供任何其他方式無法獲得的關鍵技能組合，並且他們這一重要角色應正式編入到早期發展階段的工程組織中。

相關連結：

https://twitter.com/mattklein123/status/1001979384968957952
https://en.wikipedia.org/wiki/The_Mythical_Man-Month

原文連結：https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a

3天Kubernetes線下實戰培訓

Kubernetes應用實戰培訓將於2018年9月14日在上海開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選下方圖片檢視詳情。

DevOps適用於小團隊嗎？

相關推薦

熱門標籤

熱門文章

分享創造快樂