不停機降本的四個動作：從賬單反推配置
降本不是砍配置，是從賬單與監控反推真實需求：讀賬單找大頭、用利用率找浪費、先降後升驗證、復測確認無回歸。四個動作全程不停機，附命令與回滾預案。
降本最怕兩件事：砍出停機、砍出性能回歸。本篇是服務器選型中心的實操 spoke：四個動作按順序走完，全程業務不中斷——核心思路是從賬單反推配置，而不是從感覺出發砍資源。
動作一：讀賬單，找到前三大成本項（30 分鍾）
把月度支出按機器/服務排序，通常前三項佔大頭。逐項標注：這臺機器承載什麼業務、峯谷時段、能不能合並。賬單讀不出來的，用監控補——沒有監控的機器先裝監控再談降本（順序不能反）：
# 服務器端最小監控採樣（每 5 分鍾一次，寫入 CSV 留檔 30 天）
top -bn1 | head -n 12 # CPU/內存快照
free -m # 內存與 swap 使用
df -h / # 磁盤水位
ss -s # 連接數概覽
iostat -x 1 3 # 磁盤 IO 壓力（需 sysstat）動作二：用利用率找浪費（一天觀察期）
| 指標（30 天均值） | 浪費信號 | 動作 |
|---|---|---|
| CPU < 20% 且無波峯 | 算力超配 | 降一檔 CPU/合並負載 |
| 內存長期 < 50% | 內存超配 | 降檔或加駐緩存喫掉餘量 |
| 磁盤使用 < 30% | 存儲超配 | 換小盤檔、清歷史快照 |
| 帶寬峯值 < 套餐 1/4 | 帶寬超配 | 降帶寬檔或轉按量 |
| 整機閒置（測試機常駐） | 純浪費 | 改按需啓停 + 快照 |
動作三：先降後升，灰度驗證（每步可回滾）
降配的正確姿勢是一次只動一個維度：先降內存觀察 3 天，再降 CPU 觀察 3 天。每步之前做快照（回滾保險），每步之後核對三條線：錯誤率、P99 延遲、資源水位。任何一條劣化超閾值 → 立即回滾快照，本維度到此爲止。
# 降配前快照與狀態留檔（以常見面板/CLI 爲例）
virsh snapshot-create-as web01 pre-downgrade # 或面板「創建快照」
sar -u -r -n DEV 1 10 > /root/baseline.txt # 降配前基線
# 降配後同命令再採一輪，diff 兩份基線動作四：復測確認，把新水位寫進告警線
降配完成後重跑一輪壓測（或等一個真實波峯），確認新配置的水位仍留有 ≥30% 餘量；然後把告警線按新配置重寫——舊告警線對新配置太松，等於沒有告警。最後把本輪「賬單 → 決策 → 結果」記檔，下季度復盤直接引用。
兩條紅線
- 數據庫主節點不做大跨度降配：內存降檔對緩存命中率的影響是非線性的，最多降一檔並觀察一周；
- 不爲省小錢動生產入口：負載均衡/DNS 入口層的機器規格保持冗餘，這裏省錢的風險收益比最差。
合並與搬遷：降本的另一半
降配之外，還有兩類動作常被忽略：①合並——多臺低負載機器並到一臺高配（連接數與內存留足餘量），省的是「每臺機器的固定底價」；②搬遷——對地區不敏感的負載（批處理、備份存儲、內部工具）搬到更便宜的檔位或地區，省的是地區溢價。合並的檢查點：
# 合並前：確認端口/進程不衝突，資源水位相加後仍留 30% 餘量
ss -tlnp # 各機監聽端口清單，人工比對衝突
journalctl -u nginx -u php-fpm --since "7 days ago" | grep -ci error # 近 7 天錯誤基數
# 合並動作：逐臺遷移 + 每臺之間觀察一天
rsync -avz 舊機:/var/www/ /var/www/legacy-1/
# 合並後：同基線命令再採一輪對照什麼時候不該降本
- 增長爬坡期：負載曲線每月都在抬升時，降配等於給自己埋雷——先扛住增長，季度末再復盤；
- 大促/發布前 30 天：變更窗口凍結期，任何降配都推到活動結束後；
- 故障復盤期間：剛出過性能事故就降配，等於銷毀現場還添新變量；
- 沒有 30 天監控數據時：拍腦袋降本的事故率遠高於收益——先裝監控（動作一的命令塊），數據到位再動手。
三樣東西不能拿來降本
- 備份保留期——把 30 天保留砍成 7 天省下的錢，一次誤刪事故就百倍奉還；
- 監控覆蓋——關掉撥測與告警等於盲飛，省的是小錢、賭的是全部；
- 安全基線——防火牆、補丁、密鑰管理的成本不可壓縮（哪些動作屬於不可省的安全基線，見安全基線中心）。降本的對象是浪費，不是保險。
降本的成果怎麼守住
降完不是結束：把新水位寫進告警線只是第一步，還要把「每核·每小時實際成本」做成月度指標——它比賬單總額更誠實（賬單受促銷與匯率擾動）。指標連續兩個月回升，說明負載在漲或有新的浪費點，回到動作二重跑。降本不是一次項目，是一個季度節律。