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客戶做更多的事情。請記住，每一天都是新的一天。

譯文鏈接：http://www.codeceo.com/article/10-lessons-10-years-aws.html

英文原文：10 Lessons from 10 Years of Amazon Web Services

翻譯作者：碼農網 – 小峰

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！