Kagi 上周事故复盘
Kagi 这家付费搜索引擎发生了长达 7 小时的故障，起因是一名用户进行高流量抓取，引发了关于小型初创公司如何在精简基础设施、韧性与滥用防护之间取得平衡的讨论。评论者总体上称赞 Kagi 透明的事故复盘和精简的单节点数据库架构，但也指出其在限流、监控和事故响应方面存在不足——尤其是状态页准确性和 SRE 成熟度。此次事故还引发了关于“无限”使用究竟意味着什么的争论，以及服务是否应更清楚地传达公平使用限制和技术保障，以防止类似故障再次发生。
事故范围与性质
- 故障持续了约 7 小时，由一名付费用户进行高强度自动化抓取触发，撞上了“病态”的流量模式。
- 当时服务已经在处理约 40 万次搜索/天；这次事故在短时间内又增加了约 6 万次请求，给单核主数据库和连接池带来了压力。
- 多位评论者指出，这就是典型的“无限但其实并不无限”/“一个用户就能把系统拖垮”的场景，许多初创公司最终都会遇到。
基础设施、扩展性与限流
- 很多人称赞这种精简架构（最便宜的单核 GCP 数据库、简单的 Postgres/Redis 风格技术栈），并认为大多数团队过早把分布式数据库做得过度复杂。
- 也有人认为，如果额外 6 万次请求就能让系统宕机，那基础设施就太脆弱了，而且本应早就有按用户限流和/或类似 Cloudflare 的前置防护。
- 基本形成共识的是，所有公开接口都需要 QPS 限制和突发控制；有人分享了类似经历：一个卡住的 key 或设计不佳的 typeahead 就曾把生产环境拖垮。
可观测性、诊断与状态页
- 讨论强调，对于小团队来说，解读仪表盘、辨别干扰信息、避免“被自己的指标煤气灯”是多么困难。
- 人们争论手动状态页与自动状态页：
- 有人希望状态页能根据指标自动更新；也有人说明，这通常最终会退化为手动覆盖和主观判断。
- 多位用户对状态页一直显示绿色而他们却看到 500 错误感到不满，这削弱了信任。
- 还有人建议从 SLI/SLO 入手，围绕已知限制建立告警和仪表盘（例如每个账户的查询数、锁/IO 等待、500 比率）。
“无限”与滥用以及服务条款
- 一方认为，宣传“无限搜索”却禁止高强度自动化使用是误导性的，感觉像诱导后再变卦；他们希望明确写出“公平使用”措辞或数值上限。
- 另一方则反驳说，“供人类使用的无限”显然不包括抓取或试图重新索引服务，尤其是当还有单独的付费 API 时。
用户情绪与产品质量
- 许多评论者本身是付费用户，他们喜欢搜索质量、可定制性（例如固定站点）以及这份复盘的透明度，并认为故障对早期创业公司来说是可以接受的学习过程。
- 有些人说，这次宕机让他们体会到 Google 接近完美的可靠性，也让他们对依赖一家小型服务提供商感到不安。
- 少数人报告了账户/登录问题，并把这视为危险信号；其他人则表示这很可能是个边缘情况，最好通过支持渠道处理。