一個成功的軟件，全力開發(fā)的時間可能占其整個生命周期的1/4還不到，軟件發(fā)布后要運維（Operation），運維的視角和開發(fā)的視角是很不一樣的，但是有一點，運維的數據能反哺開發(fā)，同時，開發(fā)的時候也得考慮可運維性，其中非常重要的一點是日志，沒有日志，運維就瞎了大半。怎么寫日志，就得從運維的需求來看了，通常會有以下一些常見的場景（已典型互聯網應用為例）：

1. 訪問來源，包括訪問量，訪問者數據，如用戶名、IP等等。

2. 基于上一點細化，訪問的接口，讀、寫、刪……

3. 軟件系統內部的核心鏈路，比如我這有個系統要在中美直接同步文件，那同步的情況運維的時候就要掌握。

4. 軟件系統對其他所依賴系統的訪問情況，比如我這個系統依賴一個分布式緩存，那訪問緩存的量、是否超時等情況需要了解。

5. 系統異常，比如磁盤滿了。

記錄這些信息的目的大抵有：幫助分析系統容量方便擴容；在系統某些部分工作不正常的時候及早發(fā)現；發(fā)生嚴重故障后方面定位問題原因。認識到這些需求后，下一步就是怎么實現的問題了。

前面提到的5點，有些可以通過拋異常實現，例如訪問分布式緩存超時，有些則顯然不是異常，例如就是正常的緩存訪問。我覺得可以用一種統一、規(guī)范的方式記錄，這種方法就是打碼。我記得以前用Windows 98/2000的時候，經常會遇到藍屏，藍屏上會有一堆我看不懂的英文，并且總是伴隨著一個錯誤碼。

雖然我看這玩意兒沒一點好心情，但我相信微軟的工程師肯定能從那個奇怪的狀態(tài)碼上判斷出是哪里出了問題，硬盤壞道？光驅卡死？諸如此類……其實類似的做法數據庫也用，比如MySQL。

用統一的代碼表示錯誤（也可以表示正常但核心的業(yè)務點）***的好處就是便于搜索、統計和分析，在動輒數以萬行記的日志文件中尋找感興趣的信息，一頁一頁翻看是不現實的，稍微做過點運維的必然會用上 grep,awk,wc 等工具，這個時候如果信息都有代碼標識，那真是再方便不過了！例如，我用代碼 FS_DOWN_200 表示對系統的正常下載訪問，日志是寫在 monitor.log 文件中的，我就可以使用一行shell統計4月22號5點到6點之間的正常訪問量：

$ grep FS_DOWN_200 monitor.log | grep "2014-04-22 05:" | wc -l 

具體每條日志記錄什么，那就是更詳細的了，基本就是時間、日志編碼、額外的有用信息，如：

2014-04-22 05:06:18,561 - FS_DOWN_200 216 UT8TFSDXc8XXXagOFbXj.jpg 

除了時間和日志編碼外，還有響應時間（216ms）和具體訪問的文件名。

當然如果你有日志監(jiān)控和分析系統就更棒了！你就可以在系統中錄入關鍵字監(jiān)控，比如每分鐘統計次數，然后看一天、一周的訪問量趨勢圖。進一步的，如果這個量發(fā)生異常，讓系統發(fā)出報警。如果沒有關鍵字，從海量日志中分析紛繁復雜形態(tài)各異的信息，再監(jiān)控，是非常難的一件事情。

為什么要把日志代碼設計成 FS_DOWN_200 這樣子的，下面稍微解釋下，這個代碼分成三段： 
1. FS： 表示我們的系統，這是***的級別，公司中有很多系統，那各自定義自己的標識。 
2. DOWN： 表示我們系統中的一個核心業(yè)務點或者對其他依賴系統的訪問，還可以是UP（上傳），SYNC（同步），或者TAIR（對緩存系統訪問）。 
3. 200： 具體健康碼，參考HTTP規(guī)范，200表示OK，其他包括404（不存在），504（超時）等等。

有了這些代碼，再結合公司的監(jiān)控系統，我們做統計分析就非常方便了，每天多少下載、多少上傳、多少成功、多少失敗、對其他依賴系統訪問多少量、多少失敗率，一目了然。進一步的加上監(jiān)控，當某些值突然發(fā)生變化，比如下載量/上傳量暴跌、訪問其他系統依賴超時大量增多，就能及時響應。

日志對于運維實在太重要了，而如果不接觸運維，又怎能理解其真正的需求，因此我說，不做運維，不懂日志。