各行業應用五花八門　網站服務管理經驗分享

前言：不少公司都曾經歷過網站應用服務當機的狀況，就連Google、微軟(Microsoft)等大型企業也曾經發生，究竟如何才能維持網站的穩定度？增加硬體僅是其中1項作法，為求效果更加顯著，管理政策的配合也不可缺。

以下分別從提供線上選課的勤益科技大學、經營電子商務的燦星旅遊網，以及社群網站痞客邦(PIXNET)等不同行業的應用案例，與讀者分享其網站服務管理的心得。

◎勤益科技大學－2台伺服器搞定選課系統

勤益科技大學(以下簡稱勤益科大)的學生人數近1.1萬人，一般學校最少必須部署4~5台伺服器，才能支援線上選課系統所需的資源，然而該校卻只靠2台就能搞定，究竟是怎麼辦到的？

隨著網際網路興起，不僅交易可以在網路上完成，校園的線上選課系統，更是另一相當普及的應用。線上選課系統是提供在校學生透過網際網路、選擇必修？選修課程的管道，相較於傳統人工作業，可說便利許多。不過，線上選課也是令學校頭痛的問題，系統過慢或當機，容易引來學生抱怨連連。

勤益科大電子計算中心校務資訊組副教授楊勝智表示，線上選課系統容易遇到的問題可分為2個面向：

1、瞬間流量過高、系統無法負荷－學生為了選得自己喜愛的課程，往往會爭先登入選課系統，成功選中的機率才會較高，或是選好課之後，為了加？退選之便，而遲遲不肯登出，佔住系統資源，讓後進者無法登入，瞬間爆增的流量，容易使後端伺服器不堪負荷，導致系統處理速度變慢、甚至當機。

2、安全性問題－例如不少學校曾發生少數熟稔電腦、資訊技術的同學，自行設計類似「搶票程式」的「搶課」外掛程式，好幫助自己選中想要的課程，而影響其他人權益，有失公平性。為了維持選課系統正常運作，並在公平的前提下執行，對學校電算中心的人員來說，每逢選課期間，維護人員無不得戰戰兢兢、整裝以待。

負責勤益科大校務系統的專案人員朱孝國指出，2007年下學期選課時，恰巧在許多學生上網選課的午休時間，系統中斷10多分鐘，立即湧入許多學生的詢問、甚至抱怨電話。當下的處理方式，是立即將系統容納連線數改為500人，並將持續半小時無動作的使用者踢離系統，才讓系統恢復正常。

目前勤益科大總計日間部、夜間部、假日進修班學生約1.1萬人，就國立大學來說，屬中等規模，而當時勤益科大的選課系統後端只有1台伺服器，選課期間一下湧入2,000~3,000名學生連線，系統現有資源實在難以應付。

再者，選課系統採取「即選即上」的設計邏輯，也就是說，學生登入選課系統、填入想要選取的課程後，當下系統便會顯示出選課結果，學生馬上知道自己選中哪些課程。但是問題來了，系統的設計邏輯是，較早登入系統者，選到課的機率也較高，但是基於教學品質與教室空間，每一門課皆設有最多人數上限，一旦額滿，後續的使用者就無法加選這門課，學生為了選到自己心中的理想課程，紛紛搶在系統一開放的時候選課，如此也引發一些問題。

首先是公平性問題。朱孝國指出：「有學生向學校反應，部分同學為了搶在第1時間選課，寧願翹課，反觀認真上課的學生，卻因未在黃金時間登入系統，以致無法順利選到課，因此造成學生很大的反彈」；其次，則是影響系統運作效益，學生搶著選課，導致瞬間流量太大，再加上部分已經選到課的學生又不願登出，更讓其他人很難連進來，使系統變得十分緩慢、甚至當機。

工具、政策雙管齊下　強化選課系統效益

朱孝國表示：「2007年系統出狀況時，不僅接電話接到手軟，同時還得立即除排問題，壓力很大，電算中心當下就決定不讓上述狀況再次重演，於是開始思考解決之道」，最後，勤益科大分別從工具和制度面著手，改善選課系統的穩定度。

第一步是重新檢視系統架構，採購2台中階伺服器，並搭配伺服器負載平衡設備，先解決單一伺服器無力承受爆增流量的問題。朱孝國表示，因為伺服器從1台變成2台，所以必須藉由SLB平衡伺服器的負載量，SLB會自動偵測並將使用者請求導向負載量較輕的伺服器，讓系統彼此和諧工作，使用至今效益相當不錯。除此之外，導入時還有一些小細節必須特別注意，例如導入的SLB內建防火牆功能，可能會與既有防火牆設備略有干擾，畢竟經過2道防火牆檢視，多少會影響系統效能，此時，關閉SLB的防火牆就沒問題了。

另外，朱孝國在網路上找到1個提供免費小工具的網站－mon.itor.us，透過此軟體工具，系統會定時連線到遠端監控的網站、伺服器或主機，測試機器是否處於運作狀態，並可提供各式報表，一旦偵測異常，則以E-mail或MSN通知管理者，值得其他企業參考。

不過，增加硬體設備只是其中1種方法，「不要只想著藉由增加硬體來解決問題，制度的調整亦十分關鍵，我們同時將舊有的『即選即上』作法改為『登記制』，」楊勝智表示，所謂登記制是讓全校學生分階段選課，分別為延修生、當年畢業生、一般學生，再往下細分本系生和外系生，依照指定時間選課，把所有想選的課程登記下來，之後再透過一抽籤系統，隨機抽出人選，相較於過去的方式，登記制無法立即告知選課結果，學生必須等到隔天才能知道有沒有選到課；解決了公平性以及學生翹課來選課的問題，從學校的角度來看，不失為1項好方法。同時搭配動態圖片機制，學生必須先輸入圖片上的文字，才能登入選課系統，進一步降低學生採外掛程式、機器人選課的可能性。

在解決流量部分，朱孝國表示：「我們的作法算是避開問題，相信也有其他學校是正面迎擊，大家想法、作法不同。」確實，e化沒有標準答案，各企業、學校有其自身考量和目的，只要能解決問題，就是好方法！

◎燦星旅遊網－強化備援及負載平衡以穩定系統

學校因明確了解學生人數，因此規劃選課系統時，無論在程式設計最大連線數，或是採購主機數量時，都較能掌握大致需求；反觀企業，由於難以估算使用者實際數量，想維持系統穩定就更加困難了。

提供Web應用服務的業者，以電子商務(EC)網站為大宗，初期企業多礙於成本考量，而導致網路的承載量(Capacity)不敷使用，燦星旅遊網副總經理陳明明指出，一開始很難確實知道有多少使用者，考量成本之後，往往無法1次採購多台Web Server，或是無法進行完善的備援機制，例如燦星旅遊網成立之初，僅採購1台伺服器負載平衡，後來隨著業務量成長，才再添購第2台。事實上，當企業規模開始成長，再慢慢增加設備數量，是業界普遍的作法。

以燦星旅遊網為例，平均每日瀏覽次數約10萬，每月交易量約新台幣4~5億元，顯示瀏覽人數和交易量並不低；再者，促銷活動推出十分頻繁，如果有超低價1元搶標活動，更吸引眾多網友前來搶標，自然造成龐大的網路流量。由於公司不可能為了非日常性的活動另外採購設備，如此閒置成本將過高，這時，IT單位該怎麼做？

陳明明認為，要維持網站應用服務運作正常，只有2個重點：備援以及負載平衡，為了解決上述問題，燦星旅遊網分別從工具面和管理面著手。首先在工具部分，透過SLB設備平均分散流量予不同伺服器，並透過工具預留一些緩衝空間，當系統承載量即將滿載，系統會自動剔除新的使用者，防止伺服器當機，以免影響到交易進行到一半的顧客；此外，並利用網管工具監控流量，產出每日、每週、每月報表，以供日常管理參考，一旦發生當機，將有助管理人員快速找出問題所在。

其次，則是透過管理技巧，規避瞬間流量過大，以防網站當機。陳明明表示：「很多時候其實透過一些技巧就能避掉問題。」舉例而言，行銷單位規劃活動時，是從行銷的角度出發，只想著把東西賣出去，所以顧客來得愈多愈好，為了吸引人氣，就以1元等超低價搶標作為號召，但卻忽略了網路後端系統有無能力應對，因此，行銷單位與IT單位之間的溝通很重要。

燦星旅遊網內部的處理原則是，行銷單位提出活動企畫時，必須先與IT人員討論，由IT人員大概估算需要多少資源、系統能否應付，雙方再進行溝通協調，例如不要以1元搶標，改採999元…等，諸如此類的作法。難道燦星旅遊網不擔心，如此一來，將會因搶標的人數變少而影響業績嗎？陳明明解釋，若是來了一堆人，卻因系統無力負荷、造成當機而做不成生意，影響反而更大，因此不如換個方向思考，雖然金額提高可能使搶標的人數減少，但是仍低於市價許多，依舊很有吸引力，更重要的是，正常的IT系統才能讓生意做得成，對企業來說是有益的。

網站服務的所有環節都有當機的可能，例如內部伺服器當機、甚至電信業者線路故障，要避免網站服務癱瘓，大家都明白「保險」的必要性，問題在於，企業願意買多大的保險呢？一旦斷線，每分鐘會損失多少錢，答案因企業而異，故各公司投資IT系統的意願及金額也不盡相同，如何將錢花在刀口上，則是服務業者必須思量的問題。

◎痞客邦－力保Web應用穩定度　視網站服務為企業形象

「網站服務的速度和穩定度，就是企業的招牌」痞客邦就是以這種態度來管理網站，所以，Web服務經常當機的業者，可得當心壞了招牌、客戶不再來。

有在玩社群網站的人，對於痞客邦必然不陌生，其主要經營業務是近來很夯的部落格(Blog)與相簿。

痞客邦網站是由數個當時還在校的7年級大學生所創立，後來隨著業務、會員人數快速成長，後端IT系統的需求也不斷升高。痞客邦創辦人暨技術長曾皇霖回憶，創立之初的IT架構很簡單，1台機器同時執行很多功能，在考量效能、穩定度之後，開始依照功能採購不同的產品，例如AP Server、File Server、Database，而且伺服器橫向增加的速度很快，為了有效提升伺服器效益，於是開始將負載平衡概念引入架構中。

與絕大多數企業相同，痞客邦早期礙於成本考量，常自行利用一些方法或技巧，曾皇霖表示，最初採取Round Robin DNS方式進行簡易的負載平衡，舉例而言，當使用者欲連線網站時，瀏覽器會將請求發送到DNS(Domain Name System)，並向DNS詢問該網域(Domain)的IP位址，DNS則回覆IP列表中的第1個IP，這個IP位址代表Server A；換有另一人詢問時，DNS又回覆下1個IP－Server B，如此一來，自然將每一位使用者導引至不同的伺服器，進而達成負載分散的目的。

不過，後來逐漸感覺以Squid軟體進行負載平衡，必須個別管理每台設備，人力維護成本很高，而且效益有限，一旦系統出問題，平均得花30分鐘才能解決，考量專業性以及公司核心價值不在此之後，便決定採購硬體設備。

目前在AP Server(提供相簿、部落格應用)之前，採用硬體SLB分散流量，另外，在存放使用者上傳照片、音樂的File Server前端，則透過Reverse Proxy Server以加速網頁呈現，特別是靜態圖檔部分，效果十分不錯。由於多數用戶到社群網站是為了瀏覽照片，而且是一頁頁地看，「使用者願意忍受頁面(Web Page)顯示慢1秒鐘，但是卻不願意花多1秒鐘等照片出來，」曾皇霖並進一步表示：「Reverse Proxy Server中的快取技術，可加快圖片出現的速度，不會再『卡卡的』，這對我們而言很重要，因為用戶的心情會差很多，並因此決定以後會不會再來這個網站」。

此外，Reverse Proxy Server還可提供過去Squid無法給予的分析報表，過去很難了解哪一項應用的流量最高，如今則可明確知道何種應用最受歡迎、流量最高，對於日後規劃新服務，有相當大的助益，無形中幫助企業找到更多賺錢的機會。

IT人員溝通無阻　問題發生不推拖

曾皇霖表示，網站當機的情況大家一定都曾有過，而且痞客邦採用不少Open Source，其實很快就遇到瓶頸，而DoS攻擊亦相當常見，唯有倚靠後端架構強健，即使遇到問題，影響也不至於太大。

因此，痞客邦在平日管理部分，可從3方面起：

1、監測硬體健康狀態－例如以MRTG、RMOM等軟體持續監看設備的CPU、Memory、IO等使用量與連線數，並隨時注意主機、設備的使用率，預留緩衝空間(Buffer)，曾皇霖指出，以前總是習慣操機器，常常接近滿載或承載率達90%，才會加購機器，但其中1台倒了，轉移到另1台，照樣容易當機，所以開始預留Buffer，例如DB使用量大約到60%~70%、AP Server到20%~30%，可能就要注意或評估是否需要採購設備。

2、採用SiteUpTime國外監管服務－SiteUpTime提供遠端的網站監控，4個網路節點定時檢查企業的網站是否正常，當網站發生狀況時，立即以E-mail通知，確保網站持續在可連線狀態。

3、採用3家ISP線路－ISP業者亦會協助監控線路流量，偵測到異常狀況時，例如湧入大量封包，便主動告知痞客邦，僅管不一定會在最短時間內通知，不過對企業來說，亦是1項不錯的服務。

由於網站服務涉及AP及網管領域，一旦發生當機，雙方互不承認是自己的責任，或是網管人員只關注於當下解決問題，後續未再針對問題進行溝通及修改，將導致凸槌狀況一再發生。值得一提的是，痞客邦技術人員擁有1個良好的溝通平台，當系統出現異常時，所有技術人員會收到短訊或E-mail，IT人員就可立即透過1個類似BBS的溝通平台進行討論；待問題解決後，大夥兒再共同追蹤、討論原因，無論是AP、網路或主機問題，相關負責人員必須進行後續調整、修改程式，不讓問題再度發生。

曾皇霖指出，剛開始很難估計使用者數量是一定的，但是隨著後續發展，企業必須了解網站的使用者，包括族群及其喜好，這樣後續再推出新服務時，才容易掌握大致可吸引多少用戶，並思考現有資源是否足以應付等問題；至於伺服器等硬體設備，買得太早有損公司資產，因為往後或許可以相同的價錢，買到更高規格的產品，但是買得晚，也可能傷及公司形象和利益，所以，企業必須儘量了解客戶、推估流量成長情況，才能估算出適當的採購時機。