伺服器租用規格點睇：由運算、儲存到網絡與管理責任

伺服器租用規格評審：同樣寫容量，兩家公司要的可能不同

兩份採購要求都寫「大量產品資料、需要足夠容量」。一間公司每天定時匯入貨品、平時訪客不多；另一間每天有人搜尋及同時落單。伺服器租用規格若只列 CPU、記憶體和磁碟數字，看似可以比較，實際卻未說清楚負載何時出現、資料如何讀寫、故障時誰處理。先描述工作，再請供應商把數字對應到可驗證的安排。

本文採用採購規格評審形式。所有公司情境都是假設，不代表 Black Media 實際客戶或任何現成套餐。供應商的硬件、線路、管理範圍及條款應以正式文件為準；沒有核實的價錢、效能及停機承諾不應寫進比較表。若你正在判斷需不需要 VPS，可先讀VPS 管理責任與資源取捨；本文聚焦已需就伺服器租用提出可詢價規格的公司。

採購前請指定業務負責人與技術負責人：前者說明網站哪段流程不能中斷，後者整理現有程式、資料庫及資源紀錄。對外詢問時，兩位應對同一份文件簽收；若只讓採購同事填「愈多愈好」，候選服務都可能看似符合，實際回來後卻沒有可驗收的目標。

第一輪評審：先定網站要承受哪些工作

用工作流程取代單一流量預測

採購前列出網站的幾種實際工作：訪客讀文章、商品搜尋、加入購物籃、後台上載相片、匯出報表、定時更新庫存。每項工作觸發的計算和資料庫查詢不一樣，單靠每月瀏覽量無法交代高峰時是否有大量人同時結帳。先識別不可中斷的流程，再問供應商如何監察相關資源、何時需要調整規格。若目前沒有可用的效能紀錄，記下仍未知道的部分，先用合理測試方案核對，而不是虛構精確的未來併發數。

同時把系統相依項列出：使用哪個 PHP 版本、資料庫版本、是否要定時工作、檔案寫入位置與外部付款服務。租到資源並不代表應用程式一定能跑；某些問題來自程式查詢、外部服務等待或圖片過大，升級硬件未必是第一個修正步驟。

把訪客操作與後台工作分開

訪客瀏覽服務頁、搜尋商品、提交查詢與完成訂單，可能使用不同伺服器資源。後台的匯入、報表、圖片處理與備份又是另一類工作。先列出每天或定期發生的操作、何時集中，以及慢或錯誤的情況。若沒有現有監察資料，可以以真實工作流程安排受控測試，不能只憑全站頁數估算處理需求。

例如一間假設物流公司，每日清晨由內部系統匯入貨件資料。網站其餘時間回應正常，只有匯入期間客服查詢變慢。這可能涉及排程、資料庫及資源搶用，需要技術人員查明；如果直接根據客服感受選最大 CPU，未必能解決查詢設計或匯入方式問題。採購規格應同時反映當前限制與可改善的程式工作。

用代表性情境描述高峰

高峰不必用虛構「每秒數萬人」之類數字填空，可寫成「促銷開始時，客人持續打開產品頁並提交訂單，後台同時更新庫存」。技術方可在合適環境量度，再與供應商討論可用資源及限制。若網站還未上線，便誠實標明哪些屬估計、哪些可由原有系統或同類操作取得資料，並訂上線後覆核時點。

同一台主機也可能承載多個服務，應列出共用的網站、資料庫、排程與後台。若伺服器換走後電郵通知或內部接駁會受影響，要提早盤點。這裏討論的是伺服器採購範圍，不能把所有相關服務都預設由主機租用方案自動提供。

第二輪評審：CPU、記憶體與同時工作量

同規格下要比較可持續使用條件

同樣標示多核心與一定記憶體的方案，可能在共享與獨立資源、突發使用限制、管理方式上有不同。採購單應問清楚分配的是甚麼資源、怎樣量度持續負載、過量使用會收到甚麼提示或限制，並保留書面回覆。資料庫和應用程式共用同一台主機時，也要知道誰先佔用記憶體；若記憶體不足而系統不停交換到磁碟，顧客看到的可能是間歇性變慢，而不是簡單的全站無法開啟。

若網站已運行，可找幾段實際繁忙時段觀察 CPU、記憶體和請求延遲是否同時上升。某一項數字高不一定是故障，要看是否伴隨使用者任務失敗。若無法取得足夠監察資料，要求說明觀察工具、告警責任和日後擴容步驟，讓第一次採購也留下調整空間。

處理器數字要對應程式特性

CPU 核心數與時脈會影響某些工作，但應連同虛擬或實體資源分配、使用限制及程式設計一併理解。某個單一查詢寫法不佳，增加核心未必有相應改善；多個背景程序同時工作，則可能需要清楚分配資源。請候選方說明規格代表甚麼、資源緊張時如何觀察，而不是只比較清單上哪個數字大。

網站負載還要考慮程式使用的 PHP 與資料庫版本、背景任務與快取安排。技術負責人應先確認目前服務的相容條件及是否已有明顯瓶頸，將證據放進詢問文件。若原網站尚未量度，只能先採暫定方案並安排觀察；不要在缺少測試時對管理層說「這個規格一定足夠」。

記憶體要看最忙的同時運作狀態

資料庫快取、網站程序與圖片處理可能同時使用記憶體。若只看平時平均使用量，未必看見高峰期間系統開始頻繁交換資料或程序被迫中止。請維護者選代表性時段收集資源與錯誤紀錄，並指出哪些程序最受影響。根據真實負載向供應商詢問可用記憶體，較有助判斷是否需要預留擴充空間。

採購文件還應列出「能否只增加記憶體」「升級需不需要停機或搬移」等問題。答案依服務模式和當時方案而異，不應自行假設所有伺服器都可即時擴充。若業務有固定繁忙日子，變更窗口與回退安排也要納入考慮。

第三輪評審：儲存容量與讀寫負載分開問

容量增長與備份用量要分帳

估容量時分開列網站程式、商品相片、資料庫、日誌、暫存檔，以及若放在同一環境的備份。上載原始相片會令用量突然增加；日誌和暫存資料則可能緩慢累積。問供應商方案標示的容量如何計算、哪部分可供網站直接使用、空間接近上限時會否通知，以及擴充是否需要停機。不要把機內多留一份副本等同異地備份，也不要因為大量備份佔用主機空間而影響正式網站寫入。

容量充足仍要看讀寫表現。經常搜尋商品與同時提交訂單的網站，和幾乎只提供靜態公司資料的網站，對儲存系統的要求可能不同。可以要求在真實或受控測試情境觀察資料庫延遲，並核對磁碟操作是否瓶頸；如果沒有數據，不宜只按儲存裝置的名稱判斷整體速度。

磁碟空間應逐類資料盤點

程式檔案、上傳媒體、資料庫、日誌及備份都會用空間，但增長與重要程度不同。可以先量度現有資料，再按商品增長、上載方式和日誌保留估計未來使用。若資料庫很小卻查詢慢，可能不是容量問題；若大量相片每天上載，即使伺服器效能足夠，也要管理儲存與清理。

問報價中的磁碟是否只指主機可用空間，快照或備份是否另計，以及空間不足如何通知。不要把不同儲存類型名稱當成必然性能保證；實際讀寫表現、保護安排及服務限制需要按文件核實。若有遷移舊檔需求，亦要知道上傳與校對方式。

讀寫模式與資料庫查詢可互相影響

大量商品搜尋可能持續讀取索引，匯入與訂單處理則會寫入資料。問技術團隊是否已查看慢查詢、索引與背景任務，分辨應改善程式還是調整儲存資源。存取速度的宣傳數字通常有測試條件，直接拿來預測商戶網站每頁速度並不可靠。可用代表性工作在候選環境測試，再記錄實際條件。

假設資料庫與網站分在不同設備或網絡，還要核對兩邊通訊的延遲與權限。對初次租用伺服器的公司而言，架構愈複雜，維護與排查分工愈需要清楚。若單一環境已能滿足需要，毋須只為架構看來龐大便拆成很多系統。

備份與快照不等於可恢復業務

採購文件可列出備份頻率、保存位置、保留版本、取回與還原協助，但仍須問誰驗證訂單與圖片一致。可用網站備份還原演習作為驗收依據：是否能在安全環境重建網站、找到指定時間點的資料並完成一個真實工作流程。只見伺服器後台有快照按鈕，不足以代表事故時能快速復原營運。

若商戶希望備份與主機故障範圍分開，必須問保存位置和權限；「每日備份」四字無法回答。同時核對備份檔可能包含個人資料，由誰可取得及如何處理。這些條件可能影響管理工作與服務安排，應在選型時一併比較。

第四輪評審：網絡規格與使用者路徑

把客人所在地與實際路徑說清楚

若主要顧客在香港，測試應涵蓋香港常見的使用路徑；若同時有其他地區的員工或顧客，也要把重要地區列給供應商評估。線路標籤可能描述可用的網絡安排，卻不能單憑名稱預告每位使用者的體驗。要問延遲、封包路徑與故障時的處理方式，並用實際網站頁面測試，而非只看一張連線速度圖。內容傳遞網絡可以幫助分發合適的靜態內容，對需要即時查資料庫的結帳步驟則要另行評估。

如果服務商提供不同網絡選擇，先確認申請的是哪一條、切換條件與管理責任。Black Media 自述可按需要安排不同網絡，具體適配仍須按客戶使用者所在地、網站工作量及實際方案確認，不應把路線選擇誤讀成任何地區的固定速度承諾。

頻寬、流量及連線路徑不是同一數字

帶寬可描述連線容量，流量額度可能指一段期間傳輸總量；具體計算還需看提供者條款。某網站圖片多，下載資料大，與只傳少量文字的服務可能需要不同安排。採購時先提供訪客使用地區、常見下載或接駁方式，再問哪些條件會觸發限制與加購，而不是只要求「無限流量」四字。

Black Media 自述可按需要安排不同網絡線路，包括面向中港、美加或全球等類型。實際選哪種要看訪客和業務接駁、方案內容與測試結果；不能因某條線路名稱便推斷全世界任何地點都一樣快。這篇只討論如何寫詢問規格，機房地點與跨境路徑的深入比較留待另一專題。

外部系統連線要列成清單

網站可能與收款、寄件、庫存或公司內部系統連接，供應商需知道必要的通訊方向、連接限制與出問題時的支援窗口。不要直接把所有連接埠向公眾開放，只因希望「比較易接」。由技術人員先確認哪些流量必需、來源能否限制，以及測試時如何驗證。

如果網上商店仍未完成付款或庫存接駁，採購規格也要把尚未確定的條件標成待核實，不宜用一般網站展示需求推算全部將來交易負載。業務與網站製作方應提供計劃中的流程，讓供應商回答擴充可能性和相應責任。

第五輪評審：管理、安全與支援逐項劃界

事故發生時誰有權執行哪一步

把權責寫成幾個實際問題：作業系統更新由誰安排？PHP 與資料庫版本由誰維護？防火牆與存取紀錄由誰檢查？備份由誰建立，又由誰演練還原？監察顯示資源不足時，誰可以擴容，是否需要商戶核准？如果網站被改動，哪一方先隔離問題、保存必要紀錄、再恢復正常營運？只寫「全託管」三個字，無法釐清這些工作。

商戶亦要盤點自家權限：域名誰持有、DNS 由誰管理、後台管理員有幾個、離職同事權限如何取消。託管方能管理伺服器，不代表自然擁有商戶所有帳戶；反過來說，商戶持有最高權限亦不代表日常維護不需要流程。事先建立聯絡名單、授權規則和緊急回應方式，可讓技術與業務負責人在事故中知道該由誰決定。

硬件有人管理，不代表網站應用有人維護

伺服器租用可能涉及硬件、系統、網頁伺服器、資料庫、網站程式與內容多層責任。請候選方逐層標明提供、監察、修補及事故回應由誰處理。若公司有自建 CMS，供應商可能只負責基礎環境，程式則由另一位維護者接手。把這件事寫清，才能在網站出錯時正確找人。

技術支援亦要分清接收通知、開始調查與完成修正。若服務條款涵蓋特定時段，應以文件核實，不要從電話接通速度推斷任何問題都立即解決。公司內部要有負責人判斷業務影響，並向外部團隊提供可重現的故障資料。

主機管理入口要能安全交接

誰能登入、誰能重新開機、誰可取備份及改網絡設定，應按職責給權限。共享最高權限帳戶或過期外判登入，可能令追查及交接困難。若涉及服務提供者代操作，商戶仍要知道如何批准高影響變更，以及日後更換維護方時能取得哪些設定與資料。

服務停止、硬件更換或版本升級時，資料出口與回退安排同樣要問。不要只核對新主機可否開始運行，也要知道原環境何時才可安全停用。這些管理責任與規格數字一樣，是企業長期使用伺服器的成本和風險來源。

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

先核對遷移成本與變更安排

若已有運行中的網站，採購不只比較新主機月費，還要盤點遷移所需時間與風險：程式及資料庫相容、網站檔案大小、郵件是否共用網域、DNS 更改、測試環境、回退準備和舊方案終止時間。要求每個候選方案說明哪些工作包括在報價、哪些需商戶另聘人手，以及出了問題如何恢復舊路徑。沒有辦法比較時，可要求對方用同一套假設條件重寫答覆，而不是靠看似便宜的總額作決定。

最後把決定寫成可檢查的文件：選用規格、選擇理由、仍待確認事項、上線後的觀察指標及重新評估日期。假設網站新增大量商品圖或開設跨區服務，原先選擇可能需要再看；清楚的變更觸發點比一次選到「永遠足夠」的主機更實際。

回答必須對得上商戶自己的情境

向候選服務交同一份需求摘要：業務用途、主要頁面和接駁、現有技術環境、代表性高峰、備份目標、誰負責管理。請對方逐項回答包含、另需安排、不能提供及仍待核實。若某家只提供更多硬件數字，卻沒回答自建程式與資料還原的責任，商戶仍未能比較完整安排。

示例問題可包括「若資料庫磁碟滿，會有甚麼通知」「若主機仍在線但網站表格失效，誰會先查」「升級記憶體是否要搬環境」「日誌與備份可以由誰下載」。同一組問題會顯示不同方案真正差在哪裏，亦方便技術人員判斷目前需求是否寫得太籠統。

通過、待補與不符合各有下一步

若方案已有與業務用途一致的資源與清楚責任，可安排必要技術驗證；若某項依賴仍未確定，請相關人員補資料；若缺少公司必需的備份或管理安排，應先討論能否另行提供，不應硬把缺口當成「日後再處理」。採購清單要能產生下一步，不只是把每項畫個分數。

若選擇網站寄存及伺服器租用安排，可先用寄存類型比較確認需求層級，再把本文的負載與責任表交給供應商。網站技術與程式開發安排要配合，不能只由伺服器規格單獨決定整個網站可做到甚麼。

1. 從現有資料與具體操作寫出工作負載，不填虛構訪客數。
2. 把運算、儲存、網絡及外部接駁問題分別列出。
3. 要求供應商寫明服務與網站維護的責任界線。
4. 以備份演習與代表性操作作為驗收方向。

試行期間怎樣觀察規格是否合適

若安排短期測試環境，請先定幾個可觀察任務：載入代表性的公司頁面、搜尋商品、完成測試訂單、批量匯入資料及產生後台報表。記下同時執行這些工作時的反應、錯誤與資源使用，連同測試資料量一起保存。單純開一次首頁，無法測出網站在尖峰工作時是否吃力；但用完全脫離真實流量的壓力測試去預測營運，又可能錯判需求。

測試結果應回到原本的商業問題：訪客有沒有在等待時離開？職員能否在合理時間完成訂單核對？若看到延遲，先查詢是否由程式、資料庫、儲存、網絡或第三方服務造成，不應即刻要求供應商只增加 CPU。若改動 PHP 或 MySQL 設定，記下變更前後數據，避免一次調多個變量而無法知道哪個措施有效。

最後確定退出或擴容路線：資料如何完整取走、備份何時交接、DNS 由誰切換、是否需要短暫並行運作、測試未通過時如何回到舊環境。採購時把這些過程寫清楚，將來無論留在原方案還是升級，都能依資料和責任分工處理。

還有一種值得要求供應商說明的情況：網站需要臨時應付較高的工作量，方案能否加資源、變更需要多久、結束後如何降回原規格？若調整涉及資料搬遷或重啟服務，應在業務較能接受的時段安排，並先把回退和通知流程寫下。以「可以升級」作簡答並不足夠，要知道實際操作和責任界線。

審閱方案時也要看計價單位與合約項目是否一致：標示儲存容量、資料傳輸、管理服務和備份的字眼可能指不同範圍。這裏毋須預設某家供應商的價錢或條款；把每項成本與限制列回相同表格，向對方逐一查證即可。若商戶沒有技術人手，另列日常維護的處理時間和溝通方法，比只比較主機硬件更能反映真實負擔。

常見問題

規格數字較大，是否一定比較合適？

不一定。網站的慢點可能在程式、資料庫、圖片或接駁；較大的 CPU 與容量不會自動修正設計問題。應用相同業務情境與監察條件比較候選方案，並確認供應商限制及維護責任，再決定哪些資源真的需要提高。

有伺服器備份，還要看網站資料嗎？

要。伺服器快照或備份可能有不同包含範圍與保存方式；網店訂單、上載檔案、程式設定及外部系統未必全部可一同恢復。請維護者在受控環境還原並由商戶驗收主要操作，才能知道其備份能否支持實際營運。

網站還未上線，如何估算資源？

先列已知程式、資料結構、上載及接駁需求，標出無法確定的高峰，按可行環境測試代表性操作。初期方案可有暫定前提，並安排上線後觀察與擴充方法。沒有數據時不應編造負載數字，也不能跳過備份與管理責任。

主機供應商是否必須懂我公司的全部業務？

不必替商戶決定業務規則，但應知道哪些操作重要、網站用了甚麼系統、哪些故障影響最大。商戶與網站維護者提供工作情境，供應商清楚說明資源與服務邊界，三方按各自責任驗收；若所有資訊都停留在一句「網站要快」，便難以選型。

準備比較伺服器方案時，可把網站主要工作、現有瓶頸及管理人手整理成一頁，向 Black Media 查詢合適的租用規格與支援範圍。先讓採購問題可以被核對，再看方案數字，才容易選到能配合真實操作的安排。