AWS的工程師如何開發(fā)和維護(hù)他們的內(nèi)部技術(shù),aws內(nèi)部如何研發(fā)

AWS的工程師如何開發(fā)和維護(hù)他們的內(nèi)部技術(shù)

如今硅谷內(nèi)外各大企業(yè)已經(jīng)尋找到了自己獨(dú)特的快速開發(fā)及部署功能特性的方式。

而在云服務(wù)巨頭亞馬遜的體系中，擁有一個(gè)“Away Teams”的特殊處理機(jī)制，它的核心概念為：接受自身某些弱點(diǎn)以獲取最優(yōu)解。

El Reg曾經(jīng)花了數(shù)月的時(shí)間與該機(jī)制多位相關(guān)人員進(jìn)行探討，現(xiàn)在將正式與大家進(jìn)行分享。由于亞馬遜員工無權(quán)公開討論企業(yè)內(nèi)部事宜，我們的信息源還會(huì)保持匿名的形式。同時(shí)亞馬遜云服務(wù)（Amazon Web Services，下簡(jiǎn)稱為AWS）官方發(fā)言人拒絕對(duì)我們的調(diào)查結(jié)果發(fā)表評(píng)論。

亞馬遜從未像公開其領(lǐng)導(dǎo)力原則一樣支持公開編纂他們的管理體系，因此要捕捉亞馬遜這樣規(guī)模巨頭的方法機(jī)制總會(huì)是一個(gè)挑戰(zhàn)。但以下的描述或許可以為那些尋求大規(guī)模團(tuán)隊(duì)協(xié)作開發(fā)解決方案的人們提供一些新的思路。

當(dāng)前面臨的挑戰(zhàn)

一旦企業(yè)的工程師以及技術(shù)員工人數(shù)達(dá)到數(shù)百或數(shù)千時(shí)，整個(gè)組織將會(huì)超出傳統(tǒng)團(tuán)隊(duì)協(xié)作的負(fù)荷。當(dāng)開發(fā)陷入混亂時(shí)，就需要尋求某種可以支持20，50或者100個(gè)小團(tuán)隊(duì)互相協(xié)作的管理方式。

敏捷（Agile and Scrum）以及DevOps等方法可以支持特定項(xiàng)目從概念階段到交付階段中的持續(xù)演進(jìn)，但這些方法并不會(huì)優(yōu)化現(xiàn)有各團(tuán)隊(duì)間的協(xié)作方式。

為平臺(tái)或者應(yīng)用程序創(chuàng)建完整且連貫的解決方案是較為基礎(chǔ)的需求，即便是組織一個(gè)專業(yè)團(tuán)隊(duì)來進(jìn)行實(shí)施也是如此。所以無論最初對(duì)團(tuán)隊(duì)協(xié)作考慮的多么全面，后期總會(huì)需要進(jìn)行一定程度的調(diào)整。

企業(yè)中各個(gè)團(tuán)隊(duì)都是為了某種特定目標(biāo)而設(shè)立的。甚至各團(tuán)隊(duì)還負(fù)責(zé)各自獨(dú)立的盈利或是虧損，獨(dú)立的目標(biāo)或是關(guān)鍵指標(biāo)（例如受到Intel企業(yè)使用經(jīng)歷的啟發(fā)而采用OKR模式的Google）。但在現(xiàn)今的企業(yè)平臺(tái)中，幾乎所有應(yīng)用于整個(gè)企業(yè)的服務(wù)相互間都有著密切關(guān)聯(lián)。

當(dāng)有人向你的團(tuán)隊(duì)提出挑戰(zhàn)，需要在你的團(tuán)隊(duì)正在交付的服務(wù)中發(fā)起一個(gè)新的請(qǐng)求，例如新功能，修復(fù)錯(cuò)誤或是進(jìn)行優(yōu)化性能，你會(huì)怎么處理？你會(huì)給他們權(quán)限訪問你的源代碼嗎？如果新功能能獲得用戶或是客戶的歡迎，你會(huì)將新功能的后期維護(hù)保留在你的團(tuán)隊(duì)內(nèi)部，或是將其交給負(fù)責(zé)交付的團(tuán)隊(duì)？如果你的團(tuán)隊(duì)可以添加一項(xiàng)能幫助其他團(tuán)隊(duì)增加收入的功能，那么你應(yīng)該在完成已規(guī)劃好的功能前添加這項(xiàng)功能嗎？

如果有任何人覺得以上問題可以被輕松解決，并且企業(yè)內(nèi)部每人都可以完成對(duì)的事，那么他/她一定沒有在大型組織中真正工作過。

當(dāng)然，良好的管理層應(yīng)協(xié)調(diào)團(tuán)隊(duì)，幫助他們更好地進(jìn)行協(xié)同工作。但尋求管理層的協(xié)助總會(huì)在某種程度上減慢工作效率。另外必須明確的是：管理層也并不總能做出正確的決定。

亞馬遜團(tuán)隊(duì)協(xié)作機(jī)制

亞馬遜自成立初期就面臨著以上提到的這些問題。他們創(chuàng)建了一個(gè)基于面向服務(wù)架構(gòu)(SOA)的系統(tǒng)（增添了某些特有的創(chuàng)新點(diǎn)以適配亞馬遜這樣一個(gè)互聯(lián)網(wǎng)公司的管理模式）。

2017年在舊金山舉辦的全球人工智能大會(huì)中，Andrew Ng（斯坦福研究員，企業(yè)家以及AI專家）曾發(fā)表過一個(gè)演講，其中解釋道：真正的互聯(lián)網(wǎng)公司并不是一個(gè)擁有線上網(wǎng)站的購(gòu)物中心，而是一個(gè)能夠響應(yīng)快速迭代，擁有A/B測(cè)試以及自上而下設(shè)計(jì)方法的公司。

亞馬遜并沒有重新發(fā)明一個(gè)新的模式，它只是正在研究許多公司面臨的相同問題，似乎也確實(shí)找到了解決問題的方法。亞馬遜創(chuàng)建了一個(gè)優(yōu)化內(nèi)部團(tuán)隊(duì)協(xié)作的機(jī)制，并強(qiáng)制下達(dá)指令要求內(nèi)部團(tuán)隊(duì)構(gòu)建各自獨(dú)立服務(wù)接口，這些服務(wù)必須基于A/B測(cè)試以及自上而下的設(shè)計(jì)方法。這樣的機(jī)制促成了企業(yè)內(nèi)部團(tuán)隊(duì)協(xié)作的一個(gè)新概念：Away Teams。

事實(shí)證明亞馬遜體系，尤其是Away Teams，與技術(shù)哲學(xué)家的研究結(jié)果一致。例如Ray Kurzweill對(duì)近年來技術(shù)指數(shù)級(jí)發(fā)展的分析，以及麻省理工學(xué)院教授Eric Von Hippel關(guān)于用戶驅(qū)動(dòng)創(chuàng)新能力的文章。

來自Yegge的討論：亞馬遜面向服務(wù)架構(gòu)的轉(zhuǎn)變

根據(jù)我們的了解來看，亞馬遜的CEO杰夫貝索斯（Jeff Bezos）擁有著非常強(qiáng)勢(shì)的管理風(fēng)格。從公司執(zhí)行層面來探討的話，這樣的管理風(fēng)格的確是企業(yè)變革的必要因素之一。

Bezos使用了他的領(lǐng)袖魅力以及他作為CEO的權(quán)利要求亞馬遜改造自己，并要求https://Amazon.com必須使用自己生產(chǎn)的云服務(wù)。其中的改造可能是目前AWS的負(fù)責(zé)人Andy Jassy提到的全面移除Oracle技術(shù)（Amazon completely off Oracle）。但我最喜歡的改造是在“Yegge Rant”中敘述的亞馬遜向面向服務(wù)架構(gòu)的轉(zhuǎn)變。

Steve Yegge曾經(jīng)是亞馬遜的員工，工作了幾年后轉(zhuǎn)為替Google工作。2002年左右，Bezos要求亞馬遜所有的團(tuán)隊(duì)都要以公開服務(wù)接口的方式，提供數(shù)據(jù)和各種功能。Yegge在發(fā)布的相關(guān)討論帖（發(fā)布在現(xiàn)已棄用的Google+上）中解釋說，這個(gè)強(qiáng)制的命令引起了亞馬遜內(nèi)部的巨大波瀾。亞馬遜員工們需要學(xué)習(xí)以及探索各式技術(shù)以及操作問題，例如面向服務(wù)架構(gòu)的錯(cuò)誤定位，服務(wù)性能控制（任意一個(gè)公司內(nèi)部團(tuán)隊(duì)都可能突然發(fā)起大量請(qǐng)求，成為一個(gè)潛在的DOS攻擊者），服務(wù)監(jiān)控，服務(wù)發(fā)現(xiàn)等等機(jī)制。另外，我們可以了解到這篇文章發(fā)布后，不久就被Yegge刪除并對(duì)文章的發(fā)表表示了懊悔。

這樣的強(qiáng)制命令就按照Bezos的計(jì)劃順利進(jìn)行下去了，并由此圍繞著服務(wù)架構(gòu)本身一些有趣的原則創(chuàng)建出了一種全新的技術(shù)文化。其中一個(gè)可能的（我們還沒有獲取到多個(gè)渠道信息可以支持交差驗(yàn)證）原則是：一旦某個(gè)團(tuán)隊(duì)成為了某個(gè)特定API唯一的用戶，他們就會(huì)成為該服務(wù)的所有者，即使他們并不是這個(gè)服務(wù)的開發(fā)者。

但是，對(duì)于一個(gè)成熟的面向服務(wù)的體系架構(gòu)而言，單獨(dú)的某個(gè)技術(shù)，工具或者操作并不能解決內(nèi)部協(xié)作的問題。這是亞馬遜開辟新天地的地方，尤其是Away Teams的概念。我們好像沒有聽過說亞馬遜將其正式定義為該模式的名稱，但用它來解釋面向服務(wù)架構(gòu)似乎很合適。

亞馬遜面向服務(wù)架構(gòu)的協(xié)作機(jī)制

以下是我們對(duì)亞馬遜面向服務(wù)架構(gòu)的協(xié)作方式的研究：

團(tuán)隊(duì)結(jié)構(gòu)

·任何一個(gè)負(fù)責(zé)某項(xiàng)服務(wù)的團(tuán)隊(duì)都有一系列需要達(dá)成的目標(biāo)和衡量目標(biāo)達(dá)成的收支指標(biāo)。為了實(shí)現(xiàn)這些目標(biāo)，團(tuán)隊(duì)通常會(huì)制定服務(wù)演進(jìn)圖。

·團(tuán)隊(duì)?wèi)?yīng)是自主的，可以做出實(shí)現(xiàn)目標(biāo)所需的任何重要決定。

·“對(duì)客戶的價(jià)值”是每個(gè)團(tuán)隊(duì)的使命的一部分。使用模擬發(fā)布方式(Mock)保證開發(fā)人員牢記最終用戶的需求。

·團(tuán)隊(duì)盡可能地保持小規(guī)模，堅(jiān)持兩個(gè)披薩原則，大約為六個(gè)人的團(tuán)隊(duì)。

·服務(wù)可以被重構(gòu)，也可以將其拆分為新服務(wù)并分配給一個(gè)新的團(tuán)隊(duì)。沒有工作量的團(tuán)隊(duì)將被叫停，他們的技術(shù)產(chǎn)出將由其他團(tuán)隊(duì)接手或被廢棄。

·新團(tuán)隊(duì)通常會(huì)來處理緊急的端到端問題。

開發(fā)流程

·團(tuán)隊(duì)使用一組共享的開發(fā)工具或共享服務(wù)進(jìn)行源代碼管理以及開發(fā)流水線管理。其中有許多常用的工具和服務(wù)，每個(gè)團(tuán)隊(duì)都可以自主選擇來快速完成工作，不做硬性要求。盡管如此，在某些時(shí)候還是需要解釋團(tuán)隊(duì)選擇特殊工具的原因。

·DevOps模型完全被采用并接受，每個(gè)團(tuán)隊(duì)都會(huì)為其服務(wù)提供運(yùn)營(yíng)支持。

·訪問大多數(shù)源代碼并不難，通常一團(tuán)隊(duì)在沒有事先約束的情況下，可以很容易地看到另一團(tuán)隊(duì)的源代碼。然而還是難免會(huì)有一些例外的情況。

·A/B測(cè)試和詳細(xì)監(jiān)控普遍用于站點(diǎn)和基礎(chǔ)設(shè)施的各個(gè)方面。測(cè)試由一個(gè)基于WebLab服務(wù)的團(tuán)隊(duì)提供支持，該團(tuán)隊(duì)負(fù)責(zé)培訓(xùn)員工如何使測(cè)試結(jié)果更易于統(tǒng)計(jì)。

·團(tuán)隊(duì)通常不必?fù)?dān)心內(nèi)部資源使用率。不會(huì)有單獨(dú)的內(nèi)部統(tǒng)計(jì)維度來跟蹤資源的使用情況。服務(wù)內(nèi)部使用率會(huì)作為預(yù)算流程的一部分進(jìn)行統(tǒng)計(jì)，并由財(cái)務(wù)團(tuán)隊(duì)進(jìn)行監(jiān)控。他們會(huì)定期與團(tuán)隊(duì)會(huì)面，討論服務(wù)的任何異常增長(zhǎng)并鼓勵(lì)團(tuán)隊(duì)對(duì)其進(jìn)行優(yōu)化。

·減少技術(shù)債并不是做任何事情的好理由，除非它對(duì)實(shí)現(xiàn)團(tuán)隊(duì)目標(biāo)產(chǎn)生影響。

協(xié)作實(shí)踐

·對(duì)某團(tuán)隊(duì)所有服務(wù)的修改需求可能會(huì)由另一個(gè)團(tuán)隊(duì)，也就是所謂的Away Team進(jìn)行實(shí)施。該團(tuán)隊(duì)會(huì)根據(jù)已建立的工程標(biāo)準(zhǔn)處理服務(wù)所有者的代碼，以便根據(jù)工程標(biāo)準(zhǔn)添加所需的代碼。接下來Away Team會(huì)將該代碼維持在良好可維護(hù)的狀態(tài)，并由該服務(wù)所有者所在團(tuán)隊(duì)進(jìn)行后期維護(hù)，并在需要時(shí)提供幫助。

·如果請(qǐng)求者沒有能力基于服務(wù)的演進(jìn)規(guī)劃來進(jìn)行服務(wù)修改需求的實(shí)施，而導(dǎo)致了無法采用Away Team這樣的模式。這通常是由于該服務(wù)的演進(jìn)規(guī)劃不夠全面，因此為了容納新的需求則需要重新調(diào)整現(xiàn)有的服務(wù)演進(jìn)規(guī)劃。

·如果使用Away Team模式對(duì)服務(wù)進(jìn)行擴(kuò)展時(shí)，由于某種原因無法繼續(xù)往下進(jìn)行。那么此時(shí)可以進(jìn)行復(fù)制原有服務(wù)或創(chuàng)建一個(gè)新的服務(wù)等能夠推進(jìn)你的進(jìn)度所需的任何操作。只要能夠幫助進(jìn)度的推進(jìn)，就不必?fù)?dān)心平臺(tái)內(nèi)部各服務(wù)間的重復(fù)。

·創(chuàng)建服務(wù)的團(tuán)隊(duì)在做出對(duì)其他服務(wù)產(chǎn)生積極影響的事情時(shí)會(huì)獲得信譽(yù)以及管理層的認(rèn)可，這樣的影響通常是直接影響損益的。

·“Bar Raisers”是一種作為獨(dú)立專家角色的亞馬遜員工。他們?nèi)粘?huì)在其他團(tuán)隊(duì)進(jìn)行工作，但會(huì)對(duì)負(fù)責(zé)的服務(wù)站在相對(duì)獨(dú)立的角度上進(jìn)行關(guān)鍵決策，例如招聘，宣傳，設(shè)計(jì)、客戶體驗(yàn)，架構(gòu)，A/B測(cè)試等方面。這可能違背了對(duì)于Bar Raisers這個(gè)角色的初始定義，但在這樣的操作模式下，問題會(huì)很容易被注意到并且易于更高級(jí)別的管理層進(jìn)行管理。

這些關(guān)鍵原則被運(yùn)用在了亞馬遜的各個(gè)不同階段：

亞馬遜最古老的原創(chuàng)技術(shù)通常被稱為L(zhǎng)egacy平臺(tái)，之后誕生了有一個(gè)名為MAWS的非公開內(nèi)部服務(wù)平臺(tái)，我們耳熟能詳?shù)腁WS是它最新的公開形式。但在這個(gè)演進(jìn)過程中也可能還有其他我們未曾聽說過的平臺(tái)。

例如，https://Amazon.com或Kindle等舊產(chǎn)品可能會(huì)使用三個(gè)平臺(tái)中的服務(wù)。Alexa和Echo等新產(chǎn)品則可能更傾向于在AWS上使用更多公共服務(wù)。

從Legacy到MAWS甚至是到AWS的過程中，開發(fā)工具已進(jìn)行了多代演進(jìn)，所有這些演進(jìn)都需要數(shù)年才能完成。

AWS以外的團(tuán)隊(duì)不太會(huì)在單個(gè)服務(wù)或是團(tuán)隊(duì)層面有直接的損益產(chǎn)生。所以一般而言，AWS團(tuán)隊(duì)對(duì)單個(gè)服務(wù)，團(tuán)隊(duì)以及損益之間的邊界擁有著最多的經(jīng)驗(yàn)。

這是在與組織的不同層面和不同觀點(diǎn)的許多人訪談后得出的結(jié)論，可以讓我們理清自己的思路。但找到了解整個(gè)情況和詳細(xì)歷史的人并不是一件容易的事，就像亞馬遜的公關(guān)人員總是說：我們隨時(shí)準(zhǔn)備與亞馬遜首席技術(shù)官Werner Vogels坐下來，詳細(xì)聊一聊。

Kurzweil和Von Hippel介紹面向服務(wù)架構(gòu)的協(xié)作

亞馬遜的模式鼓勵(lì)團(tuán)隊(duì)對(duì)接團(tuán)隊(duì)，服務(wù)對(duì)接服務(wù)這樣直接的協(xié)作方式，以便在每個(gè)團(tuán)隊(duì)在需要對(duì)某個(gè)服務(wù)進(jìn)行優(yōu)化時(shí)，盡可能多地取得進(jìn)展。

當(dāng)記者開始了解亞馬遜的模型時(shí)，我意識(shí)到面向服務(wù)架構(gòu)的協(xié)作結(jié)構(gòu)使用了兩位著名研究人員記錄在冊(cè)的技術(shù)優(yōu)化方案。

麻省理工學(xué)院教授Eric Von Hippel對(duì)用戶驅(qū)動(dòng)創(chuàng)新的研究表明，當(dāng)用戶直接獲得創(chuàng)建解決方案的手段時(shí)，跟高幾率會(huì)產(chǎn)生巨大的創(chuàng)新。否則必須將一系列需求相關(guān)的“粘性信息”呈現(xiàn)在需求文檔中或從用戶傳遞給開發(fā)者，這非常困難并很大幾率無法完成。但如果用戶和開發(fā)者是同一個(gè)人或處于同一個(gè)團(tuán)隊(duì)時(shí)，就不必執(zhí)行此步驟，這樣的結(jié)果反而會(huì)更好。亞馬遜的Away Teams也秉持著這一概念，并允許團(tuán)隊(duì)創(chuàng)建具有高度適應(yīng)性的服務(wù)。

Ray Kurzweil在技術(shù)指數(shù)級(jí)發(fā)展的分析中提供了另一個(gè)思路，通過它可以解釋亞馬遜模型的內(nèi)涵。記者總結(jié)了Kurzweil在技術(shù)杠桿研究使命中的模型，他論文的觀點(diǎn)如下：

·起初，任何技術(shù)領(lǐng)域的進(jìn)展看似非常緩慢，這是由于當(dāng)時(shí)處在正在開發(fā)基本服務(wù)的階段

·但是接下來到了使用簡(jiǎn)單的服務(wù)構(gòu)建更復(fù)雜的服務(wù)。長(zhǎng)此以往推進(jìn)了開發(fā)的速度

·與此同時(shí)，資金逐漸大量投入到了那些具有優(yōu)勢(shì)的服務(wù)

·隨著服務(wù)的使用越多，服務(wù)的目標(biāo)適應(yīng)性就越變?cè)胶?/p>

Kurzweil的研究表明，在許多不同的技術(shù)領(lǐng)域，這種模式總是貫穿整個(gè)技術(shù)發(fā)展史的。從我的角度上看，亞馬遜仍然處于這個(gè)模型指數(shù)曲線中的早期階段，這是由亞馬遜內(nèi)外部對(duì)服務(wù)的使用程度來決定的。

如果沒有足夠的服務(wù)數(shù)據(jù)來推動(dòng)資金和優(yōu)化，亞馬遜的模型將無法運(yùn)作，端到端的實(shí)施團(tuán)隊(duì)以及Away Team在識(shí)別新服務(wù)和改善現(xiàn)有服務(wù)的適應(yīng)性方面發(fā)揮著至關(guān)重要的作用。

目前，AWS專注于創(chuàng)建更高層次的通用型服務(wù)，這些服務(wù)適合用于各類通用平臺(tái)的軟件開發(fā)。例如亞馬遜自身（Amazon.com，Alexa，Kindle等）以及正在構(gòu)建各種產(chǎn)品和IT基礎(chǔ)架構(gòu)的AWS客戶。

亞馬遜面向服務(wù)協(xié)作的特征

亞馬遜的協(xié)作原則與其他大型組織不同，因此避免了其他大型組織經(jīng)常出現(xiàn)的一些問題，如：

·可能需要消耗幾個(gè)月請(qǐng)求訪問另一個(gè)團(tuán)隊(duì)的源代碼

·直接產(chǎn)生收益的服務(wù)或服務(wù)的關(guān)鍵決策權(quán)僅由一個(gè)固定的團(tuán)隊(duì)負(fù)責(zé)，而不會(huì)將其傳遞給服務(wù)所有者團(tuán)隊(duì)。

·讓管理層注意到重構(gòu)某些演進(jìn)需求可能需要耗費(fèi)數(shù)月時(shí)間。通常這樣的關(guān)注也不會(huì)促成有效的團(tuán)隊(duì)合作

·在調(diào)整激勵(lì)措施之前，團(tuán)隊(duì)可能會(huì)將對(duì)向他人提供幫助的優(yōu)先級(jí)降低

·團(tuán)隊(duì)內(nèi)部?jī)?yōu)化的優(yōu)先級(jí)很容易高于整體業(yè)務(wù)轉(zhuǎn)型

借助亞馬遜的面向服務(wù)的協(xié)作系統(tǒng)，大部分問題永遠(yuǎn)不會(huì)發(fā)生，有些問題則會(huì)減小發(fā)生頻率。如果說任何像亞馬遜一樣規(guī)模的組織都沒有政治因素的影響，那就太天真了。但這些原則鼓勵(lì)大家像這個(gè)最優(yōu)方案靠攏，就像鼓勵(lì)擁抱用戶價(jià)值一樣。

以下是亞馬遜體系內(nèi)的一些優(yōu)點(diǎn)：

·Away Team模型以及訪問源代碼的便捷性意味著可以輕松跨越服務(wù)邊界，以增強(qiáng)整個(gè)平臺(tái)中服務(wù)的易用性。團(tuán)隊(duì)可以輕易地完成通過改進(jìn)其他服務(wù)來完成自己團(tuán)隊(duì)服務(wù)的優(yōu)化

·解決協(xié)作問題和重構(gòu)服務(wù)演進(jìn)方案所需的時(shí)間成本大大減少。在亞馬遜的模型中，演進(jìn)方案有時(shí)需要重新考慮，但由于有Away Team的協(xié)助，這些事件會(huì)被弱化

·團(tuán)隊(duì)自治過程中還減少了對(duì)管理輸入上下文的需要。這樣的政策是盡一切可能專注于為客戶提供價(jià)值，而不是擔(dān)心服務(wù)重復(fù)或偏離標(biāo)準(zhǔn)。在開發(fā)完美的共享服務(wù)時(shí)不需要等待，在使用完美的共享服務(wù)的時(shí)候不會(huì)有任何阻力。

·服務(wù)轉(zhuǎn)讓定價(jià)制度的剔除意味著團(tuán)隊(duì)更加致力于提供更好的服務(wù)，而不是始終追求效益最大化。資源的使用情況由財(cái)務(wù)團(tuán)隊(duì)跟蹤，他們會(huì)分配請(qǐng)求并且對(duì)資源調(diào)配進(jìn)行優(yōu)化

·專注于數(shù)據(jù)減少了主觀判斷。我們不需要進(jìn)行爭(zhēng)論，任何一方都持有著各自的觀點(diǎn)。我們最終只需要關(guān)注數(shù)據(jù)，因?yàn)閿?shù)據(jù)總是正確的

·凸顯了跨團(tuán)隊(duì)審查的優(yōu)點(diǎn)。團(tuán)隊(duì)的代碼將是可見的，所有的決定會(huì)受Bar Raisers監(jiān)督，而Away Team編寫的代碼必須被其他的團(tuán)隊(duì)接受。如果馬虎對(duì)待代碼，那么它將會(huì)被公開。

·隨著時(shí)間的推移，公開版本的AWS服務(wù)往往會(huì)成為首選。顧客們對(duì)亞馬遜產(chǎn)品的迷戀加速了亞馬遜持續(xù)的優(yōu)化自身內(nèi)部服務(wù)，促使公開版本的AWS服務(wù)通常比內(nèi)部服務(wù)擁有更高的質(zhì)量和性能

亞馬遜模型的缺點(diǎn)是架構(gòu)可能包含重復(fù)的服務(wù)或是同一服務(wù)的多個(gè)版本。有這樣一個(gè)座右銘：“有兩個(gè)好過一個(gè)都沒有”，意思是做你需要做的事情，另一個(gè)平衡的座右銘是“一個(gè)都沒有好過有五個(gè)”，所以每當(dāng)發(fā)現(xiàn)有些服務(wù)并不是完全適合的時(shí)候，也不要忘掉它而去創(chuàng)造新的服務(wù)。

更大的一個(gè)擔(dān)憂是產(chǎn)品凝聚力和一致性可能會(huì)受到影響。這位作者還沒有花時(shí)間在AWS之間挖掘各API模式之間的差異，我也無法對(duì)內(nèi)部API進(jìn)行這樣的操作，但我們被告知這確實(shí)是存在的隱患。

當(dāng)然，我們提出的觀點(diǎn)代表了理論，而不是從實(shí)踐中獲取經(jīng)驗(yàn)教訓(xùn)。正如在亞馬遜體系中受挫并且在五個(gè)月后離開亞馬遜的人在本博客中所述，Away Team模型，Bar Raisers和標(biāo)準(zhǔn)開發(fā)環(huán)境都可能出錯(cuò)并導(dǎo)致問題。亞馬遜是一個(gè)高壓且競(jìng)爭(zhēng)非常激烈的環(huán)境，這就導(dǎo)致了他們的員工和經(jīng)理都很難在像Glassdoor這樣的網(wǎng)站中公開發(fā)表自己的看法。

“商業(yè)總是在發(fā)展迅速，我們必須加快行動(dòng)”。這是Bezos一貫的口頭禪。面向服務(wù)架構(gòu)的協(xié)作模型基于Kurzweil指數(shù)理論以及減少Von Hippel提到的粘性信息進(jìn)行著短期以及長(zhǎng)期的優(yōu)化。最后，亞馬遜很樂意使用面向服務(wù)架構(gòu)的協(xié)作來確保AWS和內(nèi)部服務(wù)快速增長(zhǎng)，但表面看起來確實(shí)是激進(jìn)了一些。

原作者：Dan Woods

原文鏈接：https://www.theregister.co.uk/2019/05/14/amazonsawayteams/

譯者：趙越 ThoughtWorks咨詢師，李之琳 ThoughtWorks業(yè)務(wù)分析師

文章推薦
Google Play博弈類美國(guó)暢銷榜TOP5游戲盤點(diǎn)｜出海榜單數(shù)據(jù)洞察,textnow和google voice哪個(gè)好用
B2B如何巧妙使用YouTube視頻樹立品牌贏取海外客戶青睞,外貿(mào)youtube視頻推廣的常見錯(cuò)誤
GPU云服務(wù)器產(chǎn)品概述,gpu云服務(wù)
Google 的廣告計(jì)劃與搜索結(jié)果有什么聯(lián)系,google play 服務(wù)是干什么的

點(diǎn)擊咨詢現(xiàn)在有哪些新興平臺(tái)值得關(guān)注 >>>

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。