託管與非託管 VPS 怎麼選？先算維運成本

託管與非託管 VPS：簡短答案

選擇託管或非託管 VPS，關鍵在於維運工作，而不是產品本身。非託管表示您必須自行負責套用修補程式、防火牆、備份、監控，以及凌晨 2 點重新開機。託管表示供應商會代您處理其中部分工作，但不同主機商提供的範圍可能差異極大。唯一有用的比較方式，是列出各方案可替您省下哪些工作，再以您自己的工時成本衡量價格。

「託管」沒有標準定義。對某些主機商而言，這表示作業系統會套用修補程式，並由人員回覆服務單。對另一家而言，這只表示已安裝控制面板，其餘所有工作仍由您負責。第三家可能提供附帶回應時間的書面服務合約。兩個使用相同名稱的方案，實際內容可能在所有重要面向都不同。因此，請先閱讀服務範圍文件，再查看價格。如果您還在決定這台機器究竟要用來做什麼，應先釐清VPS 實際能做什麼這個問題。

必須有人負責的工作

每台執行中的伺服器都有相同的工作清單。使用非代管方案時，這份清單由你負責。使用代管方案時，你付費請人替你移除其中的工作項目。逐項檢查清單，並在每一項旁邊寫下負責人的姓名。

• 作業系統修補，以及核心更新所需的重新開機。
• 防火牆規則。新增或移除服務時，必須持續維持規則正確。VPS 的 ufw 防火牆基本設定涵蓋初始規則集。
• SSH 存取：管理金鑰、停用密碼登入、有人離開時撤銷其金鑰，以及將自己鎖在系統外時重新登入的方法。
• 備份、異地副本，以及你實際執行過的還原作業。
• 監控，也就是確認伺服器可連線、磁碟仍有空間、服務仍在執行，以及憑證尚未過期。
• 檢視日誌，以及日誌中出現異常時的處理方式。
• Web 伺服器、資料庫、反向代理，以及佇列（若有使用）的服務設定。
• 憑證續期，以及自動續期停止運作時的修復作業。
• 容量管理，也就是在 out of memory (OOM) killer 替你發現之前，先注意到記憶體已耗盡。
• 事件回應，也就是在非自行選擇的時段保持清醒並且能被聯絡。

其中大多數工作都屬於例行作業，可以交由指令碼處理。事件回應則無法完全交給指令碼，因為需要有人做出決策。這才是代管方案真正銷售的服務。因此，後面的檢查清單大多著重於支援範圍，而不是修補作業。

代管服務通常不包含的項目

這是買方最容易誤解的地方，因此必須明確區分。代管合約通常涵蓋作業系統與供應商安裝的軟體，服務範圍止於應用程式的邊界。

您自行開發的程式碼由您負責。 應用程式回傳 500 錯誤，不代表伺服器發生故障。供應商會確認 web server process 正常執行，然後將工單退回給您。這是合理的責任界線，也是買方期待與實際購買內容之間最大的落差。

應用程式層級的問題通常不在服務範圍內。 執行緩慢的資料庫查詢、更新後損壞的 plugin、設定錯誤的快取，以及停止排出郵件的 mail queue，都屬於這條界線以上的問題，即使底層軟體是由供應商安裝，通常也不包含在內。

大多數資料復原也不在服務範圍內。 供應商的備份保護的是整台伺服器的映像，主要用於主機硬體故障的情況。這類備份很少是為了處理您刪除資料列、執行錯誤的 migration，或檔案在 6 週前損毀但直到今天才發現的情況而設計。請確認保留期限、是否能取出單一檔案，以及由誰執行復原。

您安裝的軟體由您負責。 安裝 Docker 後，供應商通常負責主機，而容器內的所有內容由您負責。

手動編輯可能使支援失效。 某些合約規定，客戶直接編輯元件設定後，該元件即不再屬於支援範圍。如果您計畫調整任何設定，請先確認這項規定。

將自己的時間成本與每月差額比較

查看眼前的兩份報價，記下每月差額。這個數字就是服務商為了替你處理上方清單中的工作所收取的費用。接著，評估你自己需要投入的成本。

• 你的一小時時間值多少？這份清單自動化後，每月需要多少小時？
• 執行於這台伺服器上的服務，每停機一小時會造成多少成本？

已完成自動更新並配置外部監控的穩定 Ubuntu 伺服器，日常維護需求很少。多數月份甚至不需要處理任何工作。由腳本負責後，例行工作成本很低。真正昂貴的是突發事件，而 managed plan 販售的正是突發事件的處理能力。若伺服器只執行個人興趣專案，服務中斷不會造成損失，選擇 unmanaged 顯然較合理。若伺服器負責接收訂單，應仔細評估 support contract 是否真的能縮短中斷時間，因為 managed provider 仍需讀取你的 ticket、重現故障並採取處置。

差額也會隨伺服器數量增加而擴大。Managed fee 通常按伺服器計費，但自動化工作只需撰寫一次即可複製。第 2 台伺服器會讓你為第 1 台撰寫的腳本有效成本減半，因此在決定支付 per-server fee 前，請先閱讀 如何管理多台 Linux 伺服器。比較兩邊的基準數字時，VPS 每月實際成本是多少可作為下限；當工作負載大到 managed premium 只占四捨五入誤差時，VPS 與 dedicated server 的取捨便十分重要。

付費採用代管進階方案前，應向主機商詢問的問題

付費前先詢問，並要求對方以書面提供答案。銷售頁面不是服務範圍文件。

1. 每項工作的服務範圍是什麼？要求對方提供清單，不要只看宣傳手冊。
2. 支援範圍是否包含我自行安裝的軟體，還是只包含由你們安裝的軟體？
3. 你們是否會自動套用修補程式？核心更新是否會在未事先詢問我的情況下重新開機？
4. 如果你們套用的修補程式導致我的應用程式故障，責任由誰負擔？
5. 你們是否會執行備份？備份儲存在哪裡、保留多久，以及由誰執行還原？
6. 你們最近是否還原過客戶的伺服器？花了多久時間？
7. ticket 回應時間是多少？星期日 03:00 是否不同？
8. 我是否保留 root 存取權限？使用 root 是否會減少你們提供的支援範圍？
9. 費用是按伺服器計算，還是按帳戶計算？
10. 如果我終止服務，可以帶走哪些內容？如果設定存在專有控制面板內，可能很難匯出。

第 5 題會決定大多數其他問題的答案。主機商能精確回答這題，表示他們過去確實執行過還原。含糊的答案表示還原從未經過測試，而未經測試的備份只是一份副本。第 5 題也涉及儲存位置：副本實際存放在哪裡，不只是技術問題，也涉及法律問題；選擇主機託管國家時真正重要的因素會詳細說明這一點。

中間方案：非託管搭配自動化

多數技術讀者不想選擇任何一個極端。他們需要非託管方案，讓例行工作交由機器處理，自己則專注於機器無法判斷的事項。第一天就完成設定。新 VPS 上線後的前 10 分鐘 是選擇非託管方案者的實務起點，而 強化 SSH 存取安全 也應在同一個初始工作階段完成。

自動安全更新

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

該檔案現在應包含 APT::Periodic::Update-Package-Lists "1"; 和 APT::Periodic::Unattended-Upgrade "1";。檔案不存在，或任一行包含 0，都表示不會執行任何工作，系統也不會通知你。

不變更系統的情況下先進行測試。請注意，套件名稱是 unattended-upgrades，但命令使用單數形式：

sudo unattended-upgrade --dry-run --debug

輸出會列出它檢查過的每個套件。如果沒有待處理項目，最後會顯示類似 No packages found that can be upgraded unattended 的一行。實際執行結果會寫入 /var/log/unattended-upgrades/unattended-upgrades.log，因此應檢查該處，而不要自行猜測。

核心更新不會立即生效，必須重新啟動機器，因為目前執行中的核心是在開機時載入的。等待重新啟動時會出現 /var/run/reboot-required 檔案。你可以監控該檔案，或在 /etc/apt/apt.conf.d/50unattended-upgrades 中讓機器自行處理：

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

有人登入時，Automatic-Reboot-WithUsers "false" 會延後重新啟動。這對互動式使用的主機較安全，但對沒有人登入的主機沒有作用。Ubuntu 上的完整 unattended upgrades 設定 詳細說明封鎖清單語法與電子郵件選項。

在其他位置執行的監控

在伺服器上執行的監控無法告訴你伺服器已離線，因為監控本身也會一同離線。請將檢查放在第二台主機或外部服務上。使用 Uptime Kuma 進行狀態監控 是常見的自架方案，而且應放在與受監控主機不同的機器上。

至少監控四項：可連線性、磁碟使用量、應用程式是否在實際連接埠上回應，以及憑證到期時間。磁碟問題最容易被忽略。每天只增加一點的日誌檔或資料庫，可能在沒有其他預警的時刻讓主機停止運作；最初的症狀通常是服務無法寫入資料後結束。

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

另外加入 heartbeat。伺服器在每次備份或健康檢查成功後，由計時器呼叫某個 URL；監控在停止收到該呼叫時發出警示。如此一來，無回應的伺服器也能自行觸發警示；如果故障點是網路路徑，僅靠 pull-only 檢查則無法做到這一點。

至少成功還原過一次的備份

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init 只會輸出 created restic repository <id> at sftp:... 一次。對已存在的 repository 執行時會失敗，而不是覆寫內容；這正是你需要的行為。請將該密碼片語的副本保存於伺服器之外的位置：沒有它就無法讀取 repository，也沒有其他復原途徑。

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots 應列出你剛才建立、日期為今天的執行項目。restic check 會驗證 repository 結構，並輸出 no errors were found。現在執行多數人會跳過的步驟：

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

你預期的檔案不是存在就是不存在，現在確認只需 10 分鐘。接著將該執行項目交由計時器處理，不要依賴自己。寫入 /etc/systemd/system/restic-backup.service：

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

以及 /etc/systemd/system/restic-backup.timer：

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers 會顯示下次執行時間與剩餘時間。結果為空表示你啟用的是服務而不是計時器，這是此處最常見的錯誤。Persistent=true 會在下次開機後執行錯過的工作，因此即使機器整晚關機，也能取得備份。VPS 上的 Restic 備份 進一步說明 repository 配置與保留策略，而 systemd 服務與計時器 會逐行解釋 unit 檔案。

自動化無法取代的事項

自動化無法取代判斷力。02:00 的自動重新啟動不會因應用程式無法正常恢復而停止，因此請先確認每項服務都能自行啟動，再在你清醒時刻意重新啟動：

systemctl is-enabled nginx docker
sudo reboot

無人值守更新也可能安裝造成應用程式故障的套件，而整個流程不會知道這件事已經發生。監控會捕捉到這類問題，因此更新改為自動執行後，監控不是可有可無的功能。機器負責例行工作。事件處理仍由你負責。

託管服務值得付費的情況

公平看待託管服務。以下4種情況適合購買託管方案。

• 團隊中沒有人維護 Linux，而且不打算聘請專人處理。
• 合規要求指定負責修補程式的一方，而該方不能是你。
• 使用的技術堆疊正是主機商擅長的項目，因此其支援團隊可能已處理過相同的故障。
• 原本會負責這項工作的員工成本最高，而其1小時的成本高於託管方案的1個月加價。

託管服務不一定更安全。託管方案確實比疏於管理的擁有者更快安裝修補程式，這是實際的優勢。託管方案也常會安裝控制面板；控制面板是大型的面向網路應用程式，具備登入頁面，也有自己的漏洞歷史。這可能是合理的取捨，但仍然是取捨。

每次決策都回到相同的清單。列出這10項工作，針對每份報價標明各項工作的負責人，再將差距與你投入1小時注意力的價值比較。多數完成這項比較的技術人員，最後會選擇非託管方案，並將例行工作交給計時器執行。這是合理且站得住腳的答案，而不只是較便宜的答案。

FAQ

受管 VPS 與非受管 VPS 有何差異？

非受管 VPS 只提供伺服器本身，其他工作都由你負責，包括修補程式、防火牆、備份、監控，以及核心更新後的重新開機。受管 VPS 則將部分工作交由供應商處理，通常包括作業系統層與供應商代為安裝的軟體。實際責任範圍取決於各供應商，而不是由這些名稱本身決定。因此，在比較兩種方案的價格前，應要求供應商以書面逐項列出服務範圍。

受管 VPS 是否代表我不需要自行備份？

不代表。供應商備份通常保護的是整台伺服器的映像，主要用於主機故障時復原。當你刪除檔案、執行錯誤的遷移，或數週前資料已損毀但直到今天才發現時，這類備份通常無法提供協助。請確認快照保留多久、能否還原單一檔案，以及由誰執行還原。接著使用 restic 等工具保留自己的異地副本，並使用 restic restore latest --target /tmp/restore-check 測試，確認備份確實可用。

受管 VPS 是否比非受管 VPS 更安全？

不一定。受管方案的修補速度通常比從不登入伺服器的擁有者快，確實能降低風險。許多受管方案也會安裝控制面板，而控制面板是大型的網路對外應用程式，具有自己的登入頁面，也有自身的漏洞歷史。若非受管伺服器啟用自動安全更新、關閉防火牆規則、僅允許使用金鑰的 SSH，且沒有其他服務監聽，則其攻擊面可能小於執行控制面板的受管伺服器。

我可以先使用非受管方案，之後再改用受管方案嗎？

通常可以，但很少只需勾選一個選項。供應商通常會在接手管理前先稽核或重建伺服器，因為他們不會支援自己無法檢視的設定。請確認導入程序包含哪些工作、是否需要重新安裝，以及之後你自行設定的項目是否仍不在支援範圍內。

使用受管 VPS 時，我是否仍保有 root 存取權？

大多數受管 VPS 方案仍會提供 root 存取權，但 root 存取權與支援範圍彼此相關。部分供應商會降低或取消你手動修改之元件的支援，有些供應商則可能在問題處理深入後，依自己的範本重建伺服器。在進行任何調整前，請先取得這項規則的書面說明，並將設定檔納入版本控制，這樣重建伺服器只需花費 1 小時，而不是整個週末。