這次救的火救的時間有點長，持續(xù)一年多，總共4次，每次去廈門大概1個月左右，每次去救火都是頂著巨大的壓力，還好每一次我都不錯的活著回來了。

　　這個項目與很多要救火的項目一樣，項目交付第一，質(zhì)量被拋在后面，幾十人的團隊不斷往上堆需求，沒有人做架構(gòu)看護，沒有人真正關(guān)注能否持久，只要功能實現(xiàn)了，暫時不出問題了，沒有人care你的代碼寫的怎么樣，可維護性怎么樣。

　　在這四次救火中，舉2個印象最深的例子，有一天晚上9點多，領(lǐng)導(dǎo)給我打電話說廈門某項目的系統(tǒng)今天下午系統(tǒng)掛了一次，他們在那邊搞不定，希望我能出差支持一下，我說好的那我明天去，領(lǐng)導(dǎo)說能否今天晚上就去，沒辦法，訂了10點多的機票，匆匆忙忙的趕到機場，由于飛機晚點，到廈門已經(jīng)是凌晨2點了。到了以后，我還沒找到地方住下，廈門這邊的PM就給我打電話，直接去他們的辦公場所解決問題，于是直接去了廈門軟件園，到了以后，當(dāng)時心里是很感動的，因為還有一波人在那里等著我一起和他們解決問題，想想大家都挺不容易的。

　　于是開啟了我連續(xù)2天2夜沒有睡覺的先河，接下來在11天的時間里每天凌晨2到3點回酒店。先不說這些苦逼的加班了，再多的加班，如果不能解決問題，都是徒勞的。我們先是把之前發(fā)現(xiàn)的一些問題做了梳理，然后我開始閱讀他們寫的代碼，開始優(yōu)化，測試，但是在頭2天里，仍然抵擋不住用戶訪問的洪流，系統(tǒng)在連接2天上午高峰期間掛了，下午掛了，甲方的在當(dāng)?shù)刈畲蟮念I(lǐng)導(dǎo)就站在我們的背后看著我們的系統(tǒng)掛了，重啟。當(dāng)時的心理壓力是巨大的，但是我心里有底的，因為在前面幾年磨練中，我已經(jīng)遇到過絕大多數(shù)的問題，我對linux操作系統(tǒng)有足夠的了解，我對java有足夠的了解。

　　但是一開始開出的藥方，似乎總是命不中要害。這時已經(jīng)臨近春節(jié)還有十多天的時間了，領(lǐng)導(dǎo)發(fā)話，如果此問題不解決，除了扣分以外(影響收入），所有的人春節(jié)都不允許回家。雖然外部不斷的施壓，但是當(dāng)時我還是有信心解決的，我仍然在不斷的在現(xiàn)網(wǎng)patch代碼，分析日志，直到第3天，我給出一個當(dāng)時絕大多數(shù)同事都不太認(rèn)可的方案，將合并部署的數(shù)據(jù)庫單獨遷移到單獨的數(shù)據(jù)庫服務(wù)器上。他們認(rèn)為這個方案的成本太高，從服務(wù)器的下單、到貨、安裝在短短十天的時間很難完成，如果遷移到新的數(shù)據(jù)庫上仍沒有解決問題，我們就一點退路就沒有了。大部分人都不同意這個方案，而我相信自己的分析，一遍遍的拿出充分的數(shù)據(jù)做圖表分析，當(dāng)時幸虧自己熟練的寫perl腳本，做了很多分析的工作。為什么要遷數(shù)據(jù)庫到新的數(shù)據(jù)庫?

　　我們的系統(tǒng)的數(shù)據(jù)庫是和另外一個系統(tǒng)的數(shù)據(jù)庫是合并部署在一臺小型機上，這臺小型機號稱是IBM性能最猛的服務(wù)器，內(nèi)存好像是128G,處理器是64核，因為我發(fā)現(xiàn)我們的系統(tǒng)的sql的執(zhí)行時間不穩(wěn)定，從單個sql來看，執(zhí)行時間最高的時候會比正常的時間高于30%左右，這樣看來問題不明顯，但是不要忘了，我們?yōu)槭裁磼斓墓δ苁且粋€非常復(fù)雜的功能，一個流程有大量的sql執(zhí)行，如果這些sql執(zhí)行時間都很慢，那么整個流程就會慢很多。這也是為什么他們懷疑的