時間2015年的某個週六凌晨5點，公司官方的QQ群有使用者反饋官網打不開了，但有的使用者反饋可以開啟，客服爬起來自己用電腦試了一下沒有問題，就給客戶反饋說，可能是自己網路的問題，請過會在試試。早點8點，越來越多的使用者反饋官網無法開啟，並且有部分使用者開發反饋app也打不開了，客服打電話叫起了還在夢鄉中的我。

分析定位

被客服叫起來之後，一臉懵逼，不知道什麼情況，給客服回覆，知道了，立刻排查，待會有訊息及時溝通。用涼水洗了一把臉清醒了一下，立刻根據經驗回憶這兩天生產投產的情況：上線了XX模組，不影響、修復了XXbug，應該也不影響、剛給伺服器配置了https，看起來好像有點關係，但是app暫時沒有投產https，怎麼也出現問題，排除之。開啟電腦核查了最近的投產記錄應該都不至於發生這麼嚴重的問題，隨懷疑是不是網路方面有問題，立刻打電話叫起來運維經理以及相關人等一起排查。

一邊讓網路和運維排除問題，一邊再次核查了web伺服器、資料庫伺服器、業務日誌、資料庫日誌，以及其它的一些監控資料，各項皆正常。試著在本機ping了一下域名確實不通，更加懷疑是網路問題，嘗試這直接使用外網訪問官，可以開啟沒有問題，可以基本確認服務沒有問題，但運維部反饋網路裝置什麼都正常，肯定是你們投產程式碼出問題了，各方硬著頭皮繼續在排查。

9點，群裡開始有大規模的使用者反饋官網和app都打不開了，更有部分使用者煽動，XXX公司跑出了（15年很多p2p公司跑路，導致使用者都成了驚弓之鳥，稍微有問題便害怕公司跑路，個個都鍛鍊成了監控高手，天天看，實時刷，凌晨起來尿尿也都順便看一下app上的今日收益），客服400熱線基本被打爆了。一邊繼續排查問題，一邊上報此問題給總監、公司各高管，給客服建議，給使用者解釋，IDC機房網路抖動，技術正在緊急解決，資金和資料都沒有任何影響，稍安勿躁。

10點，開發和運維反覆的檢查後，開始懷疑dns解析有問題，但具體是什麼問題還不清楚，CTO決定：1、大家都打車往公司走，來公司集體解決 2、在各QQ群、微信群給使用者群發解釋xxx問題，安撫客戶。在車上的時候重新梳理了一下使用者的整個訪問流程，如下圖：

到公司後，根據這個思路大家在一起驗證了一下，通過外網IP和內網IP訪問公司所有服務都正常，但是通過域名訪問不行，另外監控伺服器、防火牆、網路裝置日誌都正常，因此斷定是DNS解析出現問題。

攻堅問題

既然確實是DNS解析問題，那麼問題又來了？為什麼DNS解析會出現問題？如何去解決這個問題？一邊給萬網提工單，我們也自己測試一下電信、移動、聯通在不同的網路運營商下面的訪問情況，發現只有在聯通網路的環境下DNS解析不了。根據客服得到的反饋也驗證了這個情況，電信和移動使用者反饋很少，聯通使用者反饋最多。於是我們又開始給聯通打電話，剛開始聯通不受理我們的這個請求，於是又開始以使用者的身份打電話給聯通公司讓立刻解決不能上網的問題。

於是就開始了萬網和聯通的扯皮大戰，萬網說從他們那邊檢視DNS解析都正常，一起指標都正常，我們又給聯通打電話聯通說我們已經知道了，待會由專業的人給我們回覆，過了一會聯通的網路工程師回覆說，像這種情況一般都是域名解析的問題。早上10:30到公司開始短短的6各小時內，我們幾個輪流給聯通公司合計供打了近50、60通電話，給萬網提了N個工單，接了N個電話。

期間領導也開始動用各種關係，聯通內部的朋友、網路運維界的大拿幫忙來定位解決，我們也嘗試了很多的辦法，比如，使用ipconfig/flushdns命令清除本機的DNS快取、在萬網的官網把DNS解析重新更新一邊、刪除在重新新增等等，也不是完全沒有收穫。我們一直想找一個可以測試各個地方、運營商網路的辦法，終於在各方推薦和搜尋的情況下找了17ce 和 360奇雲測兩個網站，感覺非常實用，在以後的網路定位中，成了我必備使用的工具，可以非常方便的監控各個運營商、各個地區網站的訪問是否通不通、訪問的速度快不快等問題，截圖如下：

我們也發現，公司的其它域名也都訪問正常，就是官網的這個域名和相關的子域名不通。期間很多人都問了一個問題就是你們的域名有沒有忘了繳費，剛開始大家也都問了運維這邊說是沒有這個問題，直到中午12:30的時候在我們再三的追問下才說8點多的時候登入上萬網的時候顯示這個域名是欠費狀態，但是他已經立刻把費用補了上去了。哎呀差點把我們氣死，問了不是域名到期有提示的嗎？才知道因為上一個運維經理走後，他們沒有及時的更新萬網的電話和郵箱導致提示郵件和簡訊也沒有收到。

通過和萬網、聯通公司、領導的相關朋友溝通以及我們的測試觀察，初步明白了這個事情的原因：域名忘記繳費導致萬網的DNS解析被停止，使用者本機或者DNS伺服器有快取，所以部分使用者可以訪問部分使用者不能訪問；繳費過後萬網的DNS已經進行了更新和推送，但是DNS解析有很多的層級需要一級一級的往下面傳送更新，有的層級並沒有更新到，導致部分沒有更新到的DNS服務商下面的使用者不能訪問官網。

和萬網進行了溝通，問最延遲的情況所有的DNS更新到最新的時間，回答是48小時內肯定都會好的，但是我們等不起呀，隨著時間的推移越來越多的使用者發現問題，QQ群、微信群已經沸騰，董事長也開始關注次問題，有的客戶直接在群裡面說，你們的技術太不給力了(像這種還是委婉的，有的直接打電話罵人)…

臨時解決方案

不斷的通過17ce測試發現，大部分地區的網路都已經恢復，就剩北京聯通和部分地區聯通網路環境下不通，也說明了這幾個地區下的DNS解析記錄沒有被更新。那麼既然我們在上面已經定位出了問題，又瞭解是什麼原因，就想著試著換個DNS解析伺服器會不會好一點呢，於是我們把本地的DNS地址換成8.8.8.8（谷歌的DNS服務解析）發現好了！於是趕緊先寫解決手冊發給著急的客戶來使用。

官網的使用者可以通過更改DNS來解決訪問的問題，APP怎麼辦呢？沒有辦法我們也不能等，直接找開發人員把服務端呼叫的地址由域名暫時先改為外網的IP地址打一個版本供使用者臨時使用。安卓還比較好辦，直接讓使用者下載安裝使用還好，但是IOS那時候的稽核最少都需要一週黃花菜都涼了。其實iPhone手機可以單獨設定DNS的，我們進行了設定和測試後發現也可以實現，於是馬上更新到手冊中傳送給客服傳送到群裡面給使用者使用。

有人說直接讓使用者使用外網就行了嗎，使用外網首頁開啟到是沒有問題，但是各系統之間呼叫，相關配置檔案裡面寫的也都是域名的地址，如果硬改的話可能會引發另外的問題。第一天搞完就10點多了，中間就4點吃了一頓飯，打了N個電話大家都非常累，於是當天就先這樣了，第二天大家一早到公司繼續跟進。

第二天到公司經過17ce測試發現所有的節點都已經通了就剩北京聯通的兩個接點沒響應，但是北京是我們的大本營，絕大部分的使用者都是北京的，繼續和萬網、聯通溝通看怎麼能徹底的解決這個問題，另一方面做好最壞的打算，如果一直不通怎麼辦。在生產環境中梳理所有使用域名的配置檔案，做好隨時可以直接更新為外網地址而不能影響服務，app完整的重新做一個版本，做好隨時可以投產讓使用者強制升級到外網直連的版本。

到第二天晚上10點的時候，北京聯通的這兩個節點還是不通，和領導進行了商議如果到週一早上8點來的時候這兩個網路還是不能通的話，就上線改造好的系統和APP強制升級（因為當時週末還沒有標的，周內才有發標計劃）。第三天早上起來的第一件事情就是拿起手機，檢視自己的聯通網路是不是可以登入上官網，結果通了！皆大歡喜。

俗話說真理是愈辯愈明，經過了這次事故，也徹底的讓我瞭解了DNS解析的整個過程。

DNS 解析流程

DNS( Domain Name System)是“域名系統”的英文縮寫，是一種組織成域層次結構的計算機和網路服務命名系統，它用於TCP/IP網路，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。俗話說，DNS就是將網址轉化為對外的IP地址。

dns從使用者訪問到響應的整個流程

• 第一步：瀏覽器將會檢查快取中有沒有這個域名對應的解析過的IP地址，如果有該解析過程將會結束。瀏覽器快取域名也是有限制的，包括快取的時間、大小，可以通過TTL屬性來設定。
• 第二步：如果使用者的瀏覽器中快取中沒有，作業系統會先檢查自己本地的hosts檔案是否有這個網址對映關係，如果有，就先呼叫這個IP地址對映，完成域名解析。
• 第三步：如果hosts裡沒有這個域名的對映，則查詢本地DNS解析器快取，是否有這個網址對映關係，如果有，直接返回，完成域名解析。
• 第四步：如果hosts與本地DNS解析器快取都沒有相應的網址對映關係，首先會找TCP/ip引數中設定的首選DNS伺服器，在此我們叫它本地DNS伺服器，此伺服器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。
• 第五步：如果要查詢的域名，不由本地DNS伺服器區域解析，但該伺服器已快取了此網址對映關係，則呼叫這個IP地址對映，完成域名解析，此解析不具有權威性。
• 第六步：如果本地DNS伺服器本地區域檔案與快取解析都失效，則根據本地DNS伺服器的設定（是否設定轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS伺服器收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名伺服器的一個IP。本地DNS伺服器收到IP資訊後，將會聯絡負責.com域的這臺伺服器。這臺負責.com域的伺服器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS伺服器地址給本地DNS伺服器。當本地DNS伺服器收到這個地址後，就會找域名域伺服器，重複上面的動作，進行查詢，直至找到域名對應的主機。
• 第七步：如果用的是轉發模式，此DNS伺服器就會把請求轉發至上一級DNS伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根DNS或把轉請求轉至上上級，以此迴圈。不管是本地DNS伺服器用是是轉發，還是根提示，最後都是把結果返回給本地DNS伺服器，由此DNS伺服器再返回給客戶機。

這個事情發生後給了我們很大的教訓:
第一、流程管理有漏洞，離職交接不到位；
第二、危機處理不成熟，影響公司聲譽；
第三、監控機制不完善，像外網不通的這種問題，應該提前設定監控措施。

有時候非常的嚴重的問題，就是你常常忽略的小不點.   

打賞支援我寫出更多好文章，謝謝！

打賞作者

打賞支援我寫出更多好文章，謝謝！

任選一種支付方式