這次救的火救的時間有點長，持續一年多，總共4次，每次去廈門大概1個月左右，每次去救火都是頂着巨大的壓力，還好每一次我都不錯的活着回來了。
這個項目與很多要救火的項目一樣，項目交付第一，質量被拋在后面，幾十人的團隊不斷往上堆需求，沒有人做架構看護，沒有人真正關注能否持久，只要功能實現了，暫時不出問題了，沒有人care你的代碼寫的怎么樣，可維護性怎么樣。
在這四次救火中，舉2個印象最深的例子，有一天晚上9點多，領導給我打電話說廈門某項目的系統今天下午系統掛了一次，他們在那邊搞不定，希望我能出差支持一下，我說好的那我明天去，領導說能否今天晚上就去，沒辦法，訂了10點多的機票，匆匆忙忙的趕到機場，由於飛機晚點，到廈門已經是凌晨2點了。到了以后，我還沒找到地方住下，廈門這邊的PM就給我打電話，直接去他們的辦公場所解決問題，於是直接去了廈門軟件園，到了以后，當時心里是很感動的，因為還有一波人在那里等着我一起和他們解決問題，想想大家都挺不容易的。
於是開啟了我連續2天2夜沒有睡覺的先河，接下來在11天的時間里每天凌晨2到3點回酒店。先不說這些苦逼的加班了，再多的加班，如果不能解決問題，都是徒勞的。我們先是把之前發現的一些問題做了梳理，然后我開始閱讀他們寫的代碼，開始優化，測試，但是在頭2天里，仍然抵擋不住用戶訪問的洪流，系統在連接2天上午高峰期間掛了，下午掛了，甲方的在當地最大的領導就站在我們的背后看着我們的系統掛了，重啟。當時的心理壓力是巨大的，但是我心里有底的，因為在前面幾年磨練中，我已經遇到過絕大多數的問題，我對linux操作系統有足夠的了解，我對java有足夠的了解。
但是一開始開出的葯方，似乎總是命不中要害。這時已經臨近春節還有十多天的時間了，領導發話，如果此問題不解決，除了扣分以外(影響收入），所有的人春節都不允許回家。雖然外部不斷的施壓，但是當時我還是有信心解決的，我仍然在不斷的在現網patch代碼，分析日志，直到第3天，我給出一個當時絕大多數同事都不太認可的方案，將合並部署的數據庫單獨遷移到單獨的數據庫服務器上。他們認為這個方案的成本太高，從服務器的下單、到貨、安裝在短短十天的時間很難完成，如果遷移到新的數據庫上仍沒有解決問題，我們就一點退路就沒有了。大部分人都不同意這個方案，而我相信自己的分析，一遍遍的拿出充分的數據做圖表分析，當時幸虧自己熟練的寫perl腳本，做了很多分析的工作。為什么要遷數據庫到新的數據庫?
我們的系統的數據庫是和另外一個系統的數據庫是合並部署在一台小型機上，這台小型機號稱是IBM性能最猛的服務器，內存好像是128G,處理器是64核，因為我發現我們的系統的sql的執行時間不穩定，從單個sql來看，執行時間最高的時候會比正常的時間高於30%左右，這樣看來問題不明顯，但是不要忘了，我們為什么掛的功能是一個非常復雜的功能，一個流程有大量的sql執行，如果這些sql執行時間都很慢，那么整個流程就會慢很多。這也是為什么他們懷疑的地方，就是因為單個sql性能差異不那么明顯，但是他們沒有想到整個流程中會執行很多次sql. 另外我發現另外一個系統會不定時執行的非常耗資源的sql會拖累這個最猛的服務器，一旦服務器性能影響，在這台服務器上所有的進程都會受到影響。
其它人也沒有更好的辦法，最后只能采用我的方案，后來想辦法調借一套ATAE雙機，操作系統安裝，安裝Oracle數據庫雙機，這中間有一個小插曲，那天晚上甲方技術負責人都在幫我們一起來裝解決數據庫雙機的問題，搞過數據庫的同學可能知道，這些大型的軟件在安裝的時候因為補丁之類的問題，有時會出現一些難纏的問題。累了，大家就拿了硬紙板找個角落睡一會兒，在放假前3天的凌晨，我們完成了數據庫的遷移。
我還記得遷移完成以后大概是凌晨6點左右，等待着早上9點左右的業務高峰期，大家都很緊張，總共有近20台服務器，把top命令開着一直盯着，一上午服務器的CPU都沒有超過30%。接下來的3天也再沒出現過之前的服務掛的情況，CPU和數據庫的連接一直都穩定在安全范圍線內。
在放假前的最后一天，我和PM一起回了南京，在從南京機場回市區的路上他對我說，如果沒有你，我真的不知道該怎么辦，那一刻感覺自己做的事情還是挺有意義的。回到南京的時候，南京已經下了白皚皚的雪，回到公司的時候，大部分同事已經回家了，路上人很少，心情很好