我推崇的軟件工程思想--敏捷開發
在前一篇博客中談到了是上課學的是"上世紀"的軟件工程思想,先買呢談談我推崇的軟件工程思想----敏捷開發
為什麽要敏捷開發
“沒有人喜歡敏捷，但我們不得不敏捷。就像沒有人喜歡工作，但你必須工作。”這是我經常用來調侃敏捷的一句話。
試想一下，拿到一份完整詳盡的需求文檔，逐個功能Coding，測試部署上線。不需要再次確認需求，不會有人打斷思路。沒有需求更改，只要自己不犯錯，不存在推倒重來這才是大部分開發人員最舒服的工作方式吧，簡直太完美了。但它很像瀑布，一點都不敏捷。
既然我們喜歡的工作方式是傳統的、瀑布的，為什麽要敏捷？這還不都是市場環境逼的。今天的市場向我們提出了三個問題：
1.如何做出真正滿足用戶需求的產品？
我不確定這世上是否有人可以做到，他所做出的全部決定都是對的。但絕大多數人是無法一次性做出真正滿足用戶需求的產品的。我們無法預測未來，我們必須通過一次次的測試，去尋找用戶需要的產品是什麽？想要更快地獲得好的產品，必須迅速將產品推向市場，快速試驗，避免走彎路。
2.如何滿足不斷變化的用戶需求？
今天所有的事情的都在快速變化，用戶的需求也在變化。毫不誇張地說，我們正在全力開發的一些功能，當它們上線的時候，我們的用戶已經不再需要了。我們沒有辦法讓一切不變，我們只能選擇去擁抱變化。
3.如何同時滿足不同層次用戶的需求？
過去我們的產品會遵循產品生命周期，早期追求新奇的嘗鮮者，中期普通大眾，後期落後者。今天，產品的生命周期變化非常地快，我們可能會同時面對嘗鮮者、普通大眾、落後者，不同的用戶類型的需求是不一樣的，你如何滿足他們？我們必須快速響應，沒法快速響應，就沒法留住用戶，沒有用戶就沒有一切。
迅速將產品推向市場，擁抱變化、快速響應。今天的市場向所有的從業者提出了一個要求：擁有應對快速變化的需求的軟件開發能力。而敏捷就是賦予團隊應對快速變化的需求的軟件開發能力的方法，而這就是敏捷流行的原因。
什麽是敏捷開發
敏捷絕非某一種特定的開發方法，它只是一種應對快速變化的需求的一種軟件開發能力。敏捷本身只包含了《敏捷軟件開發宣言》和《敏捷軟件的十二條原則》兩份文檔。敏捷相信，只要符合這兩份文檔的開發方法，就能讓開發團隊擁有應對快速變化需求的能力，這樣的開發方法都叫做敏捷開發方法。
最流行的敏捷開發方式是什麽
敏捷開發的方法有很多：ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前國內最流行的應屬Scrum。
Scrum本意是指橄欖球運動中的“帶球過人”，它可以解決非常復雜的項目，並且能高效並創造性地交付高價值的產品。Scrum包含3個角色、3個工件、5個價值觀、5個事件（詳情https://www.scrum.org/）。
相比其他敏捷方法，Scrum既不簡單又不復雜。它有完善的指南，你可以按照指南，輕易在團隊內推廣嘗試。但想要實踐好Scrum，又需要很好的技巧。這種易上手難精通的方法，特別適合培訓機構。所以近幾年，關於Scrum的培訓機構遍地都是。可以說，在Scrum流行這件事上，這些培訓機構做了很大的貢獻。
下面來談談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（在最初出版近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://www.zhihu.com/question/19645396/answer/410025559
http://dockone.io/article/8189
我推崇的軟件工程思想--敏捷開發