软件故障花了 5 分钟才撤回更改，造成的混乱却花了数小时才清理干净。近日，Cloudflare 承认，由于糟糕的软件更新，搞砸了自己的“日志即服务”服务，导致客户数据丢失。在 11 月 14 日的大约三个半小时内，Cloudflare 日志服务没有将收集到的数据发送给客户，其中大约 55% 的日志丢失了。Cloudflare 日志服务收集云服务生成的日志，并发送给需要分析日志的客户。Cloudflare 表示，这些日志可能有助于“调试、确定配置调整以及创建分析工具，特别是与来自其他来源（比如应用服务器）的日志结合使用时”。Cloudflare 的客户常常需要来自多台服务器的日志，由于日志文件可能非常冗长且庞大，这家提供商担心消耗/使用所有日志文件可能会让自己不堪重负。帖子写道：“想象一下，邮局每收到一封信就按一次你家的门铃，而不是每收到一摞信按一次门铃。由于每秒有数千或数百万封信件，因此涉及的单独交易数量将变得令人望而生畏。”因此，Cloudflare 使用一种名为 Logpush 的工具，将日志打包成大小易于预测的包，然后以合理的节奏将它们推送给客户。Cloudflare 提供给客户的日志是由名为 Logfwdr 和 Logreceiver 的其他工具准备的。11 月 14 日，Cloudflare 对 Logpush 进行了更改，旨在支持额外的数据集。没想到这是一个错误的更改——它“实际上告知 Logfwdr 没有一个客户配置要推送的日志”。Cloudflare 的工作人员注意到了这个问题，在不到 5 分钟的时间内撤回了更改。但是这起事件触发了 Logfwdr 中的另一个错误；这意味着，在类似 Logpush 混乱的情况下，所有客户的所有日志事件都将被推送到系统中，而不仅仅是配置了 Logpush 作业的那些客户的日志事件。
由此造成的大量信息导致了中断，并导致一些日志文件丢失。Cloudflare 已经为这一事件责备自己。它坦承自己做了大量的工作来防止这种事发生，但工作还是没有完全做到位。该公司的帖子将这种情况比作没有系好汽车安全带——安全系统是内置的，而且有用，但如果没用上，就毫无用处。这家网络巨头会尝试在将来通过自动警报来避免这种混乱，这意味着错误配置“将不可能成为漏网之鱼”。它还计划进行进一步的测试，以便为数据中心及/或网络中断和系统过载造成的影响做好准备。![]()
![]()
![]()
![]()
