提升解決問題能力的思考

這兩天線上有兩個定時任務之間產生了衝突，可以說是線上遇到了一些問題，在兩天解決問題的過程中，感覺自己的所作所為有待於改進。其實就是解決問題的能力還不行，經過思考，感覺有以下值得注意的地方

注意點

1. 解決問題需要時間。一下午跑了好幾趟，但是都沒有想清楚

假如突然之間遇到一個問題，如果這個問題是自己寫的bug，可能有很多原因導致，(對業務不熟，分散式系統中其它系統不可靠，自己的粗心)，都可能會產生問題。

然不同的條件引起的錯誤型別不同，如果剛出現問題立刻去說問題是怎麼回事，一般是不全面的

• 對業務不熟，那麼立刻去彙報，肯定還是不熟，彙報的還有問題
• 不可能只考慮正常的情況，沒辦法假定其它系統一定沒問題。“你自己寫的程式碼都有bug，你能保證其它的系統沒有問題嗎”，要考慮多種情況，防止其它系統產生的問題波及到自己的系統，其它系統可能出現問題，但是不要影響到我們，不要跟著其它的系統一起出問題。
• 自己的粗心，粗心的問題可以統一歸結為沒有看重自己所做的事情

因為不同的情況，會產生不同的問題，第一反應我們不可能整理出所有情況，除非問題特別的緊急，否則最好先沉下心來想想是怎麼回事，好好整理問題。第二天再去彙報怎麼回事，什麼原因，產生了什麼問題，有什麼解決方案，涉及到的技術(服務，資料庫，MQ)。

2. 每個欄位的含義要清楚。概念要理清楚

和現實生活一樣，概念不清楚就好做出錯誤的決定，錯誤的選擇。就比如說order_status，理解為訂單狀態，那麼什麼是有效和無效呢。

• 有效：訂單已下單，並且未取消。在短租資料庫中的體現就是有這條訂單記錄，而且不是已取消訂單
• 無效：訂單未下單，但是preAuth表有申請、凍結記錄的。 訂單已下單，但是取消了, 實際免押型別不是芝麻免押的。(PreAuth表可能有記錄，也可能無記錄)

可以看出來這個欄位代表的意思太多了，這種就是不好的設計，如果設計以及存在，就要儘量的明白這種概念所代表的各種含義。

如果讓自己設計，設計的時候就要賦予欄位唯一的含義。並且字如其名。如果早期設計的好，order_status分為兩個欄位：(存在問題，底層儲存了業務層的內容，乾的事也不乾淨了)

• order_exists
• order_exempt_type

這個暫時也沒想好，可能要多個人討論，內部的人又共同的認知。

3. 一定要刨根問底。

比如這次系統，短租傳過來的MQ不對，找短租，短租說是mapi傳的啥，他們就是啥，找mapi，mapi說給短租的肯定是正確的，追蹤呼叫記錄，是wap呼叫mapi，mapi傳給短租錯誤資料，短租給我們錯誤資料，我們沒有考慮到會有這種錯誤。

問mapi，mapi拍著胸脯說肯定沒問題，但是事實上肯定是有問題的。(由業務邏輯推匯出的)

系統出了問題，大家包括自己都不願意承認是自己的問題，會推給其它的系統，大家相互推脫，因為寫的時候肯定覺得自己沒有問題，不然就不會往上面寫了。我們要做的是檢視日誌，還原客觀事實，實際是怎麼樣子的就是怎麼樣子的。

從自己的系統往下追蹤，問清楚明白，檢視日誌到底是什麼樣子的。這種刨根問底的習慣要培養。

弄清楚是什麼樣的原因導致的這次問題？

出現這個問題的系統一定要聯絡下。

最後

每個公司都會有自己的業務，業務千變萬化，出現的問題也是層出不窮，可能每天都有問題要解決，只有抓住了根本，學會了解決問題的能力，才能不至於疲於奔命。

不管什麼時候 對工作要頭腦清晰 ，除了關注技術 業務一定要精通 要理清 前後關聯要很清楚才行