時間 2015 年的某個周六凌晨 5 點，公司官方的 QQ 群有用戶反饋官網打不開了，但有的用戶反饋可以打開，客服爬起來自己用電腦試了一下沒有問題，就給客戶反饋說，可能是自己網絡的問題，請過會在試試。

但是到了早上點 8 點，越來越多的用戶反饋官網無法打開，并且有部分用戶開始反饋 App 也打不開了，客服打電話叫起了還在夢鄉中的我。

分析定位

被客服叫起來之后，我一臉懵逼，不知道什么情況。然后給客服回復，知道了，立刻排查，待會有消息及時溝通。

用涼水洗了一把臉清醒了一下，立刻根據經驗回憶這兩天生產投產的情況：上線了 XX 模塊，不影響;修復了 XXBug，應該也不影響;剛給服務器配置了 https，看起來好像有點關系，但是 App 暫時沒有投產 https，不會出現問題，排除之。

打開電腦核查了最近的投產記錄應該都不至于發生這么嚴重的問題，隨之懷疑是不是網絡方面有問題，立刻打電話叫起來運維經理以及相關人等一起排查。

一邊讓網絡和運維排除問題，一邊再次核查了 Web 服務器、數據庫服務器、業務日志、數據庫日志，以及其它的一些監控數據，各項皆正常。

試著在本機 ping 了一下域名確實不通，更加懷疑是網絡問題，嘗試著直接使用外網訪問，可以打開沒有問題，可以基本確認服務沒有問題，但運維部反饋網絡設備什么都正常，肯定是你們投產代碼出問題了，各方硬著頭皮繼續在排查。

9 點，群里開始有大規模的用戶反饋官網和 App 都打不開了，更有部分用戶煽動，XXX 公司跑路了(2015 年很多 P2P 公司跑路，導致用戶都成了驚弓之鳥，稍微有問題便害怕公司跑路，個個都鍛煉成了監控高手，天天看，實時刷，凌晨起來尿尿也都順便看一下 App 上的今日收益)，客服 400 熱線基本被打爆了。

一邊繼續排查問題，一邊上報此問題給總監、公司各高管，給客服建議，給用戶解釋，IDC 機房網絡抖動，技術正在緊急解決，資金和數據都沒有任何影響，稍安勿躁。

10 點，開發和運維反復的檢查后，開始懷疑 DNS 解析有問題，但具體是什么問題還不清楚。

于是 CTO 決定：

• 大家都打車往公司走，來公司集體解決。
• 在各 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 服務器再返回給客戶機。

這個事情發生后，給了我們很大的四個教訓：

• 流程管理有漏洞，離職交接不到位。
• 危機處理不成熟，影響公司聲譽。
• 監控機制不完善，像外網不通的這種問題，應該提前設置監控措施。
• 有時候非常嚴重的問題，就是你常常忽略的小問題引起的。

點擊查看當時寫的 DNS 更新手冊