虽然 Cloudflare 的运维团队许诺将实施更多预警，以确保这些特定的错误设置装备摆设不会被忽略，但他们认可错误和错误设置装备摆设是不成避免的。他们强调，所有 Cloudflare 系统的方针都该当是以可预测和文雅的体例应对此类问题。

　　Renato Losio做为云架构师、手艺从管和云办事专家具有丰硕的经验。目前，他住正在，他的次要乐趣范畴包罗云办事和关系数据库。他是 InfoQ 的编纂，也是的 AWS 数据豪杰。你能够正在 LinkedIn 上取他联系。

　　虽然团队正在 5 分钟内发觉了该缺陷并恢复了更改，但此次毛病触发了 Logfwdr 中的第二个潜正在错误，导致了大量的过载，从而导致 buttee 无响应。ESET 高级企业收集平安参谋 Nermin Smajic 评论道。

　　正在这篇文章中，该团队沉点引见了 11 月 14 日呈现的问题，所履历的毛病以及 Cloudflare 打算采纳的步履。做者认可。

　　这一事务申明了为什么收集平安不只仅是为了防止外部，也是为了可以或许抵御复杂手艺挑和的强大、有弹性的内部系统。

　　为了供给来自全球 330 多个城市的数万台办事器的日记，Cloudflare 开辟了 Logpush，这是一种 Golang 办事，旨正在收集日记并将其推送到可预测的文件大小，同时按照利用环境从动扩缩。内部 Buftee 办事为每个 Logpush 功课供给了缓冲区，此中包含由区域或帐户生成的 100% 的日记。Logpush 从这些缓冲区读取日记，并将它们分批推送到各类客户设置装备摆设的目标地，每天处置跨越 6 亿个批次。

　　我们进行了一个变动，以支撑 Logpush 的附加数据集。这需要向 Logfwdr 添加一个新的设置装备摆设，以便它晓得要为这个新流转发哪些客户的日记。(。。。。。。) 该系统中的一个缺陷导致向 Logfwdr 供给了一个空设置装备摆设。

　　当 Logfwdr 起头为所有客户发送事务日记时，Buftee 起头正在这些日记达到时为每个客户建立缓冲区 (。。。。。。) 这种庞大的增加导致缓冲区添加了大约 40 倍，这不是我们供给的 Buftee 集群所能处置的。

　　凡是，Cloudflare 每天向客户发送大约 4。5 万亿个零丁的事务日记。虽然这只占需要处置的 50 万亿个客户事务日记总量的不到 10%，但正在建立靠得住且容错的系统时，它带来了奇特的规模挑和。