-
對工程生產力的投資往往發生在特定的轉折點，例如員工人數增加、危機事件發生後、組織成熟度提升、進入新市場，或追求卓越運營。 -
有些決策至關重要，將對構建工具的演變產生深遠的影響。例如，在單倉庫和多倉庫架構之間做出選擇會影響開發生命週期、測試策略和整體工程工作流程，需要採用量身定製的方法來最佳化生產力。 -
隨著組織規模的擴大，即使風險預防措施似乎會減緩開發速度，戰略且務實地實施控制措施和門檻（例如強制程式碼審查或金絲雀部署）也至關重要。 -
如果你想引領工程生產力的改進，你需要一種資料驅動的方法。這可以幫助你的領導層瞭解看似微小的低效之處，這些低效之處最終會造成大規模的浪費。 -
是否構建專有工具或使用第三方解決方案取決於可擴充套件性需求、最佳化機會、生態系統整合需求以及按照行業標準持續發展的承諾等因素。
我在 2024 年舊金山 QCon 的 演講 深入探討了以下主題：
2011 年時，我是一個處理 PB 級資料來支援我們公司零售網站的服務團隊的工程師。隨著黑色星期五的臨近，我們需要進行負載測試以確保網站能夠處理高峰流量，但由於時間限制，我們砍掉了測試。考慮到測試很費時間，我們認為它不值得投資。結果黑色星期五到來時，我們的服務沒有足夠的硬體來處理負載。我們瘋狂地擴充套件，結果卻讓一個關鍵資料庫過載了。
亞馬遜商店在一年中最繁忙的購物日盲飛了八個小時。第二天，我的主管問我如何防止這種情況再次發生。這是一個轉折點。突然之間，建立我之前建議的負載測試基礎設施成為了優先事項。那次失敗是一個價值數百萬美元的運維問題，也成為了一個轉折點——不僅對我的職業生涯，對亞馬遜的基礎設施也是如此。教訓是？永遠不要浪費一場大危機！
我們重要的收穫是識別在哪些拐點上，對工程生產力的投資變得有利可圖。識別反覆出現的模式是非常重要的。
最明顯的拐點通常是組織僱傭的工程師數量。隨著公司從三千名工程師擴充套件到六千名，再到五萬人，以前微不足道的效率谷地可能變得非常明顯。
我傾向於考慮運維摩擦的程度、其發生的頻率以及受影響的人數。例如，一位工程師最近強調了一個需要十秒鐘完成的手動任務。這個看似微不足道的不便發生得足夠頻繁，以至於在亞馬遜的規模上相當於每年損失大約三十五年的工程生產力。這不僅意味著失去大量時間，還代表著工程師錯過的機遇——他們本可以投下更高槓杆、更戰略性的賭注。
自動化這項任務需要四個月，再加上額外的兩個月用於持續的運維維護。也就是說，投資半個工程師年可以收穫三十五個工程師年，這是資源的明智分配。這些好處會隨著時間的推移而累積。在五年的時間裡，僅固定人員編制，累積節省的金額就達到 174 工程師年，在高增長環境中，這些好處甚至更加放大。
雖然量化工程生產力可能很困難，但並非不可完成的任務。我推薦 Douglas Hubbard 的主做《如何測量任何事物》，它提供了一些有價值的方法來量化看似無形的指標。即使最初的估計不精確——比如，範圍在二十到五十年之間——獲得一個合理的近似值提供了方向性的資料，這對於做出明智的投資決策是必要的。
工程師人數構成了一個拐點，而危機代表了另一個重要的拐點。正如我前面提到的，我經歷了這樣一個轉折點，也就是前面提到的 2011 年黑色星期五的例子。
八年後，亞馬遜 Prime Video 需要負責泰勒·斯威夫特的“你需要冷靜下來”的全球首映式直播。鑑於她龐大的粉絲基礎，我們預計會有數千萬同時觀看使用者。為了應對 2011 年運維問題而開發的技術被用來驗證平臺處理這種併發使用者量的能力。
從 2011 年的運維問題演變到 2019 年支援數千萬觀眾的直播，這是一段相當長的旅程。首先，我專注於為我的團隊建立基礎設施，只是想防止之前事件重演。然後，我意識到將其提供給其他團隊會有很多潛在好處。採用率是有機增長的，從兩個團隊發展到十個，然後是一百個。
這個專案最初是一個個人寵物專案，最終擴充套件到了支援數千個服務的規模，並演變成我的主要職責。它成為了亞馬遜全公司的負載和效能測試基礎設施，用於上面提到的泰勒·斯威夫特首映式和 AWS 服務的推出等事件。這一進展揭示出了危機（無論是個人還是專業層面的）作為工程生產力進步拐點的潛力。
組織成熟度也可以作為一個拐點。像亞馬遜、微軟、谷歌、Meta 等大型軟體公司，通常在工程生產力工具上有大量重複。雖然我不是巨量冗餘的愛好者，但這種重複既常見又往往有道理。
在快速增長的時期，快速獨立行動至關重要，因此各個組織會最佳化他們的工具集以加快上市時間。
或者，在高度不確定性的條件下，進行一定程度的實驗也是合理的。當前生成式人工智慧的狀態就體現了這種情況。雖然它對工程生產力的最終影響是肯定的，但它將如何重塑編碼、測試和相關流程的具體方式還是很模糊，因此同時探索多種方法是一個合理的策略。
雖然一定程度的重複是有意義的，但總會有一個匯聚的時刻，那時廢棄冗餘系統和整合基礎設施成為優先事項。在我重新加入亞馬遜並在亞馬遜全球商店工作時，我注意到越來越多的客戶使用我們的移動應用，所以我覺得有必要改進我們的測試基礎設施以反映這種變化。
當我們考慮構建基礎設施以改善裝置配置、測試執行和透過物理和虛擬裝置進行資源管理的能力時，我與亞馬遜內部其他團隊進行了交流，這些團隊負責移動應用（例如亞馬遜 Prime 影片、亞馬遜音樂以及以裝置為中心的組織，如 Alexa 和 Kindle）的交付。這些討論讓我們看到了相當大的重複努力，這是在快速擴張期間團隊獨立開發的結果。所以，目前我專注於推動這些組織朝著更加統一的模型匯聚。作為高階負責人，我有自由度來健康地打破組織邊界，併為整個亞馬遜的最佳利益行事。
重要的是要認識到，拐點並不總是需要擴張；匯聚和整合同樣是有效的目標。我在谷歌領導了將四個不同的整合測試基礎設施整合的專案，那時的經驗也加強了這種觀點。
提高運維或工程卓越的標準也可以作為變革的催化劑。隨著組織的發展和工程師數量的增加，關卡變得更重要了，這樣才能保持我們的高標準。
安全實踐的演變就是一個例子。信不信由你，在 2009 年，直接用 SSH 訪問生產伺服器是很常見的。今天，授予類似的訪問許可權到 EC2 或 S3 生產環境是絕對不可接受的。
同樣，曾經普遍存在的還有未經審查的直接程式碼提交。雖然程式碼審查被鼓勵作為最佳實踐，但倉庫工具本身並不強制執行它。現在，我們的程式碼審查工具確保在合併程式碼之前獲得指定審查者的批准。這些控制雖然引入了一定程度的摩擦，但在大尺度上是必不可少的。
每個 AWS 服務都應該實施金絲雀來監控它們的健康度嗎？幾年前我們決定，鑑於我們向客戶提供的 SLA，答案是肯定的。因此，適當的金絲雀現在是啟動任何 AWS 服務的強制性先決條件。
程式碼更改應該在足夠的程式碼覆蓋率上進行限制嗎？同樣，答案是肯定的。雖然團隊保留了確定他們特定的程式碼覆蓋率目標的自主權，但他們也需要有意識地決定生產中可接受的未測試程式碼水平。
這些控制措施雖然可能被視為對敏捷性的阻礙，但都是對過去的運維事件的直接響應，最終目的是提高我們的工程標準。
新市場的出現也可以作為一個拐點。
回到 2014-2020 年，當我在亞馬遜的 Builder Tools 組織工作時，我的主要重心是為網路服務提供工程生產力基礎設施，因為那代表了當時大部分正在進行的工作。但公司擴充套件到裝置領域的步伐帶來了新的挑戰。我們現有的持續整合和持續交付（CI/CD）工具針對網路服務最佳化。行動電話、Alexa 裝置和 Kindle 裝置卻有著不同的需求。
多年來，我們已經擴充套件了我們的 CI/CD 基礎設施，以適應一些我從未想過我們會做的事情，例如測試旋轉門。亞馬遜 Go 商店有一個無需結賬的模式，客戶進入，掃描他們的支付方式，選擇他們的物品，然後離開，無需與收銀員互動。這些商店的旋轉門由軟體控制，我們需要測試它們。
隨著公司將其業務擴充套件到新市場，嵌入在工具中的先前假設可能不再有效，我們需要拓寬視野。
最後，某些決策本質上是基礎性的，塑造了後續工程實踐和工具的軌跡，影響幾代人。觀察亞馬遜過去十五年的演變，我見證了這些決策的持久影響。
大約在 2007 年，亞馬遜在管理一個大型、緊密耦合的程式碼庫（被稱為“Obidos”）方面遇到了很多挑戰。這些挑戰包括編譯時間、部署複雜性、記憶體限制和協作開發的困難。我們決定將單體分解為微服務——這個概念今天被廣泛接受，但當時較少見。分解單體的主要目標是建立清晰的團隊界限，從而最小化相互依賴性。
這種方法導致了“兩個披薩團隊”的採用，這個術語指的是可以用兩個披薩（通常是六到九個人）餵飽的工程師數量。其目的是建立負責離散微服務的自治團隊，這些服務透過 RPC 或 HTTP 在網路上通訊，不共享程式碼。為了加強這種解耦，我們採用了多倉庫策略，讓每個團隊維護自己的獨立倉庫。
單倉庫與多倉庫的問題本質上是架構偏好的問題。我在谷歌（單倉庫環境）和亞馬遜（多倉庫環境）的經驗表明，這兩種方法都涉及管理複雜性，儘管形式不同。一個並不比另一個更好：由你處理複雜性的地方決定該如何權衡。
考慮軟體開發生命週期，它通常包括本地開發變更、程式碼審查、提交和合並、部署到測試環境，最終部署到生產環境等步驟。理想情況下，每個階段都要執行整合測試。
用房子的比喻來說，多倉庫環境就像一個有很多獨立房間的房子。一個倉庫中的錯誤被限制在那裡，主要影響負責它的團隊，限制了對其他團隊的干擾。
相比之下，單倉庫環境類似於一個單間公寓：錯誤可能產生深遠的後果。谷歌擁有 12 萬名工程師的龐大工程團隊，已經投入了大量資源在基礎設施和流程上，以減輕缺乏分支的單倉庫相關風險。雖然這種方法在大部分情況下是有效的，但它也有缺點，例如驗證複雜度更高和部署挑戰。
多倉庫架構本質上限制了潛在錯誤的爆炸半徑。但在單倉庫環境中，影響可能是廣泛的，因此提交前測試是至關重要的。因此，像谷歌這樣的公司優先投資於提交前整合測試，以識別和防止此類問題。另一方面，亞馬遜利用其多倉庫架構固有的爆炸半徑減少優勢，專注於提交後測試策略。提交前和提交後的策略是各自的反面；然而，每種策略在其各自的環境內都是有效的。
由於這種需要左移和早期測試的需求，谷歌在基礎設施上投入了大量資金，用於快速配置和取消配置的臨時、封閉的測試環境。相比之下，多倉庫環境歷來強調長期存在的、靜態的測試環境，具有高保真度，以及健壯的金絲雀部署、遙測、回滾機制和生產報警能力。（現在，甚至亞馬遜也在增加對左移的關注）。
在多倉庫環境中管理庫依賴關係是一種獨特的挑戰。我們需要建立機制，以實現依賴庫從一個倉庫到其他倉庫的受控分發，以及跟蹤組織中的庫版本，以解決潛在的安全漏洞。
我們經常需要在開發專有工具和利用第三方解決方案之間做出選擇。投資定製工具有幾個理由。首先，現有的第三方或開源解決方案可能缺乏你的特定需求所需的可擴充套件性。我在 2012 年開發亞馬遜的負載和效能測試基礎設施的經驗就是一個很好的例子：沒有現成的工具能夠實現必要的吞吐量。
其次，最佳化可能需要定製開發。谷歌的內部 IDE 是一個相關的例子。鑑於谷歌有 12 萬名高薪工程師，投資於提高他們效率的 IDE 是一個明智的戰略決策。
第三，一個整合工具的一致生態系統可能比需要大量整合工作的一系列不同的第三方解決方案更有效。這是亞馬遜、微軟和谷歌等大型組織在全面的工程生產力平臺上進行內部投資的理由。
然而，意識到與專有工具相關的潛在陷阱很重要。在一個特定的組織“泡沫”中被孤立的風險始終存在。保持對行業趨勢的關注，並確保內部工具繼續隨著外部進步而持續發展是至關重要的。如果做不到這一點，專有解決方案可能會變得過時，效果不如商業上可用的替代品。雖然我在開發專有工具上花費了我職業生涯的很大一部分時間，但我認識到了固有的權衡和在追求這條道路時需要仔細考慮的必要性。
總之，最佳化工程生產力的路徑是多方面的，需要對各種拐點進行深思熟慮的評估：人員數量、危機、組織成熟度、新市場和追求運維卓越。基礎架構決策，如選擇單倉庫和多倉庫策略，進一步影響資源分配和測試方法的優先順序。
最終，決定投資於專有工具還是第三方解決方案需要平衡評估可擴充套件性、最佳化潛力、生態系統效應以及持續與行業進步保持一致的需求。組織可以透過深思熟慮地考慮這些因素，培養一個既促進效率又促進創新的工程環境。
原文連結：
Inflection Points in Engineering Productivity as Amazon Grew 30x（https://www.infoq.com/articles/inflection-points-engineering-productivity/）
宣告：本文由 InfoQ 翻譯，未經許可禁止轉載。
點選底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！
