Amazon爲什麼能作到持續交付

本文來源：知乎專欄 @繼小駒，做者林坦，曾就任於美國Amazon總部負責全球交易系統以及存儲系統，現爲互利科技創始人兼CEO。
原文連接：https://zhuanlan.zhihu.com/p/...

前段時間去國內一家大型電商公司作交流，正好也回顧了一下Amazon的經歷方便作比對。如下信息應該都是能夠公開的。

Amazon可讓一個Dev從功能的設計，開發，測試，發佈，後續的監控一我的在完成。平均每十幾秒就有一次發佈，天天發佈好幾千次，保證快速高質量的持續交付。

從工程師管理上，主要實行了DevOps。讓每一個人有更小更明確的任務，you build it, you run it. 而工具方面這主要得益於一個Build tools的組，他們把Platform和Internal tools作到了功能是和易用性上在界內首屈一指。讓Amazon retail那個超級龐大複雜的網站時刻能夠被流暢的使用。而這個組作的主要工具備5類：

1. Brazil Build, 對package進行分發和創建，每次build至少涉及上百個package，能夠在幾分鐘甚至幾十秒內完成build並保證不出錯。

2. Apollo Deployment, 對環境進行管理，好比某一個service上線須要用到哪些package group，依賴有哪些，參數要設置哪些，機器要多少臺etc。按最小的service單元每次也會涉及到在幾十臺host上作deployment。

3. Code base，全部代碼存放在中央代碼庫，能夠按reference，method，keyword之類搜索全部相關代碼。

4. Monitoring System，對service進行監控，告警，故障分析etc。

5. Pipeline，把build，test，deploy所有串起來，對整個流程進行監控。大部分操做如rebuild，代碼回滾，中止deploy一鍵操做就能夠完成。

與Microsoft相比，Amazon的全部tools全公司統一使用的，更新及時且統一，有專門很是大一個組負責開發維護。而Microsoft因爲組織架構緣由，各個組間code不是互相可見的，作這些tools也各自爲戰，你作一套我作一套，精力分散加上code/api等不透明致使online infra作的很是渣。以致於Microsoft想rollback一次得叫上PM，QA，Dev等人一塊兒弄個大動做。而Amazon隨便一個Dev經過Apollo只需one click就能夠rollback了。這也致使Microsoft想作daily deployment幾乎不可能，更別說hourly deployment了。

Facebook也有十餘年曆史了，但Ops的經驗還相對不足。有時候看Facebook的朋友工做作時用到了一些工具，整體感受缺少統一規劃性，deployment tool，monitoring都有，可是還不夠完善。好在工程師們都足夠強，能夠依賴工程師的我的素質去解決一些問題。這個一下子後面再補充幾句。

以Google的人才和技術實力，Internal tools天然也是同樣都不缺，惟一的區別是在易用性上還和Amazon的差一點，固然對於Google的工程師來講，這點區別並不形成太大影響。

剛纔說到Facebook和工具還不完善，不少時候要依賴於工程師素質，Google的工具易用性也還能夠提升。那麼爲何Amazon要把internal tools作的這麼強大而且這麼產品化呢？按通常公司的想法，內部工具反正給內部用的，能用就行，好很差用，醜不醜，統一不統一都不重要。

這涉及到Amazon的人才戰略。Amazon 90%以上的是初級程序員。來自於校招或1-2年工做經驗。想讓這些人真正發揮出價值有兩條路能夠選：
1.花1年培養他們，讓他們對業務能獨當一面。
2.給他們拆分出足夠小足夠簡單的任務，並給出足夠強大的輔助工具，讓他們能夠在1-2個月內就能開始發揮所有價值。Amazon顯然選擇了第二種方式（想一想當時才入職第二週就開始oncall了，若是沒有強大工具的支持，不可能去解決系統問題的。）顯然第二種方式對工程師是很是不友好的，但從資本的角度出發，這是以低廉的方法最大程序的榨取勞動力。這也致使Amazon的turn over rate要高於Google和Facebook。

之前做爲工程師，也很是喜歡Google對待工程師的方式，不事後來更多的接觸商業以後以爲Amazon和Uber這樣的公司，哪怕是Facebook這樣的公司，才更像一個正常的商業運做的公司，而Google這種過於理想化的方式更像是在研究所。

那麼何時公司須要開始重視internal tools呢？按以前Twitter一名工程師分析的結論（文章暫時找不到）是當公司工程師團隊超過50人時，internal tools能夠開始提高總體團隊的效率和工程質量。上面比較的幾家都是工程師很是強的公司，若是你的公司的工程師強不到那種程度， 利用好工具作好持續發佈更尤其重要。

美國大部分公司是很支持並願意去作internal tools的，而國內因爲對工具價值的理解不夠，或者說對長期規劃不足，致使與重視程度也不夠。據說滴滴每次發個新版還要CEO上臺全體動員，緊張的不行，工程師在發完新版後每天得加班。由此一例可見差距。