【51CTO專稿】前幾天，51CTO系統頻道推出專訪新浪劉宇的系列文章中第二部分《專訪劉宇：解密新浪CDN服務器監控機制》，今天專訪的第三部分新鮮出爐，本文中，主要講述了新浪CDN故障響應機制及其修復措施。對此感興趣的朋友，可以看看下面的訪談實錄。

[[81264]]

SinaEdge平臺運維主管 劉宇（@守住每一天）

【嘉賓簡介】劉宇：SinaEdge平臺運維主管，LinuxTone.org的創造人之一，在自動化運維方向有一定的研究，目前正在籌備《Puppet實戰》一書，大家可以在微博上@守住每一天和他聯系。

【采訪實錄】

51CTO：劉宇您好！首先請您談談您在公司主要負責的內容。

劉宇： 好的。公司配有全網絡監控，7*24小時值班的體系，我主要負責負責CDN的監控。我們CDN有自己的響應機制，這個響應機制和其他各大公司是類似的。會有統一的小組或部門來負責。打個比方說，除了響應提示他就涉及到故障了，如果沒有故障的話就不會有響應。

51CTO：對，響應就是針對故障。

劉宇：和其它公司一樣，新浪針對不同的故障有著不同的級別對待，目前來說跟微博相關的級別***，非微博相關的排其次。但并不代表就不重要。在CDN不管是什么項目，只要在CDN加速的，就是重要的。在大故障與響應方面，會更多地按照公司的標準執行。

51CTO：這個只是按業務來分層級？就是這個業務出什么問題都是最重要的。

劉宇：那不一定，你說的這個就涉及到它的影響范圍了。

像一級，重大故障，影響微博主功能的，比如：無法登陸微博、刷不了微博、登不進去的用戶投訴、圖片打不開等種種情況，而跟我這邊最相關的可能就是圖片打不開。還有另外一個業務比如說大面積的視頻無法播放，微盤用戶投訴，像你們現在去微盤，你們看到的比方說預覽。看不到找我，下載不了找我，所以我們會根據影響重要的功能（重要的功能，通常就是說這種大面積的訪問不了，然后下載不了的）。另外一個是主要的一些功能在于非這幾大類的，如果出了前面的問題，涉及到的用戶面是多少，其他的就是剛才我們說的那些不痛不癢的。

通常情況下會定位只有三級。然后分不同的權重比。再根據除了這三個之外，再根據現在影響用戶的范圍是多少，***用戶不可達，還是百分之三十、百分之五十、百分之十……類似于這樣的情況再排，接著用不同的東西再去說明。比方說百分百的用戶是完全不行，部分用戶不行，偶爾不行，然后亂七八糟的部分，比方說故障不可信或是不可重現，然后因為那只出現過一回啊，后來就好了，類似于這種，級別***的那種。比方說完全不可用那解釋說，那就是說在我加速的這個應用里面全部都掛掉了。

其實對于CDN運營級別***的就是所有服務都不可用了，就是這是級別***的。在不可用的情況下，比方說微博所有的圖片都打不開了，在我手上應用，所有圖片打不開。當然我們剛才所說的，再往下排一級別的情況下，比方說網通這一個用戶全都都打不開了。然后再網上升一層面，比方說再往下降廣州市這一個用戶打不很開了，再往下降，那就比方說廣州市里面的百分之三十的用戶打不開了，如果再往下降層面百分之十的用戶偶爾打不開，就類似于這樣子往下去排，那么公司有一定的這樣的算法，就是要有個公式然后去算。當前這個情況然后影響多少，然后會定級為ABCDE，類似這樣的故障級別，A***，然后E***，***根據這樣算出來，從而定故障級別，發通告。舉個例子：EF級別內部通知，然后剛開始所說的涉及到行政那塊東西，AB級別了，涉及到行政當中，行政的話那塊就是要固定的模板，例如故障時長，故障處理部署，故障處理人員，故障最終結果，然后這個故障的后續的改進，后續的跟進，記錄號你做什么改進，然后跟進周期是什么時候，你要做A改動，什么時候做完，要特別注重這些細節。類似于AB級故障都是要這樣去做，這個時候涉及到的人員跟進得有四五個了，公司會有專門的處理這種故障的小組來跟進處理，挖掘故障的根本原因，避免以后再出類似的故障。也算是一個故障的總結，個人認為這是非常有必要的，公司在這方面也一直很得很好。

51CTO：就你們組而言，優先是恢復業務為主的？

劉宇：我處理故障的思路是，首先確定故障，一定要先把故障定死了，清楚了是什么樣的故障，再分配人員去查，然后預估這個故障大概會影響的范圍和警示度，這個時候是需要跟所有人去說明白的，這個故障既然已經定下來了，你要先確定你有多少把握在多少時間之內能ok，在你沒有任何把握它在某一定時間能ok的情況下，我就會通知幾個人員專門去通知業務部門，做緊急預案，這個時候預案的話就是屬于故障的另外一個流程，就是說這個故障已經在我手上就不可控了，然后我已經無法去控制這個故障了，我會讓他們去走另外一個流程說，讓不同的人負責通知不同的業務，走相關的故障切換流程，故障處理預案，走切換服務的處理。***時間先保障業務可用。從操作到生效服務恢復的時間幾乎是一個TTL時間：60s，除響應時間外。

51CTO：什么？60s？

劉宇：對，我們的TTL設置是60s，也就是說這個故障只要我們操作，在60s之內就能解決，然后就是說先保證用戶可用；當然這也不排除DNS緩存與個別生效延遲情況。

如果說出現了那種特別大面積的故障，我已經完全不可控了，通過我的這種幾個級別的故障處理，我已經無法解決問題的時候，就需要快速上報，并通知四五個部門，以報將故障降低至***，各部分也會針對這個故障應用不同的策略。

有了這層通知，公司陸陸續續的各種各樣的投訴，并且有大面積反饋到前面其他部門的時候，他們心里都知道有什么事情，有一個說辭。我們會在這個時間之內提出我們這邊出現什么問題，大概多長時間會ok，如果有人問起，你就用怎么樣的語言去說，然后可以快速進入下一步處理，因為通過這種情況的話我可以更加地快，一分鐘之內就可以把這個部門全部都溝通過。然后比方說再涉及到的那種故障的那種流程的情況下，不可用了，說要切換服務，要保證服務質量的情況下，因為這才是優先的，這個時候會通知相關的部門去走以前商量好的，定制好的那個預案，按預案走就OK，那種情況會非常的快。

整個故障上報除了電話通知，還會通過固定的郵箱模板，在后臺里面啪點一下send，將故障郵件發送至相關人員。也就是說我這個預案前期做得有多好，到你出現故障的時候，響應速度就有多快，這就所謂的應急措施，這就是要向公司特別強調你要去做預案的重要性，平常一年可能用不到，但是關鍵時候用了一次，那就減一半，我們只需要在后臺你比方說我點一下這郵件就啪的一下全部都出去了，非常的快。你不需要琢磨這個郵件要發給誰，郵件內容要寫什么這樣累世的問題。只需要簡單的改幾個字，然后點個send發送，你就不用管了。所以說，我一般在這個里面充當的角色就是，前期的確認和后期的協調，然后因為故障用的解決了的那種請況下我必須要按照別人去配合，我不可能就說因為那個時候出現那種大故障的情況下，我的電話是不會斷的，所以說更多的就協調，讓你們去查，然后盡快的找到原因，然后再一方面就是就是開始著手做協調了。不管什么時候出現故障，我們小組的響應速度一般都很快。

51CTO：那這個預案系統是你在的時候做起來的？

劉宇：公司一直就有，每個人都有，只是說我需要去針對我現在這個負責的業務情況，可能會增加一些不同的方式或者說解決方案。

51CTO：嗯，那比如說，不管在哪個層級從技術上面處理可能思路差不多吧？先去確定故障，然后快速把這個故障修復。

劉宇：對，通常一般的情況下會***個先想變更，這個思路我覺得跟別的公司沒有任何區別，我覺得是沒有任何區別，因為真的，十有八九就變更，先想想有沒有變更，沒有變更再想下一步。通常就是***反應，有沒有變更，腦子里先過一遍這兩這幾天的東西，你有沒有變更，如果沒有，ok，再往下走。

51CTO：它也是有幾套模板的，除了變更之外，還有什么快速定位故障的？

劉宇：程序。我們有編寫了幾個程序，如果出現這方面問題的時，我敲幾個命令，就能夠快速先排查幾個問題。可能在哪一個環節發生了問題我們就開始寫程序，因為CDN盤子比較大，涉及到的業務線會比較多，所以先從核心層面去排查，然后核心層面沒什么問題然后再往接著往下，這份故障的話，會根據業務來，比方說你這個大文件的還是小文件的，還是直播的？會根據這幾個業務來分。

51CTO：每個業務出現的故障可能是不太一樣。

劉宇：除了大的故障之外，就沒有什么相同的。

51CTO：那么采取的措施是什么樣的？

劉宇：措施是類似的，但是可能在定位的那塊不一樣，所以說我們對于不同的應用，有不同的程序去探測，我們直接在一個后臺里面。最開始形成的時候采用的是程序，每個人電腦上裝一個，根據不同的業務進行檢測業務的可用性。如果對業務有影響的情況下，先保證服務，這也是響應機制。快速影響每一個投訴與反饋，并快速進行定位判斷。

51CTO：要不講講最近遇到的故障？

劉宇： 可以聊聊最近遇到的一個劫持事件。很多公司都有劫持。通常最多的DNS劫持，不是跳轉劫持，我們把它定義為成了TCP層面的劫持。用戶去看的時候，通過各種排查方式，出現問題，用戶說我訪問同一個頁面里面的不同的視頻，然后A同事看不了，B同事能看，然后同一家公司里面，你能看，我不能看。但是后來，就是說因為用戶就覺得，我同一家公司的，為什么我能看，他不能看，為什么今天我這部分視頻能看，明天我這部分視頻不能看。其實這個問題相當詭異的。可能很多人遇到問題的時候，要不然就是全公司的都不能看，要不然固定的時期不能看 。我們遇到的問題是說，同一家公司的，然后今天是這個不能看，明天是那個不能看，然后有些時候你能看，有些時候你不能看。然后當時我們遇到這個問題的時候，覺得是挺詭異的。不過后來我們去分析發現用戶，它出口那個IP是變的，這是一個規律，用戶他有兩個出口，走A出口的時候正常，走B出口的時候不正常，這個是我們在客戶端去模擬用戶請求，然后在服務器端抓包發現的。

51CTO：他們公司有兩個外網出口？

劉宇：這個也能理解，很多公司都有。這是一個問題。第二個我們發現用戶出來的時候，它是固定的一個域名是不正常的。因為在我們的一個視頻里面會有不同的域名來調用，其中發現只是某一個域名是不正常的，另外一個域名是正常的，由此可以判斷出為什么他們會出現這部分能看，這部分不能看，落在這個域名下面的是不能看的，后來我們就集中去排查，發現最開始以為是劫持，很簡單，如果你DNS被劫持了，然后我們發現，你去dig、ping或者去定緩存，然后就是說各種嘗試你發現沒問題，他的解析是正常的。

dns層面是完全沒有任何問題的，因為dns在windows下是有本地的緩存的，你要把他清掉的情況下，像是去跟全部DNS去查詢的，所以說這種情況下，如果你要是清掉還不正常，那說明他沒有劫持，沒有任何問題。后來我們在用戶那一層面模擬用戶的請求，因為我們有使用302跳轉技術，用戶跳轉之后302收到的請求是正常的，但下一次去訪問時異常了，通過這次判斷，應該是用戶走這個出口，公司有限制。這種做法在小運營商里面是常見的，但通常都是采用DNS劫持，叫內部Cache，這樣做的好處是可以節省大部分的帶寬，因為視頻的錢成本是很高的。為此我們判斷出來，用戶只要走這個出口，公司是采用的白名單政策，只要是在非白名單之內的都會走內部的Cache。然后我當時和他們的工程師去協調，對方反饋并沒有去做這種cache。但是我們從模擬出用戶的請求各方面來講，已經確認了絕對是內部Cache導致。后來讓他再去溝通，通過多次溝通發現是他們公司集團，某一個出口里面是有cache的，然后他去走了個申請開放了一下我們這個運營的cache限制，就好了。

51CTO：挺有意思，看起來比較隨機的問題。這個后來是算哪個層的問題？

劉宇：后來定義為用戶自己的問題。

51CTO：用戶層自己的問題，當時在你們這兒判斷是算緊急度是怎么樣的？

劉宇：嗯……優先級挺高的。

51CTO：它不是只有一個公司出問題？

劉宇：沒錯，但是那個公司是屬于付費公司，我們公司跟他們公司是有一種合作的關系。有著大量的推廣與合作，在微博兒里面是有推廣的，然后如果微博上面看不了的話，其實影響面還是挺大的，但是恰恰只影響他們公司自己人看不了。我是領導我花了錢了結果發現我看不了，所以說在我們這邊排優先級其實算挺高的，因為涉及到這里面的***一點，算是一場商務上的。

51CTO：這個層級這個也算一個評級標準？

劉宇：這個也算。公司里面對于這一方面其實也挺多的，因為商務合作，有可能涉及到是微博的，比如戰略發展方向什么的。

好了，今天的采訪就到這里了，感謝劉宇的分享！此次專訪到此也畫上了圓滿的句號。如果沒來得及看前兩篇專訪的朋友，在此回顧下。專訪***部分：《專訪劉宇：探秘新浪CDN系統的代碼發布機制》、專訪第二部分：《專訪劉宇：解密新浪CDN服務器監控機制》。再次感謝您的持續關注，如有問題，歡迎在評論欄中留言討論。