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

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

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

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

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

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

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

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

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

用統一的代碼表示錯誤（也可以表示正常但核心的業務點）***的好處就是便于搜索、統計和分析，在動輒數以萬行記的日志文件中尋找感興趣的信息，一頁一頁翻看是不現實的，稍微做過點運維的必然會用上 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）和具體訪問的文件名。

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

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

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

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