10 年 Amazon Web Services 總結得到的 10 個經驗教訓

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

2006年3月14日，Amazon S3的釋出，意味著AWS時代的開啟，離現在差不多剛好10年。回首過去的10年間，我們學到了許許多多有關於構建和運營服務所需的安全性，可靠性，可擴充套件性，以及如何用盡可能低的成本提供可預測效能的經驗教訓。考慮到AWS是在全球建設和運營這些服務的先驅，這些教訓對我們的業務至關重要。正如我們以前說過多次，“沒有用於經驗的壓縮演算法”。AWS每月有著過萬的活躍使用者，而且這些使用者反過來可能服務著他們自己數以億計的客戶，所以，我們不但不乏獲得更多經驗的機會，而且這可能是我們所能提供的最好的改進了。

我精心總結了一些經驗教訓想與大家分享，希望能對你有用。

1.建立可進化的系統

不知道從什麼時候開始，我們認識到我們構建的軟體不會是一年後執行該軟體的樣子。人們期望重新審視和修改架構，所以我們要確保我們可以解決規模的問題。

但是，我們不能採取通過停運維護來升級系統的舊方法，因為世界各地的企業依賴我們平臺7天/24小時的可用性。我們需要建立這樣一個體繫結構，它可以方便地引入新的軟體元件，而不需要考慮停止服務。Marvin Theimer，Amazon傑出的工程師，曾開玩笑地說過，Amazon S3的演變可以被很恰當地比喻為一開始作為一架單引擎塞斯納飛機起飛，但隨著時間的推移，飛機升級到737，然後是一組747，一路向前，現在儼然成為了空客380大艦隊。在這期間，我們只能在半空中給飛機加油，同時將這架飛機的乘客轉移到另一架飛機上，而不讓他們意識到這一點。

2.接受意外

失敗是必然的，隨著時間的推移，一切最終都將失敗：從路由器到硬碟，從作業系統到儲存單元損壞TCP資料包，從瞬態錯誤到永久性故障。這是一個事實，無論你使用的是最高品質的硬體還是成本最低的元件。

這個經驗教訓在大規模環境中甚至更重要：例如，由於S3要處理數萬億的儲存事務，任何誤差，即使最輕微的可能性都將成為現實。許多這樣的故障情形可以事先預見，但在設計和建造階段更多的是未知。

我們需要構建一個能夠擁抱失敗並視失敗為當然的系統，即使我們確實不知道失敗在哪裡。系統需要保持執行，即使“房子著了火”。能夠管理受影響的部分而毋需停止整個系統很重要。我們已經具備了管理一個失敗事件“爆炸半徑”的基本技能，這樣可以維持系統的整體執行狀況。

3.提供基元而非框架

很快，我們開始認識到，客戶想要的服務是永遠沒有終點的工作。當客戶留下約束，以前的IT硬體和資料中心時，我們就得開始開發從來沒有人見過的、使用模式又新又有趣的系統。因此，我們需要極度敏捷，以確保我們能夠迎合客戶的需求。

我們提供的最重要的機制之一是向客戶提供基元和工具集，在那裡他們可以挑選他們從事AWS雲的首選方法，而不是隻提供一個強迫他們使用的框架，甚至框架中已經囊括了所有一切。這種做法使我們的客戶獲得很大的成功，以致於後來幾代的AWS服務也沿用了完全相同的基元服務，因為客戶已經習慣了。

同樣重要的是要認識到我們很難預測哪些側重點更為客戶所喜愛，直到他們親身體驗過服務，並真正開始用它來構建。這就是為什麼我們釋出新服務時經常帶一個極簡的功能集，並允許客戶幫助推動路線圖通過新功能來擴大服務。

4.自動化是關鍵

需要進行操作的開發軟體服務，從根本上來說和構建需要釋出給客戶的軟體完全不同。管理大規模的系統要求非常不同的思維方式，以確保能夠滿足客戶的可靠性，效能和擴充套件性的期望。

實現這一點的關鍵機制是，要儘可能多地自動化管理，刪除容易產生的錯誤和手動操作。要做到這一點，我們需要構建管理API來控制業務操作的關鍵功能。 AWS可以幫助客戶做到這一點。通過將你的應用程式分解為基本的構建塊，每一個帶一個管理API，這樣你就可以應用自動化的規則規模化地維持可靠和可預測的效能。一個立見分曉的檢驗辦法是，如果你需要SSH到伺服器或例項，那麼你還有更多可以自動化的地方。

5. 永遠的API

這個經驗教訓是我們從Amazon零售中所吸取的，但在AWS的以API為中心的業務中更有價值。一旦客戶使用我們的API開始構建他們的應用程式和系統，就不能再改變那些API，否則會影響客戶的業務運營。我們得謹記，設計API是一個非常非常非常重要的任務，因為我們只有一次機會。

6.瞭解資源使用情況

當為一個服務構建財務模型以確定相應的收費模式時，對於服務以及操作的成本一定要確保有很好的資料資料，尤其是對於那些容量大利潤低的業務。AWS要有意識地作為關於成本的服務供應商，這樣我們才有能力提供服務給客戶，並確定哪些領域可以提高業務運營效率以進一步削減成本，然後將那些節省下來的資金用一種價格更低的形式回饋給客戶。

這裡舉一個S3的例子，在早期我們不知道需要資源為某些使用模式提供服務：我們曾假設儲存和頻寬是我們應該收費的資源；在執行一段時間之後，我們發現請求的數量也是一種同樣重要的資源。如果客戶有許多微小的檔案，那麼即使他們有數以百萬計的請求，儲存和頻寬也不會很多。我們不得不調整我們的模型以考慮到資源使用的所有方面，讓AWS成為一個可持續發展的業務。

7.徹底的安全構建

保護客戶應該總是首選目標，所以理所當然的，它一直都是AWS的首選目標……無論是從運營的角度，還是工具和機制方面：這將永遠是我們的第一位的投資領域。

其中一種我們快速學到的方法是構建安全服務，在服務設計的一開始就整合安全很有必要。安全團隊並不是在已建成之後做驗證的一群人。他們必須在第一天就攜手確保安全是徹底的，是穩如泰山的。當涉及到安全性的時候，沒有妥協。

8.加密是一等公民

加密是確保客戶能夠全面控制誰有權訪問他們的資料的一個關鍵機制。十年前，用於加密的工具和服務很難使用，然後幾年後在我們的業務操作中，我們學會了如何加密以便於更好地融入到我們的服務中。

它始於在S3中通過提供伺服器端加密用於依從性用例。如果你想在我們的資料中心檢查任何磁碟，沒有資料會允許訪問。但隨著Amazon  CloudHSM（用於硬體安全模型）和之後Amazon Key Management Service的推出，客戶可以使用他們自己的金鑰進行加密，這意味著AWS不再需要管理使用者的金鑰。

一段時間以來，對加密的支援已經整合到每個新服務的設計階段。例如，在Amazon Redshift中，每個資料塊用隨機金鑰預設加密，並且這些隨機金鑰的集合再用主金鑰進行加密。主金鑰可由客戶提供，確保他們是唯一可以解密和訪問關鍵業務資料或個人身份資訊的人。

加密仍然是我們業務的重點。我們將繼續努力讓我們的客戶更方便地使用加密技術，確保他們能夠更好地保護他們自己和他們的客戶。

9.網路的重要性

AWS支援許多不同的工作負載：從大容量事務處理到大規模視訊轉碼，從高效能平行計算到大量的網站流量。每個工作負載都有獨特的要求，當涉及到網路的時候。

AWS開發了一個獨特的技能，從而革新了資料中心的佈局和操作，這樣我們就有了靈活的網路基礎架構，用於滿足客戶的工作負荷，不管這些負荷是什麼。隨著時間的推移，我們懂得了不應該懼畏開發我們自己的硬體解決方案，這能確保我們的客戶實現他們的目標。這使得我們能夠滿足非常具體的要求，例如彼此隔離網路上的AWS客戶以實現最高水平的安全。

另一個AWS設計的網路硬體和軟體，如何使我們能夠進一步提高客戶效能的成功例子是，解決來自於虛擬機器的關於網路接入的虛擬化壓力。由於網路接入是共享資源，客戶以前有時可以在網路上體驗到顯著抖動。開發一個支援單根IO虛擬化的NIC，允許我們給每個VM它自己的硬體虛擬NIC。這降低了延遲2倍都不止，並且在網路的延遲變化中提升超過10倍。

10.沒有守門人

隨著時間的推移，AWS團隊已經發布了很多服務和功能，旨在為客戶創造了一個廣闊而深入的平臺。但是AWS不僅僅是我們內部構建的服務：合作伙伴釋出的非常豐富的生態系統服務專案將這個平臺擴充套件到許多新的方向。

例如，在AWS上，我們有提供支付服務的Stripe，也有讓電話可程式設計的Twilio等等合作伙伴。我們的許多客戶還在AWS上自己來構建平臺，服務於特定的垂直需求：Philips正在建設他們的Healthsuite Digital Platform來管理醫療保健資料，Ohpen在AWS上建立了一個用於零售銀行業務的平臺，Eagle Genomics建立了一個基因組學處理平臺，等等，還有很多。重要的是，目前在AWS平臺上沒有守門人告訴我們的合作伙伴他們可以做什麼和不可以做什麼。 “沒有看門人”解放了創新過程，併為許多意想不到的創意開啟了大門。

我期待在未來的10年時間中我們能學到更多，能為AWS客戶做更多的事情。請記住，每一天都是新的一天。