2017年經歷的那些靈異事件

2017年快要過去了，回顧這一年來，在業務代碼裏，開發新功能佔據70%，修復BUG佔了30%，在解決的這些BUG中，大部分都是代碼級別的錯誤，使用 Chrome Devtools 基本均可以解決，但其中有三個比較神奇，算得上是靈異事件了。

鬼打牆

有一次後端同窗重構了一下 DSP 廣告平臺的接口，讓 Java 服務化提供接口， PHP 作 web 控制層掌管路由和透傳接口，因而對以前的接口URL從新規劃統一了一下，內測沒問題後就高高興興上線了，然而沒過多久就有商家上報說頁面報錯沒數據，因而我趕忙復現，但怎麼都復現不出來，而後問商家瀏覽器是否是版本過低，網絡是否是不穩定之類的，但商家的瀏覽器和網絡環境都沒問題，這就納悶了，因而果斷找了一臺 Windows 機器（由於咱們都是Mac並且沒裝虛擬機），讓商家加 QQ 遠程協助看一下到底報了什麼錯，倒騰了半天，連上商家電腦，復現果真報錯了 NetWork Error ，打開 Chrome Devtools 一查， ajax 請求竟然沒沒發出去。看了一眼瀏覽器上那一排插件，懷疑是否是插件搞的鬼，發現竟然有屏蔽廣告的插件，大哥，你特麼本身都在咱們平臺上投廣告，你還裝屏蔽廣告插件。果斷讓他關閉這個插件，而後果真沒問題。原來咱們的接口URL裏有 advertisement 這個單詞，插件直接屏蔽了這個URL。沒過多久，又有一個商家報頁面沒數據，呵呵，咱們直接叫他關閉瀏覽器屏蔽廣告插件，結果商家告訴我仍是不行。?，仍是遠程協助查一下，發現開了隱身窗口，接口仍是沒返回數據，看到商家電腦右下角運行的系統殺毒軟件，眉頭一皺，難道是這貨搞的鬼？打開設置一看，赫然有屏蔽廣告這個選項。果真國產軟件都流氓，你這全部的瀏覽記錄都被人家知道了啊。次日果斷把 advertisement 改爲gg（guanggao），整個世界都清淨了。

斷頭鬼

過了一段時間，我司搭了一個前端錯誤監控平臺，能夠收集客戶端錯誤，上報到這個平臺而後郵件告警開發者。收集的信息包括用戶操做系統、瀏覽器版本、 IP 、操做路徑等，這樣就不須要再用 Windows 遠程了。某一天，告警平臺發郵件報錯，店鋪選擇頁面 js 運行報錯，那還得了，選擇不了店鋪，至關於咱們的後臺入口掛了啊。果斷按照報錯的操做路徑操做一次，又沒復現。再一看操做系統與瀏覽器版本，找了一個如出一轍的環境，仍是復現不出來。暈了，仍是用遠程協助吧。商家那裏確實有 js 運行報錯，因爲線上 js 也沒有 source map ，壓縮的代碼也看不懂，查半天也沒查出什麼東西。回到監控平臺後臺，反覆比對各條報錯。結果發現 IP 都是差很少的範圍，一查都是合肥電信的運營商，難道全部合肥電信的用戶加載的這個 js 有問題？而後報給運維同窗，他把那個 js 下載下來一看，長度不同，和正常的版本比，少了一小段。確定是 cdn 同步的時候，出了故障，果斷把鍋丟給七牛。

替死鬼

前幾天，有一次發佈後，一直收到郵件告警某個 base 的 js 運行報錯，涉及的瀏覽器版本都是Chrome 31到37，輕車熟路開虛擬機復現，找半天找了一個Chrome 31，確實報錯了，然而報錯內容看不懂。想着那天發佈內容包括升級基礎 react 組件，加了一個 babel runtime ，還有一些其餘的改動，難道是這些問題引發的？
而後嘗試想讓虛擬機 Chrome 運行本地代碼，因而在 win 裏面裝 node 、 git 、下載倉庫、打包、把線上代碼代理到本地。結果node-modules都裝不上去。而後再試試裝 fiddler 抓包軟件，把打包後的代碼放在 win 裏面，抓取那幾個 js ，替換成打包後的本地代碼，然而仍是看不懂，只知道是一個基礎函數，多是 babel polyfill 的問題，因而嘗試把前端倉庫那幾天的改爲一一 revert ，看看究竟是哪一個改動致使的問題。結果回退到發佈以前都仍是報錯，這就尷尬了，至此我已經花了一天時間去排查這個問題，期間讓幾個同事一塊兒排查也沒發現問題本源。
最後想着把 win 的網絡設置成 Mac 同樣的網絡，把 win 瀏覽器使用 SwitchySharp 設置成 Mac 的代理，這樣就能夠在 win 裏面使用 Mac 的開發環境，（其實就是在 Mac 起一個 node 服務，監聽一個端口，在這個服務裏把全部的線上的前端資源（ js , css ）替換成本地代碼，本地這個服務至關於一個網關服務器，還能夠把網址指向不一樣環境的服務器。）結果驚奇的發如今預發環境是沒有問題的，只有線上環境纔有報錯。個人第一反應是難道後端改造了什麼數據類型？把線上數據和預發環境數據比對一下，然而如出一轍。這個時候，對比兩個環境只有兩個差別了，一個線上環境多一個統計日誌上報的 js ，還有一個就是錯誤收集上報的 js ，問了一下這兩個 js 的維護者，果真統計日誌的js，在那次發佈的時候改動了，爲了使用Object.assign，加了一個 polyfill ，而後和 base js 裏面的 polyfill 衝突了，因爲統計日誌的 js 先加載，因此報錯是在 base js 裏面。
這個問題比較難排查的地方是：

1. 復現環境比較苛刻
2. 後端倉庫的改動（統計日誌的 js ）和前端倉庫產生了關聯，版本回退難以排查
3. 產生問題的 js 並非出現報錯的 js

總結

出現BUG在所不免，代碼邏輯、瀏覽器兼容性、網絡故障等等都會致使一些意想不到的問題，遇到問題首先不要慌，解決問題要有方法論，先把問題復現出來，而後使用 Chrome Devtools ，設置斷點，觀察數據條件，基本能夠找出代碼錯誤，其餘問題，能夠相似高中生物實驗，結合條件對照，找出差別的條件，定位到問題，這個過程當中須要敏銳的觀察力。