日誌分析及網站運營改進實例

大家好，我是道哥。 此次活動有不少站長從戰略層面上分享了網站運營的思路，只是發現不少朋友一旦說了思路就很難將實例講細，所以我就以一個去年的實例，來和大家分享下我們是如何從日誌分析中發現問題，解決問題到最終總結教訓並優化網站運營流程的， 同時我會將細節講細也順帶普及一下日誌分析的方法，希望對朋友們有所説明。

網站運營中有一個環節至關重要，那就是資料監控及資料分析，否則出問題都不知道出在哪裡。 而爬蟲日誌分析做為資料監控及分析的一部分是所有SEO技術中最基礎的，但是卻不是最簡單的。 說基礎是因為所有的科學的SEO策略都必須依賴于資料分析，而日誌是為數不多的能直接瞭解搜尋引擎和我們網站發生了哪些交互的管道之一而且是流量到達之前的第一手資料。 說不簡單是因為資料的存儲及處理上，日誌從幾十MB，幾百MB，幾個GB，幾十個GB，幾百個GB，幾個TB用到的工具及部署難度是完全不同的：幾十MB用ultraedit等文字編輯器都可以做到資料的拆分 ；幾百MB的時候得用shell；而如果是幾個GB可以開始考慮利用Mysql或者其他行存儲的資料庫來存儲欄位切分後的結構化日誌了；幾百個GB可以上Infobright或者其他列存儲的資料庫了 ；如果達到TB那只有Hadoop的hive能夠解決了，目前在用Hive的SEOer我所知道的只有趕集網的zero大神了。

對於99%的站長朋友來說，shell用於處理日誌已經很稱職了，我目前用的也是shell。 這裡簡單介紹一下shell的概念，shell可以理解成*nix系統的cmd命令列，而日誌拆分中常用的shell指令有cat以及awk（實際上grep用的也很多，只是本文為了控制篇幅就不多介紹了）。 cat實際的作用是合併多個檔並且將標準輸出(stdout)的結果列印到螢幕上。 而awk指令其實當成程式設計語言都可以寫一本書的，他的特色就是可以按照分隔符號切分文字欄位並且處理，預設的分隔符號為空格。 以上兩個指令網上資料一堆，建議各位都花時間學習一下。

言歸正傳，作為網站運營的資料據監控體系的一部分，我們公司建立一個全自動爬蟲日誌分析的系統，功能上可以參考夜息的博文來看。 全自動化日誌分析腳本很好的起到了監控及預警的作用，但不是萬能的，日誌如果出現莫名其妙的錯誤，就還是得自己動手豐衣足食。 在去年12月第二周的周日誌監控報表中，百度爬蟲的301及302回應碼的抓取量大幅增長，這部分異常抓取量加一起一周漲了6w！ 因為一定時間內蜘蛛的抓取量是恒定的，那麼錯誤頁面的抓取上漲代表著其他頁面抓取的下降，在本例中，內頁受影響最大。 抓取量發生如此劇烈波動意味著肯定有地方出問題了，所以我們第一步需要確定的是具體哪些頁面出現了問題。

貼一條日誌記錄（目的是説明大家定位下面實例中awk具體的域分別是哪些，由於有競業保密協定，所以下面的關鍵區段我打碼了）：

<IGNORE_JS_OP>

接下來開始工作了，我們首先構造第一個指令進行查詢：根據上面的日誌我們可以知道利用awk分析日誌時HTTP狀態碼位於第九域也就是$9，而URI位於$7，那麼首先我們合併上周的日誌，從中提取出所有狀態碼為302的日誌， 同時將功能變數名稱及URI進行合併成完整的URL，最後我們拆分出返回302狀態碼最多的TOP10個的二級目錄，按訪問次數降冪排序。 由於當時忘了截圖了，所以現在就手打下面的代碼供各位參考：

cat 20121203.txt 20121204.txt 20121205.txt 20121206.txt 20121207.txt 20121208.txt 20121209.txt | awk ‘{if($9 ~ 「302」)print $16$7}’ | awk -F」/」 ‘{print $2}’ | sort | uniq -c | sort -nr | head -n10

在10個結果中發現abc（好吧，我可恥的打碼了）這個二級目錄格外搶眼，數量達到了2W，同時我對比了上上周302的資料，發現之前abc目錄也有302的問題，只是數量級在1K左右， 而且之前abc目錄下返回302的頁面是完全正確的。 至此我開始懷疑abc二級目錄下存在有異常情況，同時由於abc二級目錄下的頁面數量依舊眾多，我們如果要知道是具體哪類頁面有問題的話，還是得進一步往下細分。 我的思路很簡單，繼續挖URL的目錄層級確定問題出現的位置。

1，先計算abc目錄有多少次跳轉被百度爬蟲抓取到

<IGNORE_JS_OP>

2，多加一個判斷條件，判斷出問題的URL目錄層級具體是第幾層

<IGNORE_JS_OP>

<IGNORE_JS_OP>

<IGNORE_JS_OP>

3，在發現了出錯的URL的目錄層級後，我們將這部分出錯的URL提取個100條出來看看

cat 20121203.txt 20121204.txt 20121205.txt 20121206.txt 20121207.txt 20121208.txt 20121209.txt | awk ‘{if($9 ~ 「302」)print $16$7}’ | awk -F」/」 ‘{if($2 ~ 「abc」 && $4)print $0}’  | head -n100

通過上面的查詢發現了在不同次層網域的abc目錄下都存在同類錯誤URL(如domainname/abc/123/123)被爬蟲抓取到，那麼可以肯定這個一定是個批量存在的問題，而且是範本上有錯誤導致大量頁面受影響， 而絕不是個別頁面出錯。

既然如此我們可以順藤摸瓜了，最終發現問題是出現在了產品頁的相關產品連結模組上，在前一周上線相關功能時研發部同事為了省事，直接將此處的a標籤寫成了這種格式的相對路徑(<a href=」123456″>xxx </a>)，那麼當使用者訪問的當前URL為domainname/abc/123的情況下這類相對路徑在補全之後會變成domainname/abc/123456，這個URL是正確的。 但不巧的是，上線該功能的時候研發同時調整了rewrite規則，導致原先domainname/abc/123/這種不規範URL301跳轉到標準化的不帶斜杠的URL規則由於被覆蓋而失效了，結果就是domainname/abc /123/竟然返回了200代碼，而要命的是，相對路徑在這種情況下就被補全為domainname/abc/123/123456了，也就是我們日誌分析中最後發現的錯誤URL形式。 而這類錯誤的URL則又莫名其妙的匹配到了301和302的rewrite規則，於是乎錯誤抓取量一發不可收拾。 當時的截圖如下：

<IGNORE_JS_OP>

既然問題根源已經找到了，接下來就是制定解決方案：

1，修改產品頁範本：對相關產品連結使用根目錄起始的相對路徑(也就是<a href=」/abc/123456″>xxx</a>)；

2，增加URL標準化的rewrite規則：將帶斜杠的網址301到不帶斜杠的標準網址(Rewriterule ^/abc/([0-9]+)/$ /abc/$1 [R=301,L])

3，由於百度對301反應很慢，所以需要利用百度站長平臺中的網站改版工具的高級改版規則來加強URL標準化效果：替換規則為abc/#/<>，然後再填入兩個樣例説明百度匹配下即可。 這裡可以簡單說一下，替換規則中的#代表著任一數字，在我們這個實例中代表產品頁的數位id，而最後的<>則是將<>中的內容，此處其中為空，直接替換掉最近匹配到的文字，也就是URL結尾的斜杠。 但是可惜的是如果遇到的標準URL是帶斜杠的/abc/123/這種，那就沒法使用百度改版工具來做了，因為目前的站長改版工具的規則很刻板，也不像正則可以用後向引用，所以這種情況就只有囧的份了。

4，優化網站運營流程：本篇文章寫了很多的技術細節，以至於有點偏離運營優化的主題了，但是透過現象看本質，我寫清楚這整個流程，是為了告訴大家這個問題發生的根本原因實際上是運營流程出了問題，因為這類錯誤本是可以避免的， 是本就不該出現線上上的！ 上面的3個只是治標的方法，治本得從源頭做起：一，優化整個網站的版本上線流程，網站上凡是涉及到前端代碼更改的程式版本，都需要在測試通過後轉由SEO人員做前端代碼的質檢，相當於二次確認，確認過後才能發佈到正式環境；二， 開展針對產研部門的SEO內訓，並與產研部門建立起良好的溝通及信任關係（這要求SEO人員本身技術夠硬，得能使研發信服，同時還得有優秀的人際交往技巧及人格魅力），提高產研人員對SEO的理解及重視程度， 並將以前曾犯過的錯誤建立FAQ，保持更新。 三，BUG與績效掛鉤。 四，PUSH流程優化方案並落實。

最後總結：

1，資料（不僅僅是日誌）的監控很重要，最好能每週整理成圖表，重點看趨勢線，其次才看絕對值；

2，將大資料一步步拆分到小資料的過程很重要；

3，一個良好的工作流程才是保證整個團隊高效的重中之重；

題外話：
說道跳轉還有個小細節要說一下，那就是多重跳轉：A301到B，B301到C，C301到D等等，如果你網站的URL改版也很頻繁的話這個問題你遲早會發現，因為研發的觀點是不管跳2次還是3次還是100次， 反正能跳到最後一個最新的頁面了對他來說就行了。 但對於SEO來說這是個要命的事情，因為幾乎每多1次跳轉你都在損失舊頁面的權重傳遞百分比，matt cutts在youtube上的google webmaster專區談到過這個問題，google能接受的範圍也不過是one or two, maybe three，百度據我觀察基本也是最多2次。 回到運營流程的主題上來，如果研發每次遇到這類問題他都能意識到對SEO有潛在影響，並會主動問詢，那你可想像在這樣的公司做SEO是件多幸福的事情。