不知道是不是又裁员裁到了大动脉。
上上周 AWS 的问题还没有折腾清楚，今天 CF 又出现严重的故障，很多网站都受到了影响，当然包括我们的网站也是一样。
当 CF 出现故障后，我们甚至无法调整 CF 的配置跳过代理，因为网站都登录不上去了。
很多 AI 的网站也受到了影响。
一些新闻上说是因为 CF 受到了非常的大量流量，这些流量导致 CF 的服务中断。
不只我们受到了影响，很多知名网站都受到了影响，在美国东部时间上午 9 点 45 分左右，服务逐步恢复。
实在没有想到的是，美国目前的基础网络服务变得如此的脆弱，基本上感觉是没几周就抽风下。
基础网络脆弱是都用了Cloudflare
Cloudflare 提供的 DDoS 功能主要还是太好用，还是免费。
很多网站不管用不用得上，反正套一个也没啥损失，最后为了管理方便干脆连域名注册都放上去了。
不过话说回来，Cloudflare 的提供很多服务都是免费的，连 Page 这种服务基本上都给免费了。
总结 Cloudflare 故障复盘：
故障的直接导火索是机器人管理系统生成了一个异常增大的配置文件。
一次本意是提升安全性的数据库权限变更，意外地与一个存在逻辑缺陷的旧查询代码相结合，最终突破了核心代理软件的内存限制，导致了大规模服务中断。
觉得挺扯的地方是，很多人使用 CloudFlare 的目的是代理来避免 DDoS。
其实真正的原始网站是没有问题的，当 Cloud Flare 的配置出现问题的时候，其实是可以不再为这些用户提供代理服务，而直接跳过去，至少还可以保持网络不中断。
当整个服务宕机后，所有的都没有办法用了。
不管应不应该，我觉得这种基础架构的代码更新应该是需要进行测试的，而且这些公司的测试条件肯定比我们强多了。
换句话说，应该是连基本的测试都没有做，直接就推送。
使用 AI 的代码一定要小心，上面的很多逻辑是不正确的，而且可能会导致代码完全不可读。
使用 AI 越多，后面代码越不可读，整个逻辑错误会被一层一层的覆盖，然后导致整个系统的崩溃。
所以说，用 AI 来写代码现在来看就是个笑话，什么 AI 增加生产力这类的话术就是为了给大公司进行裁员和人力资源调整的接口。
不可否认的是 AI 能提供生产力。
以前需要 10 个人的工作，使用 AI 后，确实可能 6 个人就够了，对人的要求确实更高了。
但目前，无法完全替代人。
是的 还有一个引发的思考就是
目前很多轻量但重要的服务为什么去中心化备份这么少
身份验证和dns本不应该是一毁具毁的东西
这个AI 总结的挺好的 分享给大家
本次事件是 Cloudflare 自 2019 年以来最严重的停机事件，导致核心网络流量传输出现重大故障。
以下是事件的总结及从中得出的启发：
起始时间： 2025 年 11 月 18 日 11:20 UTC，Cloudflare 的网络开始经历核心网络流量传输的重大故障。
主要恢复时间： 核心流量大致在 14:30 恢复正常。
全部系统恢复时间： 截至 17:06，Cloudflare 的所有系统都恢复正常运行。
非恶意活动： 事故并非由网络攻击或任何恶意活动直接或间接引起的。
数据库权限更改： 故障是由对其中一个数据库系统的权限进行更改而触发的。
错误配置文件的生成： 权限更改导致 Cloudflare 的 Bot Management 系统使用的“特征文件”的生成逻辑出现了问题。
具体技术问题： 用于生成该特征文件的 ClickHouse 查询在逻辑上没有对数据库名称进行过滤。在权限更改后，该查询开始返回底层 r0 数据库的元数据，实际上使响应行数增加了一倍多。
这导致特征文件包含大量的重复“特征”行，使其大小翻倍。
系统崩溃： 流量路由软件对特征文件的大小设置了限制（当前限制为 200 个特征）。当这个大于预期的文件（超过 200 个特征）传播到所有机器上时，触及了 Bot Management 系统的内存预分配限制，导致系统恐慌（panicking），进而返回 5xx 错误。
诊断复杂性： 由于配置文件的生成是周期性的（每五分钟），且只有当查询在已更新的部分集群上运行时才会生成错误数据，导致系统周期性地恢复又失败，这种波动性最初让团队误以为可能是攻击所致。Cloudflare 状态页面的巧合性宕机也加剧了团队关于 DDoS 攻击的怀疑。
核心服务： 核心 CDN 和安全服务返回 HTTP 5xx 状态码。
代理版本差异： 部署在新的 FL2 代理引擎上的客户看到了 HTTP 5xx 错误；部署在旧的 FL 代理引擎上的客户没有看到错误，但 Bot 分数生成不正确（收到零分），导致阻止机器人的客户可能出现大量误报。
下游依赖服务： Workers KV 返回大量 HTTP 5xx 错误。Cloudflare Access 认证失败普遍存在。Turnstile 加载失败。
内部服务： Cloudflare Dashboard 大多数用户无法登录，部分原因是 Workers KV 被内部使用，以及 Turnstile 不可用。Dashboard 经历了两次可用性降低的时期。
团队通过停止错误特征文件的生成和传播，并手动插入一个已知良好的文件，随后强制重启核心代理解决了问题。
在 13:05，团队通过实施 Workers KV 和 Cloudflare Access 的旁路（bypass），使其回退到核心代理的先前版本，减少了对下游系统的影响。
通过扩展控制平面并发性，解决了因登录尝试积压而导致的 Dashboard 第二次可用性降低的问题。
Cloudflare 认为今天的停机事件是不可接受的，并计划采取措施确保未来不会再次发生此类故障。
弹性要求： Cloudflare 承认，鉴于其在互联网生态系统中的重要性，任何系统停机都是不可接受的。系统的架构必须具有高弹性，以确保流量始终持续流动。
初始诊断障碍： 系统行为的周期性波动（恢复和再次失败）以及状态页面的巧合故障，可能导致团队最初对问题原因产生误判（如怀疑 DDoS 攻击）。
为了防止未来发生此类故障，Cloudflare 正在进行以下强化工作：
配置文件的摄取强化： 强化 Cloudflare 内部生成的配置文件的摄取过程，使其像对待用户生成的输入一样进行严格处理。
全局终止开关： 为系统功能启用更多的全局终止开关（global kill switches）。
资源保护： 消除核心转储或其他错误报告压倒系统资源的能力。
故障模式审查： 审查所有核心代理模块中错误条件的故障模式。
技术细节改进： 需要评估和修复导致配置生成错误的数据库查询逻辑，例如确保查询中包含数据库名称的过滤条件。
该事件表明，即使是看似旨在提高安全性的内部权限更改，也可能因系统内部对依赖关系的错误假设而引发严重后果，凸显了在部署基础架构更改时进行全面集成测试和故障模式分析的重要性。
就像更换高速公路收费站的软件时，如果新软件没有明确指示只计算本区域的车辆，而意外地把隔壁区域的车辆也算了进来，导致系统在内存限制内无法处理翻倍的数据量，最终造成整个交通网络瘫痪一样。为了防止类似情况，需要确保软件具备严格的数据边界检查（强化摄取）和紧急断电开关（全局终止开关）。
反正我是觉得更多的是人祸。
这些年的的基础架构问题是没完没了，估计和含印度量有很大的关系。
