工作中如果遇見XX系統出現問題了，我們的第一反應是什么？你的內心活動肯定是：是自己的鍋和坑嗎？連蒙帶猜，趕緊看日志，有錯誤日志還好，但是沒有錯誤日志啊？參數的問題？窩草，方法的入參忘了打印了，添加打印日志方法，發版，看日志……，這樣有點太Low了，小哥哥下一篇給你說一下日志系統，這篇先說解決問題的套路，我相信干什么事情都有套路的，比如學駕照，學英語，撩妹等。
什么是問題？
1. 上下文 -- 和問題相關的場景，指一組已經是明確已知的，關於問題的條件的描述（比如訂單-產品-支付-庫存肯定有關系）。
2. 目標 -- 指關於構成問題的結論的明確的描述（讓系統更流暢，更高速的，更穩定的運行）。
3. 障礙 -- 指問題的正確解決方法不是顯而易見的，必須通過一定的思維活動，才能找到答案。
良好的定義問題是解決問題的關鍵步驟。
定義問題就是鑒別期望和現狀的差異。有如下幾個關鍵點：
1. 首要的是，收集整理關於現狀的可信的信息，而不要假設已經擁有完備的可信信息；
2. 不暗示傾向於某種原因或者解決方法；
3. 只陳述現狀和期望的狀態；
4. 在解決問題的過程中，問題的定義可能（有必要）會不斷的改進或者轉換形式。
把問題描述理解清楚，不要掩蓋問題，把問題公開化，透明化，解決完問題最好自己再總結一下(二狗子，高中時候的糾錯本你給忘了)。
心態
靜心：在定位問題之前，最好先安靜下來，摒除雜念。放下自己的身份（項目經理、開發人員），以解決當前系統的問題為中心。靜心之后，將問題現象在腦中過一遍，弄清問題。
問題解決者不輕信，不盲從
不確定定問題的時候，不要說大概是什么問題， 絕不因為一句“應該是對的”，“大概沒有變化”，“我昨天沒發版，之前都是好的”，而拋棄一個懷疑的點。
大局觀：不要盡早的陷入細節
實際上，在整個問題定位和解決的過程中，都應該盡量在頭腦中對整個系統的映像以及當前位置保持清晰的認知。這樣有助於前后、上下聯系，在更高更廣闊的空間中發現問題。在解決問題的時候提醒自己：我現在處於一個什么位置？如果不啟動調試環境我能不能解決掉這個問題？
預判斷，然后驗證：
讓我們一起debug,注意environment(dev,qa), zone,region,contextPath等，盡量將日志、調試、Postman等都用作驗證問題的工具——首先對問題的原因做預判斷（猜測），然后確定該原因會導致什么現象，然后驗證該現象（日志等）。預判斷比驗證更應被關注。
當很難預判斷問題位置時，可以采用排除法：每次排除系統范圍的一半左右，逐步將包圍圈縮小到問題原因本身。應注意：排除的過程中，同樣要注意驗證排除的是否正確，即：排除、驗證、排除、驗證……
關注日志
日志一定要看明白NumberFormatException: For input string，NumberFormatException: Value out of range，Duplicate entry，Data truncation: Data too long for column……，很多問題解決過程中其實打開日志文件就能馬上得到結論，但是開發人員寧可自己猜也不願意動手打開日志，那么日志該怎么打印？留個懸念，下篇說。
工具
工具是讓人用的，善於借助監控和運維工具排查問題，會有一些童鞋說，我壓根就沒權限看到這些東西，springbootadmin，zipkin，log history，zabbix等，記住我們是解決問題的，沒有權限也是問題，我們要去解決。
這些大致是一些常用的解決問題的套路，歡迎指正。說了這么多，全靠實戰。就像看了好多《如何脫單》一樣，扎心了……，最近時不時的有點焦慮，我覺得解決焦慮的最好辦法就是看書，學習，運動，做家務等，不要讓自己閑下來，看下圖！！！願代碼是你的“柳飄飄”，你就是是“尹天仇”！
