Cloudways Monitoring 監察教學：升級前後確認網站容量的六步流程

網站突然變慢時，不要先猜是主機規格不足，也不要立即重啟伺服器。Cloudways 的 Monitoring 可以把 CPU、RAM、磁碟 I/O、流量及應用程式狀態放在同一個升級前後檢查流程中查看。本文以 WordPress 為例，示範如何先記錄現象，再確認備份、選擇資源、覆核維護提示，最後用同一組指標驗證結果。示範畫面中的伺服器名稱、網域、IP、電郵、帳戶及登入資料均已遮蔽；最頂部一般瀏覽器介面可保留。

何時應該開啟 Monitoring？

當訪客回報間歇性 5xx、後台載入緩慢、Cron 延遲，或付款及表單偶爾失敗時，先用同一時間範圍比較監察圖表。一次短暫尖峰不一定代表主機不足，至少記錄一個繁忙時段，並把網站錯誤時間與圖表時間對照。

步驟 1：先記錄問題發生的時間

記下問題開始及結束的時間、受影響的網址、操作類型及錯誤訊息。不要把真實網域、電郵或訂單編號直接貼到公開記事；截圖只保留示範標籤，識別資料以黑條遮住。

步驟 2：建立升級前備份

在調整伺服器規格前建立一次按需備份，並確認備份完成時間及保留政策。備份是回退基線，遇到相容性或部署問題時，可以先回到變更前狀態；不要在備份仍進行時開始升級。

步驟 3：按瓶頸選擇資源

回到 Monitoring 對照 CPU、RAM、磁碟使用量與 I/O。CPU 長期滿載可考慮增加 vCPU，記憶體不足或 PHP worker 排隊可考慮增加 RAM，磁碟接近上限才增加容量。不同雲端供應商的可回退規則不同，儲存容量通常不能直接縮減，選擇前先查看控制台顯示的規格和費用。

步驟 4：覆核規格、費用與維護提示

在確認頁覆核新規格、預估費用、備份狀態及可能的維護或短暫離線提示。確認網站沒有正在進行的部署、匯入或資料庫工作，並先通知團隊在升級期間不要修改內容。公開文章可以保留一般方案價格，但不應保留任何帳戶或付款識別資料。

步驟 5：等待操作完成並持續監察

開始升級後不要重複點擊，也不要同時修改伺服器設定。等待狀態列完成，期間可準備網站健康檢查清單；若畫面顯示錯誤，先保存訊息和時間，再按控制台提供的回退或支援流程處理。

步驟 6：驗證容量與網站功能

完成後重新查看 CPU、RAM、磁碟與應用程式健康狀態，並測試首頁、登入、表單、付款、佇列及 Cron。保留升級前後數據，至少觀察一個高峰週期；若仍然緩慢，再從資料庫、外掛或程式碼找原因。每次只改一項，方便回退。

常見問題：CPU 高是否一定要升級？

不一定。爬蟲、未快取查詢、影像處理及外掛排程都可能短時間吃盡 CPU。先用日誌和時間軸找出觸發者，再決定優化、限流或增加資源。

常見問題：可以直接重啟解決嗎？

重啟可能暫時清除佇列，卻不會修正程式錯誤或資源洩漏。只有在已建立備份、確認維護影響並有回退方案時，才把重啟列入處理步驟。

總結

有效的 Cloudways 排錯流程是「記錄時間 → 比較資源 → 對照日誌 → 檢查背景工作 → 單項修正 → 建立基線」。把每次事故的數據保存到本機 Markdown 知識庫，下一次遇到相同症狀時便可以更快判斷。