某網絡公司是新成立的B2B企業。當時，我是技術主管，擔任這家公司網絡平臺的架構、開發和管理的工作。在技術部同事的日夜奮戰下，不到一個月我們的網絡運營系統就全面上市了。之后三個月的運行過程中，系統除了修改當時需求不明確的地方外，運行相對穩定。當時的日訪問量已經達到100萬，Aleax排名在20萬名。

    我們的工作越來越輕松，每天就是檢查各站點是否正常，看著訪問量不斷增加。同時，我們也不忘未雨綢繆，開始向老板提出新的服務器方案。但公司當時決定把大量的資金投入到廣告上，基本不考慮我們的方案。

    直到有一天，技術部電話突然成了熱線……

  日均訪問量５０００萬

    那天，我剛到公司就接到業務部電話說網站打不開了。又過一會兒，老板也打來電話問我們的網站怎么打不開。沒過幾分鐘，老板再次打來電話說：“楊工，我們目前在各大門戶網站、搜索網站投入了大量廣告，趕緊找到網站打不開的原因，否則一天巨額的廣告費就損失了。”

    經過技術部同事的努力，網站很快恢復了正常。但不一會兒所有部門又都打來電話說網站打開什么都沒有。技術部的工程師打開來看，的確如此。我心想：“這是怎么回事？剛才不是已經恢復了嗎？”

    這次，我先讓網站正常運行起來，然后查看早上的系統日志。結果發現，早上網站一直是停止的，最后的日志是早上六點多的。可以肯定，它從六點到上班都不是正常服務的。進行Windows的TCP/IP連接分析和服務狀態分析后我們得知，在這幾天網站每天總的頁面訪問量均達到了5000萬。

    網站宕機的原因終于弄清了，那就是大量的廣告投入使每天網站的總頁面瀏覽量超過5000萬。這完全不在技術方案的預料中，而且公司的大量廣告投入技術部事先也不知道。這讓我們措手不及。

    那幾天我們上班不做別的，就8小時盯著服務器，一發現應用服務器內存/連接過高時，就重起服務。這樣基本上可以在3～5秒鐘之內完成服務的重起，網站基本保持不中斷。但可怕的是8小時之外，當所有人都下班了，要是服務停止，基本上就要等到第二天才有人知道。那幾天，每天晚上基本上老板都會打電話來說網站打不開，要求馬上處理。由于晚上訪問的人數相對要少些，基本上是重啟一次就可以堅持到第二天早上。就這樣一天一天地過去，我們對服務器的管理非常被動。我們一邊采用定時檢查服務的方法來維持系統的運行，一邊討論解決方案。

    公司重要的營銷計劃，只要與ＩＴ系統有關系，就都要與ＩＴ部門提前溝通，否則后果會很嚴重。

  第一步：重新規劃

    經過討論，我們決定對網站軟、硬件結構進行重新規劃，主要采用細分頻道、前端緩存技術、負載均衡、靜態頁面等技術。我們經過仔細分析發現，公司網站的基礎架構的確存在一些先天的不足，比如：所有頻道都在同一應用程序服務器中運行；只有一臺Web服務器，沒有做負載均衡；所有頁面數據均在訪問時從數據庫中產生；項目本身需求不明確，對網站的進程沒有明確等。這些都是導致系統沒法應對突發其來的高訪問量的直接原因。

    針對這些不足，我們分別采取了以下措施：首先，采用多應用程序服務器、分頻道的方式，分散網站的頻道到不同的應用程序服務器中，減輕同一應用程序服務器的壓力。其次，在所有應用程序服務器前端加了緩存服務器和負載均衡器，達到分流的目的。另外，我們通過生成靜態頁面，把以前在訪問時才調用的數據庫中的數據全部生成HTML文件。這主要是考慮內容系統，靜態頁面可以讓緩存服務器達到更好的緩存效果，同時也能大大減輕數據庫、應用程序的壓力。新方案的實施僅用了一周時間，我們就把以前的網站分成了幾個頻道，并加了負載均衡和緩存，這大大增加了網站的穩定性。網站宕機的頻率越來越小，整個技術部又恢復了以前的平靜。

    但是，無論多穩定的系統總是會有出問題的時候。為保證公司系統正常運營，我們在8小時內間隔性地查看各服務器的工作狀態，比如不定時地查看各服務器的CPU使用率、內存使用、磁盤空間、應用服務器工作狀態、APACHE的服務狀態、Oracle會話數、Oracle死鎖會話等。

    但是隨著公司業務的增加，服務器也開始迅速地增加，后來達到了四十多臺。要一臺一臺地檢查這些系統的運行狀態就得一臺一臺地登錄其中進行詳細查詢，這種被動的服務器管理使得我們的服務器運維成本越來越高。

    在充滿機會的時代，今天的小公司沒準就是明天的巨人。所以，ＩＴ系統規劃不能只滿足當前需要，而是要著眼于未來，考慮長遠，適應業務快速發展的需求。

  第二步：集中管控

    當時，網站普遍存在的問題是異常情況出現后，直接負責人不能即時發現。即使直接負責人有時發現了異常，由于受到時空的限制（比如無互聯網、外出等）也不能即時處理服務器的故障，使得服務器出現故障后不能即時恢復。這些故障如果出現在核心系統中還可能導致更嚴重的經濟損失。比如，如果是制造企業的MIS系統出現故障而沒有能及時發現和處理，每一小時損失可能就是上百萬元。

    工程師定時登錄服務器查詢各服務器的狀態、性能、服務運行狀態固然是一種維護服務器穩定運行的有效方法，但是人為被動地去查詢總是不方便的。因為首先，人不可能24小時不間斷地檢查服務器的運行狀態；其次，當服務器越來越多時，每一次檢查都將占用一上午甚至更長的時間，運維時間成本將不堪重負；同時，24小時值班監視服務器，人力成本也越來越高。

    技術部多次討論，設想如果能開發一套監控管理系統就好了，但是人力緊張，遠水救不了近火。

    如果采用一個平臺來集中監控和管理所有服務器，以上問題將都不存在，同時網絡運維人員也不再用24小時值班和定時查詢服務器的運行狀態了。集中監控系統將代替運維工程師實時監控所有服務器的運行狀態和各種性能參數，并在不正常時以短信、電子郵件等方式向直接負責人實時報警，使得服務器的離線時間、異常時間減到最少。

    最終，我們選用了上海哲濤科技研發的SUM（服務器集中監控與管理平臺）來實現服務器（異構）和網絡設備的集中監控。通過SUM，運維管理人員只需要登錄系統就會立即查看到哪些設備正常工作、哪些設備的哪些性能有異常。

    去年國慶節，技術部用手機查看服務器運行狀況，發現網站的訪問量真高，不過網站運行一切正常。即使宕機也不怕了，因為用手機就可以重起服務器了。

    技術人員會想自己做工具，這既可滿足個人的虛榮心，又可以在短期節約成本。但從長期成本和系統穩定性來看，還是買一個工具合算。