结论:服务器降本增效的正确顺序是「先回收闲置、再做规格右调、最后谈采购折扣」。先把没人用的资源关掉,再按真实负载把规格调到刚刚好,最后用包年包月与预留实例换折扣,三步下来常见可降 30%~50%,且不影响稳定性。
很多团队一提降本就去跟云厂商谈折扣,结果折扣拿到了,账单一看没降多少——因为钱花在了「开着但没人用」的机器上。真正有效的降本增效,本质是一套数据驱动的持续优化流程(FinOps,云财务管理):看得见成本、找得到浪费、改得动配置、守得住稳定性。本文给出可立即执行的六大手段与配套命令。
服务器成本到底花在哪?先拆解构成
结论:先把账单拆成「计算、存储、带宽、增值服务、人力」五类,找出占比最大的那一类再动手。通常中小企业的计算资源占 50%~65%,存储占 10%~20%,带宽占 10%~25%。
| 成本项 | 典型占比 | 常见浪费点 | 优化空间 |
|---|---|---|---|
| 云主机 / 物理机(计算) | 50%~65% | 规格过高、长期低负载、测试机常开 | 20%~40% |
| 块存储(云盘) | 8%~15% | 已卸载但未释放的云盘、高性能盘装冷数据 | 10%~30% |
| 对象存储 | 3%~10% | 全部存标准类型、无生命周期规则 | 30%~60% |
| 公网带宽 / 流量 | 10%~25% | 按固定带宽付费但峰值只用几小时、未开 CDN | 20%~50% |
| 数据库(RDS) | 5%~15% | 规格冗余、备份保留过久、只读实例闲置 | 15%~30% |
| 负载均衡 / NAT / WAF | 3%~8% | 多个 LB 各挂少量实例、闲置公网 IP | 10%~20% |
| 快照与备份 | 2%~5% | 快照保留策略永不过期 | 30%~50% |
| 人力运维 | 隐性 | 大量时间花在手工扩容与救火 | 难以量化 |
拆账单的三条实操建议:
- 按标签(Tag)分账。给每台资源打
env(prod/test)、owner(团队)、service(业务线)标签,否则账单只能看到一串数字,无法归因。 - 看「单位成本」而非「总成本」。单订单成本、单 QPS 成本、单用户成本,这些指标才能判断降本是否真的有效。
- 区分「浪费」与「必要冗余」。生产环境为了高可用保留 30% 余量是必要的,测试环境开 8 核跑一个静态页面才是浪费。
# 本机成本自查:找出长期低负载却开着高规格的迹象
uptime # 看 15 分钟平均负载
free -g && nproc
sar -r 1 5 2>/dev/null || vmstat 1 5
# 统计过去 30 天 CPU / 内存的真实峰值(需已部署 node_exporter + Prometheus)
# CPU 峰值
# max_over_time((100 - avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)[30d:5m])
# 内存峰值
# max_over_time((100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))[30d:5m])手段一:闲置资源回收——最快见效的动作
结论:先把「开着但没人用」的资源清掉,这一步通常能立竿见影降 10%~25%,且零风险。
常见的闲置资源清单:
- 未绑定的弹性公网 IP:云厂商对闲置 EIP 收费,很多人不知道。
- 已停止但未释放的云主机:停机后云盘和 EIP 仍计费。
- 卸载状态的数据盘:实例删了,云盘还在。
- 没人访问的测试环境:开发测试机 7×24 开机,实际每天只用 4 小时。
- 过期快照:自动快照策略没设保留期限,一年累积几百个。
- 僵尸负载均衡:实例已下线,LB 还挂着。
# Linux 主机侧:找出 30 天未被访问的站点目录(判断是否可下线)
for d in /var/www/*/; do
last=$(find "$d" -type f -name '*.log' -mtime -30 | head -1)
[ -z "$last" ] && echo "疑似闲置站点: $d"
done
# 找出长期无连接的监听端口(服务可能已无人使用)
ss -lntp
# 配合 Nginx 访问日志统计各域名的近 30 天请求数
awk -F'"' '{print $2}' /var/log/nginx/access.log | awk '{print $2}' | sort | uniq -c | sort -rn | head -20
# 找出大文件与长期未访问的冷数据(准备降冷存储)
find /data -type f -size +100M -atime +90 -printf '%s\t%p\n' | sort -rn | head -30执行纪律:查出闲置资源后,先停机观察 7 天再释放,避免误删。释放前务必确认快照或备份存在。
手段二:规格右调(Right Sizing)
结论:按过去 30 天的真实峰值而不是平均值来定规格,峰值上加 30% 余量即可。一台 8 核机器长期 CPU 峰值只有 20%,降到 4 核完全够用。
| 观察指标 | 30 天峰值 | 建议动作 |
|---|---|---|
| CPU 使用率 | < 20% | 降一档(如 8C → 4C) |
| CPU 使用率 | 20%~50% | 保持,或降半档 |
| CPU 使用率 | 50%~80% | 理想区间,不动 |
| CPU 使用率 | > 80% | 升配或做性能优化 |
| 内存使用率 | < 40% | 降内存档位 |
| 磁盘使用率 | < 30% | 缩容云盘(注意需先快照) |
| 带宽使用率 | 峰值 < 付费带宽 30% | 降带宽或改按流量计费 |
右调的注意事项:
- 先优化再降配。很多时候 CPU 高是因为没开 OPcache、没加索引、日志级别开到 DEBUG,优化完自然就能降配。
- 数据库降配要谨慎。MySQL 的 buffer pool 缩小后 IO 压力会上升,降配后必须观察慢查询数。
- 分批执行。一次改 3~5 台,观察 24 小时无异常再继续,避免批量操作引发大面积故障。
- 利用停机窗口。多数云平台变配需要重启,安排在业务低峰执行。
# 降配前的性能基线记录(降配后对比,确认没有劣化)
echo "=== $(date) ===" >> /var/log/baseline.log
uptime >> /var/log/baseline.log
free -m >> /var/log/baseline.log
iostat -x 1 3 >> /var/log/baseline.log 2>/dev/null
curl -sS -o /dev/null -w 'P99探测 http=%{http_code} total=%{time_total}s\n' https://www.example.com/手段三:预留实例与包年包月
结论:稳定负载用包年包月或预留实例(Reserved Instance)换 30%~50% 折扣,波动负载保留按量付费。混合付费是成本最优解。
| 付费方式 | 折扣幅度(参考) | 适合场景 | 灵活性 |
|---|---|---|---|
| 按量付费 | 无折扣,单价最高 | 短期任务、临时压测、不可预测负载 | 随时释放 |
| 包年包月 | 相对按量约 6~8 折 | 长期稳定运行的生产服务 | 可升配,退订有成本 |
| 预留实例券 | 相对按量约 5~7 折 | 已确定一年以上的基线负载 | 抵扣指定规格,灵活匹配 |
| 抢占式实例 | 相对按量约 1~3 折 | 批处理、CI 构建、无状态计算 | 可能被回收 |
(以上折扣为截至 2026 年主流云厂商的常见区间,实际以官网实时报价为准。)
采购策略:
- 先算基线负载。把过去 90 天的最低负载作为基线,用包年覆盖基线,波动部分用按量。
- 预留实例券优先于包年包月。券是抵扣型,换规格也能用,比锁定某台实例更灵活。
- 到期日历。把包年资源到期日登记到日历,提前 15 天评估续费,避免自动续费到已无用的资源。
- 抢占式实例做 CI/CD。构建机、压测机用抢占式,成本可降到十分之一,但要做好被回收的重试。
手段四:对象存储分层与生命周期
结论:冷数据自动降级到低频 / 归档存储,是存储成本里最容易拿到 30%~60% 降幅的一招。
| 存储类型 | 单价参考(相对标准型) | 访问特点 | 适合数据 |
|---|---|---|---|
| 标准存储 | 1.0× | 随时高频读取 | 网站图片、热点资源 |
| 低频访问 | 约 0.6× | 每月访问 1~2 次 | 备份、日志归档 |
| 归档存储 | 约 0.2× | 每年几次,需解冻 | 合规存档、历史备份 |
| 深度归档 | 约 0.08× | 几乎不访问,解冻数小时 | 长期合规留存 |
配置要点:
- 生命周期规则按前缀或标签生效。例如
logs/前缀 30 天后转低频,90 天后转归档,365 天后删除。 - 注意「最低存储时长」与「解冻费用」。低频通常有 30 天最低存储期,提前删除仍按 30 天计费;归档取回要收费且需等待。
- 别把要频繁访问的数据降冷。降冷省的存储费可能还不够付取回费。
{
"Rules": [
{
"ID": "logs-tiering",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "ARCHIVE" }
],
"Expiration": { "Days": 365 }
},
{
"ID": "abort-incomplete-multipart",
"Status": "Enabled",
"Filter": { "Prefix": "" },
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
}
]
}# 用 AWS CLI 应用生命周期规则(其他云用对应 CLI,参数基本一致)
aws s3api put-bucket-lifecycle-configuration \
--bucket my-logs-bucket \
--lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket my-logs-bucket手段五:CDN 与压缩——把带宽费降下来
结论:把静态资源交给 CDN,并开启 Gzip / Brotli 压缩与 WebP 图片,通常能减少源站 60%~85% 的出网流量。
- CDN 回源合并:开启 CDN 后源站只需响应回源请求,带宽压力骤降,且 CDN 单价通常低于云主机出网带宽。
- 压缩:文本类资源(HTML/CSS/JS/JSON)开启 Brotli 可再压 15%~20%(相对 Gzip)。
- 图片优化:转 WebP / AVIF,体积通常比 JPEG/PNG 小 30%~50%。
- 缓存头:给静态资源设长期
Cache-Control,提高 CDN 命中率。 - 按流量计费的场景:峰值带宽不高但总量大,改按流量 + CDN 更划算。
# /etc/nginx/conf.d/compress.conf
# Brotli(需 ngx_brotli 模块)优先,不支持时回落 gzip
brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types text/plain text/css application/javascript application/json
application/xml image/svg+xml;
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_proxied any;
gzip_types text/plain text/css application/javascript application/json
application/xml+rss image/svg+xml;
# 静态资源长缓存 + 协商缓存策略
map $uri $cache_control {
default "no-cache";
~*\.(js|css|png|jpg|jpeg|gif|webp|avif|woff2)$ "public, max-age=31536000, immutable";
}
add_header Cache-Control $cache_control;# 检查压缩是否真的生效
curl -H 'Accept-Encoding: br' -sSI https://www.example.com/app.js | grep -i 'content-encoding\|content-length'
curl -H 'Accept-Encoding: gzip' -sSI https://www.example.com/app.js | grep -i 'content-encoding\|content-length'
# 统计 CDN 命中率(看响应头)
curl -sSI https://www.example.com/static/logo.png | grep -i 'x-cache\|age\|via'手段六:弹性伸缩与定时降配
结论:有明显波峰波谷的业务,用定时伸缩与自动伸缩把非高峰时段的资源降下来,可再省 20%~40%。
- 定时伸缩:最稳妥。例如工作日 09:00 扩容到 8 台,22:00 缩回 2 台;周末全天保持 2 台。
- 动态伸缩(HPA / ESS):按 CPU、内存或 QPS 触发,适合波动不规律的场景。注意设置冷却时间,避免频繁扩缩。
- 定时开关测试环境:开发测试机每天 08:00 开机、20:00 关机,一年能省下三分之二的费用。
- 缩容保护:一定要配置「最小实例数」和「缩容冷却时间」,防止误判导致业务被打垮。
# 方案 A:用 crontab + 云 CLI 做定时升降配(最通用)
# 每天 22:00 降配(业务低峰),次日 08:30 恢复
0 22 * * * /usr/local/bin/aliyun_cloudops.sh down >> /var/log/autoscale.log 2>&1
30 8 * * * /usr/local/bin/aliyun_cloudops.sh up >> /var/log/autoscale.log 2>&1
# /usr/local/bin/aliyun_cloudops.sh
#!/usr/bin/env bash
set -euo pipefail
INSTANCES=("i-xxxxxxxxxxxx" "i-yyyyyyyyyyyy")
case "$1" in
up) TYPE="ecs.c7.large"; ACTION="升配" ;;
down) TYPE="ecs.c7.medium"; ACTION="降配" ;;
*) echo "usage: $0 up|down"; exit 1 ;;
esac
for id in "${INSTANCES[@]}"; do
echo "$(date '+%F %T') $ACTION $id -> $TYPE"
# 云平台 CLI 示例(以实际厂商命令为准,先停机再改规格)
# aliyun ecs ModifyInstanceSpec --InstanceId "$id" --InstanceType "$TYPE"
done# 方案 B:Kubernetes HPA(容器化场景)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 10
behavior:
scaleDown:
stabilizationWindowSeconds: 300 # 缩容冷却 5 分钟,避免抖动
policies:
- type: Percent
value: 20
periodSeconds: 60
metrics:
- type: Resource
resource:
name: cpu
target: { type: Utilization, averageUtilization: 60 }
- type: Resource
resource:
name: memory
target: { type: Utilization, averageUtilization: 70 }
企业QQ咨询




