網頁寄存比較指南：由公司網站需要判斷主機與支援安排

網頁寄存比較，先把規格表上的名詞拆開

磁碟空間、流量、核心、記憶體、備份、管理支援：寄存方案把這些項目排在一起，卻未必說明它們怎樣影響你的網站。網頁寄存比較應先看網站的工作量和管理責任，再核對資源限制。只選容量最大的方案，未必能解決真正的運行問題。

一個主要展示公司資料的網站，與需要處理登入、搜尋、付款及即時存貨的網店，對資源和維護的要求不同。即使兩者檔案大小相近，使用時也可能有完全不同的負載。空間夠不夠，只是其中一條問題；程式能否相容、故障由誰處理，也會直接影響使用。

閱讀寄存規格時，可以在每個名詞旁邊加三欄：實際限制、到達限制後的處理，以及負責確認的人。沒有寫清楚的項目應向供應商查詢，不能把空白理解成無限制。這樣整理後，方案才由一張宣傳清單變成可討論的運行安排。

同一份比較表也應註明資料取得日期及適用方案。供應商可能提供不同服務層級，公開介紹與實際訂購範圍不一定完全相同。把最新答覆附在方案旁邊，日後交給同事或開發團隊時，才不會把另一個版本的限制當成目前已包括的能力。

先寫網站用途，才選共享主機、VPS或獨立伺服器

服務模式與管理方式要分開看

共享主機通常讓多個網站使用同一組基礎資源，商戶可使用的設定和權限由服務安排決定。VPS 透過虛擬化提供一個可分配資源的環境，但資源保障及管理範圍仍需看實際方案。獨立伺服器則把一台實體設備交由指定用途使用，也不自動代表所有工作都有專人代管。

「共享」「虛擬」及「獨立」描述資源組織方式；「自行管理」和「代管」描述工作分工。兩組概念不要混為一談。公司可以租用資源較多的環境，卻沒有合適人員更新系統；也可以在受管理的環境使用較有限的權限，但更符合自己的營運能力。

因此，網站寄存選擇的第一份資料不是預算數字，而是網站用途、程式要求和負責人。若網站仍在規劃，宜先依網站開發的需求流程列出內容、互動及交易功能，讓技術人員據此評估，避免先買了環境才發現不能運行必要功能。

• 網站主要是公開內容、會員服務，還是網上交易？
• 有沒有定時工作、檔案上載或外部系統整合？
• 公司內誰有能力處理更新、備份及事故協調？
• 哪些設定需要自行控制，哪些可交由供應商管理？

如果網站由外判團隊開發，應讓開發者提供最低需要及建議配置，並說明依據。只說「買大一點較安全」仍不足夠。初期資料不足時，可以選擇有清楚量度和調整方法的安排，再按真實運行情況檢視，而不是假裝已能準確預測所有負載。

公司也可以列出不能接受的限制。假設網站每天要自動產生一份業務文件，環境便需要配合相關程式和排程；若方案禁止必要的背景工作，即使容量較大也不合適。先用必要條件篩選，再比較可有可無的附加功能，會較容易看清差異。

運算能力：核心數字要連同工作類型和限制一起讀

同樣核心數，不代表同樣可用能力

CPU 負責處理程式工作，但核心數字只是部分資料。處理器、虛擬化分配、共享情況及服務限制，都可能影響可用能力。網站一次請求需要做多少運算，也取決於程式和資料查詢。沒有相同測試條件，不宜只看核心數便替不同方案排快慢次序。

公開內容若可由合適快取提供，與每次都要查詢資料庫、計算價格或產生文件的功能，負載性質不同。即使訪客數相同，後者也可能需要更多工作。評估時應描述最常使用及最重的功能，讓團隊知道需要觀察哪些操作。

還要問達到資源限制後會發生甚麼：是暫時限制處理能力、請求排隊、回傳錯誤，還是需要人手處理。不同服務安排可以不同，不能只看平時流量少便忽略限制。促銷、批量匯入或備份工作，也可能與正常訪客同時使用資源。

不建議未量度便直接升級。若某個查詢反覆處理不必要的資料，增加資源可能只延後問題出現。先確認是持續需求增加、程式效率、定時工作重疊，還是其他原因，再決定調整方案或修正應用。寄存比較應包含這種排查能力。

量度時應保留不同時段，而不是只截取最繁忙或最清閒的一刻。若問題只在某項工作執行時出現，應把那項工作的開始和結束時間一同記錄。供應商與開發團隊有共同時間線，才能比較系統用量和網站操作，減少各自只看一張截圖的誤判。

記憶體與同時請求：看尖峰時怎樣運作

記憶體用來承載正在運行的程式及資料，並非另一種永久儲存空間。網站、資料庫、快取及背景工作可能各自使用一部分。某些方案會另外限制程序數、連線數或單次工作可用資源，所以不能只問總記憶體而忽略其他配額。

並發請求與總瀏覽量不是同一項數據

一天有多少次瀏覽，與某一刻同時要處理多少請求，是兩個不同問題。幾個需要較久處理的搜尋或匯出工作，可能與大量簡單頁面請求有不同影響。供應商若提供負載建議，應請他說明工作類型和測試條件，不要把一個訪客數字視為任何網站都適用的保證。

可以記錄尖峰出現的時間及功能，例如每日商品同步、同事匯出訂單或宣傳活動開始後。這些紀錄能協助判斷是人流集中，還是內部工作安排造成重疊。若可把重型背景工作移到較少人使用的時間，也應驗證是否影響資料更新需要。

公司應知道資源用量在哪裏查看、警示送給誰，以及超出限制後如何取得證據。只收到一句「網站用量太高」卻沒有時間、程序或數據，便難以跟進。量度資料未必需要公開給所有同事，但至少要有能看懂並作決定的負責人。

若環境有自動重新啟動失敗工作的安排，也要確認日誌是否保留，以及重啟會否影響尚未完成的操作。網站重新開得到，只代表服務恢復，不能證明剛才所有表格或交易都已正確完成。對重要操作，仍要檢查相應資料，避免只以首頁回復正常作結。

磁碟與資料庫：空間、檔案數和讀寫工作要分開

不要只計網站圖片大小

儲存用量可能包括程式、媒體、資料庫、附件、日誌及備份；如果同一服務亦放電郵，郵箱也可能佔用配額。比較時要問哪些計入同一容量，以及有沒有檔案數或資料庫大小限制。大量小檔案未必佔很多容量，卻仍可能遇到其他配額。

容量與讀寫能力也不同。可存放很多資料，不代表同時查詢和寫入一定快。資料庫索引、查詢方式及儲存設備都有影響。若網站經常批量更新或產生大量紀錄，應把工作特徵交代清楚，不能只按現時圖片資料夾大小選方案。

網店尤其要保留商品與訂單的關係。在討論網上商店的資料安排時，應同時確認訂單紀錄、商品媒體及備份的保存方法。不能為騰出空間便隨意刪除仍有業務用途的資料，也不應把正式資料和測試副本混在同一位置而無法辨認。

清理和擴充都要有條件

先分類甚麼可以輪替、甚麼需要保留、甚麼只屬測試。日誌可按需要設定保留，舊備份則按既定政策處理；涉及交易或個人資料時，要配合公司實際責任。擴充前亦應確認是否需要停機、資料搬移或重新設定，避免把「可升級」理解成完全沒有操作影響。

如果方案提到儲存鏡像或 RAID，應知道它主要針對部分設備故障的持續運作需要，不能代替獨立備份。誤刪、錯誤更新或受破壞的資料，可能同樣反映到鏡像中。比較儲存保障時，要分開設備容錯與資料復原兩個問題。

試用環境若容許上載資料，也應先用不含敏感內容的樣本核對匯入與下載。測試結束後確認由誰刪除樣本，不要把試用帳戶變成公司檔案的長期存放點。正式環境的資料管理責任仍應另行確認。

日誌空間也容易被忽略。發生錯誤時，程式可能反覆寫入相同訊息，令用量比平日增長得快。應有查看和輪替安排，但不能在未保留診斷資料前全部刪掉。採購時確認誰能讀取所需日誌，以及它們保留多久，對日後排查有直接幫助。

流量、頻寬與主機位置：從訪客實際路徑判斷

流量配額通常關心一段期間傳送了多少資料，頻寬則與傳輸速率有關，兩者不能當成同一項規格。還要確認所列數字屬連接埠能力、共享安排還是合約保障。只看一個很大的速率數字，不能直接推論每位訪客都會以同樣速度讀取網站。

位置影響路徑，但不是唯一速度因素

主要訪客在哪裏、使用甚麼網絡，以及網站是否依賴其他地區的服務，都會影響體驗。香港公司不一定所有訪客都在香港，海外客戶也可能使用不同連線。應選代表性地區和頁面實測，不宜單憑主機所在地為所有情境下結論。

CDN 可在適合的情況下協助傳送可快取內容，但不等於自動加快每個動態操作。登入、購物車及個人化資料需要正確規則，不能把整站一律快取。比較方案時問清有沒有相關設定及管理支援，也要知道誰負責避免私人內容被錯誤快取。

如果頁面主要時間花在等待資料庫，增加外部傳輸能力未必有效；如果圖片檔案過大，則可能需要先處理媒體。實測應區分連線、伺服器回應和內容傳送，不要只用一次首頁測速結果判斷整個寄存方案。

超出流量配額後的安排亦需清楚。有些服務可能限制速度、暫停或另行計費，實際以條款為準。預計有活動或大量下載時，提前提供用途和時間安排，並確認監察方法，會比出現限制後才臨時詢問更容易處理。

程式相容性：能放檔案，不代表網站可以正常運行

核對版本、擴充及定時工作

PHP、資料庫版本、必要擴充、排程工作及檔案權限，都可能是網站運行條件。開發者應列出真正需要的項目，並區分最低可運行與建議使用的環境。不要只確認「支援PHP」便開始搬站，因為不同版本和設定可能有相容差異。

自建網站亦可能需要特定的圖片處理、寄信或外部連線能力。若寄存環境限制相關功能，前台頁面或許開得到，但某些操作會失敗。比較時應測試主要功能，而不是只上載一個簡單測試頁。測試結果應記錄執行環境，方便之後重現。

當公司考慮網站程式與後台製作，應把環境要求寫進交付文件，說明由誰核對版本支援及安排更新。網站曾經可以運行，不代表適合永久停留在相同環境；但更新也要經過相容測試，不能在正式站毫無準備地切換。

資料庫方面，字元編碼、排序規則、時間設定及匯入方式都可能影響結果。中文內容顯示正常，不代表所有比較或排序都符合預期。搬移前應保留結構及資料備份，並用代表性中文、符號及日期內容驗證，不要等正式查詢出錯才發現差異。

另外要盤點網站對外連線的需要，例如寄送通知、查詢物流或取得其他系統資料。環境可以提供公開網頁，不代表所有對外連線都獲容許。應按實際服務測試連線和逾時處理，不要為求方便而要求關閉全部限制；清楚列出必要存取範圍會較容易管理。

備份規格要讀到還原那一步

「有備份」仍未回答備份甚麼、保存多久、放在哪裏及怎樣還原。網站檔案和資料庫若來自不同時間，還原後也可能不一致。動態網站、交易網站及大量上載附件的系統，尤其需要確認備份方法是否配合資料變化。

從可接受的損失倒推安排

公司應先討論能接受遺失多少近期資料，以及功能中斷後優先恢復哪些工作。這些是業務要求，不能由供應商憑空猜測。若網站主要是公開介紹，與持續接單的商店相比，復原時需要協調的資料和人員自然不同。

可以請供應商說明一次還原需要商戶提供甚麼、由誰批准，以及能否先還原到另一環境確認。直接覆蓋正式站可能影響最新資料，因此要知道還原目標和範圍。只保存備份檔而從未驗證內容，不能等同已確認可復原。

• 備份是否同時涵蓋檔案、資料庫及必要設定？
• 是否有不同時間點，能否辨認各版本？
• 備份是否與正式環境有適當分隔？
• 誰可以下載或還原，帳戶失效時怎樣取回？
• 還原後由誰核對內容、權限及主要操作？

備份也有安全責任。備份內可能包含客戶資料和系統設定，不應放在可任意下載的公開目錄。取回備份後，公司亦要有合適保存位置及權限。不能因為它不是正在運行的資料庫，就忽略保管和刪除安排。

一次可覆核的復原演練，可以選定一份備份，在隔離環境還原，核對幾筆代表性內容，再測試登入與主要操作。演練記錄應列出使用的版本、缺少的設定及需要人手補做的工作。這樣才能知道備份是否符合實際需要，而不是只確認有一個壓縮檔存在。

對網店而言，還原前後的新增訂單需要特別處理。可以先參考網店平台的資料責任比較，了解交易、匯出和退出安排之間的關係。寄存層能提供備份，也不能代替商戶核對已付款、已出貨及待處理的業務紀錄。

保安與技術支援：列清楚邊界才知道買了甚麼

環境保護不能代替程式與帳戶管理

防火牆、流量防護、TLS 憑證和系統更新各有用途，但沒有單一項目可以涵蓋所有風險。HTTPS 主要保護傳輸，不代表後台密碼、程式邏輯及資料存取都已妥善處理。網站保安是多項安排的結果，不能由規格表上一個剔號作全面保證。

主機與程式的責任應有對照。環境更新由誰做、網站元件由誰更新、帳戶由誰建立，以及發現可疑活動時找誰，都需要確認。即使採用代管服務，也應了解哪些工作仍由商戶或開發團隊負責，避免出現雙方都以為對方處理的空位。

評估寄存與伺服器服務時，可以要求按實際網站列出支援範圍，而不是只看聯絡方式。支援可用時間、問題分類和處理安排應以確認內容為準；未經提供的回覆時間、備援能力或不停機承諾，不應自行假設。

事故發生時，公司也要提供足夠資料。保留網址、時間、影響範圍及最近改動，並指定可以批准處理的聯絡人。不要把正式密碼貼在公開群組或錯誤截圖內；支援人員需要存取時，應採用適當的臨時權限及事後撤銷安排。

若合約列出服務可用性或補償條款，要分開看量度方法、排除事項及申請程序。條款中的可用性描述，未必涵蓋網站程式、第三方接口或商戶自行改動造成的問題。理解合約有助分工，但不能把某個服務指標延伸成整個網站永遠不會中斷。

把候選方案放進同一份採購問題表

到這一步，應已知道網站需要哪些能力，以及哪些項目尚未確認。比較時可以先排除不能符合必要條件的方案，再看管理便利和調整方式。不要用不相關的額外容量抵銷核心相容問題，也不要因為熟悉某個名詞便忽略支援邊界。

1. 交出網站用途、主要功能及執行環境要求。
2. 核對資源限制、量度方法及超額處理。
3. 確認備份、復原、更新與事故分工。
4. 要求說明擴充、搬出及資料取回程序。
5. 保存書面答覆，標示未確認或不包含的項目。

若是更換寄存，還要先保存域名記錄和現有設定，安排資料同步、測試及回復。網站和電郵可能使用不同供應商，切換網站不代表需要更改所有域名記錄。沒有清楚盤點便直接替換，可能令原本正常的服務一併中斷。

應在決定前了解搬出條件，包括備份取得方式、帳戶停止後的資料保留安排，以及是否需要特定人員協助。這些問題不只在離開供應商時才有用，也反映公司平日能否掌握自己的網站。把控制權和技術支援分開確認，交接會較清楚。

正式交接時，建議公司保存一份環境資料表，列出域名管理位置、寄存帳戶、程式版本、備份方式及相關聯絡角色。表內不應直接公開密碼，可指向公司指定的安全保存方法。資料表的用途是讓獲授權人知道去哪裏處理，而不是把所有權限集中在一份普通文件。

續期之前也可以使用同一份問題表重新檢視。網站新增會員、網店或大量附件後，原本的安排可能需要調整；若使用情況沒有明顯改變，也不用只因為新規格看起來較大便更換。按真實需要和可取得的量度資料作決定，才能避免不必要的搬移及管理工作。

常見問題

公司網站一定需要VPS嗎？

不一定。要看程式需要、負載及管理能力。公開內容較簡單的網站，可能在合適的共享環境已能運作；需要特定設定或管理權限時，才進一步評估其他方式。VPS 是一種資源安排，不是所有網站的必然升級路線。

主機空間越大，網站是否越快？

容量決定可存放多少資料，速度則涉及運算、記憶體、讀寫、網絡和程式。空間不足確實可能造成問題，但增加空間不代表所有慢速都會改善。先量度瓶頸，再決定應調整哪一項資源。

有SSL是否代表網站已經安全？

憑證和加密連線只處理其中一部分。後台帳戶、程式漏洞、權限及備份仍需管理。應分別確認不同層面的責任，不能以瀏覽器顯示加密連線，推論整個網站沒有其他風險。

供應商有備份，公司是否不用再理會？

公司仍要了解備份範圍和還原安排，並按業務需要驗證。還原後的資料是否完整、哪些最新交易需要補回，以及誰批准覆蓋正式資料，都涉及商戶責任。備份服務不能代替這些判斷。

怎樣避免買了之後才發現不適合？

把主要功能、環境要求及管理分工寫清楚，要求候選方案逐項回覆。可以測試的就用代表性操作驗證，尚未確認的不要當成已包括。最後保存限制、擴充及退出安排，日後才有明確比較和交接依據。

Black Media 提供網頁寄存、主機租用及網站相關服務。你可以先列出現有網站用途、執行環境和遇到的問題，再查詢合適的寄存安排，讓討論從實際需要開始，而不是只比較規格表上最大的數字。