如何配置维护期自动补丁并前置回归测试？ - 问题详情 - 创脉思

解读

面试官真正想考察的是：

你是否理解 Cloud SQL “维护期”与自动补丁的耦合机制；
能否把“补丁”这一运维动作从“被动救火”变成“主动质量门禁”，即在补丁真正打到生产实例之前，用可控成本完成回归测试；
是否熟悉国内合规与灰度节奏（如金融客户常要求**“补丁观察期≥7天”、“可回滚窗口≥72小时”**）。
回答时要体现“配置”+“验证”+“兜底”三步闭环，而不是单纯贴控制台截图。

知识点

维护期（Maintenance Window）：以UTC 时间配置，国内用户务必换算为北京时间（UTC+8），并避开凌晨 0:00–6:00 业务高峰；
维护通知：Cloud SQL 可提前7–14 天发送邮件/Pub/Sub 事件，国内常通过钉钉群机器人订阅 Pub/Sub 转 Webhook；
补丁策略：小版本补丁默认自动应用，但可设置**“拒绝维护”标志**（settings.denyMaintenancePeriod）用于春节、双十一等封网期；
克隆实例回归测试：利用**“时间点恢复克隆”（PITR Clone）在5 分钟内拉起与生产同版本、同数据量的临时实例，成本仅为实际存储按量计费**；
Cloud Build + Terraform：把**“克隆→跑回归 SQL→回写结果→销毁”做成 nightly pipeline**，实现0 人工值守；
回滚能力：补丁后 72h 内可一键降级小版本（目前仅 MySQL 5.7/8.0、PostgreSQL 14+ 支持），需提前关闭自动存储扩容以避免磁盘缩容失败导致回滚被拒。

答案

配置维护期
a. 在 Terraform 中固化窗口，避免控制台手滑：

resource "google_sql_database_instance" "prod" {
  settings {
    maintenance_window {
      hour          = 3   # 北京时间 11:00，业务低峰
      day           = 7   # 周日
    }
    deny_maintenance_period {
      start_date = "2025-02-09"
      end_date   = "2025-02-17"
      time       = "00:00:00"
    }
  }
}

b. 国内多地域部署时，主实例与只读实例维护期错开 24h，防止同城双可用区同时重启。

前置回归测试
a. 事件驱动：收到 Pub/Sub 维护预告消息后，Cloud Function 自动触发 Cloud Build；
b. 克隆：Build 第一步调用 gcloud sql instances clone prod-test-$(date +%s)，指定 30 分钟前的时间点，保证数据新鲜；
c. 回归：在克隆实例上执行预置的 SQL 脚本集合（含慢查询、核心报表、索引缺失检测），阈值参考上月 P99 延迟+10%；
d. 质量门禁：只有100% SQL 通过且性能衰退<5% 才在 Cloud Build 末尾置位“allow_patch”标签；否则自动调用 gcloud sql instances patch prod --deny-maintenance-period … 把补丁窗口临时封掉，并飞书告警。
兜底与复盘
补丁完成后，Cloud Monitoring 仪表盘持续观测24h 内连接错误率、锁等待、临时文件涨幅；若异常，立即使用 gcloud sql instances patch prod --database-version=MYSQL_8_0_36 回滚小版本，并提交 RCA 报告到客户微信群与Google 企业工单，满足国内金融**“72h 可回滚”**合规要求。

拓展思考

如果业务不允许重启，可评估 Cloud SQL Enterprise Plus 的**“在线补丁”（目前仅 PostgreSQL 15+），但需接受额外 20% 单价**；
对上百个实例的集团客户，建议把**“允许补丁”标签作为Terraform Workspace 的变量**，实现**“蓝绿标签”**批量灰度；
国内等保 2.0 要求**“补丁记录留存≥180 天”，可把 Cloud Build 日志转存到中国境内 OSS Bucket**，并通过日志服务 CLS 建立**“补丁审计索引”**，方便现场测评老师抽查。