前言
挺長時間沒發文了，因為公司有一個緊急專案要趕進度，加班如吃飯喝水，久違的進入到碼農的狀態。
之所以抽空來發個文，是這個專案才剛上線，時間不長卻因為一位新同事的程式碼引起了生產環境的事故，造成了一批短款，差點讓整個團隊這段時間的努力付諸東流。
所以，本著好人一生平安的處事原則，百忙之中我依然抽空以文章的形式把這次事故記錄下來，希望有做支付相關功能的同行們能夠引以為鑑。
經過
1、包裝簡歷不是錯
大家知道，每年到這個時候就是一個公司人員變動最頻繁的時候，有些是拿了年終獎走人，有些人是騎驢看唱本，找到下家然後走人，反正這個時間就是傳說中的金三銀四。
如果公司這個時間有緊急專案，一定是你難受我難受大家一起難受的階段，因此，為了應付這種情況，人事頂著很大壓力招人，往往不一定能招到合適的。
我們公司年後就入職了一位新同事，就是專門為這個緊急專案招過來的，簡歷我有看過，3年工作經驗，熟悉Java、SpringBoot、SpringCloud、SpringCloudAlibaba，還會docker、k8s，會前端vue、uniapp用法，有過微信小程式開發經驗，且熟悉微信支付、支付寶支付開發。
其實，前面熟悉java、springboot、springcloud什麼的，我們面試沒遇到過不寫的，基本上沒當回事，而後面的docker、k8s也只是個添頭，因為來公司沒人會讓開發同事來操作，會點前端的vue倒是加分項，最重要的是最後一句，熟悉微信支付、支付寶支付開發，這一點一下戳中了人事的軟肋，因為主管特別給人事提過會支付功能的優先考慮，所以人事打電話瞭解後極力推薦給主管。
主管看後發給我看，我們其實心裡都有數，這簡歷裡面的專案一看就是包裝過的，因為大家都這麼過來的，寫的3年經驗，大部分其實只有1年或2年，偶爾能遇到沒有經驗但盲寫3年的，對於中小公司而言，面試人員包裝簡歷不是什麼問題，重要的是能幹活就行。
改天主管就喊我一起去給這位同事面試了，這人口條很好，我們問的很基本，都是挑他專案裡寫過的技術來問，基本上都能答出來主要的，主管心裡也很滿意，面試完後就給人事說讓他入職了。
2、能幹活不一定會幹活
新同事來週週一入職的，經過了簡單的培訓，立馬就要投入到緊急專案中，好在這是個新專案，不需要他額外熟悉既有的業務，產品評審過後就開始分配工作，因為人員變動導致的工作積壓，我和另一位老同事手頭上都有離職人員交接的工作，需要日常維護老專案，加上同時參與新專案開發，有些力不從心，主管考慮到這點，就把新專案微信支付相關的功能都交給了這名新同事，因為他簡歷中確實寫了會這部分，而且面試時連我也覺得他明顯是會的而且做過的，後面事實證明只是他口條好罷了……
從真正開始做專案，我就發現此人會的確實挺多，但問題更多，比如git工具只會pull和push，遇到程式碼衝突不知道如何解決，瞬間拉低了他原本通過面試在我心中塑造的等級。
再比如他很喜歡使用try..catch，每個介面都加，卻不知道我們本身就統一了異常管理，更可怕的是catch中竟然寫e.printStackTrace()這玩意也提交上去，我專門給他提醒後他才改成log.error("xxxx:{}", e.getMessage())，我當時看到也無語了，又跑去說你不要getMessage()，這樣生產環境不好排查問題，改成log.error("xxxx:", e)就行，他當時反問我這樣能列印出來東西？此時我心裡已經蒙上了一片陰霾，也發覺到他對我三番四次跑去指點他似乎有些許不滿。
工作忙起來後很多時候你不是領導，你也不太想管那麼多，管好自己就行，我也懶得再管他了。後來證明我這種心態也是隱患之一，團隊開發成果是由大家一起決定的，果不其然最後出事故連坐了，誰也逃不掉。
3、事故來的就像龍捲風
等到專案進入提測階段，測試出來的BUG雖多，但總體不錯，新同事負責的那部分之後也通過測試了，我當時覺得他其實還是挺有能力的，支付這塊業務上還是有很多痛點的，他能自己一個人做完確實不容易，簡歷上雖然包裝過可幹活還是可以的。
專案上線後，大家都鬆了一口氣，畢竟是個緊急專案，也牽扯到公司今年的戰略規劃，能完成對我們老同事來講是一種解脫，對新同事來講是一種自我價值的證明，3個月沒到他提前順利轉正了。
那句話怎麼講來著，是福不是禍，是禍躲不過，今年屬蛇的人據說犯太歲，這才剛開年，我果然間接中彈了，專案上線不到一個月，某天上午客戶方突然出現大量短款，造成直接損失接近十萬元，好在我們駐點人員較多，緊急情況也有備案，接到通知後馬上關閉了開關，等到高峰期一過，才重新開啟開關繼續執行，否則很可能持續造成更大損失。
大家心都快跳出來了，好在接下來整個下午都很平靜，沒有再出現問題，我們根據經驗立馬判斷是上午那段時間處於流量高峰期造成的。
排查日誌後發現竟然是微信退款的回撥中進行業務確認時大量失敗，從而造成了大量短款。
至於分析和解決的過程，在後面分析小節中會說明，這裡提一嘴，這名新同事知道問題是自己造成的後臉都白了，那會兒說話也不利索，還被其他同事埋怨了幾句，樣子別提多可憐了，看著讓人心酸，事故處理完成後他自己就離職走人了。
我能感受到這次事故對他的整個程式設計師人生都是一次重大打擊，臨走前還專門找他說了些安慰的話之類的，把改正後的程式碼片段也發給他作為參考，我這人比較心軟，見不得相處一段時間的同事那麼難受，還把他推給了以前公司熟悉的人事，幫忙給他找新工作，我能做的也就這麼多了。
最後客戶方追回了損失大概六七萬，還有兩三萬追不回來了，因為是短款，人家不退你也沒辦法，這還是在我們駐點人員響應及時的情況下，否則可能今年和這個客戶的生意徹底要黃了，公司後來交代事故原因時也沒有說是我們程式碼寫的有問題，全部推給呼叫業務確認介面超時引起的，同時賠償了沒追回的金額，最主要是領導層關係很硬，這一劫算是度過了。
分析
前面講了，排查日誌後發現是微信退款成功後回撥中進行業務確認時大量失敗，從而造成了大量短款。那麼很多小猿猴就很奇怪，我說的是什麼意思。
這裡就要提下微信支付等支付功能開發過程中的必要流程了：
支付：建立業務訂單---> 建立支付訂單---> 喚起支付收銀臺---> 輸入密碼或指紋支付---> 進入支付回撥處理 ---> 更改支付狀態及業務狀態
退款：建立退款訂單---> 發起退款---> 進入退款回撥處理 ---> 更改支付狀態及業務狀態
主要的流程大概是這樣，裡面還有一些細節，這裡針對本次事故著重說下回撥處理這塊，當一個支付完成後，微信會發給我們的回撥介面進行最後的業務處理，正常來講只需要更改我們自己的業務表狀態就行。
但如果你的專案不是公司自有產品，而是給客戶做的，牽扯到客戶自己的業務系統，那麼就很有可能需要在回撥中專門去呼叫客戶系統提供的業務確認介面，簡單來講，就是你要告訴客戶系統這筆支付完成了或失敗了好讓業務系統做一些自己的邏輯處理。
我拿這次事故專案的業務為例，客戶系統的支付環節有一個前提是從號源池中取號，而退款時要進行退號或銷號。這裡就不單單是一個微信支付的簡單實現了，而是一個重要的業務邏輯實現。
大家可以思考下，我們到底是要先取號再支付還是先支付再取號，同樣的，退款時我們是要先退款再退號，還是先退號再退款呢？
我相信，如果不是經常做支付相關業務的小夥伴，在沒有經驗的情況下一定會寫錯的，而這裡就是我們這位新同事犯的問題：
在退款時，他的程式碼邏輯寫的先退款再退號，在流量高峰期，因為try...catch中寫了異常時自動退款，結果剛好發生了預料之外的異常，開始自動退款，好死不死的客戶方業務系統也有問題，最終導致退款執行成功了，呼叫客戶方業務系統退號確認介面時卻確認失敗了，結果就是錢先退給使用者了，號卻沒退掉（人活著，錢沒了），在客戶的業務系統裡這就是一筆短款。
究竟正常的邏輯是怎樣的，我以這個案例給大家梳理下就清楚了：
1）、支付時，一定要先完成支付，再處理業務系統的業務。
比如這裡就是先支付再取號，這樣的好處就是，正常情況下沒事，異常情況下要麼支付失敗就不走後續，要麼支付成功但後續取號失敗，這樣你服務的客戶方沒損失，損失的是使用者，因為使用者已經付錢了，這就是一筆長款，客戶方只需要根據使用者反應的情況審查一下然後退款給使用者就行了。
相反，如果你寫反了，導致的其中一種後果就是使用者先取了號，但支付失敗了，使用者依然可以拿著號來用，這對客戶方就是一種損失，錢沒收到號還能用。
2）、退款時，一定要先完成業務確認，再執行退款。
比如這裡就是先退號，再退款，這樣要麼退號失敗不會往下走，要麼退號成功，但退款失敗，損失的依然是使用者的錢，客戶方怎樣都沒損失，形成一筆長款，審查過後確認情況沒問題再退款給使用者即可。
相反，如果你寫反了，導致的後果就是先退款，但退號確認失敗了，客戶方的號還沒退回來，但錢已經打進使用者賬戶了，客戶方就損失了，還得找使用者追回來，如果使用者不給你也沒辦法，因為是你自己的失誤導致的，這就形容嚴重事故了。
案例分析梳理的邏輯，不僅僅在這裡適用，在其他場景也是適用的，大家可以多看看仔細揣摩下，任何和錢打交道的功能開發都要謹慎，支付功能實現一點都不難，有現成的工具可以使用，難的其實還是業務，遵循一個原則：不管你的業務邏輯怎麼寫，只要正常及異常情況下，你服務的客戶都不會虧錢，那麼你的支付邏輯就是正確的。
總結
現在新技術非常多，學起來累不說，還卷，我誠心給大家一點建議：
1）、減少對熱門流行技術的病態追逐，沉下心來把基本功打紮實，進入公司後需要用到的開發工具、開發流程、程式碼規範等等多花點心思學習，因為你就算把分散式技術學的再厲害，這些蓋房子用的工具不熟悉，會很容易被看破手腳；
2）、進入公司第一件事，熟悉業務場景，這往往才是你在公司往後的立身之本，工作時間越長你越會明白；
3）、簡歷不要過分包裝，包裝無可厚非，很多人都這麼幹，都是為了生活，但過分包裝會帶來隱患，比如這裡講的這個同事，專門把微信支付等功能作為亮點，結果缺乏真正的經驗導致事故。
最好不要在簡歷中牽扯到支付相關的介紹，可以說參與過，但不能形成亮點，因為和錢有關的技能都不簡單，多對簡歷中的專案進行潤色更有效果。
純手打，覺得有一滴滴幫助的話，麻煩點個推薦吧啦吧啦~~~~~~
也可以關注下我，本人專注分享工作中的趣事和實戰經驗哦~~~~~~~~