正如我最近在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