解读

面试官问“如何设置最大容量上限”并不是单纯想知道点两下控制台，而是考察候选人是否具备成本治理闭环思维：能否在架构设计阶段就把“容量-性能-费用”三角关系量化，并给出可落地的运维预案。国内客户对云账单敏感，经常出现“测试库一夜跑爆 20 TB”导致季度预算被击穿的真实案例，因此答案必须兼顾Google Cloud 原生能力与国内财务合规流程（如合同主账号、伙伴折扣、预算审批链）。

知识点

1. 存储层上限：Cloud SQL 的磁盘自动扩容默认开启，最大可至 64 TB（MySQL 5.7/8.0），一旦开启费用随容量线性增长。
2. 预算与告警：Google Cloud 的Budget API 支持“实际费用”与“预测费用”双阈值，可绑定短信、邮件、钉钉（通过 Pub/Sub + 函数转 webhook）。
3. 配额（Quota）体系：项目级**cloudsql.instances.diskSize** 配额可硬性限制新实例规格，需提交工单由 Google 中国交付经理审批，适用于国企客户的事前审计场景。
4. 实例层软限制：通过 Terraform 变量**disk_autoresize_limit（单位 GB）可给单实例设置非零天花板**，这是代码化治理的关键字段。
5. 国内折扣抵扣：承诺使用折扣（CUD） 只覆盖 vCPU 与内存，不覆盖存储，因此存储上限必须单独治理，否则 CUD 省下的钱会被存储费瞬间吃掉。
6. 备份与二进制日志：事务日志（PITR）存储与数据盘分开计费，若binlog保留 7 天，峰值期间可能产生等同于数据盘 30% 的隐藏费用，需纳入容量评估。

答案

分三层闭环回答，体现可验证、可回滚、可审计：

1. 架构层——代码化封顶
   在 Terraform 模块中强制写入：

   disk_autoresize       = true
   disk_autoresize_limit = **500**  # 单位 GB，按业务峰值 2 倍+冗余
   disk_size             = 100      # 初始值
   

   把disk_autoresize_limit作为MR 审批必检字段，任何大于 500 GB 的变更需要二级财务负责人在工单系统留痕，满足国内审计署 2022 年 8 号令对云资源的留痕要求。

2. 治理层——预算配额双保险

   • 在组织级节点创建 Budget：金额=**月度预算 80%**作为预警，100%作为硬停机阈值；通知渠道同时配置邮件+钉钉群机器人。
   • 向 Google 中国提交配额提升工单，把项目级cloudsql.instances.diskSize上限锁死在2 TB；若业务突发需要扩容，需走线下特批并同步更新CMDB，确保财务、运维、审计三方数据一致。

3. 运维层——持续巡检
   每周通过gcloud sql instances list --format="table(name,settings.storageAutoResizeLimit)"导出CSV 清单，用 Python 脚本比对CMDB 白名单，发现超限实例立即触发Ansible playbook关闭autoresize并通知值班。脚本结果存入OSS 审计桶，保留五年，满足等保 2.0对日志留存的要求。

一句话总结：用 Terraform 变量做技术封顶，用 Budget+Quota 做财务封顶，用脚本巡检做持续合规，三层锁死即可在国内环境下零舆情、零罚单地避免费用爆炸。

拓展思考

如果面试官继续追问“autoresize_limit 设置后，业务突发流量导致磁盘打满，数据库只读，如何平衡可用性与成本？”，可给出**“动态限流+临时升配+事后回退”**方案：

1. 提前在Cloud Monitoring创建基于database/disk/utilization > 85%的SLI，联动Cloud Tasks触发函数，函数自动把autoresize_limit上调 20% 并记录变更单号；
2. 同时函数在配置库写入“24 小时后回退”的定时任务，到期自动恢复旧限值；
3. 全程通过IAM Conditions授予函数仅提升权限，禁止降低权限，避免恶意缩容造成事故；
4. 成本中心每月拉取BigQuery 账单导出表，用Looker Studio可视化“临时扩容费 / 当月总费”占比，若超过 5% 则触发架构评审，倒逼业务做分库分表或归档以根治容量痛点。