数据库 canary 应用

平台团队改一个 Terraform 模块、升一次引擎版本、换一个连接库，会炸到平台之上每一个应用。 Canary 应用的作用，是在这些应用受影响之前先发现问题。

问题

平台层变更会以单元测试抓不到的方式失败。某个参数组默认值把连接池弄挂，一次 provider 升级让 state 漂移， 换个引擎版本，驱动行为就变了。最早的信号，以前来自产品团队的 pager。

需要的是：

• 尽早发现破坏性变更，赶在影响客户之前
• 贴近真实，打真实数据库连接，不是 mock
• 覆盖平台支持的每一项技术
• 自动化，接进发布流水线，而不是手动跑

做法

一套应用，平台支持哪种技术就配一个，持续连真实集群，跑有代表性的操作：

这些应用跑在 QA 和生产环境里，一失败就告警。坏掉的模块版本会先在 canary 里露头， 而不是先炸到客户事故频道。

所有东西都走平台自家那套 no-code 模块开通 —— canary 就是平台团队的 customer zero。 凭证放 secrets store，数据库用户动态开通，TLS 强制，能用的地方就上 IAM 认证。 Secure-by-default 不写在文档里， canary 本身就这么建。

结果

七种技术全覆盖。模块发布、引擎升级、provider 变更，都要先通过 canary 验证才能发布。 凭证处理、打标签、监控接入，这些做法后来成了产品团队在平台上搭东西时的参考文档。

还有个好处不那么明显：canary 让平台团队自家升级也变例行公事。引擎版本升级从「带着回滚计划的协同变更」 ，变成「canary 过了，发吧」。