最近兩周因為一個升級搞的精疲力竭，一共熬了四次通宵。睡了一天，總算把覺補回來了。
不得不說這次升級非常失敗，為了從哪跌倒從哪爬起，為了以后不再這么悲催，我總結下我收獲的經驗教訓，希望對那些和我們處於同一水平線的項目有些許借鑒意義。
預則立，不預則廢
准備不充分是我們這次犯得最嚴重的問題，從開發到測試再到運維。雖然為了這次升級我們已經忙了幾個月，但是在升級這件事上還是過於樂觀了，或者說不重視。
先說開發，低估了工作的難度和復雜性（這應該算是程序猿這個物種的通病吧），一而再再而三的出現任務延遲。這次升級主要內容是對原來用C#寫的系統用Java重寫，所以從編碼的角度來說沒什么難度，只是時間問題，但可能就是因為“沒難度”導致重視不夠，最后上線的前一天還發現了好幾個bug，開發測試關鍵時刻總是在做救火的事
另外，上線准備的時候，低估了一些工作所花的時間，導致上線時大分部時間花在了數據遷移上，當出現問題的時候發現留給自己的時間已經不多了。
討論、討論、然后就沒有然后了
其實准備開始的足夠早，考慮到一次性升級的東西太多，也計划分步驟來上線。有會議記錄，有文檔，有郵件……，但是結果卻沒有按計划的時間點執行。 至於原因很多，可能真的是太忙了吧。
環境問題
測試環境：
1、 首先測試環境非常混亂，組件那么多，都部署在一台機器上，相互影響的可能性誰也說不清楚；
2、 一開始一直沒有提供一個完整的集成測試環境讓客戶端集成測試，導致集成測試不充分。
3、 測試環境和現網環境差距比較大（部署結構、數據量、硬件…）導致性能測試的結果沒有100%說服力，升級過程中發現好幾次測試環境性能ok，上線后卻出現了問題。
現網環境：
1、 幾台機器的環境不一致（部署路徑不一樣，mysql版本等），直接的影響就是出現問題的時候，變量太多了，由不得大家不亂猜，結果就是越猜越亂，時間都浪費在了驗證各種變量和配置上面了。最嚴重的是導致修改了一天的驗證性工作都白做了，嚴重打擊了大家自信心，大伙本來就累得夠嗆還感覺在做無用功，效率極其低下。
2、 硬件的問題。當最后定位發現時硬盤有問題的時候，運維同事自己都說“這機器不適合做服務器”，我只能“呵呵”，熬了兩個通宵，眼皮都抬不起來了…
3、 現網優化不足，比如mysql就發現查詢緩存沒有開啟。
應對問題的准備不夠
一開始過於樂觀，風險評估不足。沒有做好應對問題的打算，比如提前准備好profile工具，開啟mysql的慢查詢日志……尤其是第一次升級失敗后，第二次仍然過於樂觀，拍腦袋認為問題已經解決了，最后導致第二次升級基本白做。
每次升級都應該抱着最壞的打算。
補充：導致升級反復的另外一個重要原因就是測試環境驗證的問題。尤其是第一次升級失敗后，沒有仔細分析現網的數據，沒有把現網的包拉下來做對比驗證，就妄下斷論。后面幾次驗證出現反復的修改回退代碼，手動打一大堆包，測試環境的變量總是不停的變（一會連這個庫一會連那個庫，一會這個配置一會那個配置），最后我們自己都弄不清哪個包對應哪個版本，因為時間緊中間做的一大堆驗證測試都沒有做記錄，后果就是像無頭蒼蠅一樣，做了很多無用功。中間暴露了兩個問題：1.缺乏數據收集（包括日志記錄不詳細，驗證沒有做記錄等）；2.分析問題不足（有日志也沒有仔細分析）。第一點相對來說容易解決，第二點我想除了技術能力，經驗非常重要。
技術問題
首先需要自我反思的是引進的一些新技術沒有能夠研究透徹，導致上線后性能很不理想。隨着系統負載壓力越來越大，不像之前網上隨便找找復制粘貼拿來用就可以了，不光知其然還要知其所以然。
從這次暴露出來的問題，我覺得我們可以朝以下幾點努力，其中有的我們已經嘗試在做了：
1、自動化部署。我們現在的部署方式太原始了，完全依賴手動操作，有多少台tomcat測試就要准備好多少個war包，而且依賴測試手動的去一個個修改配置文件，效率太低。當然一口吃不了個胖子，可以先逐步的腳本化。
2、 配置管理。這次升級過程中發現配置太多，而且寫在一個本地文件里，開發、測試和上線，版本庫就那一個文件，相互影響，上線時候依賴測試手動修改，太容易出錯了。要想實現自動化部署，首先要解決的就是配置問題。
3、自動化測試。和自動化部署目的是一樣的減少人力的投入，減少失誤。解放人才能提高生產力，現在我們的測試手段還是比較落后的，還是依賴測試一個個去手動執行用例，像上線后驗證這種工作完全可以腳本自動化完成。
4、服務降級。系統應該具備一定的降級能力，這樣出現問題的時候，可以通過拒絕一些出現問題的服務來保證其他服務正常，這樣可以邊驗證已經上線的功能一邊修復問題。
5、平滑升級。完全的平滑升級不太可能，但做一些系統升級的時候如何在盡可能不影響現有服務的情況下完成升級是很值得思考的。其實我們這次升級最欠考慮的一個地方就是把后端存儲結構也一起改了，這就導致新系統和老系統完全不能兼容，上線和回退的成本都比較高，非常浪費時間。最后我們也是調整了方案，讓后端存儲保持一致，先從nginx拉一點流量到新部署的tomcat上，發現沒問題，再逐步的遷移，等所有web應用服務器升級完了，下次再考慮升級后端的存儲結構。
團隊發展
我們現在這個項目正處於一個發展階段，而運維已經先行動起來了，慢慢規范起來了，現網各種權限只有運維有，現網的操作完全依賴運維一個人操作，這是必然的趨勢，時代不同了，不再是當年一兩個人時開發測試運維一人全包了，但是在自動化部署、持續集成等等這些都還沒來得及跟上的這個階段，升級的瓶頸往往就出現在運維這塊了。這次升級發現一個無賴的情形：部署時或出現問題時一大堆人圍着運維，有的干瞪眼，有的不停說着運維不熟悉的業務方面的術語，效率非常低。當下敏捷和DevOps非常流行，不知道是否可以解決這個問題？
最后想對自己說的是：不斷提高自己的能力，做一個讓別人值得信任的同伴。