不停机降本的四个动作：从账单反推配置
降本不是砍配置，是从账单与监控反推真实需求：读账单找大头、用利用率找浪费、先降后升验证、复测确认无回归。四个动作全程不停机，附命令与回滚预案。
降本最怕两件事：砍出停机、砍出性能回归。本篇是服务器选型中心的实操 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 天省下的钱，一次误删事故就百倍奉还；
- 监控覆盖——关掉拨测与告警等于盲飞，省的是小钱、赌的是全部；
- 安全基线——防火墙、补丁、密钥管理的成本不可压缩（哪些动作属于不可省的安全基线，见安全基线中心）。降本的对象是浪费，不是保险。
降本的成果怎么守住
降完不是结束：把新水位写进告警线只是第一步，还要把「每核·每小时实际成本」做成月度指标——它比账单总额更诚实（账单受促销与汇率扰动）。指标连续两个月回升，说明负载在涨或有新的浪费点，回到动作二重跑。降本不是一次项目，是一个季度节律。