文小刚1. 起因：GCP 账单失控前的三个征兆
干云成本优化这行快十年了，经手过的故障和超额账单少说也有一两百起。很多人以为成本失控是瞬间发生的，其实不是。我见过的最典型场景是：某天早上财务甩来一张账单，说“这个月比上个月多了 40%，你们看看怎么回事”，然后 DevOps 同学开始连夜排查，最后在一台被遗忘的 64 核高内存实例上找到了元凶——它已经连续跑了三个月，用途是跑一个没人再看的定时任务。
我一直觉得，云成本优化的核心并不是“省多少钱”，而是“别让钱花在你不知道的地方”。GCP 成本优化的第一步永远是建立可观测性，而不是急着关实例。你连账单里的成本大头都说不清楚，任何优化动作都是拍脑袋。
在动手之前，先对照这几个征兆看看自己是不是已经在失控边缘：
- 项目里所有资源都混在一个账单里，没人说得清某个服务到底花多少钱。
- 预算警报设了，但阈值设在“永远不可能触发”的金额上，纯粹为了应付合规。
- 开发环境、测试环境、生产环境的机器规格一样大，没人按需调整过。
如果中了至少两条，那这份 GCP 成本优化指南就是给你写的。这篇文章里我尽量不写那种“你要关注成本”的废话，全是我自己在项目里验证过的操作、命令、教训，以及踩过坑之后才理解的一些道理。
我按一个完整的优化闭环来梳理：先讲怎么搭成本观测体系，再讲怎么规划架构节省大头，然后讲承诺折扣、存储生命周期、网络流量这些具体的省钱动作，最后是问题排查。你能直接照着一步步操作，也能当字典用，哪个环节出问题就翻哪节。
这套方法适用的对象，主要是已经在 GCP 上有一定资源规模、月度账单在几千到几十万人民币之间浮动、想认真做优化的团队。如果你刚注册账号连实例都没开过，也可以先收藏，回头账单开始涨了再看，体会会更深。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先看清钱花在哪：从账单导出到成本标签的完整闭环
任何成本优化项目，第一步不是省钱，而是把账算清楚。GCP 的计费体系其实比 AWS 要透明一些，原生支持把详细计费数据导出到 BigQuery，这个功能从 2017 年就有了，精度很高，能细化到“某个 SKU 在某个项目里的某个标签下消耗了多少钱”。可惜大多数团队根本没利用起来。
2.1 配置账单导出到 BigQuery：这件事越早做越好
项目创建之初就应该把 Billing Export 开起来。如果现在还没开，先花 10 分钟做这件事，后面所有分析工作都依赖它。
操作路径：GCP Console → Billing → Budgets & alerts → Billing export。
有两个导出选项：一个是“Detailed usage cost”到 BigQuery，另一个是“Detailed usage cost”到 Pub/Sub。我建议先做 BigQuery 导出，因为 BigQuery 本身就是 GCP 的强势产品，查起来极其流畅。Pub/Sub 导出适合有实时成本监控需求的团队，如果你们运维体系还没建好，就别急着上实时链路。
导出表的数据结构分为几类：cloud_billing_export 标准表，以及后续版本增加的 standard table 和 detailed usage cost 表。旧版表结构是按行计费明细，新版加入了更多字段，例如 system_labels、labels、location、cost_type 等。
顺带提醒，在配置导出之前要先启用 BigQuery。详细计费导出 API 叫 cloudbilling.googleapis.com，同时数据导出到 BigQuery 的方式不会额外产生 BigQuery 存储之外的网络流量费用，查询成本按正常 BigQuery 价格收取。
表结构有三块最容易用错，先提醒一下：
- cost 字段是 float，代表这个行项在该计费周期内的费用，currency 字段代表币种。
- usage.amount 是使用量，usage.unit 是单位。核时、GB 月、百万次请求这些单位各不相同，分析时要配合 unit 看。
- system_labels 里面有一个
compute.googleapis.com/resource_name字段，能拿到 Compute Engine 实例的机器名。这是定位“哪台机器最烧钱”的关键线索。
我的习惯是第一次导完后先跑这么一条查询看全局概况：
sql复制SELECT
project.id AS project_id,
service.description AS service_name,
ROUND(SUM(cost), 2) AS total_cost
FROM
`project_id.billing_dataset.gcp_billing_export_v1_xxxx`
GROUP BY
project_id, service_name
ORDER BY
total_cost DESC
LIMIT 20;
通过这个查询，你能在一分钟内知道：钱主要花在 Compute Engine、Kubernetes Engine、Cloud Storage 还是 BigQuery 上。第一次跑完，通常最少三分之一的人会惊讶地发现“怎么还有 Cloud SQL 费用？我们项目早就不用了”。
2.2 成本标签体系：没打标签的资源就像“公海里的垃圾”
看到费用构成之后，第二件事是建立标签体系。GCP 支持在资源级别打标签，比如 env=prod、team=payments、cost_center=growth。标签会同步进 BigQuery 导出的表里，后面所有维度分析都能用。
标签设计有个原则：少而精，别超过 6 个键。我见过团队搞了十几个键，结果没有一个人能填对，标签变成摆设。比较实用的一组是：
env：必填，取值 dev / staging / prod。team：必填，表示归属团队。project_owner：选填，表示负责人邮箱。
在 Compute Engine 实例上打标签的命令是：
bash复制gcloud compute instances update instance-name \
--update-labels=env=prod,team=payments
GKE 节点池的标签设置稍有不同。节点池打标签要用 --node-labels 参数，而且要在创建节点池时指定，或在 NodePool 的配置里改：
bash复制gcloud container node-pools create core-pool \
--cluster=my-cluster \
--node-labels=env=prod,team=payments
标签还有一个细节，新打的标签只对之后产生的费用生效，历史费用不会回填。所以如果你是为了上个季度的账单做分析，靠标签是救不回来的。这就意味着，标签体系应该在业务上线、或至少在收到第一笔值得分析的账单之前就建好。
2.3 预算与警报：让“超支”成为一个事件，而不是一个结果
预算这块没啥技术含量，主要是习惯问题。很多团队只在 GCP Console 上设了一个总预算，然后设了 50%、90%、100% 三个阈值，但从不设基于标签的预算。我建议拆成两层：
第一层是项目总预算，防止整体失控。第二层是基于标签的预算，比如 team=payments 月度预算 1 万元，env=dev 月度预算 2000 元。
预算阈值要按实际使用情况来设，别拍脑袋。我的建议是：50% 代表“提醒一下”，80% 代表“开始评估是否需要限流”，100% 代表“触发推送通知到相关人员”。最终我们通过 Webhook 把 GCP 预算通知接到钉钉/企微群，实现一条简短的预警消息自动推送到工作群：
python复制import json
import requests
def send_to_webhook(message):
webhook_url = "YOUR_DINGTALK_WEBHOOK_URL"
payload = {"msgtype": "text", "text": {"content": message}}
requests.post(webhook_url, json.dumps(payload), headers={"Content-Type": "application/json"})
预算对象在 GCP 控制台里创建后，可以把阈值对应到 Pub/Sub topic 上，由云函数消费后转发。这套链路非常轻量，半天就能配完。别小看这一步，在优化动作落地之前，预算警报就是“汽车仪表盘上油量灯”，没有它你连什么时候该踩刹车都不知道。
3. 让架构本身省钱：资源规格、弹性伸缩与冷热分层
账单看清之后，进入真正的大头优化阶段。我通常在项目里把成本优化手段按“性价比”排序：
第一梯队是“降配”，占整体优化效果的 50% 以上；第二梯队是“弹性伸缩”，按需创建、按需销毁；第三梯队才是“折扣方案”，用承诺使用换取价格优惠。
原因是：降配和弹性伸缩直接减少了真实用量，折扣方案只是降低了单价。用量没变，再怎么打折，基数大的问题依然存在。
3.1 资源规格评估：别为 5% 的峰值付 100% 的账单
这一节是 GCP 成本优化里见效最快的环节。多数团队在选择实例规格时，都是照着“最坏情况”或“上线初期预估峰值”来定的。结果就是生产环境配了 16 核 64G，实际 CPU 常年不超过 10%。
这里我建议所有团队做一个“实例画像”动作，主要是利用 GCP 自带的监控数据选型：
bash复制gcloud monitoring time-series list \
--filter='metric.type="compute.googleapis.com/instance/cpu/utilization"' \
--interval="2024-01-01T00:00:00Z,2024-01-07T23:59:59Z" \
--format="table(metric.labels.instance_name, points)"
以 7 天为窗口，拉出每个实例的 CPU 使用率。经验阈值是：CPU 平均值低于 10% 的实例，直接降一档甚至两档；平均值在 10%-30% 的，降一档后观察；平均值超过 60% 的，不用动，那是确实忙的机器。
内存同理。GCP 的监控里，内存使用率不是默认采集项，需要安装 Cloud Monitoring Agent 或用自定义指标。建议选型时用 GCP 提供的“机器规格推荐”作为参考方向，但最终还要结合自己业务的真实曲线来判断。
降配操作本身很简单：
bash复制gcloud compute instances stop instance-name
gcloud compute instances set-machine-type instance-name \
--machine-type=e2-standard-4
gcloud compute instances start instance-name
注意，这里必须先停止实例才能修改机器类型。如果你跑的是有状态服务，停机时间必须提前规划。对无状态服务，我建议结合机制直接替换，不要把停机当成不可接受的流程。
还有一点要特别提醒：GPU 实例和 TPU 实例的成本远高于 CPU 实例。如果你不确定任务是否需要 GPU，先在 CPU 上用小规模数据跑一遍 profiling，只看 CPU 耗时。如果 CPU 耗时已经能接受，就没必要上 GPU。上了 GPU 之后，要设置“空闲自动关机”，否则一个没人用的 GPU 实例可能是账单里最大的单项成本。
3.2 弹性伸缩的真相：省钱的不是“自动扩”，而是“自动缩”
很多人一听“弹性伸缩”就兴奋，觉得这是成本优化的王牌。但从实际看，自动扩缩容在多数场景里是把双刃剑：扩容规则设置得太灵敏，流量一起来就疯狂加节点；缩容规则又设了十分钟冷却期，结果流量已经降下去了，机器还撑着。
GCP 的托管实例组（Managed Instance Group，简称 MIG）支持基于 CPU 使用率的自动伸缩。这是最基础的配置，关键是合理设置参数，不是简单开个开关。
一个比较稳的配置参考：
- 初始实例数：1 台（最小可靠规模）。
- 最大实例数：根据业务峰值预估。如果上线以来峰值是 10 台，那最大设成 12 台留一点余量。
- CPU 利用率目标：60%-70%。低于 60% 会缩容，高于 70% 会扩容。
- 扩缩容冷却时间：扩容设 60 秒，缩容设 600 秒。扩容追求快，缩容要求稳。
这样设置的逻辑是，扩容时 60 秒等待能避免因瞬时抖动频繁加机器；缩容等 10 分钟，是给负载均衡器留出连接排空的时间，防止正在处理的请求被切断。
注意：MIG 自动伸缩只适用于无状态服务。如果你要在实例上写本地文件，必须把状态放到外部存储（Cloud SQL / Spanner / Redis / GCS），否则缩容一次就丢一次数据，这个代价远大于省下的那点机器费用。
3.3 GKE 场景下的成本视角：节点池拆分与资源请求
用 GKE 跑业务的团队，成本优化要从“集群维度”转到“节点池维度”。我常看到的反面案例：一个集群里只有两个节点池，一个叫 default-pool（全是 n1-standard-4），一个叫 spot-pool（全部抢占式）。然后什么负载都塞进去，按调度随便跑，最后成本完全不可控。
规范做法是按优先级和能力拆分节点池。标准环境用一个稳定节点池，跑关键业务；批处理任务和容错服务用 Spot 节点池。关键一步是给节点池打上标签，并在 Pod 的 nodeSelector 或 nodeAffinity 里指定：
yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
name: batch-job
spec:
template:
spec:
nodeSelector:
cloud.google.com/gke-spot: "true"
同时，Kubernetes 的成本黑洞通常是“没有设置 requests”。如果 Pod 不声明 requests，调度器就不知道它会占用多少资源，所有服务都挤在一起，CPU 被打满后扩容算法不断加节点，账单飙升但业务响应还是在变慢。
给 Pod 加资源声明是成本治理的基础：
yaml复制resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: 1
memory: 1Gi
requests 是调度依据，limits 是运行上限。从成本视角，requests 比 limits 重要得多，因为集群的自动扩缩容看的是“调度到节点上的 requests 总量”，不是“实际负载”。
建议用 GKE 自带的 Vertical Pod Autoscaler（VPA）跑一周，在推荐模式下观察它建议的 requests 值，再按业务实际情况做微调，然后改为 Auto 模式，让 VPA 自动调整。仅这一步，通常能让 GKE 集群的节点数减少 30% 左右。
3.4 开发环境的定时休眠：没人用的资源必须“会睡觉”
这是成本优化手段里最枯燥但最有效的一项。我见过太多开发、测试环境的实例一周 7 天、一天 24 小时坚挺运行。开发人员白天偶尔用一下，晚上和周末完全空闲，但费用照收不误。
GCP 有个原生方案叫 compute.instances.stop 的定时任务，配合 Cloud Scheduler 和 Cloud Functions 实现。我常用一个极简版本，先用 Python 写一个云函数：
python复制from google.cloud import compute_v1
def stop_idle_instances(event, context):
instances_client = compute_v1.InstancesClient()
projects = ["dev-project-a", "dev-project-b"]
zones = ["asia-east1-a", "asia-east1-b"]
for project in projects:
for zone in zones:
request = compute_v1.AggregatedListInstancesRequest()
request.project = project
aggregated_list = instances_client.aggregated_list(request=request)
for zone_path, instances_in_zone in aggregated_list:
for instance in instances_in_zone.instances:
labels = instance.labels
if labels.get("env") == "dev" and instance.status == "RUNNING":
stop_request = compute_v1.StopInstanceRequest()
stop_request.project = project
stop_request.zone = zone_path.rsplit("/", 1)[-1]
stop_request.instance = instance.name
instances_client.stop(stop_request)
print(f"stopped: {instance.name}")
注意这个代码只匹配标签为 env=dev 的实例，避免误伤生产环境。上线前一定要先在小项目里测试一次，确认停止列表里没有生产实例。
别贪心。
定时触发器设置成：工作日 20:00 停止，工作日 07:00 启动。启动逻辑类似，只是把 Stop 换成 Start。这样一周下来，开发环境的在线时间从 168 小时降到约 65 小时，节省约 60% 的常驻费用。
这里也说一个重要心得：如果你所在团队没人值班去“手动启动开发机器”，那就别搞定时关机。否则周一早上开发发现机器关了，又不知道怎么开，怨声载道，最终这个方案会被人偷偷停掉。上线前提前与开发团队沟通好规则，让他们知道“晚 8 点机器会被停，第二天早上会自动起来，数据还在”，大家接受度会高很多。
4. 折扣与存储策略：从“用多少付多少”到同类资源尽享折扣
4.1 承诺使用折扣（CUD）：拿确定性换价格
CUD（Committed Use Discount）是 GCP 用“未来 1 年/3 年的承诺”换“当前账单折扣”的方案。Compute Engine 的 CPU、内存承诺最高可以打 55% 左右（3 年承诺），Cloud SQL、Cloud Run、Spanner 也有类似形态。
对成本优化有经验的人，不会一上来就无脑买 CUD，而是先用前几步把用量压下来，再评估购买。买 CUD 之前，至少要有最近 3 个月、最好是 6 个月的资源用量曲线。判断标准是“这些资源在未来承诺期内是否稳定占用”？
我从一个实际项目的简化例子来说明思路。假设有一个项目，运行着 20 台 e2-standard-8（8 vCPU，32GB 内存）实例，7×24 小时不关机，过去半年的 CPU 使用率几乎没有波动。那么这 160 个 vCPU 和 640GB 内存的持续用量，很适合买 CUD。
如果某个资源本质上会被定期清理，比如大数据批处理集群，则不建议立刻购买 CUD。许多团队以为买了一年期 CUD 就能便宜，但半年后重构微服务后计算资源形态大变，当初承诺的 CUD 部分被闲置，钱还是花出去了。
GCP 资源抵扣规则需要熟悉：CUD 分为“基于资源”的 CUD（旧版）与“灵活 CUD”（Flexible CUD）。如果资源金额足够大，优先购买灵活 CUD，这样跨系列调整规格时不至于浪费信用额度。关于多项目共用一个 CUD 账本的场景，要注意把承诺规划放在 Billing Account 层级，而不是单个 Project 层级，这样才能让折扣覆盖更广范围内所有匹配的机器。
在 GCP Console 里购买路径是：Billing → Commitments → Create Commitment。按需填区域和核数/内存即可，很少踩坑。唯一要反复确认的是区域，CUD 是区域级别的，你承诺了 4 个核在 asia-east1，它只会抵扣这个区域里的用量，其他区域完全不会计入。这设计让不少团队把 CUD 买错了区域，得在创建后 72 小时以内退掉重买。
4.2 抢占式实例：便宜七成，但只有“能随时接受中断”的任务才能用
抢占式实例（Spot VM）的价格大约是按需价格的 60%-80%。做机器学习训练、大数据批处理、渲染任务，这些场景可以普遍使用抢占式。关键是设计容错和重试机制。
有一个 Spark 作业项目，在抢占式实例上跑 task 节点，主节点依然用按需实例。一旦 task 节点被抢占，就会由 YARN / Spark 自动调度其他节点补位重跑失败的任务。跑一个 200 万数据的 ETL 作业，用抢占式的总成本是按需的 30% 左右。这是我最推荐的“高性价比改造”之一。
如果用 GKE，那就开 Spot Pool 并把特定 workload 调度到 Spot 节点。对已经采用云原生架构的团队来说，踩过坑后会发现“Spot 节点 + 容错设计”才是最大红利：
yaml复制nodeSelector:
cloud.google.com/gke-spot: "true"
tolerations:
- key: "cloud.google.com/gke-spot"
operator: "Equal"
value: "true"
effect: "NoSchedule"
注意新增的 Spot 类型 Pod 必须声明 PodDisruptionBudget，否则节点在系统维护期间可能瞬间消失，服务直接中断：
yaml复制apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: batch-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: batch-job
有些团队不敢上 Spot，因为觉得不稳定。我通常给出的判断是：如果服务可以在 5 分钟内重启，且重启后不丢关键状态，那你完全值得为 60% 的折扣去承担节点随时消失的风险。
4.3 存储生命周期管理：冷数据一定要“动起来”
存储费用的优化是个完全独立的战场。GCP Cloud Storage 的存储级别包括 Standard、Nearline、Coldline、Archive 四种。价格逐级降低，但访问费用和最小存储期限则不同。
Nearline 适合 30 天以上才访问一次的数据，Coldline 适合 90 天以上，Archive 适合 365 天以上的归档备份。但很多人不做生命周期规则，导致所有文件全部堆在 Standard 里。
用 gsutil 配置生命周期规则很方便。先写一个 JSON 规则文件：
json复制{
"lifecycle": {
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 90}
},
{
"action": {"type": "Delete"},
"condition": {"age": 365}
}
]
}
}
应用规则：
bash复制gsutil lifecycle set lifecycle.json gs://my-backup-bucket
注意高频访问数据不适合降级到 Nearline，因为每次读取都有检索费（retrieval fee）。如果你每天要读的文件数量很大，把它放在 Coldline 反而比放 Standard 更贵。存储降级前，用 BigQuery 账单导出数据判断一下这个 bucket 的文件读取频率。
快照管理也是常被忽略成本点。GCP 的磁盘快照费用是按实际占用量收取的，同项目下太多快照会让账单悄悄膨胀。建议设置定期删除策略。用 Cloud Scheduler 触发以下逻辑：保留最近 7 个每日快照，删除其他。
bash复制gcloud compute snapshots list --filter="creationTimestamp<$(date -d '-7 days' +%Y-%m-%d)" \
--format="value(name)" | xargs -I {} gcloud compute snapshots delete {}
这个脚本要先跑一遍 dry-run，把要删除的快照名列出来核对一遍，再执行删除。生产环境的快照，我建议保留至少 30 天，除非你确定数据库备份完全可靠。
4.4 网络流量费用：常常被忽略的“隐形税”
网络流量费用各云厂商政策不尽相同。GCP 对“同一区域内的通信”通常免费（或极低），对“跨区域出网”则收取不菲流量费。这方面最容易出现高额账单的是：一个服务在 asia-east1，另一个服务在 us-central1，然后它们之间疯狂同步数据。
处理策略很简单，就是架构上强制让高频互通的服务位于同一区域或同一 VPC 内。如果要跨地域容灾，就接受流量费是“容灾成本”的一部分，但从技术上优化同步频率和数据量。
另外两个不引人注意却频繁超支的细节：
- 负载均衡器的 Cloud NAT 流量。如果后端实例通过 NAT 访问外部，出网流量按字节计费。可以考虑把访问外部 API 的请求集中到少量代理实例，借助缓存减少内部请求。
- BigQuery 的查询费用。SELECT * 跑几次全表扫描，账单就能让你心疼。优化方式是把查询降到扫描字节数最少，尤其是对分区表都加
_PARTITIONTIME条件。
5. 落地实战：一次完整的 30 天成本压降记录
理论聊了不少，现在把我最近一次在某个电商业务项目上做 GCP 成本优化的全过程写出来，作为一个可以照着复现的案例。项目背景：中型电商后端，跑在 GKE + Cloud SQL + Redis + Cloud Storage 上，月账单随机波动。团队感受到成本开始失控，但又不知道从哪里下手。我接手后安排了一个 30 天优化计划，共分四个阶段。
5.1 第 1-3 天：做账单体检
第一阶段目标只有一个：完全搞清楚钱花在哪。打开 BigQuery 账单表，跑出三个维度的数据：
第一个维度：按 GCP Service 统计，看哪个服务占比最高。他们 Compute Engine 与 GKE 合计占了 57%，Cloud SQL 占 15%，Cloud Storage 占 11%，网络流量占 8%，其他占 9%。
第二个维度：按项目统计。项目总数有 8 个，其中 3 个已接近停用状态，但仍共产生了约 9% 的月费用，主要原因是测试遗留的磁盘、快照和静态 IP。
第三个维度：按标签统计。当时还没有确立标签体系，这一维度直接宣告失败，绝大多数资源没有标签。团队随后补了标签。这里的产物是“资源清单”和“成本分布饼图”，也是后续所有优化动作的输入。
5.2 第 4-12 天：完成“降配与清理”
第一阶段找到的降配机会比较大。有几台 n1-highmem-16（16 核 104GB）实例用于跑后台任务，连续监控发现 CPU 平均利用率只有 8%，内存平均使用率也只有 12GB 左右。直接下调为 e2-standard-8（8 核 32GB），改动后业务零感知，单项成本约降了 40%。
清理环节同样有效：快照保留了将近三个月，且每天新增一个。最终删除冗余快照后，存储费用掉了一大截。
静态 IP 也是常见漏洞。GCP 的静态 IP 只要被分配，即使没有绑定资源，也按小时计费。清理了 11 个没人用的静态 IP，又省下了一笔不小的费用。
在清理之前，需要先确认这些静态 IP 没有被负载均衡器或白名单引用。我的检查方法：
bash复制gcloud compute addresses list --filter="status=RESERVED"
如果状态是 RESERVED，说明没有绑定资源，可以直接释放。
5.3 第 13-21 天：推进弹性与折扣
在项目资源的利用率评估之后，团队买了 CUD。当时确定生产环境稳定算力约为 200 个 vCPU 与 768GB 内存。创建了一年期资源型 CUD，整体折扣约为 20%，而且这 20% 是全量抵扣，能直接从月账单上看到降价。
同日，测试环境全部迁移到 Spot 节点。测试环境本身就可以容忍节点消失，反正重启一轮测试就行。这个方案让测试环境的计算费用降了 60%-70%。因为测试占整体计算费用的比重比较小，全局角度仍然产生很大的价值。
引入集群自动扩缩容的实践也有些波折。刚开始对生产集群打开 CA 后，发现每天削峰时节点数量的节奏很乱。GCENode 从 6 台梭到 13 台，扩容与缩容几乎每小时都换一轮。通过把 autoscaler 配置里的 scale-down-unneeded-time 从默认的 10 分钟调到 30 分钟，同时把 scale-down-utilization-threshold 从 0.5 调到 0.3，集群稳定性改善了不少，节点波动才趋于平缓。
5.4 第 22-30 天：定预算、定报警、沉淀规范
优化动作之后，团队的精力从“救火”转向“日常管理”。我把预算体系建好、告警接入企业微信，并把“新建生产项目必须打标签”“计算资源选型前必须查历史监控数据”“随时注意清理静态 IP”等要求写进了团队的云资源申请文档。
这个 30 天项目的最终结果：月成本降低约 38%，并显著提升成本可追溯性。这个结果对绝大多数做中等规模 GCP 业务的团队是合理可复制的。因为很多团队都有大量闲置和过度配置的资源，几乎没有做过系统性的降本操作。
5.5 成本优化从“一次性项目”变“例行机制”
30 天结束后，接下来的每个周三下午，我会花 15 分钟快速过一份“成本周报”。周报的内容是我之前做好的一个 BigQuery SQL 自动导出到报表里，包含以下几个维度：
- 本周总费用 vs 上周总费用，变化率。
- 按 Service 分类的费用 Top 5。
- 按标签
env=dev/env=prod分组的费用变化。 - 用量最高的前 10 个实例名称及其 CPU 使用率。
看周报时真正要回答的问题就 4 个：
- 费用增长是不是业务增长带来的？
- 有没有已经无人使用的资源在空转。
- 有没有资源在非工作时间运行。
- 有没有实例规格明显超配。
回答完了，就可以决定这周要不要动手调整。没有异常就不调，继续保持观察。成本管理本来就是常态化监控，而不是一次性极限压缩，一旦重新随业务增长而膨胀，就会悄悄回去。每周看一次表格，是在用最低成本防止这种事情发生。
6. 常见问题与避坑技巧：我要单独列出来的几条“真金白银”的经验
6.1 预算警报为什么没触发？
分配预算之后往往要等几个小时甚至一两天才会产生预算历史数据。如果刚设置就希望触发测试，用 GCP Console 的“发送测试通知”功能就能立即验证渠道链路。另一个常见原因：实际费用超过了阈值，但预算作用范围是“整个 Billing Account”，而你只创建了 Project 级别的预算，那么其他项目的高额费用不在统计范围内。注意，这里的超过阈值指“已经过了阈值”。如果设了两个预算，一层 Billing Account、一层 Project，则需要在不同层级都创建，才能完整覆盖。
6.2 买 CUD 之后用量反而降了，折扣用不满怎么办？
在近期做过一次性优化（比如大范围降配、删除闲置资源）的项目上，很容易发生买了 CUD 但用量降低的情况。这正是我强调“先优化再买 CUD”的原因。
如果已经出现了，能做的是把资源的形态切换到兼容 CUD 的规格上。如果 CUD 是基于项目的资源型承诺，大部分是“消耗承诺额度优先使用承诺容量”，因此你只需要确保新的资源规格符合匹配的地域，就会正常抵扣。剩余额度不足的部分按需付费，没有额外惩罚。但如果买超太多，剩下的承诺余额就相当于沉没成本。实在无法避免时，要评估是否需要重新购买更小规模的承诺。
6.3 快照费用为什么怎么清都清不掉？
GCP 的磁盘快照具有增量特性。删除任意一个快照时，GCP 只会删除“该快照独有的数据”。如果几个快照基于同一磁盘，且底层数据块相同，那么保留其中一个，其他快照不会释放对应的一些底层数据块。因此，如果每次都只删除“唯一最早”快照，并不能节省对应的费用。
正确的清理方式是：把某个磁盘的所有快照清掉，才能一次性释放它们引用的所有底层数据块。备份策略上，如果只是为了容灾保底，我建议直接使用持久磁盘快照的计划任务，定期保留新快照、删除旧快照，但不要同时保留大量从同一磁盘三天内创建的重复短周期快照。
6.4 gcloud 命令误删生产资源怎么办？
删除前用带 --dry-run 或先跑 list 来确认要执行的资源范围。GCP 的很多命令没有回收站设计，删了就是删了。快照删除还好，实例删除后本地磁盘数据直接不可恢复，要极其小心。
我的习惯是：凡是含 delete 或 stop 的大批量命令，永远先在测试项目里跑一遍。并且在生产环境执行前，先导出当前资源清单：
bash复制gcloud compute instances list --format="json" > instance_list_backup.json
出错后，至少可以根据这份清单反推当时有哪些实例在运行。
6.5 BigQuery 的成本分析查询越跑越贵怎么办？
成本分析本身也会产生全表扫描费用。随着数据量增加，这句话的代价越来越高。有效的缓解方案是：预先制作一个“成本日报表”汇总，查询时不直接扫整个明细表，而是查询自动聚合后的视图。简单说就是每天定时跑一次汇总写入一个新表：
sql复制CREATE OR REPLACE TABLE `billing_dataset.cost_daily_agg` AS
SELECT
project.id,
service.description,
labels,
billing_account_id,
EXTRACT(DATE FROM usage_start_time) AS usage_date,
SUM(cost) AS total_cost
FROM `billing_dataset.gcp_billing_export_v1_xxx`
WHERE usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
GROUP BY 1,2,3,4,5;
这样每次周报查询只扫汇总表，成本可以忽略不计。而且汇总表还能按标签做过滤，效率非常高。我知道有些团队开通了 BigQuery 后，主要成本之一竟然是成本分析本身。这句话听起来像个段子，但我确实见过几次。为了避免自己变成那个段子，建议尽快把成本分析查询脚本改造成基于汇总表的模式。
7. 最后再多说一句
关于 GCP 成本优化，我见过太多团队一味将注意力放在“买更高的折扣”、“换更便宜的套餐”上，却始终忽略三个比折扣更有效的动作：把规格降下来、把不用的东西清掉、把作息规律和扩缩容规则设好。
在多次项目中我使用的验证顺序一定是“降需求”优先于“谈折扣”。只要用量在真实、合理的范围内，折扣才有意义。在资源利用充分的前提下，用 CUD 和 Spot 去降低单价，整体优化效果更为理想。
最后分享一个值得长期坚持的习惯：把成本报表做成团队每个季度回顾的一项固定议程，让核心开发人员也参与其中。只靠一个人关注意义有限，当团队每个人重建资源时都会潜意识考虑一下费用，账单自然会表现得更稳定。这是我做了这么多年成本优化之后，得到的最有价值的一条心得。