「不設守門人才能激發更多創新」——亞馬遜CTO：打造AWS的10年裡學到的10個經驗

Amazon的執行長Jeff Bezos前幾天在致股東的信中表示，亞馬遜雲端服務AWS目前已經有超過100萬的用戶，2016年的營收也將突破100億美元。

Amazon的AWS服務是在2006年3月推出，距今已有整整10年的時間了。AWS最早推出的雲端服務是簡易儲存服務Simple Storage Service（S3），後來又陸續推出了Amazon彈性雲端運算Elastic Compute Cloud（EC2）、亞馬遜簡易資料庫（Amazon SimpleDB）、Amazon Simple Queue Service（SQS）以及Amazon CloudFront等雲端服務。

目前，成千上萬的新創公司在AWS的數據中心和服務基礎上構建了自己的線上業務。不僅大量小公司仰賴於Amazon AWS 的雲端運算服務，很多諸如Adobe、GE、Netflix和Pinterest這樣的大公司也都在使用Amazon的AWS服務。

在Amazon的AWS服務上線10週年之際，推動AWS服務發展的核心人物、Amazon的CTO Werner Vogels在本文中總結和分享了他在AWS上線營運10年過程中所學到的10條經驗，希望對大家有所啟發和借鑒。

圖說明

從第一天開始，就要打造一個可以持續演化的系統

從第一天開始，我們就非常清楚地認識到，我們所開發的這套軟體是一個一定需要持續改進的軟體，現在開發的軟體可能並不是一年以後運行。我們當時是這樣預期的，隨著數量的增加，我們需要重新檢視和修改已有的架構，確保能夠解決擴展性的問題。

然而，由於全球很多公司都依賴著我們平台所提供的7 x 24 小時全天候不間斷的服務，因此我們無法採用過去常用的停機維護以進行系統升級的方式來達到這一個目標。

因此，我們從一開始就需要打造一個在引入新軟體構件時不會迫使服務暫停的架構。Amazon的一位非常出色的工程師Marvin Theimer有一次曾開玩笑說，Amazon S3服務的持續演進和下面這個場景非常像：

我們最一開始開的是一架單引擎的賽斯納飛機，在開了一段時間後升級成了一架波音737飛機，之後又換成了波音747飛機編隊，我們現在開的則更像是由空中巨無霸空中巴士A380 組成的一支大型飛機編隊。從最開始到現在，我們都是透過空中加油的方式確保飛機的正常飛行，同時，我們直接將AWS的用戶在空中從一架舊飛機上轉移到另一架新飛機上面，而AWS用戶在這整個過程中甚至沒有意識到他們被悄悄地轉移到另一架更先進的飛機裡了。

為意料之外的失敗和問題做好充分準備

失效是難以避免的的，隨著時間的推移，任何東西都有可能會出現這樣的問題：從路由器到硬碟，從操作系統到儲存單元損壞的TCP數據包，從瞬間誤差到永久失效等等。不管是使用高品質的硬體還是低成本的組件，這些問題都將無可避免地出現。

隨著服務規模的擴大，明白這點將變得越來越重要：舉個例子，當Amazon S3的服務處理數億的儲存交易時，即使是可能性最小的錯誤也會變成現實。這些失敗和出問題的場景中的一部分是可以被事先預想的，然而很多問題在設計和構建過程中是無法被事先考慮到的。

所以說，我們需要打造一個將失敗和故障視為自然會發生的系統，即使我們不知道故障和問題可能會是什麼。這個系統需要在即使「屋裡已經失火」的情況下依然能夠維持正常運行的狀態。其中很重要的一點是，要能夠在不讓整個系統當機的情況下就能處理好受到影響的組件。我們現在已經掌握了一套能夠控制故障發生後所波及範圍的基本技術，這樣一旦出現任何問題，系統的整體健康狀況是可以繼續維持、不會出現服務停機的狀況。

要提供基元，而非僅提供一個大而全的統一框架

很快，我們就發現很多用戶喜歡在AWS提供的服務上持續建立自己的業務。在離開了傳統舊世界裡備受束縛的IT硬體和數據中心之後，他們開始以一種全新有趣的使用方式來開發自己的系統。正因為如此，我們就需要有足夠地靈活性去滿足用戶各種不同的需求。

我們提供的最重要的機制之一是為用戶提供一系列功能基元和工具，他們可以選擇自己喜歡的方式來使用AWS服務，而不是提供一個強迫用戶必須使用的包羅一切的大而全的統一框架。這個方法讓我們的用戶獲得了巨大的成功，甚至AWS後來提供的很多服務都使用了同樣類似的機制，而這個服務機制是很多用戶都已經習慣的。

此外，在用戶真正開始使用AWS來開發產品和服務之前，我們很難去預測用戶的優先順位是什麼，意識到這一點非常重要。這也是為什麼我們後來推出新服務一開始都只配有最小的功能集，這樣一來，我們可以透過用戶的回饋來對擴展我們服務的新功能，以更好地滿足用戶的需求。

自動化是關鍵

開發一個需要去檢測維護的軟體服務和開發一個最終交付給客戶的軟體是有著非常大的區別的。為了滿足用戶對產品可靠性、性能以及可擴展性等方面的期待和需求，管理AWS這樣的規模化系統是需要一種不同的心態和方法的。

要想實現上述目標，一個關鍵的機制就是盡可能地將管理工作全部自動化，這樣就可以避免手動操作可能帶來的任何容易產生的誤差。為了實現這一目標，我們需要打造一套可以控制操作中各項主要功能的管理 API。此外，AWS 也能夠幫助用戶同樣實現這個目標。通過把你的應用分解成一個個基本的構建模塊，每個模塊都有自己的管理 API，這樣你就可以利用自動化規則進行大規模可靠、可預測的的運營。自動化工作究竟做得如何，有個很簡單的檢驗方法就是看你是不是還需要 SSH 登陸到服務器進行操作，如果需要的話，說明你的自動化的工作還有待加強。

API是永恆的，一旦上線便無法變更

其實之前在Amazon零售業務中已經吸取了類似的經驗和教訓了。然而對於AWS這種以API為中心的服務而言，「API是永恆的」這個原則顯然就變得更為重要了。一旦用戶開始使用我們的API開發他們的應用和系統後，我們就不可能再去對那些這些API做任何變動了，因為變動API會嚴重影響到用戶的業務。我們已經意識到，設計API是一個非常重要的任務，必須要一次性成功。

關注和了解自己的資源使用情況

在你為一項服務制定合適的計費模式的時候，一定要確保你有一份關於這項服務的各項成本和運營費用的詳細數據，當你運營一個業務量大、利潤率低的業務時更需要如此。AWS作為一個服務提供商，我們必須對服務成本非常瞭如指掌，這樣我們就能清楚地了解基於這一成本，我們是否能夠承擔得起為用戶提供這項服務。此外，我們還可以藉此找到那些可以通過提高運營效率而降低成本的一些方法，並通過這種方法進一步降低服務價格，從而讓用戶從中受益。

舉例說明一下，在我們發展早期，我們一開始對Amazon S3服務所需要的資源成本其實並不是非常清楚。我們當時是這樣設想的，儲存和頻寬成本是我們首先需要考慮的收費點。不過後來在Amazon S3運行了一段時間之後我們開始意識到，請求數量其實和存儲與帶寬是一樣重要的。如果有用戶有大量的小文件，在這種情況下，即使這個用戶請求上百萬次，其實都不會佔用太多的儲存和頻寬資源，佔最多資源的其實是請求數量。因此我們必須對收費模型進行調整，將請求數量也放進了資源成本中去，這樣才能確保AWS有一個可以持續發展的業務。

從一開始就要將安全問題考慮進去

保護用戶的安全是一個你永遠都要排在第一位的優先級問題，在AWS當然也是這樣，這無論從營運的角度來看，還是從工具和機制的角度來看都是如此。因此，我們在安全方面的投入將一直是我們的第一大投入。

我們很快就學會的一個方法是，為了打造更加安全的服務，這就要求我們在服務設計的最初階段就將安全問題考慮進去。安全團隊的工作不是在一項服務開發完成之後再去檢查驗證它的安全性問題到底如何。安全團隊應該在開發工作開始後的第一天就參與到產品開發中去，確保安全問題在剛開始開發時就被考慮進去，而且貫穿於整個項目的開發的全過程。在任何涉及安全的問題時，你都不能做任何妥協。

數據加密太重要

數據加密是讓用戶確保他們對誰能獲取自己的數據擁有絕對控制權的一個關鍵機制。在10年以前，用於數據加密的相關的工具和服務的使用體驗非常差，直到AWS 開始運營後的最初幾年裡，我們慢慢知道瞭如何最好地將數據加密功能整合進我們的服務裡。

Amazon S3最初提供的是服務器端的加密。如果你想檢查我們數據中心的任何磁碟，你是無法訪問到任何數據的。後來，我們陸續推出了Amazon CloudHSM和Amazon Key Management Service，這些服務允許用戶利用自己的加密金鑰對數據進行加密，這樣就不需要AWS再去幫助用戶去管理他們的加密密鑰了。

如今，在AWS所有新推出的服務中，對數據加密的支援已經在服務的原型設計階段就被整合進去了。例如在Amazon Redshift這項服務裡，每一個數據模塊都是透過一個隨機的金鑰進行加密的，而所有這些隨機金鑰最後又都是由一個主金鑰進行加密的。用戶是可以自己自主定義這個主金鑰的，這樣就保證了用戶自己是唯一能夠加密和訪問這些關鍵業務數據或個人隱私信息的人。

數據加密在我們的業務中一直都是一個優先級比較高的工作。我們會持續不斷地對數據加密改進，讓數據加密能夠更方便地使用，這樣用戶能更好地保護自己和自己的客戶。

網絡的重要性

AWS業務已經支撐了很多不同種類的負載，從大容量事務處理到大規模影片轉碼，從高性能並行運算到巨大的網站流量等等，所有這些負載對網絡都有非常獨特的需求。

在數據中心佈局和運維的創新方面，AWS已經開發出了一種獨特的新技術，這讓我們能夠提供更加靈活的網絡基礎設施去滿足不同用戶的不同負載的需求。我們在這個過程總學習到，為了能夠讓用戶實現自身的目標，我們必須開發自己的網絡硬件解決方案。這也讓我們能夠滿足我們一些定制化的需求，例如，為了確保最高等級的安全性，我們可以在網絡上將不同的用戶彼此隔離開來。

另一個AWS透過自己設計的網絡硬體和軟體解決方案去進一步幫助用戶改善性能的例子就是解決虛擬機之間的網絡訪問。因為網絡訪問是一個共享的資源，用戶之前經常會遇到網路壅堵的問題。AWS後來開發了能夠支援單根IO虛擬化技術的NIC，它能夠讓我們給每個虛擬機虛擬出自己的NIC，這個做法有效降低了網絡延遲兩倍以上。

不設守門人

為了給用戶提供一個更加廣闊和深度的服務平台，AWS團隊陸續開發和提供了越來越多的服務和功能。不過AWS遠遠不僅限於我們目前已經提供過的這些功能和服務，我們很多合作夥伴基於AWS提供的服務進一步擴大和豐富了整個AWS生態系統。

比如，我們的合作夥伴Stripe利用我們的服務提供的支付服務，以及 Twilio 利用 AWS 服務提供的網絡電話業務等。我們的很多用戶基於 AWS 服務開發出自己的平台，以解決各自垂直領域的一些問題。例如飛利浦開發了用於健康數據管理的數字平台 Healthsuite Digital Platform，Ohpen 在 AWS 基礎上開發了一個零售銀行平台，Eagle Genomics 開發了基因處理平台，這樣的例子還有很多。