一个桶有两个主人时,最后 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,全部按实际代码流程整理。
为什么单词书背得再多,开口还是说不出来?本文聊聊真正的原因,以及把今天看到的东西变成自己的句子、让记忆真正留下来的方法。
习惯失败不是因为意志力弱。只要设计成一天一次、足够小的动作,坚持自然会跟着来。整理了 4 条实战规则。
在一个仓库里管理多个应用和网站的 Turborepo Monorepo 搭建方法。共享公共配置、靠缓存省下构建时间、按应用分别部署,全部从实战视角整理。
只靠家里一台迷你主机,安全地对外发布多个 Web 服务的方法。不开放任何端口,用 Cloudflare Tunnel 挂上 HTTPS,再用 Docker Compose 跑起来。
不去做宏大的创业项目,而是做一个又一个小应用的理由。快速上线、低风险,还有创造本身的乐趣,一个独立开发者的想法。
没有上司,没有同事,一个人工作虽然自由,却很容易被耗尽。整理了我为了不丢掉节奏而坚持的日常安排和几条规则。
让我们一再推迟上线的,往往是“还不够好”的心态。可有些东西,只有发布到世界上才能看见。聊聊如何选择上线,而不是选择完美。