#硬编码限制

avatar
刚读完 Cloudflare 的官方报告，这次全球中断不是因为攻击，而是一次数据库权限变更引发的连锁反应。 PS: 非常感兴趣可以拉到最后有原文的链接 所有时间均为UTC时间 以下是原文中的关键细节还原： 1. 问题的发生：从变更到崩溃 起因：权限变更为了改善分布式查询的安全性和可靠性，团队在 11:05 进行了一次 ClickHouse 数据库权限升级。目的是让用户能显式访问底层表（r0），而不仅仅是默认视图。 触发：SQL 查询变味了Bot 管理系统有一个每 5 分钟运行一次的定时任务，负责生成“特征文件”。它使用了一个查询 SELECT name, type FROM system.columns WHERE table = ...。 关键点： 这个查询没有过滤数据库名称。 在权限升级前，它只看得到默认库；升级后，它同时读到了默认库和底层分片（r0）的数据，导致返回结果里出现了大量重复条目。 爆发：文件翻倍与硬限制结果，“特征文件”体积直接翻倍。 当这个文件推送到全球边缘节点时，运行在核心代理（Proxy）上的 Rust 代码崩溃了。因为代码里为了性能预分配了内存，并设定了一个硬限制（Limit: 200个特征），翻倍后的文件瞬间冲破了这个限制，导致进程 Panic。 2. 排查的曲折：为什么像攻击？ 灰度发布的副作用因为 ClickHouse 的更新是逐步推送到不同节点的，导致生成的特征文件有时候是好的（旧节点生成），有时候是坏的（新节点生成）。 现象误导系统表现为“崩溃 -> 恢复 -> 再崩溃”的震荡状态。这种不寻常的波动让团队一开始误以为是遭受了超大规模的 DDoS 攻击，甚至怀疑攻击者针对了状态页。 3. 问题的解决：回滚与修复 定位团队最终确认 Bot 管理模块是 5xx 错误的源头，并锁定了那个坏掉的配置文件。 止血（14:24）停止生成和分发新的特征文件。 修复（14:30）手动将一个已知正常的旧版本文件插入分发队列，并强制重启核心代理服务。此时核心流量开始恢复正常。 完全恢复（17:06）处理积压的请求，缓解流量回涌带来的负载，重启所有进入坏状态的剩余服务。 总结不是黑客，没有恶意活动。就是一个 SELECT * 类的宽泛查询，撞上了数据库权限升级，最后被代码里的硬编码限制（Hard Limit）卡死
#Cloudflare中断 #数据库权限变更 #Bot管理系统故障 #硬编码限制 #非恶意事件