***xx倉，倉code ：
1.開啟聯運收貨
2.配置發貨dts-是否針對加工品
3.越庫回傳dts
4.採購開啟多配多發開關
5.開啟配貨單接收開關
6.開啟波次完整性校驗開關
7.取消、延期介面開關
8.開啟內部倉開關
9.庫存占用開關
作為ums整個鏈路的入口，現在接單這邊主要維護兩個開關，b2boutdecouplingwids和b2bwarehouseidlist
b2boutdecouplingwids為接耦名單，dts占用和生成揀貨單都依賴該開關進行占用
b2bwarehouseid是b2b倉白名單
開關推送
16:54 產品通知新開倉開關
17:15:56進行開關推送
diamond反饋推送成功
正常發布
20:11:10開始灰度部署
20:30左右反饋缺貨出
21:00開始回滾
發現是實操打包完成依賴開關outdecouplingwids為空
檢查日誌發現是diamond解析報錯
問題原因
開關推送diamond該配置是乙個字串的解析，該推送在末尾存在乙個無法肉眼識別的回車
該解析**:
private void parseoutdecouplingwids(string config)
try
outdecouplingwids = lists.newarraylist(set);
// 容器載入完成，靜態變數載入
outdecouplingwidconstant = lists.newarraylist(set);
} catch (exception e)
}
邏輯是解析報錯只會記錄乙個日誌資訊，系統仍然使用上一次推送快取的值.
這樣的結果就是線上正常執行，只是推送值無效。
4. 3. 正式發布機器重新啟動。diamond的init方法開始去解析配置最新值, 依舊解析錯誤，正式發布機器無法獲取配置，獲取的值為空
4. 4. 線上機器與發布機器的開關不一致，發布機器上的rf請求打包依賴的開關配置為空，打包缺貨出回傳
問題解決
umx緊急評估影響主要在缺貨出，由於已經回傳，相關鏈路需要進行資料訂正
各個域相關同學進行資料訂正
拉取2019-02-20 00:00:00 ～ 23:40的缺貨xx訂單資料
整理出其中需要訂正的缺貨的單子, 同步客服處理退款的方案
整批次缺貨出的訂單篩選是否需要重新下發
根據履約單單狀態，給出不同的處理方案在途庫存不需要訂正，實物庫存根據第二天的配送，需要ums跟庫存進行對比訂正
財務根據配送結果進行缺貨訂單的訂正
後續action
開關配置注意避免使用回車與空格或中文等特殊字元, 推送完要盡量確認各種指標是否正常
開關解析**需要優化, diamond配置不像switch強行定義的推送型別，推送成功失敗有明確的反饋，因此需要格外注意
diamond解析錯誤監控需要配置
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
記一次線上快取問題
今天上線專案時，檢視乙個軟體列表，我的介面裡是findall,可是軟體列表裡沒有type欄位沒有出現，後來檢查發現 是線下softmodel裡type欄位沒更新過來，清完線下表快取，並用gii重新生成了下softmodel，然後再次上線。再次檢視線上該軟體列表，還是沒有type欄位，估計第一次檢視的...
記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...