AWS的工程師如何開發和維護他們的內部技術,aws內部如何研發

AWS的工程師如何開發和維護他們的內部技術

如今硅谷內外各大企業已經尋找到了自己獨特的快速開發及部署功能特性的方式。

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

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

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

當前面臨的挑戰

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

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

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

企業中各個團隊都是為了某種特定目標而設立的。甚至各團隊還負責各自獨立的盈利或是虧損，獨立的目標或是關鍵指標（例如受到Intel企業使用經歷的啟發而采用OKR模式的Google）。但在現今的企業平臺中，幾乎所有應用于整個企業的服務相互間都有著密切關聯。

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

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

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

亞馬遜團隊協作機制

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

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

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

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

來自Yegge的討論：亞馬遜面向服務架構的轉變

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

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

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

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

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

亞馬遜面向服務架構的協作機制

以下是我們對亞馬遜面向服務架構的協作方式的研究：

團隊結構

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

·團隊應是自主的，可以做出實現目標所需的任何重要決定。

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

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

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

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

開發流程

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

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

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

·A/B測試和詳細監控普遍用于站點和基礎設施的各個方面。測試由一個基于WebLab服務的團隊提供支持，該團隊負責培訓員工如何使測試結果更易于統計。

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

·減少技術債并不是做任何事情的好理由，除非它對實現團隊目標產生影響。

協作實踐

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

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

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

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

·“Bar Raisers”是一種作為獨立專家角色的亞馬遜員工。他們日常會在其他團隊進行工作，但會對負責的服務站在相對獨立的角度上進行關鍵決策，例如招聘，宣傳，設計、客戶體驗，架構，A/B測試等方面。這可能違背了對于Bar Raisers這個角色的初始定義，但在這樣的操作模式下，問題會很容易被注意到并且易于更高級別的管理層進行管理。

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

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

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

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

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

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

Kurzweil和Von Hippel介紹面向服務架構的協作

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

當記者開始了解亞馬遜的模型時，我意識到面向服務架構的協作結構使用了兩位著名研究人員記錄在冊的技術優化方案。

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

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

·起初，任何技術領域的進展看似非常緩慢，這是由于當時處在正在開發基本服務的階段

·但是接下來到了使用簡單的服務構建更復雜的服務。長此以往推進了開發的速度

·與此同時，資金逐漸大量投入到了那些具有優勢的服務

·隨著服務的使用越多，服務的目標適應性就越變越好

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

如果沒有足夠的服務數據來推動資金和優化，亞馬遜的模型將無法運作，端到端的實施團隊以及Away Team在識別新服務和改善現有服務的適應性方面發揮著至關重要的作用。

目前，AWS專注于創建更高層次的通用型服務，這些服務適合用于各類通用平臺的軟件開發。例如亞馬遜自身（Amazon.com，Alexa，Kindle等）以及正在構建各種產品和IT基礎架構的AWS客戶。

亞馬遜面向服務協作的特征

亞馬遜的協作原則與其他大型組織不同，因此避免了其他大型組織經常出現的一些問題，如：

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

·直接產生收益的服務或服務的關鍵決策權僅由一個固定的團隊負責，而不會將其傳遞給服務所有者團隊。

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

·在調整激勵措施之前，團隊可能會將對向他人提供幫助的優先級降低

·團隊內部優化的優先級很容易高于整體業務轉型

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

以下是亞馬遜體系內的一些優點：

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

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

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

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

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

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

·隨著時間的推移，公開版本的AWS服務往往會成為首選。顧客們對亞馬遜產品的迷戀加速了亞馬遜持續的優化自身內部服務，促使公開版本的AWS服務通常比內部服務擁有更高的質量和性能

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

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

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

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

原作者：Dan Woods

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

譯者：趙越 ThoughtWorks咨詢師，李之琳 ThoughtWorks業務分析師

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

點擊咨詢現在有哪些新興平臺值得關注 >>>

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