作為普通開發，可能都有過這種感受，正在瘋狂的coding運營 測試跑過來，有投訴，線上出問題了、有報警，線上出問題了，內心不免一驚仔細排查后發現：第三方問題，要找第三方解決、網絡問題要找網絡組解決、配置錯誤，你們運營配置有誤、正常業務錯誤，用戶輸入數據有誤，等等等，一方便耽誤了我們coding改變世界，一方面因為我們去日志定位問題需要時間，但可能問題在我們這里並解決不了，白白延長了解決問題的時間。
不免抱怨明明日志里都有read time out了，你找網絡啊、找通道方啊，他們服務掛了，明明通道返回system error這是他們的錯誤啊，你找我能解決嗎？Flume Kafaka elasticsearch 都搞好了你們倒是用啊！！！！，但這能怪運營嗎？你可能覺得system error很簡單，但他們知道嗎？不覺心里替運營一陣委屈。這明明是你自己挖的坑啊！寫代碼的時候，我們只是從自己的角度捕獲了異常，記錄了各種出錯堆棧信息，對我們足夠了，但有時候可能這錯誤第一手並不是我們看到的，一個穩定的產品，大多數的錯誤可能都來自於用戶投訴后運營的反饋，這個時候，如果他們在日志平台上看到的不是system error，而是“支付網關通道下單，單號：{123231312}，通道方返回錯誤信息：{system error}”，完美，鍋已經走遠了，這個錯我們不背所以日志記錄不光是面向程序員，也要面向運營，面向產品，面向測試，面向一切可能查看日志的人員，要知道，我們的編碼產品是面向用戶的，但我們的日志是面向我們內部人員的，遠遠不止我們開發自己，所以在實際開發，一套合理的日志規范至關重要，玩不可玩逼格高，只是定義一堆為了方便數據分析，業務監控等而打印出只有統計代碼和我們自己看得懂的日志。
一、不要丟了中文
不要認為各種英文和符號才是逼格高，但並不實用，可能代碼懂、我們懂，但並不一定其他看日志的同事懂，甚至下一位繼續維護代碼的程序員也看不懂越是簡單易懂的日志，就會有更多的同事替我們分擔查日志的問題，想想都輕松的不行（奸笑）
二、要有統一明確的規范
統一的日志規范是老生常談的問題，統一規范不但有助於后期日志的分析統計，更對我們平常查詢錯誤結果一目了然，可能相關問題我們輔助運營查一次，解釋一次，以后類似問題，他們就可以自助查詢，去分析，到底應該找哪個部門，哪個同事去解決相關問題，這個規范不是以前的只考慮機器，只考慮錯誤堆棧分析，還要考慮除了開發和日志分析系統以外的其他同事。良好的規范要包括以下信息：打印日志的系統、打印日志的業務、業務單號、報錯系統名稱（自己系統報錯？渠道報錯？上游系統參數錯誤？）、錯誤信息，其他的如響應時長、調用參數等依據業務去做相關的打印當然還要注意敏感信息的脫敏處理。
三、簡單易用的日志平台
日志寫好了，如果是讓運營去敲命令也太low了吧，而且互聯網公司的業務日志也很多，系統調用復雜，所以必須有一個完善的日志平台，去串聯起來系統間的調用日志，現在開源的ELK很方便的，開可以以此進行二次開發那就更好了