Cloudflare 首席执行官马修·普林斯（Matthew Prince）承认，周二发生的严重服务中断事件，根源在于一次数据库权限配置的变更。公司最初误以为该问题的症状表明其正遭受“超大规模 DDoS 攻击”，后来才查明真正原因。

普林斯在周二深夜发布的一篇博文中解释称，此次事故“由我们某个数据库系统权限变更所触发，导致数据库向 Bot Management（机器人管理）系统所使用的‘特征文件’中输出了多条重复记录”。

该特征文件用于描述恶意机器人的行为模式，Cloudflare 会将其分发给运行路由基础设施的软件，以便及时识别新兴威胁。

此次权限变更使特征文件体积翻倍，超出了 Cloudflare 软件设定的文件大小上限。当系统检测到这个非法过大的特征文件时，便发生了故障。

不过，系统随后一度短暂恢复——因为事故发生时，Cloudflare 正在对其用于生成新版本特征文件的 ClickHouse 数据库集群进行权限管理更新。这次权限调整本意是让用户能够访问底层数据和元数据，但由于执行数据检索的查询语句存在错误，返回了多余信息，导致特征文件体积激增超过一倍。

当时，该集群每五分钟就会生成一个新版本的特征文件。

普林斯写道：“只有在查询运行于已更新权限的部分集群节点上时，才会产生错误数据。因此，每五分钟都有可能生成一组正常或异常的配置文件，并迅速传播至整个网络。”

从周二约 11:20 UTC 起的几个小时内，Cloudflare 的服务因此出现了间歇性中断。

普林斯进一步解释道：“这种波动使得问题难以判断——整个系统会因有时分发的是正常配置、有时是异常配置而反复恢复又崩溃。最初，这让我们误以为可能是遭受攻击所致。最终，所有 ClickHouse 节点都开始生成错误的配置文件，系统稳定地陷入持续故障状态。”

这一“稳定的故障状态”在 13:00 UTC 前几分钟形成，真正的混乱由此开始，Cloudflare 客户也随即遭遇持续性的服务中断。

最终，Cloudflare 找到了问题根源，停止了错误特征文件的生成与传播，并手动将一份已知正常的文件插入特征文件分发队列。随后，公司强制重启了核心代理服务，确保系统只读取正确的配置文件。

但这一切都需要时间，也给依赖该代理服务的其他系统带来了连锁反应。

普林斯为此事件公开致歉：

“像今天这样的中断是不可接受的。我们设计系统时始终以高容错性为目标，确保流量永不中断。过去每次发生故障，都会促使我们构建出更稳健的新系统。”

此次事件后，公司计划采取四项改进措施：

1. 对 Cloudflare 自身生成的配置文件，采用与处理用户输入相同级别的安全加固措施；
2. 为各项功能启用更多全局“紧急关闭开关”；
3. 消除核心转储（core dumps）或其他错误报告占用过多系统资源的可能性；
4. 全面审查所有核心代理模块在各类错误条件下的失效模式。

普林斯在博文结尾再次致歉：“为我们今天给互联网带来的困扰深表歉意。”