內(nèi)容來源：DevOps案例深度研究 –Amazon持續(xù)交付之道戰(zhàn)隊（本文只展示部分PPT及研究成果，更多細節(jié)請關(guān)注案例分享會，及本公眾號。）

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

本次案例解讀：王立杰

（圖片來源于網(wǎng)絡(luò)）

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

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

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

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

在整個打造閉環(huán)的過程中，Amazon一共經(jīng)歷了四個方面的變革。

一、組織變革

1.1 “兩個披薩”團隊

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

1.2 一流的人才

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

1.3 充分授權(quán)

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

二、架構(gòu)變革

2.1 變革背景

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

很明顯，這種單體架構(gòu)的開發(fā)效率之低和協(xié)作成本之高可想而知。

• 所有人修改的代碼都是一個應(yīng)用代碼，代碼沖突不斷。?
• 構(gòu)建時間長，任何小修改都必須重新構(gòu)建整個項目，這個過程往往很長。?
• 穩(wěn)定性問題：一個小問題，都可能導(dǎo)致整個應(yīng)用掛掉。?
• 代碼高度耦合，新人的學(xué)習(xí)成本太高，不容易融入團隊。?
• 不易擴展：無法滿足高并發(fā)的業(yè)務(wù)需求，在必須規(guī)模化時，很快達到其極限。

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

2.2?變革成效

在完成這樣的架構(gòu)變革后，收效顯著：

1) 發(fā)布效率提升

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

2) 錯誤隔離

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

3) 技術(shù)多樣性

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

4) 新人融入快

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

5) 團隊擁有更大的自主權(quán)

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

三、工具變革

3.1 APOLLO

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

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

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

3.2 Build tools

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

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

1）Brazil Build

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

2）Apollo Deployment

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

3）Code base

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

4）Monitoring System

對service進行監(jiān)控、告警、故障分析等。

5）Pipeline

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

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

四、流程變革

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

總結(jié)

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

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

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

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

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

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

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

DevOps黑客馬拉松?

9月7-8日 北京

專業(yè)大咖陪你一起進化

歡迎企業(yè)組隊PK，企業(yè)團隊報名有特惠

目前已經(jīng)有兩家企業(yè)組隊！！

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

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。