近日，亞馬遜CTO Werner Vogels在其部落格發表了《10 Lessons from 10 Years of Amazon Web Services》的總結性文章，闡述了這些年踩過的坑和自己的經驗。扇貝網工程師趙餘對本文進行了全文翻譯
AWS（Amazon Web Service） 開始於 2006 年 3 月 14 日 Amazon S3 的釋出，距今已經有十年的時間了。回過頭來看，過去這十年，對於構建和運營 AWS 這種需要確保安全性、可用性、可擴充套件性、效能可預知性，同時價格還要儘可能低廉的雲端計算服務，我們積累了大量的經驗教訓。考慮到 AWS 是雲端計算行業的開拓者，這些經驗教訓對我們來說變得更加重要。就像我們經常說的那樣，“沒有面向經驗的壓縮演算法”，任何經驗都來之不易。考慮到 AWS 有著超過一百萬的月活躍使用者，而這些使用者中有些需要服務的自家使用者則高達數千萬，因此，積累上述經驗教訓的機會在 AWS 比比皆是。
在這些經驗教訓中，我挑選了一些分享給大家，希望對各位也能有所幫助。
1.構建可持續演進的系統
從做 AWS 的第一天開始，我們就清楚地認識到，我們在做的這套系統不是一勞永逸的。現在可以用的系統，一年之後很可能將不再適用。我們的預期是，隨著（使用者）量級的每一次增加，我們都需要重新檢視和適當修改我們已有的架構，以便解決擴充套件性的問題。
但是我們並沒有採取過去常用的，通過停機維護進行系統升級的方式來實現上述目標，因為 AWS 支援的大量客戶背後，是提供 7 x 24 小時服務的遍佈全球的商業機構。因此，我們需要構建的，是一個可以在新增模組的時候不停機的架構。Amazon 傑出的工程師 Marvin Theimer 有一次開玩笑說，Amazon S3 這項服務的持續演進，就好比是開飛機。我們最開始開的是一架單引擎的賽斯納，後來換成了一架波音 737，之後又換成了一個波音 747 小隊，而現在更像是由空中巨無霸空客 A380 組成的一個大型機隊。最重要的是，整個過程飛機都沒有降落過，我們一邊通過空中加油確保飛機的正常飛行，一邊在萬米高空上將 AWS 的使用者，從一架舊飛機挪到另一架新的上面去。同時，AWS 的使用者對此毫不知情。
2. 預料到不可預料的情況
出問題是肯定的，至於什麼時候出，只是個時間問題。從路由器到硬碟，從作業系統到記憶體裡的 TCP 資料損壞，所有的元件都有可能出錯。有時候，錯誤是暫時的，有時候則是完全當機。不管你用的是最好的還是廉價的硬體，出問題總是不可避免。
在服務規模變得很大之後，這個問題愈加地凸顯：舉例來說，Amazon S3 服務時時刻刻都在處理著萬億級的儲存請求，（在這種規模下）任何出錯概率極小的問題都會被放大，進而影響到具體的業務。在設計和實現階段，這些問題中的一部分事先會被考慮到，而更多的則是完全不知情。
因此，我們需要構建的，是一個對於未知錯誤保持高容忍度的系統。這個系統應該要做到，即使在“後院已經著火”的情況下依然可以繼續執行。區域性元件出現小問題的時候，系統應該能繼續執行，而不是直接當機。對此，我們學會了一套控制未知錯誤的影響範圍的技能，以期將這些錯誤對系統健康度的影響降至最低。
3. 多提供元語，少提供框架
很快我們就發現，使用者大都喜歡在 AWS 提供的服務上持續構建和演進自己的業務系統。在擺脫了傳統 IT 硬體和資料中心的束縛之後，他們開始以一種全新、有趣的、之前從未出現過的模式開發自己的系統。也正是因為如此，為了滿足使用者多樣的需求，我們的架構需要保持高度的靈活性。
關於這一點，很重要的一個機制就是，我們提供給使用者的是一系列元語和工具，使用者可以自由選擇組合來使用，而不是由我們提供一個大而全的統一的框架。這個機制給我們的使用者帶來了巨大的成功，甚至 AWS 自身後續的一些服務也用上了這套機制，就像我們的普通使用者一樣。
同樣重要的一點是，我們很難在使用者還沒開始使用一個服務之前，就準確預知到該服務的最終形態。這也是為什麼所有的新服務最初都會以最小的功能集釋出，然後藉助使用者的反饋，再對該服務進行後續的擴充套件。
4. 自動化非常關鍵
開發一個需要持續維護的軟體服務和開發一個最終交付給客戶的軟體有著巨大的差異，管理一個像 AWS 這種規模的系統，需要一種完全不同的觀念，才能確保滿足使用者對可用性、效能以及可擴充套件性的要求。
實現這個目標的一個主要的機制，就是避免手工操作，儘可能的將管理工作自動化。為此，我們需要實現一套可以控制主要功能的管理 API。在這方面，我們同時也對自己的使用者給予幫助。通過將應用解耦成一個個獨立的模組，每個模組都有自己的管理 API，你可以很方便的定義自動化規則來進行大規模的維護。判斷自動化做的是不是到位，可以思考一下你是不是還需要 ssh 到某臺伺服器進行一些運維操作？如果答案是 yes，說明你的自動化做得還不夠好。
5. API 定義要嚴謹，因為一旦上線就無法更改
我們在 Amazon 零售專案中已經接受過類似的教訓，但對於 AWS 這種以 API 為中心的服務，這個原則變得更加重要。一旦使用者開始用我們的 API 開發他們的應用和系統，我們就不可能再對這些 API 進行變更了。因為 API 的任何改動都會影響到使用者已有的專案。因此我們充分意識到，在 API 給到使用者之前，我們只有一次將 API 做對的機會。
6. 監控你的資源使用情況
當你為一項服務確定計費模式的時候，請務必確保你有一份關於該服務的資源成本和運營的資料。對於邊際成本很低的業務尤其如此。作為服務提供商，AWS 需要對服務成本保持足夠的敏感，以便我們能清楚地認識到我們是否承擔得起某項服務，同時也能夠定位到一些可以通過提高運營效率而進一步降低成本的地方，並藉此降低服務價格，最終惠及使用者。
舉一個例子，早期的時候，我們對於 Amazon S3 服務所用到的資源成本並不是很清晰。我們當時假定，儲存和頻寬應該是我們首要考慮的收費點；後來執行了一段時間之後，我們才意識到，請求數跟儲存與頻寬同等重要。如果某個使用者有大量的小檔案要儲存，這種情況下，即使是百萬量級的請求，都不會佔用太多的儲存和頻寬資源。最終我們做了調整，將請求數也納入了計費模型，以便 AWS 在收支上可以保證這項服務的可持續性。
7. 從頭開始建立安全機制
保護你的使用者，這一點的優先順序永遠都應該排在第一位，在 AWS 也不例外。不光要從運營的角度，還要從工具和機制的角度保證這一點。對此，我們也將繼續保持最高的支援與投入。我們很快就學到的一個經驗就是，為了實現安全的服務，我們需要在服務設計的最初階段就抱有這種安全意識。安全團隊的任務不是在一項服務實現完了之後才開始安全檢查，相反地，安全團隊的工作應該和開發團隊一道，貫穿於整個專案的生命週期，以確保專案的安全性。總之，涉及到安全的問題，沒有任何妥協的餘地。
8. 資料加密是“一等公民”
資料加密，是保證使用者資料安全的重要機制。十年前，資料加密相關的工具和服務還不夠完善，直到 AWS 剛開始運營的最初幾年，我們才逐步積累了很多關於在服務中整合資料加密的最佳實踐。
Amazon S3 最初提供的，是伺服器端的加密機制。當我們在資料中心移除帶有使用者資料的磁碟的時候，這些資料就無法被訪問到了。但是後續上線的諸如 Amazon CloudHSM 和 Amazon Key 管理服務，均向使用者提供了自定義加密金鑰的機制，這樣一來，AWS 就不需要替使用者維護這些加密金鑰了。
現在，AWS 所有的新服務，在原型設計階段就會考慮到對資料加密的支援。比如，在 Amazon Redshift 服務中，每一個資料塊都通過一個隨機的金鑰進行加密，而這些隨機金鑰則由一個主金鑰進行加密儲存。使用者可以自定義這個主金鑰，這樣也就保證了只有使用者本人才能訪問這些機密資料或敏感資訊。
資料加密在我們的業務中的優先順序一直非常高。我們也會持續改進，讓資料加密機制用起來更簡單，最終，讓使用者能更好地保護自己的資料安全。
9. 網路的重要性AWS
服務支撐了各種各種的負載場景。從高併發處理到視訊轉碼，從高效能平行計算到海量的網路請求。這些不同的負載場景，對網路的要求也各不相同。
關於資料中心的設計和運營，AWS 開發了一套獨特的機制，這套機制提供了靈活的網路基礎設施，以便滿足任何使用者的不同負載場景的需求。在這個過程中，我們也認識到，為了讓使用者達成自身的目標，我們必須開發自己的網路解決方案。這樣也能滿足我們自身的一些定製化的需求，比如在保證高安全性的同時，通過網路來隔離使用者的能力。
AWS 自主開發的這套軟硬體解決方案，也能給使用者帶來進一步的效能提升。關於這一點，有一個成功的例子，那就是虛擬機器之間的網路通訊。由於網路通訊是一個共享的資源，在使用 AWS 自己定製的解決方案之前，使用者時常會遇到網路擁堵的問題。最終，AWS 通過開發支援單個根 IO 虛擬化技術的 NIC，實現了給每個虛擬機器虛擬出自己的 NIC 的解決方案。這一改動成倍地降低了網路延遲，同時提升了高達十倍的網路效能。
10. 不設限，保持平臺的中立與開放
隨著時間的推移，AWS 團隊提供了越來越多的服務和功能，這也給我們的使用者創造了一個廣闊的開發平臺。但是 AWS 遠不止我們團隊開發的這些功能與服務，一些合作伙伴基於 AWS 提供的服務進一步擴大和豐富了整個系統的生態。比如，我們的合作伙伴 Stripe 提供的支付服務得以讓 Twilio 在 AWS 上支援電話業務。很多使用者基於 AWS 本身的服務，開發出自己的產品，用於解決特定的垂直領域的問題。
比如，飛利浦開發了用於健康資料管理的 Healthsuite 數字平臺，Ohpen 則基於 AWS 開發出自己的零售銀行平臺，Eagle Genomics 開發了自己的計算平臺用於基因處理等等，這樣的例子不勝列舉。AWS 並不會限制我們的合作伙伴，規定他們什麼可以做什麼不可以做。“不設限”的原則釋放了創新的動力，為意想不到的創新敞開了大門。
對於在接下來的十年裡， AWS 的團隊會學到哪些經驗教訓，我們的使用者又會創造出什麼樣的價值，我充滿了期待。
永遠記得，對 AWS 來說，這僅僅是一個新的開始。