墨菲定律，萬一就是一萬。
此次上線，是時隔開發結束，測試結束後一週開始的。預計兩小時上線完畢，結果最終弄五小時才結束，還要繼續保持警惕。通過昨日上線兩小時後獲取的日誌，以及此前莫名打出來的console日誌，繼續分析上線在這段時間內有沒有別的問題。

此次的上線設計三個專案，兩個獨立程序PED,PEO以及一個WEB工程UM，都存在較多改動。針對改動，我提前整理了 資料庫改動SQL，配置改動標記，測試服程式包。
專案除PEO之外都有較多改動，包含新功能的聯動開發，以及實用性的增強開發。

上線於下班之後開始：

第一步，將整理的所有相關專案的資料表修改SQL提交，彙總並一一執行，資料庫基於ORACLE，新增欄位為可空欄位。這一部分沒什麼問題就解決了。

開始第二步，上線，從比較容易上的獨立程序開始，PED為非同步操作的獨立程序，不涉及及時性資料資訊，於是先上。獨立程序封裝為Jar包，使用shell指令碼啟動，此處注意配置檔案Config路徑，不使用Jar包中所用，所以若配置存在改動，打Jar是沒用的。(這是一個錯誤點，開發時間線太長部分配置忘了，由此導致第一個耗費時間的問題！)

第三步，PED啟動之後，繼續準備啟動PEO，同理。PEO相關及時性處理，所以啟動時注意資料庫是否出現新的變動資料，發現較長時間沒有新的資料之後，開始ShutDown原獨立程序，更換Jar包，將原始Jar備份以供回滾。

此時PEO上線暫時結束，回看PED的處理情況，檢視資料庫變動情況。發現關鍵資料沒有插入！PED出現問題，同時檢視PEO有成功資料，然後專注於PED的問題。檢視伺服器日誌，報出java.lang.NullPointerException，空指標問題，最終定位到Service入口處，是拓展的新功能處。馬上先殺掉PED，回滾至原始PED，開始解決問題。針對於新功能Service中的入口處的判斷，進行了單元測試，發現並沒有問題，膠著一段時間。度秒如年。最終由他人從程式碼提交的更新中發現，是存在配置改動，引起空指標是由於Service沒有注入，那是我新加的，赧顏。兩個月前的改動，偏偏今天上線給忘了。還好的一點是，發現了，並且在排查過程中因為極端情況又解決了初始化的一個問題，立馬重新打包，再次上線。期間觀察PEO中是否有即時資料的操作成功動態。

第四步，實際上在獨立程序上線後啟動的時間段內，繼續上線UM，一個WEB專案的war包，部署在Jboss的叢集中。這次把更改的配置一一記錄清楚了，全部替換成上線所用。期間，關於JNDI配置提交錯誤一次，由測試庫轉到正式結果還是使用的測試資料庫。耽誤了不少時間，叢集的伺服器啟動需要5分鐘。除了疏漏之外，暫時未發現程式碼上的問題，剩下就是資料庫為登入使用者配置選單許可權，以及本地新增配置目錄。叢集中使用兩臺伺服器，要測試session共享問題。在session如何通過路由器共享的這裡耗費時間較多。配置虛擬IP來登入伺服器，將session共享到3031兩臺伺服器之中。檢視資料庫，各個關鍵資料的寫入情況，以及翻查日誌記錄問題。
最後，UM還有個問題，就是正式資料對於現有UM中的操作邏輯以及不太合適了，要重新整理。

總結，針對複雜情況的把握，以及突發情況的應變能力還是要加強啊。強記不如紮紮實實的整理上線文件，預測可能出現的問題。上線之後留意中單，翻看日誌和資料庫。本來應該很順暢的上線，磕磕絆絆了一點，總結以吸取教訓，加油。