系統崩了，竟然是不規範列印日誌的鍋？

　　如果你是一名優秀的應用系統開發人員，想必應該非常清楚在應用系統執行期間，列印日誌有多麼重要。它不但能夠記錄應用系統執行情況及軌跡，還有助於提升故障排查及定位問題的效率，甚至還可以對其進行分析及監控，洞察系統隱患，提前預警防範。

　　但並不是說只要列印儘可能多的日誌，就能輕鬆獲得這些能力。設想一下，如果你肆無忌憚地列印了一堆毫無價值的日誌，那請問日誌又何以能夠來為你提供價值呢。由此可見，這裡的核心關鍵點並不在於日誌的多少，而在於日誌列印是否規範且合理。

　　不規範合理的日誌，不但無法發揮作用產生價值，還會增加故障定位難度、降低解決效率，以及額外增加日誌儲存成本，消耗應用系統效能。在極端情況下，甚至還會對應用系統造成致命性打擊，引發應用系統癱瘓的可能。

　　講到這，我想你應該明白我想說的——應用系統日誌列印確實非常重要，但日誌列印規範將更為重要，它就像一把雙刃劍，只有合理運用才能發揮其特有的作用及價值。

　　但在組織中，如果你想讓你周圍的人都能明白這個道理可並不容易，它需要一個漫長的傳播過程，而在這個過程中，你不僅需要堅持不斷地宣導來逐步增強他們的認知，還應藉助必要的治理手段及工具平臺進行輔助，只有利其所器，才能善其所事。

　　 利器一：規範先行

　　在你想啟動規範化日誌列印前，建議先制定一份日誌列印規範，它可能無法面面俱到，但沒有關係，它的目的僅是為了先突顯日誌列印規範的重要性，並且讓這件事情能夠正式進入正軌。

　　如果組織中大部分都是Java應用，那麼規範內容可以主要圍繞Java應用來寫，雖然無法覆蓋所有開發語言，但其核心原則仍是可以借鑑的。另外，前期請務必不要將其複雜化，否則它將無法具備普適性，也無法被接受和傳播。

　　Java應用系統日誌列印規範

　　1）Java日誌框架

　　常用的Java日誌框架可選擇Log4j/Logback/Log4j2等，但為了避免後續更換日誌框架所帶來的額外改造成本，建議將介面層和實現層進行分離，將SLF4J作為介面層，將Log4j/Logback/Log4j2作為實現層，兩者透過橋接的方式進行整合。

　　2）Java日誌規範

　　規範一：【強制】級別只允許使用ERROR、WARN、INFO、DEBUG，定義如下：　　

　　規範二：【強制】禁止使用Logback/Log4j2等的API，應使用SLF4J的API。

　　規範三：【強制】在介面/方法的入口/出口處，列印請求及響應引數日誌。

　　規範四：【強制】ERROR級別日誌需列印堆疊，而非ERROR級別日誌則不需要。

　　規範五：【強制】禁止在程式碼迴圈體中直接列印非DEBUG級別的日誌。

　　規範六：【強制】禁止日誌列印內容中僅列印特殊字元或數字的情況。

　　規範七：【建議】日誌內容中應包含關鍵特徵類資訊，例如：使用者標識或流水號。

　　規範八：【建議】應採用非同步列印模式，且列印時建議關閉列印位置資訊。

　　規範九：【建議】日誌列印若出現堵塞，建議至少丟棄INFO級別以上的日誌。

　　規範十：【建議】每條日誌在語義上可獨立被理解，減少上下文關聯理解。

　　3）Java日誌欄位　　

　　注：位置資訊包括類(class)/檔案(file)/行號(line)/方法(method)，若列印位置資訊，則對效能有所影響。

　　以上僅是一些規範參考，你可以根據組織中的實際情況來進行調整，但規範僅僅只是規範，有了它並不代表你已達成目標，只能說明你已為日誌列印規範化這件事，邁出了第一步。

　　 利器二：服務至上

　　當制定完應用系統日誌列印規範後，請不要幻想有任何人會來自覺地遵守它，一是不知它的存在，二是他們無從下手，三是大家都挺“忙”的。我把它總結為六字真言，分別是“不知”、“不會”、“不想”。

　　我曾見過組織中的有些規範，特別是技術規範，在制定完成後就會被長久地封存起來，沒有人知道，也沒有人想知道。所以，要落實好規範，你還得構思一套戰術才行。否則，那些無法落實的規範就和廢紙毫無兩樣。

　　在很多人眼裡，可能會將規範視為是一種約束，而又錯誤地將約束理解為貶義詞，從而避而遠之。這種誤解的發生，其原因並不出在他們本身，而更多的出在那些制定規範的人身上。

　　有些規範制定者不但沒有身在其中，甚至也沒有去詮釋規範所能帶來的價值，而僅僅只是強行推行那份冷冰冰的規範，請問此時誰會樂意在不知其所以然的情況下，無緣無故地背上這沉重的“負擔”。

　　因此，你必須得為這份規範賦予更多的“溫度”，而主動服務可能會是一種比較好的“升溫”方式。但在行動前，切忌不要站在他們的對立面，並請做好放低姿態的覺悟，你要讓對方深刻的意識到你和他們是同一陣營的。

　　在釋出規範後的初期，你可以嘗試挑選幾個日誌列印情況最為糟糕的應用系統，扮演為“VIP私人助理”來與對方進一步傳達規範內容及作用，併為他們逐一列舉出當前存在的日誌列印問題，以及這些問題會對系統造成哪些影響。

　　這種方式不但能夠避免僅用文字傳達所產生的理解偏差，及時有效地為對方解答各種疑問，使他們能夠更深一步地理解規範內容及作用，還能夠讓規範制定者更進一步地瞭解對方的顧慮及困難，並從同理心視角出發，為對方提供更好的建議及解決思路。

　　就這樣5個、10個、15個應用系統......在精力有限的前提下逐步擴大輻射範圍，事實證明，這種主動服務+循序漸進的方式對提升規範的接受度將會有所幫助。不過在過程中你仍然需要不斷回看規範的合理性及適用性，並對規範作出及時且有效的調整。

　　 利器三：度量為王

　　當規範逐漸被更多的人接受後，你的使命並沒有完成，而真正的考驗才剛剛開始。一是接受並不代表整改，二是如何驗證整改有效性，三是整改是否可持續性。如果這些問題都不在你的考慮範圍內，那你可能會前功盡棄。

　　若想要解決以上這些問題，藉助度量或許會是一個不錯的選擇。管理大師德魯克曾說過：“沒有度量，就沒有管理”，它同樣適用於規範的落實工作，你可以根據日誌列印規範來制定一些度量指標，並配套研發相應的度量工具平臺。

　　透過度量工具平臺“視覺化”和“自助化”的兩種特性，讓開發人員能夠及時發現日誌列印規範的問題，還能夠讓他們自主驗證日誌列印規範整改後的效果，從而讓他們感受到一種“看得見”+“摸得著”的安全感。

　　其中，度量指標的設計將會尤其重要，往往一個不合理的指標，會讓整個事情朝著預想中的反方向發展。所以，在初期並不建議你設計過多的度量指標，並建議從度量難度、影響程度、達成難度、可解釋性四個方面進行綜合性評估，以確定較為合理的指標。

　　如下是當時初期選擇的8個指標。　　

　　注：以上僅列出指標，指標要求建議你可根據實際情況進行動態調整，但過高的指標要求會變得毫無意義。

　　可能會有人提出，對於規模較大且日誌條數較多的應用系統，是否可放寬指標要求，這聽上去好像蠻有道理的，但我卻並不這麼認為。規模越大意味著所承載的職責和能力也就越大，一旦發生故障影響面也就越大，所以反倒更應該達到指標要求。

　　這些指標雖然有一定的指導性，但似乎並不能滿足開發人員的“胃口”，因為這些指標仍然無法直接暴露問題根源，也無法讓他們可快速定位及明確最佳化方向。因此，你還得賦予指標一定的分析能力。

　　例如：訂單系統單日ERROR級別日誌888條（佔日誌總量0.05%），90%在com.OrderService的第88行。（TOP2）10%在com.PayService的第188行。

　　就這樣，你可以逐步完善指標體系及配套的分析能力，但請在設計每一個指標時，遵循先進行系統現狀摸排，再進行小範圍試點執行，最後進行持續觀測並調優，從而確保每一個指標的設計都具備一定的合理性和可解釋性。

　　如下列出了一些指標，僅供參考。　　

　　

　　

　　除此之外，你還可以將不同應用系統的指標進行橫向對比，並採用排行榜的形式在科技內部進行公開，它將會產生一種改變行為的驅動力，可以有效激發“想要贏”和“不想失敗”的心理活動，這就好比某些產品也會採用排行榜的方式來激勵使用者一樣。

　　透過設計指標體系+研發度量平臺+公開排行榜單這三個手段的組合，在一定程度上可以驅動開發人員持續性整改日誌列印的問題。但萬事無絕對，那些始終無動於衷的人依然會存在，不過請不要強行要求對方，畢竟有時候存在即合理。

　　 寫在最後

　　日誌列印規範固然重要，但也請不要過分追捧，它的核心價值還是在於能夠幫助開發人員更好地記錄應用系統的“案發現場”，並可為應用系統提供可持續改進的“線索”。但請牢記，日誌列印規範雖不是全能的，但沒有日誌列印規範卻是萬萬不能的。