项目 on cloudplz

No-code 基础设施平台

Mon, 01 Jan 0001 00:00:00 +0000

当时的瓶颈不在数据库本身，而在它前面排着的那条队。这个平台把队去掉了：产品团队填个网页表单，就能开通生产可用的 Aurora 集群，不用碰 Terraform。

基础设施即代码让开通变得可重复，可瓶颈只是换了个地方：

Mon, 01 Jan 0001 00:00:00 +0000

迁一套数据库到 Aurora，那是个项目。迁五十套 —— 里面还有数 TB、7×24 写入的 tier-0 系统 — — 那就是一套平台。这套工具链和方法论，让迁移变成可重复的事。

Mon, 01 Jan 0001 00:00:00 +0000

自助式基础设施要成立，前提是自助这条路最好走。这个模块库做的事，是让 AWS 上「合规、经过生产加固」的开通方式，同时也是最好走的那条路。

七十个应用仓库，每个都能自己开通基础设施。没有共享库，每个团队就得重造 VPC 接线、数据库参数调优和 IAM 边界。每重造一次，都是未来一次事故，外加一条审计发现。

Mon, 01 Jan 0001 00:00:00 +0000

Vitess 连跑三年生产环境，横向扩展真正咬人的地方就露出来了：是运维纪律，不是 demo。这里记的是：跑那套系统要付出什么。它撑着 YouTube 那批 MySQL 集群。我们规模比 YouTube 小得多，而这让整笔账不一样。

Mon, 01 Jan 0001 00:00:00 +0000

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

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