【工做隨筆】兩個線上問題（不停機發布&大型字符串hashcode出現負數）以及解決方案

      自從去年11月入職新公司後，工做職責忽然擴大了，不只僅是測試開發，連部分QA的活也幹了，這其中就包含了線上發佈。

      說實話，從11年工做到如今，第一次接觸到項目發佈，而後就發現了幾個比較有記念性的問題：

      問題一 ：不停機發布 && 沒有關閉服務入口致使髒數據。

      系統架構：    咱們這個系統是用戶經過web調用service，service作用戶登陸校驗和各系統調用，business系統就是其中一個系統。

     系統使用狀況: 這個系統是給公司經銷商和內部人員用，用戶不到1500，使用頻率更是一月5~6次。

      之前提發佈流程，我都是隻提單要求發佈對應服務。此次也不例外，直接部署business。沒想到碰巧有個經銷商在提報活動，根據後來我查數據以及比對代碼，代碼是已經走到business的事務裏，調用了額度系統，準備調用審批流程系統時，服務剛好重啓，即若是審批流程系統沒有數據，這個事務也沒了，活動表也就沒有數據。咱們business作的事務一致性只能保證其餘服務掛了時會回滾數據，本身系統重啓就只能毫無辦法，咱們系統也沒有定時任務給重要的數據作數據一致性檢查，因此這個問題直到昨晚由於經銷商一個普通諮詢才發現。 綜合考慮，這種問題仍是在發佈的時候就能夠防範，發佈時直接先把web停了，發佈好business再啓動web，左右不過幾分鐘的事，卻能避免一些諸如：經銷商錢被吞了一部分這種大問題。

 

       問題二：一個線上纔會出現的問題。

      公司重質量重視到嚴格執行測試流程的地步，不壓縮測試時間。因此這個變動我是在release分支測試結束後，代碼反合再合併到master分支後迴歸測試主流程，都沒問題。發現線上後，借了業務帳號再試，結果發現了一個坑。流程系統在流程拒絕後不發消息了，由於開發爲了讓不一樣系統發出的消息有順序的被業務系統消費，將非數字型code取hashcode再排序，因爲線下數據少，不會出現問題。線上數據多，code取hashcode後變負數，就不發消息了。   這個問題經過黑盒測不到，由於這個不是業務需求，只能經過代碼走查方式了提早發現。再否則就是等用戶發現不對後，前來反饋。

 

     解決方法：

       項目開發過程當中，需求文檔只能做爲方向，具體小細節仍是每一個開發人員本身定，這就致使了有些問題測試發現不了，上面的問題二就是這種狀況。至於停機發布，我所經歷的項目都沒有停機發布過，最可能是選擇一個用戶使用頻率低的時間範圍發佈，因此問題一的狀況也避免不了。 

      既然問題沒法從源頭解決，那能夠換個思路，啓用數據檢查機制。就像人類沒法讓本身不生病，可是能夠按期體檢同樣。可使用腳本或者存儲過程對數據庫裏重要的那部分數據進行按期檢查，檢查時間則參考各個項目。