伺服器管理
生產營運的伺服器管理原則。 學習思考方式,而非記憶指令。
1. 程序管理原則
工具選擇
| 情境 | 工具 |
|---|---|
| Node.js 應用 | PM2(叢集、重載) |
| 任何應用 | systemd(Linux 原生) |
| 容器 | Docker/Podman |
| 編排 | Kubernetes、Docker Swarm |
程序管理目標
| 目標 | 意義 |
|---|---|
| 崩潰時重啟 | 自動恢復 |
| 零停機重載 | 無服務中斷 |
| 叢集 | 使用所有 CPU 核心 |
| 持久性 | 在伺服器重啟後存活 |
2. 監控原則
要監控什麼
| 類別 | 關鍵指標 |
|---|---|
| 可用性 | 正常運行時間、健康檢查 |
| 效能 | 回應時間、吞吐量 |
| 錯誤 | 錯誤率、類型 |
| 資源 | CPU、記憶體、磁碟 |
警報嚴重度策略
| 層級 | 回應 |
|---|---|
| 關鍵 | 立即行動 |
| 警告 | 儘快調查 |
| 資訊 | 每日檢視 |
監控工具選擇
| 需求 | 選項 |
|---|---|
| 簡單/免費 | PM2 指標、htop |
| 完整可觀測性 | Grafana、Datadog |
| 錯誤追蹤 | Sentry |
| 正常時間 | UptimeRobot、Pingdom |
3. 日誌管理原則
日誌策略
| 日誌類型 | 用途 |
|---|---|
| 應用日誌 | 除錯、稽核 |
| 存取日誌 | 流量分析 |
| 錯誤日誌 | 問題偵測 |
日誌原則
- 輪替日誌 防止磁碟滿
- 結構化日誌(JSON)方便解析
- 適當層級(error/warn/info/debug)
- 日誌中不含敏感資料
4. 擴展決策
何時擴展
| 症狀 | 解決方案 |
|---|---|
| 高 CPU | 新增實例(水平) |
| 高記憶體 | 增加 RAM 或修復洩漏 |
| 回應慢 | 先分析,再擴展 |
| 流量尖峰 | 自動擴展 |
擴展策略
| 類型 | 適用時機 |
|---|---|
| 垂直 | 快速修復、單一實例 |
| 水平 | 可持續、分散式 |
| 自動 | 變動流量 |
5. 健康檢查原則
什麼構成健康
| 檢查 | 意義 |
|---|---|
| HTTP 200 | 服務正在回應 |
| 資料庫已連線 | 資料可存取 |
| 依賴正常 | 外部服務可達 |
| 資源正常 | CPU/記憶體未耗盡 |
健康檢查實作
- 簡單:僅回傳 200
- 深入:檢查所有依賴
- 根據負載平衡器需求選擇
6. 安全原則
| 領域 | 原則 |
|---|---|
| 存取 | 僅用 SSH 金鑰、無密碼 |
| 防火牆 | 僅開啟需要的埠口 |
| 更新 | 定期安全修補 |
| 密鑰 | 環境變數、不是檔案 |
| 稽核 | 記錄存取和變更 |
7. 疑難排解優先順序
出問題時:
- 檢查是否在執行(程序狀態)
- 檢查日誌(錯誤訊息)
- 檢查資源(磁碟、記憶體、CPU)
- 檢查網路(埠口、DNS)
- 檢查依賴(資料庫、API)
8. 反模式
| ❌ 不要 | ✅ 要 |
|---|---|
| 以 root 執行 | 使用非 root 使用者 |
| 忽略日誌 | 設定日誌輪替 |
| 跳過監控 | 從第一天就監控 |
| 手動重啟 | 自動重啟配置 |
| 無備份 | 定期備份排程 |
記住: 管理良好的伺服器是無聊的。那就是目標。