某企業有一台已經運作多年的 Linux 伺服器，主機上放置多個網站、資料庫、排程與寄信服務，但原維護人員離開後，企業只保留部分登入資料，沒有完整的伺服器文件。
網站表面上仍能開啟，但沒有人能確定備份是否正常、哪些排程正在執行、DNS 由誰管理，也不清楚哪些帳號還有伺服器權限。
這類伺服器最危險的地方，不是當下已經故障，而是發生問題時沒有人知道該從哪裡處理。
案例重點：伺服器接手的第一步不是立刻更新所有套件，也不是直接搬家，而是先確認目前環境能不能被管理、能不能備份、能不能還原。
接手前的伺服器狀況
- Linux 伺服器已運作多年。
- 主機上放置多個企業網站。
- 網站使用不同 PHP 版本。
- 部分網站透過 cPanel 管理。
- 另有 aaPanel、1Panel 或一般 Linux 主機管理經驗需求。
- MySQL／MariaDB 資料庫數量較多。
- 存在多組 Cron 排程。
- 有網站寄信與第三方 API 串接。
- 沒有完整的帳號與權限清單。
- 備份是否可還原並不明確。
企業目前擁有 root 登入資訊，但不清楚過去有哪些人使用過 root，也不知道是否還存在其他 SSH 金鑰或管理員帳號。
接手時發現的主要問題
初步盤點後，發現伺服器並非只有單一故障，而是存在多個維運風險。
- 網站與帳號對應關係不完整。
- 部分網域不確定由哪個 DNS 平台管理。
- 多個網站使用舊版 PHP。
- 備份排程存在，但沒有還原測試紀錄。
- 部分 Cron 沒有輸出 Log。
- 主機上保留過期帳號與 SSH 金鑰。
- 沒有記錄最近做過哪些設定修改。
- 磁碟使用量持續增加，但沒有告警。
- 網站錯誤紀錄分散在不同位置。
- 不知道哪些服務可以重啟，哪些不能直接中斷。
這類環境如果直接進行大規模升級，可能讓原本還能運作的舊網站立即發生相容性問題。
1）建立伺服器基本資訊清單
接手後先記錄作業系統、核心版本、主機名稱、IP、磁碟與主要服務。
常用檢查指令包括：
hostnamectl
cat /etc/os-release
uname -a
ip addr
df -h
lsblk
free -m
接著確認伺服器目前使用的 Web Server、資料庫與 PHP 環境：
systemctl status httpd
systemctl status apache2
systemctl status nginx
systemctl status mariadb
systemctl status mysql
php -v
如果使用控制面板，也要記錄：
- cPanel／WHM 版本。
- aaPanel 版本。
- 1Panel 版本。
- 面板登入網址與 Port。
- 面板管理員帳號。
- 目前管理的網站數量。
重點：先建立現況基準，之後任何修改才有辦法比較前後差異。
2）盤點帳號、SSH 與管理權限
伺服器接手最重要的工作之一，是確認誰還能登入主機。
先查看系統帳號：
cat /etc/passwd
再檢查具備管理權限的群組：
getent group wheel
getent group sudo
同時查看 SSH 設定：
cat /etc/ssh/sshd_config
主要確認：
- SSH 使用哪個 Port。
- 是否允許 root 密碼登入。
- 是否使用 SSH 金鑰。
- 有哪些帳號可透過 SSH 登入。
- 是否存在來源不明的 authorized_keys。
- 是否有離職人員帳號仍保留。
對來源不明的帳號或金鑰，不會在未確認用途前直接刪除，而是先記錄、備份，再與企業確認。
3）盤點網站、網域與主機帳號
接著整理伺服器上有哪些網站，以及每個網站對應哪個帳號、路徑與網域。
盤點內容包括：
- 網站網域。
- 網站根目錄。
- 系統帳號。
- PHP 版本。
- 資料庫名稱。
- SSL 憑證。
- DNS 管理平台。
- Cloudflare 是否開啟代理。
- 是否有測試站或舊站。
- 是否有停用但未刪除的網站。
部分主機會留下多份網站備份、舊版目錄或測試檔案，因此不能只依資料夾名稱判斷哪一份是正式網站。
需要透過 Web Server 設定、網域解析與實際請求結果交叉確認。
4）確認資料庫與網站的對應關係
伺服器上如果有多個網站，資料庫通常也不少。接手時要確認每個資料庫由哪個網站使用。
盤點內容包括：
- 資料庫名稱。
- 資料庫使用者。
- 網站設定檔位置。
- 資料庫大小。
- 最近更新時間。
- 是否存在無人使用的舊資料庫。
可以先查看所有資料庫：
mysql -e "SHOW DATABASES;"
再查看資料庫大小：
mysql -e "
SELECT table_schema,
ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;
"
不會在第一次盤點時直接刪除看起來沒有使用的資料庫，因為部分排程、API 或舊系統可能仍會連線使用。
5）檢查現有備份是不是真的可用
原伺服器雖然存在備份檔案，但只有看到備份，不代表真的能還原。
本次接手主要檢查：
- 備份檔案是否持續產生。
- 最近一次成功備份時間。
- 網站檔案是否完整。
- 資料庫是否包含在備份內。
- 備份是否存放在同一顆硬碟。
- 是否有異地備份。
- 備份壓縮檔能否正常開啟。
- 是否有還原測試紀錄。
對重要網站先執行小型還原測試，確認資料庫匯入、程式檔案與設定檔都能正常使用。
發現：部分備份排程雖然每天執行，但因磁碟空間不足，最近幾次備份實際上並未完整完成。
6）盤點 Cron 與自動化排程
伺服器上的 Cron 可能負責備份、寄信、訂單檢查、資料同步與憑證更新。
先查看系統排程：
crontab -l
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
再依不同帳號查看使用者排程。
盤點後將排程分類為：
- 系統維護排程。
- 網站功能排程。
- 備份排程。
- 資料同步排程。
- 寄信排程。
- 用途不明排程。
原本部分排程使用：
php script.php
但主機同時存在多個 PHP 版本，容易因系統預設 PHP 改變而出錯。
後續改為明確指定 PHP 執行路徑，並加入 Log：
/usr/bin/php /path/to/script.php >> /var/log/project-cron.log 2>&1
7）檢查磁碟、記憶體與系統負載
接手時主機仍能運作，但磁碟使用量已接近警戒範圍。
主要檢查：
df -h
du -sh /home/*
du -sh /var/log/*
free -m
uptime
top
發現空間主要被以下內容占用：
- 舊網站壓縮備份。
- 大量未輪替的 Log。
- 郵件帳號累積檔案。
- 過期的資料庫匯出檔。
- 開發人員手動留下的網站副本。
處理前先確認檔案用途與保存需求，再分批移至外部儲存或清理。
8）檢查主機安全與異常登入
伺服器接手不能只看網站是否正常，也要確認是否存在可疑登入或惡意程式。
檢查項目包括：
- 近期 SSH 登入紀錄。
- 登入失敗紀錄。
- 來源不明的管理員帳號。
- 可疑 PHP 檔案。
- 異常排程。
- 開放 Port。
- 防火牆規則。
- 長期未更新的套件。
常用指令：
last
lastb
ss -lntup
ps aux
網站目錄則檢查近期修改檔案：
find /home -type f -mtime -7
如果發現來源不明的 PHP 檔案，不會只刪除單一檔案，而是繼續確認入口、修改時間、同類型檔案與受影響帳號。
9）建立監控與告警
原主機沒有完整告警機制，過去通常是客戶先發現網站無法開啟，才通知維護人員。
接手後建立基本監控項目：
- 網站 HTTP／HTTPS 可用性。
- 主機 CPU 使用量。
- 記憶體與 Swap。
- 磁碟使用量。
- MySQL／MariaDB 狀態。
- Apache、Nginx、LiteSpeed 狀態。
- PHP-FPM 狀態。
- SSL 憑證到期時間。
- 重要排程是否完成。
- 備份是否成功。
監控的目的不是避免所有故障，而是讓問題在客戶發現前，就能先收到通知。
10）建立變更與維護紀錄
過去主機設定修改後沒有留下紀錄，導致後續人員不知道哪些設定是刻意調整，哪些是歷史遺留。
接手後建立簡單的變更紀錄，內容包含：
- 修改日期。
- 修改人員。
- 修改原因。
- 修改前設定。
- 修改後設定。
- 影響範圍。
- 回復方式。
- 驗證結果。
即使只是調整 PHP 版本、Cron 或防火牆，也要留下基本紀錄。
接手後的處理優先順序
- 確認 root、SSH 與控制面板權限。
- 建立伺服器與網站清單。
- 確認備份與還原能力。
- 盤點 DNS、SSL、資料庫與排程。
- 檢查磁碟、記憶體與服務狀態。
- 檢查異常登入與可疑檔案。
- 建立監控與告警。
- 處理高風險問題。
- 再規劃 PHP、系統與套件升級。
這個順序的重點是先確保可回復，再進行改善。
處理結果
- 完成伺服器、網站、資料庫與網域清單。
- 整理 root、SSH 與控制面板權限。
- 移除確認無需保留的舊帳號與金鑰。
- 重新整理備份排程。
- 完成重要網站的小型還原測試。
- 為重要 Cron 增加執行紀錄。
- 清理過期備份與異常增長的 Log。
- 建立網站、服務與磁碟告警。
- 建立日後修改所需的變更紀錄。
- 將舊版 PHP 升級列為分階段處理項目。
伺服器沒有在接手當天全部重做，也沒有立即搬移所有網站，而是先把現有環境整理成可以掌握與回復的狀態。
從這個案例可以得到什麼經驗？
- 伺服器可以運作，不代表維運狀況正常。
- 有 root 密碼，不代表已經掌握全部權限。
- 有備份檔案，不代表一定能還原。
- 用途不明的 Cron 不能直接刪除。
- 舊 PHP 不能在沒有測試的情況下直接升級。
- 主機設定修改應留下變更與回復方式。
- 監控與告警是伺服器維護的基本項目。
- 接手時先求可控，再求最佳化。
