<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>cloudplz</title><link>https://cloudplz.cc/zh/</link><description>Recent content on cloudplz</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Thu, 10 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://cloudplz.cc/zh/index.xml" rel="self" type="application/rss+xml"/><item><title>No-code 基础设施平台</title><link>https://cloudplz.cc/zh/projects/no-code-infrastructure-platform/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/projects/no-code-infrastructure-platform/</guid><description>&lt;p&gt;当时的瓶颈不在数据库本身，而在它前面排着的那条队。这个平台把队去掉了：&#10;产品团队填个网页表单，就能开通生产可用的 Aurora 集群，不用碰 Terraform。&lt;/p&gt;&#10;&lt;h2 id="问题"&gt;问题&lt;/h2&gt;&#10;&lt;p&gt;基础设施即代码让开通变得可重复，可瓶颈只是换了个地方：&lt;/p&gt;</description></item><item><title>Aurora 迁移工具集</title><link>https://cloudplz.cc/zh/projects/aurora-migration-toolkit/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/projects/aurora-migration-toolkit/</guid><description>&lt;p&gt;迁一套数据库到 Aurora，那是个项目。迁五十套 —— 里面还有数 TB、7×24 写入的 tier-0 系统 —&#10;— 那就是一套平台。这套工具链和方法论，让迁移变成可重复的事。&lt;/p&gt;</description></item><item><title>Terraform 模块库</title><link>https://cloudplz.cc/zh/projects/terraform-module-library/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/projects/terraform-module-library/</guid><description>&lt;p&gt;自助式基础设施要成立，前提是自助这条路最好走。这个模块库做的事，是让 AWS 上「合规、&#10;经过生产加固」的开通方式，同时也是最好走的那条路。&lt;/p&gt;&#10;&lt;h2 id="问题"&gt;问题&lt;/h2&gt;&#10;&lt;p&gt;七十个应用仓库，每个都能自己开通基础设施。没有共享库，每个团队就得重造 VPC 接线、&#10;数据库参数调优和 IAM 边界。每重造一次，都是未来一次事故，外加一条审计发现。&lt;/p&gt;</description></item><item><title>Vitess 生产部署</title><link>https://cloudplz.cc/zh/projects/vitess-production-deployment/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/projects/vitess-production-deployment/</guid><description>&lt;p&gt;Vitess 连跑三年生产环境，横向扩展真正咬人的地方就露出来了：是运维纪律，不是 demo。&#10;这里记的是：跑那套系统要付出什么。它撑着 YouTube 那批 MySQL 集群。我们规模比 YouTube 小得多，&#10;而这让整笔账不一样。&lt;/p&gt;</description></item><item><title>数据库 canary 应用</title><link>https://cloudplz.cc/zh/projects/database-canary-applications/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/projects/database-canary-applications/</guid><description>&lt;p&gt;平台团队改一个 Terraform 模块、升一次引擎版本、换一个连接库，会炸到平台之上每一个应用。&#10;Canary 应用的作用，是在这些应用受影响之前先发现问题。&lt;/p&gt;&#10;&lt;h2 id="问题"&gt;问题&lt;/h2&gt;&#10;&lt;p&gt;平台层变更会以单元测试抓不到的方式失败。某个参数组默认值把连接池弄挂，一次 provider 升级让 state 漂移，&#10;换个引擎版本，驱动行为就变了。最早的信号，以前来自产品团队的 pager。&lt;/p&gt;</description></item><item><title>50 套生产库迁到 Aurora，停机不到 3 分钟</title><link>https://cloudplz.cc/zh/writing/database-migration-at-scale/</link><pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/database-migration-at-scale/</guid><description>&lt;p&gt;大约两年时间，我们把约 50 套生产库从自建 MySQL 迁到 AWS Aurora。最大的几套是数 TB 的 tier-0 系统，&#10;7×24 写入。多数切换停机压在 3 分钟以内。&lt;/p&gt;&#10;&lt;p&gt;这个数字不靠维护窗口里小心点几下。它来自把停机预算当作 &lt;strong&gt;设计输入&lt;/strong&gt;：一旦「3 分钟」&#10;变成硬性要求，而不是一句期望，后面每个决定 —— 复制拓扑、演练门禁、连接排空、DNS 权重 —&#10;— 都被逼出一种具体形态。这篇写的就是这条约束逼出来的方法论，外加路上真正咬过我们的那几口。&lt;/p&gt;</description></item><item><title>把 AI Agent 当基础设施管：用 Ansible 预置 Hermes Agent</title><link>https://cloudplz.cc/zh/writing/provisioning-ai-agents-with-ansible/</link><pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/provisioning-ai-agents-with-ansible/</guid><description>&lt;p&gt;我花了 18 年让云基础设施变得可复现。数据库用 Terraform module。VM 配置用 Ansible role。&#10;golden image 用 Packer 模板。等到要在 Linux VM 上跑一个 AI agent，我没多想 —— 顺手就上了 Ansible。&lt;/p&gt;</description></item><item><title>一次 terraform apply，开出 20+ 个 AWS 服务 —— 全部按新的 Free Plan 调好</title><link>https://cloudplz.cc/zh/writing/terraform-aws-free-tier/</link><pubDate>Mon, 06 Apr 2026 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/terraform-aws-free-tier/</guid><description>&lt;p&gt;AWS 新的 free plan 送 $200 credits（$100 基础 + $100 奖励）。前提是五项活动都得单独激活。&#10;这一步很容易漏掉，我自己就差点漏了。&lt;/p&gt;&#10;&lt;p&gt;第一次给个人项目起 ElastiCache 集群，我选了 &lt;code&gt;cache.t4g.micro&lt;/code&gt;。Graviton 机型，&#10;看上去就是那个显而易见的现代选择。问题在后面：旧的 free tier 只覆盖 &lt;code&gt;cache.t3.micro&lt;/code&gt;，&#10;新的 Free Plan 干脆两种机型都不给额度，全烧 credits。等我发现，已经白烧了几天 —&#10;— 那个 cache 我根本没在用。这个模块就是为防住这类错误写的。&lt;/p&gt;</description></item><item><title>Vitess vs Aurora：MySQL 扩展该怎么选</title><link>https://cloudplz.cc/zh/writing/vitess-vs-aurora-mysql-scaling/</link><pubDate>Fri, 20 Dec 2024 00:00:00 +0000</pubDate><guid>https://cloudplz.cc/zh/writing/vitess-vs-aurora-mysql-scaling/</guid><description>&lt;p&gt;单实例 MySQL 一旦到顶，你手上就只剩三条路，哪条都不轻松：给应用写自研分片逻辑、&#10;换一套数据库系统，或者上一套 Vitess 这样的集群方案。&lt;/p&gt;&#10;&lt;p&gt;先说结论，你据此决定要不要往下读：&lt;strong&gt;在生产环境跑了 3 年 Vitess 之后，我们把它换掉了 —&#10;— 换成 Aurora。&lt;/strong&gt; 不是 Vitess 不行，而是撑起它运维成本的那项能力 —— 横向写分片 —&#10;— 我们从来就没真正需要过。你的写流量确实超过一台大规格主库的上限 —— 指的是持续每秒几万次写，&#10;不是突发峰值 —— 那 Vitess 很可能就是你的答案，这篇文章会说清运维它要付什么代价。&#10;低于这条线，Aurora 几乎肯定是更优解，这篇文章会说清为什么。&lt;/p&gt;</description></item></channel></rss>