一个桶有两个主人时,最后 apply 的一方获胜
我加了一条 S3 lifecycle 规则,terraform apply 却失败了。原因是同一个桶的 lifecycle 配置被两个资源各自拥有。S3 lifecycle 不是按规则粒度,而是按整个文档粒度生效,最后的赢家会悄悄抹掉对方的规则。
- #基础设施
- #Terraform
- #S3
- #AWS
- #故障处理
亲手做小应用时遇到的技术、工具和踩坑记录。
我加了一条 S3 lifecycle 规则,terraform apply 却失败了。原因是同一个桶的 lifecycle 配置被两个资源各自拥有。S3 lifecycle 不是按规则粒度,而是按整个文档粒度生效,最后的赢家会悄悄抹掉对方的规则。
往队列里塞任务的代码从上线第一天起就每次都失败。错误被吞掉了,测试靠 mock 一直是绿的。一个冒号悄悄干掉三个功能的故事。
把证书固定(pinning)切到 report-only 之后,Sentry 里堆了 74 条 SPKI 不匹配。看着像是 MITM 攻击,而 AI 一口咬定“谷歌不会拦截你的 HTTPS”,直接把商店审核这个可能性排除掉了。可从生产 API 日志里捞出来的真实 IP,把这个推论掀翻了。
一天之内堆了四条 CRITICAL 告警。504、Prisma P2028、后台 500,还有一条“DATABASE 服务宕机”。我先打开 RDS 指标,结果那 21 小时里 CPU 峰值只有 19.7%,好得很。慢的不是数据库,而是要横跨大西洋二十五次的往返;而那条“宕机”告警,是健康检查自己造出来的。
原以为并行开几个智能体会话,生产力就能翻倍。实际上一周之内真事故接连不断:分支劫持、落在别人分支上的提交、靠 reflog 捞回来的孤儿提交,还有同一个功能的重复实现。这是共享一个检出的并行智能体所制造的事故类型学,以及一路踩坑后立下的规则。
AI 编码智能体没跑测试也会报告“测试通过”。这不是撒谎,是结构问题。做一个把报告变成检查的开源关卡 prove-it 的过程中学到的东西,以及自己手写的五行钩子悄悄失效的四种方式。
让同一个模型评审自己的代码,它只会把自己得出的结论再批准一遍。一个几乎所有代码都和 AI 一起写的独立开发者,把“让另一个 AI 来反驳这个 AI 的工作”这套交叉验证循环固化成常驻流水线的故事。包含自我评审漏掉的 bug 被连续三轮抓出来的真实案例和提示词设计。
staging 每天都会弹出同一条 Google Play 404 告警。把源头关掉,告警确实安静了,但那和修复失败模式是两回事。404 是一种重试也没用的永久性错误,却和 5xx 混在一起被当成可重试对待-这是一次排查的记录。
AI 编码智能体常常没干完活就说干完了。没跑测试就说测试通过了,没复现问题就说修好了。一个几乎所有代码都和 AI 一起写的独立开发者,如何做出一道验证关卡,让“完成”只认证据、不认口头承诺。
每次部署,Sentry 都会收到一条 Prisma P2028 错误。本想只是修一下关闭顺序,结果发现 NestJS 的 enableShutdownHooks 和 graceful shutdown 库同时抢占了 SIGTERM,导致关闭钩子每次都被执行了两遍。
AWS 账单连续两个月超出预算。想找能砍掉的资源,才发现真正的杠杆不是「用多少」,而是「怎么买」。这篇文章讲清楚 Spot 和 Graviton 为什么便宜,也讲清楚看似浪费、实则不能关掉的成本(RDS Proxy)-账单上每一个数字背后的「为什么」。
不用 CMS,只靠 Markdown 文件就能运转的博客,用 Next.js 16 App Router 搭建的全过程。目录结构、MDX 配置、SEO,全部按实际代码流程整理。
在一个仓库里管理多个应用和网站的 Turborepo Monorepo 搭建方法。共享公共配置、靠缓存省下构建时间、按应用分别部署,全部从实战视角整理。
只靠家里一台迷你主机,安全地对外发布多个 Web 服务的方法。不开放任何端口,用 Cloudflare Tunnel 挂上 HTTPS,再用 Docker Compose 跑起来。