谷歌GAE運維揭秘：如何做到每天處理超過1000億個請求
在這篇博客帖中，我們請到了Chris Jones（他做了三年半Google App Engine運維工程師，到目前為止已經當了9年的谷歌運維工程師），來探索更多關于在Google上運行產品系統的細節。Chris也是《Site Reliability Engineering: How Google Runs Production Systems》這本書的編輯之一，該書由 一直處于互聯網發展前沿的O’Reilly Media出版，現在已經可以買到。
Google App Engine每天都服務超過1000億個請求。就像你聽說的那樣，是我們的運維工程師讓這成為可能。這的確有點像是魔術，將計算機科學和工程原則運用到編程系統的設計和開發中——這個總體來說是十分龐大。
谷歌運維是一套工程方法，讓我們或者任何人更好的運行產品系統。它將運維的推廣到更大的IT社區。它用有趣的方式來大規模提高性能和可靠性，這對于任何公司來說都是有用的。做得好的話，SRE技術可以提高操作編程服務的效率。
Q：Chris，能告訴我們有多少SRE在操作App Engine嗎，現在有多大規模呢？
Chris：我們每天有百萬級以上的應用程序在處理1000億以上的請求，支持的SRE大概幾十個的樣子。
Q：只有那么少的人，是如何做到這樣的規模的呢？
Chris：SRE也是一個工程方法，它可以操作大規模分布式編程服務。但是讓系統高度標準化也是有爭議的。高度標準化意味著所有的系統工作都是相似的，這也就意味著對操作人員的需求越來越小了，因為操作的復雜性大大降低了。
自動化也十分重要：我們的啟動進程是全自動的，所以我們可以很好地用計算機來對這些進程進行擴容，而不是雇更多的人。如果想要將人放到進程上，那會顯得很無趣，很多余。你會發現錯誤飆升。計算機的對錯誤的反應次數遠遠比我們人要來得多，而且快。在我們還沒有注意到錯誤的時候，計算機就已經在將流量引到另一個數據中心了，同時保證服務繼續運行。讓人做人擅長的事情，讓計算機做計算機擅長的事情。
Q：在SRE模式后，還有什么其他的方法嗎？
Chris：因為有很多SRE團隊在處理Google的服務，所以我們可以在產品上擴展標準化原則：SRE－創建工具原本是用于部署新版本的Gmail 的，例如，可以被整理來覆蓋更多的場景。這也就意味著每個團隊都不需要再自己創建方法來部署更新。這就確保每個產品在工具提升之后，都會得到改進，這就使得整個系統更好的使用工具。
另外， 軟件工程和系統工程知識的結合，令解決方案囊括兩者優點。谷歌的軟件網絡負載均衡器，Maglev，就是一個例子———而且它是Google云平臺負載均衡器的底層技術。
Q：那么這些方法是如何影響App Engine和我們運行在AppEngine上的用戶的呢？
Chris：我說個故事來闡述這個。在2013年的夏天，我們將所有App Engine的美國區域從國家的一邊轉移到另一邊。這個舉動招致沒有停工期給我們的用戶。
Q：怎么做到的呢？
Chris：我們先關閉一個App Engine集群，然后就如設計的那樣，在上面運行的apps自動移動到了剩下的集群。我們早就事先在目標數據中心創建了美國區域的High Replication Database（ https://www.油Tube.com/watch?v=xO015C3R6dw ）的復本，這樣那些應用程序的數據（PB級別的數據!）就在該在的地方；對數據存儲的修改是自動復制的，這樣就可以實時更新。當在新的本地打開App Engine的時候，apps自動被分配到那個從他們備份集群中轉移的集群，而且他們所有的數據是已經在適當的地方了。然后我們用剩下的集群來重復進程，直到我們完成之后。
事先準備，將大量的測試和應變計劃結合，這就意味著當事情出錯時候可以將沖擊減少到最小。當然，我們將內部事后析誤——SRE如何工作的另一個重要部分——放在一起來理解到底什么出錯了，以及如何修復對長遠比較好，沒有指責。
Q：So cool！那么我們如何找關于SRE更多的消息？
Chris：如果你對SRE是如何在Google運行很感興趣的話，那么就點擊這個網站： https://landing.google.com/sre/ ，我們這周（四月7-8）也會在SREcon： https://landing.google.com/sre/ 就這個話題給出不同的演講。