这事前后折腾了一个多月，最近终于算彻底结束了，简单记录一下。
我有一个开源的 WebRTC 项目，之前生产环境用过 Cloudflare RealtimeKit 。当时 RealtimeKit 还在 Beta ，官方 pricing 页面写的是 Beta 期间免费。8 月 19 日我发现 Cloudflare 账单里出现了 RealtimeKit participant usage ，一百多美元，于是开了一个 Urgent support case 。
我一开始以为这事应该很简单：既然 Beta 免费，为什么会产生账单？结果后来这个问题被一路拖进了 Engineering Investigation 。
因为费用还在继续增长，而且我没办法判断最终会涨到多少，我在那个周末把生产从 RealtimeKit 迁到了 Cloudflare Serverless SFU 。8 月 21 日之后，生产流量已经不再经过 RealtimeKit 。
比较奇怪的是，迁移以后 RealtimeKit 的 participant usage 还在继续增加，每天大约 $28-29 。
后来我直接调 RealtimeKit API ，把整个 App 的状态扫了一遍。一共是 2,440 个 Meetings 和 2,609 个 Sessions ，其中还有 12 个 Session 显示 LIVE ，里面正好有 10 个 live participants 。但是这 12 个 Session 对应的 Meeting 当时全部已经是 INACTIVE ，生产客户端也早就不存在了。有一些 Session 已经挂了很多天，最老的可以追溯到 8 月 1 日。
当时有一个数字很巧：
10 × 1,440 × $0.002 = $28.80 / day
而 Cloudflare 其中一天实际记出来的 participant usage 大约是 $28.76 。
这个当然只能说明高度相关，不能仅凭这个数字证明计费一定就是这些 stale participants 产生的。
最后我是自己调用 Cloudflare 官方的 active-session/kick-all 接口，把剩余的 participant 清掉。清理以后是 0 live participants ，所有 2,440 个 Meeting 都是 INACTIVE 。
后面 Cloudflare Engineering 确认过，客户端已经断开、Meeting 已经 INACTIVE ，但 Session 仍然保持 LIVE ，这不是 expected behavior 。客服还转述过 Engineering 的说法，说 session cleanup mechanism did not trigger as intended 。
他们当时给我的临时建议之一，是定期通过 automation 或 scheduled alarm 执行 kick-all 。这个建议我没有实际采用，因为生产已经完全迁走了，而且他们同时又要求我保留 App 给 Engineering 调查。
整个过程中还有一个让我比较困惑的地方，就是最开始那个最简单的 Beta billing 问题一直没有被单独回答。Support 不断在讲 Engineering review 、Session 、Participant 、Meeting ID ，我后来直接要求他们把两个问题分开：Session lifecycle 可以慢慢查，但请先回答 RealtimeKit Beta 到底应该收费还是不应该收费。
后来 Cloudflare 明确确认，Beta 期间这些 RealtimeKit usage 不应该收费。
两张账单最后分别退款 $143.53 和 $147.68 ，共 $291.21 ，已经全部到账。
这期间 Support 还发生过一次比较有意思的反复。客服先建议我考虑删除 RealtimeKit App 来停止可能继续产生的 usage ，没过多久 Engineering 又要求我千万不要删除，因为他们还需要这个 App 做调查。于是这个已经不用的 App 又保留了一个多月。后来 RealtimeKit 已经从 Beta 转成 GA ，开始正式收费，我又专门追问了一次为什么还要继续保留一个 billable GA App 。
直到最近，Cloudflare 才确认 Engineering review 已经完成，可以删除 App 。我已经把它删掉了。
最终技术结论也比较微妙。
Cloudflare 前面确认过 stale LIVE Session 属于异常状态，也说过 cleanup mechanism 没按预期触发。但最终 Engineering review 的结论是，没有识别到 underlying RealtimeKit platform defect ，因此没有 product fix 在跟踪。他们同时也没有认定 audio-only / Audio-Video participant classification 存在独立的 metering defect 。
所以比较准确的描述应该是：Cloudflare 确认当时观察到的 Session 状态不是预期行为，但一个多月的调查最后没有定位到可以归因的 RealtimeKit platform defect 或明确 root cause 。
我其实不太关心最后是哪一行代码出了问题。让我觉得这件事麻烦的主要是处理过程。
错误计费本身最后退款了，这部分没有经济损失。但为了一个并非由我造成的问题，我做了紧急生产迁移，自己检查了两千多个 Session ，自己清理 stale participant ，然后一个 support case 来回跟了一个多月。期间大部分时间没有明确 ETA ，也没有类似 incident owner 的角色来统一推进 Billing 、Product 和 Engineering 。
至少在我的经验里，production + billing 这种问题通常会比较快被当成 incident 处理：先隔离客户风险，再由相关团队并行调查。Cloudflare 这次给我的体验更像一个普通 support ticket 在几个团队之间来回转。
我以前对 Cloudflare 的印象一直不错，现在也还在继续用 Workers 、DO 、R2 、Serverless SFU 等服务。它对独立开发者的开发体验确实很好。
但这次以后，我会把“开发体验很好”和“生产运维成熟度很高”当成两件不同的事情。
Beta 产品有 bug 很正常。Billing 、metering 、incident escalation 这些东西最好不要也处于 Beta 。
现在这个项目已经完全迁到 Serverless SFU 。至少从我自己的使用场景来看，按实际 egress 计费，比 participant-minute 加 server-side session state 这种模型更容易理解风险。
Select Language