解決問題的通常套路

        工做中若是碰見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等，記住咱們是解決問題的，沒有權限也是問題，咱們要去解決。

       這些大體是一些經常使用的解決問題的套路，歡迎指正。說了這麼多，全靠實戰。就像看了好多《如何脫單》同樣，扎心了……，最近時不時的有點焦慮，我以爲解決焦慮的最好辦法就是看書，學習，運動，作家務等，不要讓本身閒下來，看下圖！！！願代碼是你的「柳飄飄」，你就是是「尹天仇」！