內容來源：DevOps案例深度研究 –Amazon持續交付之道戰隊（本文只展示部分PPT及研究成果，更多細節請關注案例分享會，及本公眾號。）

本案例內容貢獻者：單冰 (Topic Leader)、 趙棟、梁興龍、李杰、毛艷清、牛恒

本次案例解讀：王立杰

（圖片來源于網絡）

上一篇文章《DevOps案例研究|史上最能“拜客戶教”的公司，是如何做到持續交付的？（第1趴）》，通過介紹Amazon實行DevOps的背景，為大家解答了為啥Amazon被稱為史上最“拜客戶教”的公司，以及它如何在這種理念指導之下，通過DevOps提升研發效能，從而支持業務增長。

注：整個案例研究分成如下幾個部分，本文為該系列文章的第二篇，后續內容會在本公眾號持續發布，請大家關注“DevOps”公眾號！避免錯過后面的精彩內容。

了解了實行DevOps的背景，那么，Amazon這家史上最能“拜客戶教”的公司，具體是如何做到持續交付的呢？本文將為大家拆解Amazon持續交付的具體實踐。

Amazon的DevOps也是端到端的閉環過程，即先有構建（Build）->測試（Test）->發布（Release）的交付流水線，再從客戶經歷監控（Monitor）->下次計劃(Plan)的反饋閉環。

在整個打造閉環的過程中，Amazon一共經歷了四個方面的變革。

一、組織變革

1.1 “兩個披薩”團隊

任何時候、任何大的變革，都需要先從“人”的層面進行。這涉及到組織文化的重構、組織價值觀與行為的梳理。Amazon也不例外。Amazon的“兩個披薩”團隊在業界流傳已久，“兩個披薩”團隊是指在Amazon內部劃分團隊的規則：購買兩個最大號的披薩，如果能夠讓你的團隊吃飽，那就可以保留這么多人；如果不能吃飽，說明你的團隊人數太多，需要拆分。這個說法其實也是在提倡敏捷小團隊，典型的敏捷團隊是5-9人，也差不多兩個披薩可以吃飽。

1.2 一流的人才

團隊組建成功，要想充分激發起團隊的主動性、能動性，必然離不開授權與激勵，因此Amazon提倡充分授權，即“完全所有權；完全問責制；一致的激勵措施”，一句話概括就是權責利的獎罰分明。當然，開發與運維的協同必不可少，畢竟這是狹義DevOps的基本范疇。這里需要強調一點：Amazon對人才的要求極高。貝索斯認為：雇傭最優秀和最聰明的員工是公司走向成功的保證。Amazon一直堅持招人的高標準，堅決不會為了滿足各業務部門的人力資源需求而放低招聘標準。每次招募員工時，無論男性還是女性，都要求一個比一個水平高，只有這樣，才能使整個人才儲備的標準提高。隨著Amazon的不斷壯大，貝索斯對員工的要求更高了，并在會上不斷重申要求員工要用心工作、努力工作和超時工作。同時，貝索斯不能容忍愚蠢的行為，即使是偶爾為之也無法容忍。2009年2月，Kindle2發售前夜的大會彩排現場，由于出現了一些計算失誤，貝索斯怒斥了通訊部門的員工，“我不知道你們是不是沒有用高標準要求自己，還是你們只是不知道自己在做什么。”在這樣的高標準要求之下，那些不滿以及不適合Amazon的員工都被貝索斯堅定地解雇了，取而代之的是擁有新觀念和更多經驗的人。當然，留下來的老員工都得到了豐厚的回報。

1.3 充分授權

有了一流的人才，還需要對員工充分授權。為了強化沃爾瑪創始人山姆-沃爾頓“崇尚行動”的理念，貝索斯創造出了“放手去做”（just do it）這一獎項，Amazon非常支持員工發揮主動精神去取得顯著業績，尤其是在其主要工作職責之外取得的成績，并認為即使員工因此出現了很大的失誤，也應該獲得褒獎，因為他們承擔了很大的風險，并在此過程中展現了足智多謀的一面。另外，貝索斯認為等級制度對變化不利，他在會議和演講上表示，要把Amazon的經營重點放在權力下放和獨立決策上，并且一以貫之地執行。

二、架構變革

2.1 變革背景

在2001年，Amazon網站仍然是一個大的單體應用，由數百萬行C++代碼組成。幾千個開發者同時開發一個大的版本，開發完成，再由一個工程師團隊手工進行應用上線。如下圖所示：

很明顯，這種單體架構的開發效率之低和協作成本之高可想而知。

• 所有人修改的代碼都是一個應用代碼，代碼沖突不斷。?
• 構建時間長，任何小修改都必須重新構建整個項目，這個過程往往很長。?
• 穩定性問題：一個小問題，都可能導致整個應用掛掉。?
• 代碼高度耦合，新人的學習成本太高，不容易融入團隊。?
• 不易擴展：無法滿足高并發的業務需求，在必須規模化時，很快達到其極限。

這樣的單體架構已經嚴重影響到業務的增長。為了徹底解決這一問題，貝索斯2002年發了一封信，要求必須改變，如果誰不改，就開除誰。這個背景我們在上篇文章有提到，點擊復習?【DevOps案例研究|史上最能“拜客戶教”的公司，是如何做到持續交付的？（第1趴）】。這個突破口就是“架構變革”，整個網站需要從單體應用轉變為面向服務的架構，也就是SOA。每個服務只需要單一用途，讓每個開發團隊都可處理一個獨立的可交付的代碼單元；要簡單，不要復雜；各個業務的組成都是通過API實現連接和數據交換，從而實現去耦合。

2.2?變革成效

在完成這樣的架構變革后，收效顯著：

1) 發布效率提升

在Amazon初始架構中，任何一個bug修復，都需要更改應用程序中某些C++ ，單個修復完，還要等待其他人完成對應用程序其他模塊的更改，并對整個應用程序進行測試之后才能發布。切換到微服務體系架構后，開發團隊可以只對其負責的微服務進行更改，可以獨立發布，只要保證質量即可。

2) 錯誤隔離

在微服務體系架構中，每個團隊都在獨立的代碼基礎上工作，不僅團隊間的代碼沖突減少，而且錯誤被隔離到單個微服務中。

3) 技術多樣性

以前，所有的代碼都是C++代碼，整體開發團隊被限制在一個通用的技術堆棧和過程中。采用微服務后，允許獨立的團隊為給定的服務選擇正確的流程和技術，采用Java或者Python等框架都可以。這樣，就可以吸引更多有才華的工程師，讓他們采用各種新技術。

4) 新人融入快

新工程師可以安全地在一個小型的微服務上進行編碼。對于一個工程師來說，沒有必要僅僅為了修復一個bug而去學習一大堆代碼庫，學習曲線降低。

5) 團隊擁有更大的自主權

采用微服務的最大變化可能是文化。為了提高敏捷性和效率，微服務開發團隊做出以前無法控制的決策，比如發布日期、質量策略。這一點跟前面的組織變革，正好相輔相成。

三、工具變革

3.1 APOLLO

一個云應用程序可能擁有數百個單獨的微服務，每個微服務可能由多個實例組成(為了可用性和可伸縮性)，這就帶來微服務規模的增長；而每個微服務將由各自的開發團隊獨立更新。快速增長的微服務數量和更新的頻率要求一個完全自動化的部署工作流程和基礎設施。Amazon內部的APOLLO工具，在這種場景下應運而生。APOLLO主要對環境進行管理，比如某一個服務上線需要用到哪些package group、依賴有哪些、參數要設置哪些、機器要多少臺等。按最小的服務單元每次也會涉及到在幾十臺主機上做部署。

APOLLO可以自動化整個部署工作流程，這也是目前大多數類似工具的通用功能。

• 從代碼到客戶的全自動化。通常，一旦開發人員將代碼提交源代碼庫，就會有一個按鈕流程，自動獲取最新的源代碼，并將其打包到部署工件中，如容器，然后將整個工件部署到準生產或生產環境中。這被稱為持續交付。
• 彈性縮放。微服務本質上是相當短暫的部署新版本、退出舊版本，并根據利用率添加或刪除新實例。Amazon采用的是Elastic Compute Cloud，支持彈性擴展地部署基礎設施。

3.2 Build tools

Amazon崇尚每個人有更小更明確的任務，“you build it, you run it.” 落到工具層面，這主要得益于一個叫Build tools的組，他們把Platform和Internal tools做到了功能性和易用性在業界內數一數二。

這個組做的主要工具有5類：?

1）Brazil Build

對package進行分發和建立，每次build至少涉及上百個package，可以在幾分鐘甚至幾十秒內完成build并保證不出錯。

2）Apollo Deployment

對環境進行管理，比如某一個service上線需要用到哪些package group、依賴有哪些、參數要設置哪些、機器要多少臺等。按最小的service單元每次也會涉及到在幾十臺host上做deployment。

3）Code base

所有代碼存放在中央代碼庫，可以按reference、method、keyword之類搜索所有相關代碼。

4）Monitoring System

對service進行監控、告警、故障分析等。

5）Pipeline

把build、test、deploy全部串起來，對整個流程進行監控。大部分操作如rebuild、代碼回滾、停止deploy一鍵操作就可以完成。

Amazon的所有工具是全公司統一使用的，更新及時且統一，有一個非常大的組專門負責開發維護，在Amazon，隨便一個開發通過Apollo只需一鍵就可以實現回滾。而大多數公司由于組織架構的原因，各個組之間的代碼不是互相可見的，做這些工具也各自為戰，你做一套我做一套，精力分散，加上code/API等不透明導致online infra做得非常渣，以至于想回滾一次得叫上PM、QA、Dev等人一起弄個大動作，這也導致很多公司想做每日部署幾乎不可能，更別說分鐘級部署了。?

四、流程變革

人都是不可靠的，都會犯錯誤，但機器不會，只會忠實地執行。提高效率，避免錯誤的關鍵，就是要把一切能流程化的東西自動化。關于這部分，就不多做贅述了。

總結

正是上述四大變革提升了Amazon公司的整體DevOps能力：Amazon可以讓一個Dev從功能的設計、開發、測試、發布、后續的監控由一個人完成。平均每十幾秒就有一次發布，每天發布好幾千次，讓Amazon最終實現一年5000萬次的部署。
如果你對搭建流水線感興趣，想體驗一下如何用工具實現真正的交付流水線，體驗從修改代碼再到一鍵上線的快感，體驗如何從0到1打造一款產品，建議你來我們的DevOps黑客馬拉松！！（識別文末圖片中的二維碼即可報名~）號外！號外！！如果你想跟“無敵哥-王立杰”老師微信交流，請在公眾號后臺回復“無敵哥”，您將會得到“無敵哥-王立杰”老師的微信二維碼，添加時注明理由。

拓展閱讀：DevOps案例研究：知人善任——Google敏捷核心文化

DevOps案例研究：進取到讓自己毛骨悚然，Netflix公司的簡介和文化

DevOps案例研究|史上最能“拜客戶教”的公司，是如何做到持續交付的？（第1趴）

DevOps案例研究：庖丁解牛，剖析Google持續交付之道

歷久彌新 - 微軟萬億市值背后的文化支撐（上）|DevOps案例研究

歷久彌新 - 微軟萬億市值背后的文化支撐（下）|DevOps案例研究

DevOps黑客馬拉松?

9月7-8日 北京

專業大咖陪你一起進化

歡迎企業組隊PK，企業團隊報名有特惠

目前已經有兩家企業組隊！！

趕緊報名吧~??????

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的史上最能“拜客户教”的公司，是如何做到持续交付的？（第2趴）|DevOps案例研究...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。