亞馬遜是如何進行軟體開發的？這個訪問告訴你

作者 | Todd Hoff

譯者 | 閆亮

亞馬遜是如何進行軟體開發的呢？如果你確實對這個話題感興趣，不妨邀請三五好友，訂上幾個披薩，然後一起坐下來觀看這個對 Ken Exner 的精彩訪問，他是 AWS 開發者工具部的部門經理。這裡著重強調 Ken 來自工具部，是因為畢竟每一個行業的進步都需要更好的開發工具。

https://www.youtube.com/watch?v=FlZm3nFMIAM&feature=youtu.be

本訪問強調了三個關鍵主題：細化團隊、自動化和以客戶為導向。

關鍵思路:

通過縱橫諜海的方式來實現規模增長。團隊以單個服務為部門分解成更小的團隊。EC2 一開始也只不過是七八個人的小團隊。

上述引文很好地體現了這三個主題，實際上，它也是 AWS 能夠笑傲公共雲市場的關鍵因素。亞馬遜根據客戶需求，從開發底層不斷分拆出新的團隊，從而增長了其自身規模。

如果你想要參考一個實例，不妨收聽一下重型網絡 433：深入 AWS 轉運站網關。這個講座詳細介紹了一個複雜的 AWS 功能（轉運站網關）是如何從客戶需求發展而來的。

隨著顧客需求的不斷增大，AWS 也在不斷推出更多的產品，不知不覺 AWS 已經走在了公共雲行業的前列。

下面是整個採訪的一些總結：

亞馬遜喜歡細化團隊。過去亞馬遜內部只有一個統一的組織和軟體架構 (perl/mason/c++)，但隨著規模的擴大這個模式很難再發揮作用，於是他們將這個架構按照單獨服務的形式進行了重構，整個組織也全部分拆成了小於十人的小團隊。團隊本身是完全獨立的，他們提供一個端到端的服務，並且負責所有服務相關的工作：與客戶接觸、開發、測試以及後續的技術支持等。

亞馬遜鍾愛自動化。亞馬遜開發部門幾乎自動化了所有事情：構建、發布以及部署。每一次提交的變更都自動推送到生產環境，這一開始很令大家擔心，但其實無非就是把手工做的工作自動化了而已，使其每次都以相同的方式執行。為確保證生產環境正常進行，我們在自動化過程中增加了很多不同的測試：集成測試、基於瀏覽器和網絡的測試以及負載測試等；我們也監測了自動化的整個過程。結果表明，通過自動化我們可以更頻繁更及時地推出更新，從而可以做到更多的、質量更好的發布。

亞馬遜實現了滾動式部署。部署一直是一個很打擊人的事情，不論是預生產還是在生產部署，我們需要找出每一次失敗的原因。對此，亞馬遜內部實現了滾動式部署。首先將服務部署一個 AZ 中的一台機器上，如果部署失敗，則回滾本次操作；部署成功，則部署到另一個 AZ，進而擴展到更多的 AZ，更多的地區；一旦發現問題，則回滾到前一個可正常工作的版本。

亞馬遜推崇安全為先的開發模式。開發人員需要像安全工程師一樣思考，這是亞馬遜文化的一部分。工程師同時也必須是開發人員、操作人員、架構師、測試人員和安全專家，為此亞馬遜為開發者提供了學習所有技能的機會。羅伯特·海萊應該很喜歡這種模式，畢竟他主張人類應該掌握盡可能多的技能。在亞馬遜 DevOps 也稱作 DevSecsOps，因為安全已經完全融入到了整個全棧開發流程。

開發人員需要為新項目架構和安全模型負責。安全模型由安全工程師進行審查。每個開發人員都需要負責自己代碼的安全隱患，因為他們離問題最近，所以也最有可能發現問題；正式開發中，代碼提交會被審查，同事在提交之前也需要靜態分析並給予反饋；構建過程中，也存在自動靜態分析；最終發布流程，會有更多的檢查，也會有金絲雀監視器對部署進行全方位測試。

檢查無處不在，整個生產環節處處都有檢查。亞馬遜為此制定了各種不同的政策。如果我們可以檢查一個流程，那麽我們就可以確定它是否遵循了最佳實踐。而如果我們能夠描述這個最佳實踐，那大家就可以針對流程的方方面面制定規則。作為一個組織領導者，我們可以為團隊制定規則，例如每個新提交必須達到 70% 的單元測試代碼覆蓋率才能部署。我們也有針對整個 AWS 部門的規則，例如不能同時部署到所有區域（特殊情況下可以，詳情見相關信息）。我們需要使用規則來阻止那些錯誤的做法。規則在團隊級別執行、也可以在部門或公司級別。這種檢查能夠避免大家犯一些常見的錯誤。亞馬遜通過多年的實踐經驗積累，已經建立了一個非常有效的工作流程，避免了開發上的很多彎路，開發人員不必再走試錯和汲取教訓這一艱辛之路了。通過對這個最佳實踐的自動化實現，亞馬遜保證了每次都能最優地完成全部工作流程。

團隊中的開發人員對架構負責，而不再由架構師來完成。一旦團隊有了一個架構，就由架構師或首席工程師對其評估。首席工程師的職責是審查和培訓，而不是設計架構。安全方面也是如此，安全工程師的角色不是設計安全模型，而是審查開發人員創建的安全模型。測試也是如此。亞馬遜花費了很多時間在內部培訓上，因為他們希望開發人員能夠主導一切。

亞馬遜需要領導者時刻做好表率作用。我們知道在亞馬遜運營很重要，這是因為我們看到領導者的確很重視它。要想員工認真對待某件事情，領導者就必須先認真對待。例如，每個團隊都必須在周會上展示他們當前的工作安排，每一個細節都需要給出解釋。

最好的計劃方式來自底層開發。直接開發產品的團隊也最接近客戶。他們知道客戶的需求，因此應該由他們告訴亞馬遜該做什麽。亞馬遜每年需要提交兩個文檔 OP1 和 OP2（即 Operating Plan 運營計劃）。每個開發組都需要提交一份關於下一年計劃的 6 頁文檔。在計劃書中，團隊需要列明所需要的常規資源和新增加資源，並注明資源用途。這 6 頁商業計劃書將會自下而上呈現給公司各級組織。經理們會從所有團隊計劃書中歸納出一份新的 6 頁文檔，並上報給他們的管理層。最終報告會一直上交到貝佐斯手中（CEO），在做出最終決策後，資源下發給各個團隊。

管理層需要發揮監督作用。儘管最接近客戶的團隊往往能夠提供最好的創意，但這些創意需要管理層的仲裁和判斷。

每個團隊都有目標考核。公司會根據團隊計劃分配相應資源，整個過程會被跟蹤管理。每個團隊都被認為是一個創業公司，而管理層則是董事會，他們通過審查和衡量目標進度來管理所有團隊。

團隊可以有專家。這些專家可以有不同的技能組合，像一個 Web 開發、SE（系統工程師）、PM（項目管理）、文檔編寫者甚至是行銷人員。

每個團隊都是獨立的，這也增加了溝通和達成共識的難度。由於很難及時溝通，亞馬遜通常會存在兩個甚至多個相同的產品計劃，但這總比沒有計劃要好，畢竟這仍在可控風險內，可以隨後加以修正，但最好不要拖延計劃執行。團隊一致性上則通過內部重構來解決，公司會創建另一個團隊和服務來處理這些額外的責任。

你可以說服任何一個團隊去協助你的計劃，前提是你能夠說服他們。在年度規劃過程中，公司性決策則是由上向下驅動。例如，如果公司要進入一個新的區域，每個團隊必須為此做好計劃。

當看到一個公司高層在解釋其公司的軟體開發流程時，我總覺得很奇怪。作為一個從業多年的個人開發者，我發現管理層其實並不需要知道工作是如何實現的。讓我驚訝的是，根據下面 reddit 的討論思路，很多來自亞馬遜的員工也同意我這個觀點。

相關信息

https://www.reddit.com/r/programming/comments/axxaar/how_software_is_developed_at_amazon/

Site Reliability Engineering

https://landing.google.com/sre/books/

Mjr00：需要更正一下，我們可以在一天內部署到所有地區，但這只限於盡快修複一個關鍵 bug 的情況，另外這也需要副總裁的批準，因此這隻發生在極少數情況下。然而，真正有趣的不是修複 bug 而是修複後的事：你需要挖掘所有日誌和數據來解釋發生了什麽、為什麽發生、為什麽沒有被更早地檢測到，以及如何確保以後不再發生等。然後你要準備一份報告，又被稱為 " 錯誤更正 "（COE），如果夠幸運，這份文件只會被你的主管審查和批準；但如果運氣不好，你很有可能要在工程組會上把這份報告展示給 Charlie Bell 和 Andy Jassy，他們可是會把它撕成碎片的，更糟糕的是這一切會被所有參會人看到，甚至在網上直播。

英文原文

http://highscalability.com/blog/2019/3/4/how-is-software-developed-at-amazon.html

點個在看少個 bug