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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

亞馬遜團隊協(xié)作機制

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

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

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

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

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

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

Bezos使用了他的領(lǐng)袖魅力以及他作為CEO的權(quán)利要求亞馬遜改造自己，并要求https://Amazon.com必須使用自己生產(chǎn)的云服務(wù)。其中的改造可能是目前AWS的負責(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要求亞馬遜所有的團隊都要以公開服務(wù)接口的方式，提供數(shù)據(jù)和各種功能。Yegge在發(fā)布的相關(guān)討論帖（發(fā)布在現(xiàn)已棄用的Google+上）中解釋說，這個強制的命令引起了亞馬遜內(nèi)部的巨大波瀾。亞馬遜員工們需要學(xué)習(xí)以及探索各式技術(shù)以及操作問題，例如面向服務(wù)架構(gòu)的錯誤定位，服務(wù)性能控制（任意一個公司內(nèi)部團隊都可能突然發(fā)起大量請求，成為一個潛在的DOS攻擊者），服務(wù)監(jiān)控，服務(wù)發(fā)現(xiàn)等等機制。另外，我們可以了解到這篇文章發(fā)布后，不久就被Yegge刪除并對文章的發(fā)表表示了懊悔。

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

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

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

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

團隊結(jié)構(gòu)

·任何一個負責(zé)某項服務(wù)的團隊都有一系列需要達成的目標和衡量目標達成的收支指標。為了實現(xiàn)這些目標，團隊通常會制定服務(wù)演進圖。

·團隊應(yīng)是自主的，可以做出實現(xiàn)目標所需的任何重要決定。

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

·團隊盡可能地保持小規(guī)模，堅持兩個披薩原則，大約為六個人的團隊。

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

·新團隊通常會來處理緊急的端到端問題。

開發(fā)流程

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

·DevOps模型完全被采用并接受，每個團隊都會為其服務(wù)提供運營支持。

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

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

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

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

協(xié)作實踐

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·隨著服務(wù)的使用越多，服務(wù)的目標適應(yīng)性就越變越好

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

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

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

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

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

·可能需要消耗幾個月請求訪問另一個團隊的源代碼

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原作者：Dan Woods

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

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

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

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

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