谷歌今天挂了，我这边三个海外项目直接停摆。客户邮件在凌晨三点开始轰炸，我盯着服务器监控面板上那一排红色感叹号，脑子里只有一个念头：这帮孙子当初签合同的时候可没告诉我，我的命脉捏在谷歌手里。
2019年扩张团队的时候，我们把所有海外业务的用户认证、邮件推送、甚至部分数据存储都绑在了 Google Firebase 和 Gmail API 上。图的就是快，图的就是省事。一个五人的小团队，吭哧吭哧搞了半年，自以为架构挺“现代化”。结果今天一盆冷水浇下来，现代化个屁，这他妈是把地基打在别人沙滩上了。客户可不管什么谷歌故障，他们只知道付了钱，服务断了。团队里负责后端的小孩急得满头汗，在 Slack 里刷屏“API全都返回 503”，我让他切备用方案，他愣了半天，反问我：“老板，我们没做备用方案啊。”那一刻我真想砸了电脑。不是生他的气，是生我自己的气。我，一个自称资深的产品，居然犯了这种把鸡蛋全放一个篮子里的低级错误。
这根本不是技术问题，是产品架构的致命缺陷。我们太迷信“云原生”、“Serverless”这些漂亮词了，以为用了大厂服务就高枕无忧。但大厂不是神，它的 SLA 协议里写满了各种免责条款。今天谷歌的故障，暴露的是我们整个业务链的“单点故障”。用户登录依赖 OAuth，发信依赖 SMTP 中继，连个最简单的“忘记密码”功能，因为用了 Firebase Auth，现在都瘫了。用户点击按钮只会看到一片空白，或者一个莫名其妙的错误码。这种体验灾难，足以让一个初创项目直接归零。
必须搞一套离线冗余机制，不能再偷懒了。不是简单的多备一个云服务商那么简单，那成本扛不住。我的想法是分层处理。核心是身份认证，这块必须有自己的 fallback。比如，在 Firebase 之外，本地数据库存一套最简单的用户名-密码哈希，平时不用，但谷歌挂掉的时候，能立刻切换到一个极简的本地登录页面，哪怕丑点，功能少点，至少保证用户能进来。其次是通信，不能只靠一家邮件服务。SendGrid、Mailgun、甚至自建一个 Postfix 做最低限度备份，通过 n8n 或者自写脚本做健康检查，主服务超时立刻切换。最关键的是数据同步，主数据库在云上，但关键业务表（比如订单、用户核心资料）要在本地有个只读镜像，用增量同步，哪怕延迟半小时，也比完全抓瞎强。
这要加多少工作量？我粗略算了下，至少两个月，而且团队现在深陷交付泥潭，抽不出人。但今天这通宵的教训太贵了。这不是技术债，这是生存债。明天早会，第一件事就是砍掉一个华而不实的新功能需求，把人力全部挪过来搞这个“逃生舱”系统。自由？当你所有业务都挂在别人裤腰带上时，你早就没有自由了。所谓的“轻资产”、“敏捷”，在真正的黑天鹅事件面前，脆弱得像个笑话。团队扩张赚的那点流水，可能一次这样的故障就全赔进去，还得倒贴信誉。这管理，管了个寂寞。
