谷歌服務中斷事故能否避免？

圖靈君導讀

當地時間12月14日凌晨3點47分，谷歌遭遇大面積技術故障，多項服務受影響，直到約45分鐘后才恢復，谷歌在宣告中稱本次事故的原因是“內部存盤配額問題”，

可以想象，谷歌有多少工程師度過了一個不眠之夜？在分布式系統上線后，開發人員和運維人員到底能不能高枕無憂？當出現問題時，系統能否依然穩定運行？

邁克爾·尼加德是擁有20余年經驗的運維專家，他在《發布！設計與部署穩定的分布式系統（第2版）》一書中分享了一些案例，今天，圖靈君就給大家分享其中一個案例：屋漏偏逢連夜雨，請移至文末了解本書詳情，

寶寶的第一個感恩節

我的客戶在夏天新推出了一個電商系統，推出產品之后那幾周和幾個月的經歷，一次又一次地證明：新推出一個網站就像養一個寶寶，某些事情必然會發生，例如半夜被喚醒，然后被告知一些“可怕”的發現，就好比聽到“天吶！你給孩子喂了什么……橙色橡皮泥嗎？”然而，在處理完這個新系統遇到的所有問題之后，我們仍可以持謹慎樂觀的態度去迎接這個假日季，

我們的樂觀態度源于幾個因素，第一，生產服務器的數量幾乎翻了一番，第二，我們有可靠的資料顯示該網站在目前的負載下能穩定運行，第三，我們有信心應對網站出現的任何錯誤，

為了過感恩節，有些同事在周末加班，從而在感恩節休假，我有4天假期，于是帶著妻兒去父母那團聚，吃感恩節大餐，他們的住所跟我們隔了3個州，我們還在感恩節的那個周末，安排了24小時的作業現場值班，正如我所說的，我們抱著謹慎樂觀的態度行事，當然，作為一名前童子軍成員（口號是“時刻準備著”），去父母家之前，我將筆記本電腦塞進了家用小貨車，以防萬一，

把脈

當星期三晚上抵達父母家時，我立即在父母的家庭辦公室里安置好了筆記本電腦，我可以在任何有寬帶和手機的地方作業，憑借父母家的3兆有線寬帶，我使用PuTTY登錄跳板機，并啟動我的采樣腳本，

在新推出這個網站之前的準備階段，我參與了負載測驗，測驗完成后，大多數負載測驗提供了測驗結果，由于資料來自負載生成器而不是被測系統內部，因此這是一個“黑盒”測驗，為了從負載測驗中獲得更多資訊，我開始使用應用程式服務器的圖形用戶界面，檢查一些重要的指標，如延遲、空閑堆記憶體數量、活動的請求處理執行緒數量和活動的會話數量，

如果事先不知道要找什么，使用圖形用戶界面就是探索系統的好方法，如果明確知道想要什么，使用圖形用戶界面就會變得乏味，但如果需要一次查看三四十臺服務器，那么使用圖形用戶界面就完全不切實際了，

為了能從負載測驗中獲得更多資訊，我寫了一個Perl模塊的集合，實作圖形用戶界面螢屏抓取，并能決議HTML里面的值，

這些Perl模塊可以讓我獲取和設定屬性值，并呼叫應用程式服務器的內置組件和自定義組件的各個方法，由于整個圖形用戶界面均基于HTML，因此應用程式服務器不能區別Perl模塊和Web瀏覽器，通過使用這些Perl模塊，我可以創建一組腳本，來采樣所有應用程式服務器的重要統計資料，列印出詳細資訊和匯總結果，休眠一段時間，然后回圈往復，

這些都是簡單的指標，但自從新網站推出以來，我們所有人都通過查看這些統計資料了解網站的正常“節奏”和“脈搏”，比如我們一眼就知道，7月的一個星期二中午系統是正常的，

感恩節

感恩節早上一醒來，我來不及喝完咖啡就跑進父母的辦公室查看整晚運行的資料視窗，對所看到的資料檢查再三，清晨的會話數量已經達到了正常一周中最繁忙的高峰水平，訂單數量如此之高，我不得不打電話給DBA，了解是否有重復提交的訂單，答復自然是沒有，

截至中午，顧客在半天內下的訂單量，已經與過去平常一周的訂單量相同，從頁面延遲、系統的回應時間和整體網站性能這些總體指標來看，系統雖然承受著壓力，但仍處于運維標稱范圍之內，

更好的是，即使會話和訂單的數量在不斷增加，但隨著時間的推移，這些資料也在趨于穩定，這讓我在整個感恩節火雞晚餐中興高采烈，

到了晚上，這一天內的訂單量已經達到了在此之前11月的總訂單量，到午夜時分，日訂單量已經與整個10月份的訂單量持平，即使是這樣，網站還在正常運行，它通過了第一次嚴酷的負載測驗，

黑色星期五

第二天是黑色星期五，用完早餐后，我走到家庭辦公室，看了一下資料，訂單數的增長趨勢甚至比前一天還要高，會話數量也增加了，但一切正常，頁面延遲仍然低至大約250毫秒，我決定帶著老媽出門買些做雞肉咖喱的食材，

當然，如果后來沒有出現可怕的錯誤，我是不會絮絮叨叨地講這個故事的，在我離開辦公桌之前，什么狀況還都沒發生，果然，當在外邊走了一半路程時，我接到了電話，

“早上好，邁克爾，我是丹尼爾，”

“一定有麻煩了是不是，丹尼爾？”我問道，

“所有的DRP在SiteScope上都變紅了，我們一直在進行DRP的滾動重啟，但它們重啟后會立即失效，戴維已經召集了電話會議，并請你加入，”

雖然是寥寥數語，但我已從丹尼爾那里得知，網站停機了，問題很嚴重，SiteScope模擬的其實就是真實的顧客，如下圖所示，

SiteScope變紅，表明顧客無法購物，我們正在損失收入，在一個使用ATG軟體的電商網站中，頁面請求由專用的實體處理，Web服務器通過DRP協議呼叫應用程式服務器，因此通常將應用程式服務器上處理請求的實體稱為DRP，一個DRP變紅，表示應用程式服務器上處理請求的一個實體已經停止回應頁面請求，所有DRP都變紅，則意味著該網站已經停機，并且正以大約每小時100萬美元的速度流失訂單，

我立即撥進了電話會議，里面一片嘈雜聲，顯然，會議室里的免提電話也撥入了這個電話會議，試圖在有回聲的會議室里分辨15個聲音，這種感覺簡直無以言表，然后，我聽到有人提醒說“網站存在問題”，是的，我們知道了，謝謝，勞駕請掛機，

生命體征

丹尼爾給我打電話時，事故大約已經過去20分鐘了，運維中心已將問題上報給現場團隊，團隊運營經理戴維請我參與解決，與顧客可能遭受的巨大損失相比，中斷休假根本不算什么，

事故發生20分鐘后，我們知道了以下一些情況，

- 會話數量非常高，比前一天還要高，

- 網路帶寬使用率很高，但沒有達到極限，

- 應用程式服務器的頁面延遲很高（回應時間很長），

- Web、應用程式和資料庫CPU使用率非常低，

- 搜索服務器這個以往常見的罪魁禍首這次倒是回應良好，其統計資料看起來沒問題，

- 幾乎所有處理請求的執行緒處于忙碌狀態，其中許多已處理超過5秒，

為了獲得更多資訊，我開始獲取那些有例外行為的應用程式服務器的執行緒轉儲，其間，我請在會議室現場作業的那位明星級工程師阿肖克，幫忙檢查后端訂單管理系統，他在后端看到了與前端類似的模式：CPU使用率很低，大多數執行緒長時間處于忙碌狀態，

從我接到電話到現在已經有近一小時了，或者說，網站已經停機80分鐘了，這不僅意味著訂單流失，還意味著這次極為嚴重的事故讓我們幾乎就要違背SLA，我討厭違背SLA，因此感到很不安，所有同事和我一樣，都很不安，

進行診斷

前端應用程式服務器上的執行緒轉儲顯示，所有的DRP都表現出相似的模式，有幾個執行緒忙著呼叫后端，而其他大部分執行緒則在等著呼叫后端的可用連接，等待中的執行緒全部被阻塞在一個沒有設定超時的資源池上，

如果后端停止回應，那么進行呼叫的執行緒將永遠不會回傳，而那些被阻塞的執行緒將永遠無法獲得呼叫后端的機會，簡而言之，所有3000個處理請求的執行緒，都被束縛在那里動彈不得，這完美地解釋了所觀察到的低CPU使用率現象：100個DRP全部處于空閑狀態，一直在等待永遠不會獲得的回應，

再看一下訂單管理系統，該系統上的執行緒轉儲顯示，在其450個執行緒中，一些正忙著呼叫外部集成點，剩下的你也許已經猜到了：其他所有執行緒都在等待呼叫那個外部集成點，

求助專家

當訂單管理系統的技術支持工程師撥入電話會議時，我感覺像是等了半個世紀（但可能只等了半小時），他解釋說，通常處理送貨調度的4臺服務器中，有2臺在感恩節這個周末因維護而停機，而另一臺由于未知原因失靈了，直到今天，我還是不知道為什么他們會在全年52個周末中，偏偏選擇這個周末進行維護！

這種情況使得流量在幾個系統之間產生了巨大的失衡，如下圖所示，

當那位接到技術支持請求的工程師檢查那臺“孤獨”的送貨調度服務器時，發現其CPU利用率已經達到100%，盡管已經多次收到CPU利用率過高的警告，但這位工程師還是沒有做出反應，該團隊經常因為CPU利用率的瞬間峰值收到警告提示，但結果常常是誤報，之前所有的誤報，讓他們學會忽略所有CPU高利用率警告，

在電話會議上，業務負責人語氣低沉地告訴我們，市場營銷部門在感恩節前準備了新的廣告插頁，登在感恩節第二天（星期五）的報紙上，廣告上提到，所有在感恩節后第一個星期一之前在線下的訂單，均享受免費送貨上門服務，在這個持續了4小時的電話會議上，所有參會者第一次陷入了沉默，

回顧一下，前端系統是一個電商系統，擁有分布在100臺服務器上的3000個執行緒，以及發生了根本性變化的流量模式（因為廣告促銷），電商系統發出的請求流量，淹沒了其下游的訂單管理系統，訂單管理系統擁有450個執行緒，它們既可能被用來處理來自前端系統的請求，也可能被用來處理訂單，而訂單管理系統發出的請求又淹沒了其下游的送貨調度系統，后者一次只能處理25個請求，

這種狀況會隨著促銷宣傳而一直持續到星期一，這簡直就是噩夢，網站已停機，而且這種情況沒有手冊可以參考，我們正處于事故的“漩渦”中，不得不硬著頭皮解決問題，

如何應對

接下來就做頭腦風暴，大家提出了許多方案，也否決了許多方案，否決的原因大多是在目前的情況下，應用程式代碼的行為是未知的，此時唯一可行的方案逐漸變得清晰起來：停止發出如此多的請求來對訂單進行送貨調度預約，由于周末的市場營銷活動主要圍繞免費送貨上門，因此用戶下訂單的請求是不會放慢速度的，此時必須找到一種方法來抑制對送貨調度系統的呼叫數量，而訂單管理系統無法做到這一點，

當查看電商系統的代碼后，我們看到了一絲希望，電商系統的代碼使用了標準資源池的一個子類，管理訪問訂單管理系統的連接，實際上，它還有一個單獨的連接池，專用于處理有關送貨調度的請求，電商系統擁有一個專用于處理送貨調度連接的組件，所以我們就可以將該組件用作限流器，

要是電商系統的開發人員為連接池添加了一個enabled屬性，那么將其設定為false就會使事情變得很簡單，也許他們下一步就可以這樣做，不管怎樣，把資源池中最大的連接數設定為0也能有效地將資源池關閉，

尾聲

我撰寫了一個新的腳本，可以完成重置該連接池最大值所需的所有操作，它能設定max屬性，停止服務，然后重啟服務，

通過執行一個命令，運維中心或客戶現場“指揮所”（會議室）的工程師，就可以將最大連接數重置為任何所需的數值，我后來才知道，這個腳本在整個周末都被不斷地使用著，

電話會議結束了，我掛斷電話，去哄孩子上床睡覺，這著實花了我一點時間，因為他們不停地說著各種趣聞：逛公園，在草坪上的噴灑器下邊玩兒，去后院看剛出生的兔寶寶，我很喜歡聽他們聊這些，

本文節選自以下圖書

邁克爾·尼加德 著

吾真本 譯

案例研究 + 行業思想家的真知灼見

助你掌握生產環境的生存法則

原版美亞評分接近滿分

作者介紹

邁克爾·尼加德，程式員兼架構師，擁有20余年的從業經驗，先后為美國政府以及銀行、金融、農業、零售等多個行業交付過運營系統，對如何在不利的環境下構建高性能、高可靠性的軟體有獨到的見解，

譯者介紹

吾真本，本名伍斌，ThoughtWorks首席咨詢師，著有測驗驅動開發入門讀物《馴服爛代碼》，作業20余年，做程序式員、測驗工程師、專案經理、敏捷教練，最近7年成功輔導10余家大型金融和科技公司的敏捷和DevOps轉型團隊，曾主辦多場編程道場，人稱“道長”，

| 留言

你有過一輩子也忘不了的開發事故經歷嗎？歡迎跟小伙伴們分享！