这篇文章是关于一个月前发生的数据丢失事件的更新。目的是描述我们正在做些什么来防止将来发生类似的故障。事件回顾2016年2月22日，我们发生了一次数据丢失事件，导致9%的客户在2016年2月22日或23日丢失事件，具体取决于客户的时区。对于超过一半的受影响者来说，从那天起我们损失的事件不到1%。然而，在许多情况下，它是更多的，在某些情况下，它是一整天的事件价值。这是我们四年来最严重的数据丢失事件，对我们受影响的客户、Mixpanel工程团队和公司其他人员来说，这是一次非常紧张和破坏性的经历。这起事件引发了两个基本问题。首先，一个bug是如何在没有被检测到的情况下发布到所有生产数据服务器上的？其次，考虑到会发生错误，单个错误如何导致无法恢复的数据丢失？防止错误我们有四个主要的工具来防止和限制产品缺陷的范围：自动化测试、代码评审、登台和金丝雀部署。不幸的是，在本例中，由于各种原因，bug从所有这些错误中溜走了。我们进行了一组压缩测试，测试了触发bug的条件——重复运行属于同一天的数据——但是这些测试只断言在压缩运行之后存在正确的文件，而不是文件的内容是正确的。相反，我们有另一组压缩测试来验证内容输出文件，但不是在触发bug的条件下。（我们已经修复了压缩测试，这样他们就可以发现这个bug了。）代码由正确的人进行了彻底的检查，但是错误并不明显。更改被分多次进行，首先是在我们的staging集群中，然后是在生产中选定的canary主机上。在每种情况下，我们运行压缩，一切看起来都像预期的那样；但是，我们没有在一个有足够容量和潜在数据的项目上触发多个运行来触发bug。因为对于任何给定的项目，压缩每天只在生产中运行一次，直到部署后几个小时，bug才逐渐显现出来。实际情况是很难编写能够预测每一个可能的场景的测试，同样地，在代码评审中捕捉每一个bug也很困难。考虑到对压缩的更改可能会导致数据损坏或丢失，而且我们知道可能会有潜在的影响，因为它只是每天运行，所以我们应该让新代码在一组副本上运行几天，然后再在所有地方发布。为什么没有发生这种事？虽然我们有工具来测试，阶段和金丝雀压缩，他们是手动步骤，每次应用略有不同。相反，我们需要一种可重复的、自动化的方式来部署服务。我们现在确信，我们需要采取持续部署的办法。这意味着，对代码存储库的更改将启动一个过程，该过程将以完全自动化、定义良好的方式将这些更改转移到生产中。这对我们扩大团队规模也至关重要。转移到持续部署将是一个长期的努力，由我们的网站可靠性工程团队领导。在短期内，我们已经制定了一套部署运行手册，准确地解释了如何遵守当前的最佳实践。即使不幸的是，它们仍然需要手动操作，至少我们可以像我们所知道的那样安全地使用我们当前的工具，并且以团队中每个人都可以访问和明显的方式进行操作。由于构建跨所有服务的连续部署和运行手册需要一段时间，因此我们还审查了我们的服务并将其划分为多个层。这样我们就可以按优先顺序处理它们。防止不可恢复的数据丢失为了防止数据丢失，存储在数据库Arb中的事件数据至少写入四个（通常是八个）独立的磁盘。我们还定期自动备份所有事件，并将它们发送到两个独立的数据中心。然而，虽然这在为磁盘故障提供冗余方面做了一件合理的工作，但它对bug的恢复能力并不强。bug是软件开发中不可避免的一部分。如果你承认它们会发生——当它们发生时，所有的赌注都没有了——那么很明显，一个bug就可以全面删除生产数据。因此，为了防止不可恢复的数据丢失，我们需要一个完整的、非生产的数据拷贝。事件发生后，我们重新编写了备份系统。它现在更加高效、可靠和灵活。最大的变化是Arb备份，以前是每周备份，现在是每天备份。但是，最近24小时，在每天的更新之间呢？这些仍然处于危险之中，事实上，在这次事件中损失了很多。为了解决这个问题，我们正在实施一个系统，该系统存储过去7天的摄取流量，这些流量在我们的摄取API的头部被虹吸。我们直接从负载平衡器发送数据的分叉副本，这意味着在数据到达运行代码的任何其他服务器或进程之前，该副本在系统的外部边缘生成。通过这种方式，我们最大限度地减少了可能影响在线和离线数据的潜在错误或操作错误。如果发生类似这样的事件，我们将备份超过一天的内容，对于最近的事件，我们将能够重放来自临时存储的流量。我们再次感谢您的耐心和理解，我们一直在寻找最佳的短期和长期解决方案，以防止今后发生此类事件。如果您对此事件有任何疑问，请随时联系您的客户代表或Mixpanel支持，网址为support@mixpanel.com。