前段時(shí)間去國(guó)內(nèi)一家大型電商公司做交流，正好也回顧了一下Amazon的經(jīng)歷方便做比對(duì)。以下信息應(yīng)該都是可以公開(kāi)的。

Amazon可以讓一個(gè)Dev從功能的設(shè)計(jì)，開(kāi)發(fā)，測(cè)試，發(fā)布，后續(xù)的監(jiān)控一個(gè)人在完成。平均每十幾秒就有一次發(fā)布，每天發(fā)布好幾千次，保證快速高質(zhì)量的持續(xù)交付。

從工程師管理上，主要實(shí)行了DevOps。讓每個(gè)人有更小更明確的任務(wù)，you build it, you run it. 而工具方面這主要得益于一個(gè)Build tools的組，他們把Platform和Internal tools做到了功能是和易用性上在界內(nèi)數(shù)一數(shù)二。讓Amazon retail那個(gè)超級(jí)龐大復(fù)雜的網(wǎng)站時(shí)刻可以被流暢的使用。而這個(gè)組做的主要工具有5類：

1. Brazil Build, 對(duì)package進(jìn)行分發(fā)和建立，每次build至少涉及上百個(gè)package，可以在幾分鐘甚至幾十秒內(nèi)完成build并保證不出錯(cuò)。
2. Apollo Deployment, 對(duì)環(huán)境進(jìn)行管理，比如某一個(gè)service上線需要用到哪些package group，依賴有哪些，參數(shù)要設(shè)置哪些，機(jī)器要多少臺(tái)etc。按最小的service單元每次也會(huì)涉及到在幾十臺(tái)host上做deployment。
3. Code base，所有代碼存放在中央代碼庫(kù)，可以按reference，method，keyword之類搜索所有相關(guān)代碼。
4. Monitoring System，對(duì)service進(jìn)行監(jiān)控，告警，故障分析etc。
5. Pipeline，把build，test，deploy全部串起來(lái)，對(duì)整個(gè)流程進(jìn)行監(jiān)控。大部分操作如rebuild，代碼回滾，停止deploy一鍵操作就可以完成。

與Microsoft相比，Amazon的所有tools全公司統(tǒng)一使用的，更新及時(shí)且統(tǒng)一，有專門(mén)非常大一個(gè)組負(fù)責(zé)開(kāi)發(fā)維護(hù)。而Microsoft由于組織架構(gòu)原因，各個(gè)組間code不是互相可見(jiàn)的，做這些tools也各自為戰(zhàn)，你做一套我做一套，精力分散加上code/api等不透明導(dǎo)致online infra做的非常渣。以至于Microsoft想rollback一次得叫上PM，QA，Dev等人一起弄個(gè)大動(dòng)作。而Amazon隨便一個(gè)Dev通過(guò)Apollo只需one click就可以rollback了。這也導(dǎo)致Microsoft想做daily deployment幾乎不可能，更別說(shuō)hourly deployment了。

Facebook也有十余年歷史了，但Ops的經(jīng)驗(yàn)還相對(duì)不足。有時(shí)候看Facebook的朋友工作做時(shí)用到了一些工具，總體感覺(jué)缺乏統(tǒng)一規(guī)劃性，deployment tool，monitoring都有，但是還不夠完善。好在工程師們都足夠強(qiáng)，可以依賴工程師的個(gè)人素質(zhì)去解決一些問(wèn)題。這個(gè)一會(huì)兒后面再補(bǔ)充幾句。

以Google的人才和技術(shù)實(shí)力，Internal tools自然也是一樣都不缺，唯一的區(qū)別是在易用性上還和Amazon的差一點(diǎn)，當(dāng)然對(duì)于Google的工程師來(lái)說(shuō)，這點(diǎn)區(qū)別并不造成太大影響。

剛才說(shuō)到Facebook和工具還不完善，很多時(shí)候要依賴于工程師素質(zhì)，Google的工具易用性也還可以提高。那么為什么Amazon要把internal tools做的這么強(qiáng)大并且這么產(chǎn)品化呢?按一般公司的想法，內(nèi)部工具反正給內(nèi)部用的，能用就行，好不好用，丑不丑，統(tǒng)一不統(tǒng)一都不重要。

這涉及到Amazon的人才戰(zhàn)略。Amazon 90%以上的是初級(jí)程序員。來(lái)自于校招或1-2年工作經(jīng)驗(yàn)。想讓這些人真正發(fā)揮出價(jià)值有兩條路可以選：

1.花1年培養(yǎng)他們，讓他們對(duì)業(yè)務(wù)能獨(dú)當(dāng)一面。

2.給他們拆分出足夠小足夠簡(jiǎn)單的任務(wù)，并給出足夠強(qiáng)大的輔助工具，讓他們可以在1-2個(gè)月內(nèi)就能開(kāi)始發(fā)揮全部?jī)r(jià)值。Amazon顯然選擇了第二種方式(想想當(dāng)時(shí)才入職第二周就開(kāi)始o(jì)ncall了，如果沒(méi)有強(qiáng)大工具的支持，不可能去解決系統(tǒng)問(wèn)題的。)顯然第二種方式對(duì)工程師是非常不友好的，但從資本的角度出發(fā)，這是以低廉的方法***程序的榨取勞動(dòng)力。這也導(dǎo)致Amazon的turn over rate要高于Google和Facebook。

以前作為工程師，也非常喜歡Google對(duì)待工程師的方式，不過(guò)后來(lái)更多的接觸商業(yè)之后覺(jué)得Amazon和Uber這樣的公司，哪怕是Facebook這樣的公司，才更像一個(gè)正常的商業(yè)運(yùn)作的公司，而Google這種過(guò)于理想化的方式更像是在研究所。

那么什么時(shí)候公司需要開(kāi)始重視internal tools呢?按之前Twitter一名工程師分析的結(jié)論(文章暫時(shí)找不到)是當(dāng)公司工程師團(tuán)隊(duì)超過(guò)50人時(shí)，internal tools可以開(kāi)始提升整體團(tuán)隊(duì)的效率和工程質(zhì)量。上面比較的幾家都是工程師非常強(qiáng)的公司，如果你的公司的工程師強(qiáng)不到那種程度， 利用好工具做好持續(xù)發(fā)布更尤為重要。

美國(guó)大部分公司是很支持并愿意去做internal tools的，而國(guó)內(nèi)由于對(duì)工具價(jià)值的理解不夠，或者說(shuō)對(duì)長(zhǎng)期規(guī)劃不足，導(dǎo)致與重視程度也不夠。聽(tīng)說(shuō)滴滴每次發(fā)個(gè)新版還要CEO上臺(tái)全體動(dòng)員，緊張的不行，工程師在發(fā)完新版后天天得加班。由此一例可見(jiàn)差距。