救火隊員的那些事(2)

　　此次救的火救的時間有點長，持續一年多，總共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一塊兒回了南京，在從南京機場回市區的路上他對我說，若是沒有你，我真的不知道該怎麼辦，那一刻感受本身作的事情仍是挺有意義的。回到南京的時候，南京已經下了白皚皚的雪，回到公司的時候，大部分同事已經回家了，路上人不多，心情很好