解读

在国内云原生交付场景里，“数据库状态漂移检测”通常指：在持续交付流水线中，自动发现 Cloud SQL 实例的真实运行配置与 IaC 基线（Terraform 状态文件或 Git 声明）之间发生的非预期差异，并在差异达到阈值时阻断发布或触发自愈。面试官想确认候选人是否能把 Google Cloud 的托管能力与企业级 DevSecOps 流程打通，既利用托管服务减少运维，又保留对配置一致性的绝对控制力。

知识点

1. Config Drift 的本质：Cloud SQL 仍允许用户通过控制台、gcloud、API 等多通道改配置，导致 Terraform 状态与实际出现偏差。
2. Google Cloud 原生工具：Asset Inventory、Config Controller、Cloud Asset API、Policy Analyzer。
3. IaC 基线：Terraform 状态文件（.tfstate）与 Git 声明文件（.tf）作为唯一可信源。
4. 检测触发点：流水线阶段分为“计划阶段检测”与“运行时检测”；前者在 MR 阶段做静态 diff，后者在发布后被周期巡检。
5. 阻断策略：使用人审 + 自动回滚双闸门；差异分级为 Warning、Critical、Block。
6. 合规要求：国内等保 2.0/3.0 要求“变更可追溯”，因此检测日志必须写入不可篡改的 Cloud Logging Bucket，并开启Bucket Lock。

答案

我设计的流水线分三层实现漂移检测：

1. 基线固化
   所有 Cloud SQL 实例通过 Terraform 模板创建，模板统一放在 GitLab Mono-Repo；合并请求触发 Terraform Plan，Plan 结果以 JSON 形式上传到 Cloud Storage 基线桶，桶开启**统一桶锁（Bucket Lock）**确保不可篡改。

2. 计划阶段预检
   在 GitLab CI 的 plan Job 里，用 terraform show -json 生成期望态 JSON；同时调用 Cloud Asset API batchGetAssetsHistory 拉取过去 1 小时该实例的 actual state；用 jq + python-deepdiff 做字段级对比，重点检查 tier、disk_size、database_version、backup_enabled、ip_configuration.require_ssl、flags。若出现 Critical 级别差异（如 backup_enabled 被关闭），直接 exit 1 阻断 MR，并 @DBA 审核人。

3. 运行时巡检与自愈
   实例上线后，Cloud Build 定时触发 Cloud Scheduler → Cloud Function；函数内使用 Config Controller 的 Config Sync 机制，每 30 分钟拉取一次 Asset Inventory 快照，与 Terraform 状态做三向对比（desired、actual、last-known）。发现漂移后：

   • 轻度漂移（如标签增减）→ 自动提交 Terraform Apply 回滚，并产生 Cloud Logging 事件。
   • 重度漂移（如主版本号被抬升、高可用被关闭）→ 函数发布 Pub/Sub 消息，触发 Spinnaker 暂停下游交付流水线，同时开 Incident 到飞书 On-Call 群，附带 Cloud Trace 链路，确保 15 分钟内人工介入。

4. 审计闭环
   所有检测结果写入 BigTable 分区表，按实例+日期主键；次日凌晨用 Dataflow 批量对账，生成漂移率日报推送到企业微信，实现“日清月结”的合规要求。

通过上述四层，既利用了 Cloud SQL 全托管能力，又把“最后一人修改”锁定在 Git，真正达到零运维、零漂移。

拓展思考

如果企业已采用 Anthos Config Management (ACM)，可以把 Cloud SQL 的 Terraform 基线封装成 Config Controller Custom Resource，让 ACM 直接监听 Asset Inventory 变更事件，实现声明式自愈，省去 Cloud Function 这一跳，延迟从分钟级降到秒级；同时把检测逻辑下沉到 Policy Controller，用 OPA Gatekeeper 模板将“backup_enabled 必须为 true”写成约束模板，一旦有人通过控制台关闭备份，Constraint 立即触发 Kubernetes Event，由 ArgoCD 回滚，实现Git 作为唯一真相源的终极形态。