2016年1月4日星期一，从太平洋标准时间晚上8:22到晚上11:37，我们经历了一次中断，客户无法访问他们的振幅数据。在这次大修之后，振幅的数据在太平洋标准时间1月11日星期一下午3:23之前一直是过时的，关于振幅的几个重要特征无法访问。我们知道我们的许多客户依赖于振幅的可用性和最新的业务，我们让你失望了。我们想解释一下，我们将如何采取措施来防止这一情况再次发生。##怎么搞的？在太平洋标准时间1月4日（星期一）晚上8:22，一位工程师在生产环境中错误地运行了一个原本要在开发环境中运行的脚本。脚本删除了DynamoDB上的四个表，其中包含用于处理事件和查询数据的元数据。具体而言，这些表格包含以下信息：服务的内部配置查询引擎使用的文件元数据与我们看到的所有设备标识相关的元数据与我们指定的所有振幅ID相关的元数据删除这些表格后，振幅的web报告仪表板变得无法访问。此外，我们的处理管道停止了，因为没有ID信息就无法继续。仍在收集来自客户端的事件数据，并将其存储在队列中，以便稍后处理。我们的当务之急是让仪表盘再次进入。我们的查询引擎使用内部配置来确定要查询哪些分区，并使用文件元数据来确定数据的物理位置。我们能够在几个小时内从备份中恢复内部配置和文件元数据。在太平洋标准时间晚上11:37，客户可以访问大多数仪表板。由于处理仍然暂停，仪表板反映了在太平洋标准时间晚上8:22之前收集的数据。实时活动、用户时间线、显微镜、队列重新计算和下载都依赖于我们尚未恢复的表中的信息，因此这些功能仍然不可用。下一步是恢复这两个ID表。不幸的是，我们没有这些表的备份。但是，我们有所有的历史事件，我们可以用它们来重新创建这些表中的数据。太平洋标准时间1月5日星期二凌晨1点，我们开始开发和测试一系列MapReduce作业，以重建并重新填充数据。太平洋标准时间下午1点，我们开始重建数据；大约花了14个小时才完成。1月6日，星期三，太平洋标准时间凌晨4:30，我们开始重新填充ID表。我们在太平洋标准时间下午3:30开始最后的MapReduce作业，并开始并行验证重新填充的数据集。工作和验证于1月7日星期四下午1:30完成。此时，仪表盘在太平洋标准时间1月4日下午8:22之前已完全可以处理数据。然后，我们继续对事件backlog进行数据处理。我们最初预计处理积压订单需要1-2天，但我们不得不推迟几天。在典型的操作中，我们的采集服务器将对发送给我们的数据量的设备进行节流，这些数据量比实际数据量高出许多数量级，正如我们的处理管道所通知的那样。在大修期间，此功能处于非活动状态，导致我们收集的数据比平时多得多。这导致积压的时间比预期的要长。1月11日，星期一，太平洋标准时间上午9:30，我们完成了积压工作的处理，并开始在仪表板上进行数据验证。经过广泛测试，在太平洋标准时间下午3点23分，我们确认所有数据都已正确处理并恢复正常运行。在整个事件中，数据收集工作全面展开。为什么会这样？这一事件和随后的恢复时间长短是多种因素综合作用的结果。不幸的是，我们没有足够的保护来防止在生产环境中运行的脚本，该脚本可能会删除操作上关键的表。恢复很困难，因为DynamoDB中的一些表没有可用的备份，这迫使我们从历史数据中重建大量状态。即使是有备份的表，它们的恢复也被延迟了，因为我们没有有效地从这些备份中恢复数据的过程。整个星期一晚上，工程团队都在努力解决这个问题，但直到第二天才通知组织的其他成员。我们没有一个明确的上报流程，这导致我们最初的回应和与客户的沟通大大延迟。一旦事件得到适当升级，我们通过电子邮件通知了所有客户，并解释了情况，以及我们对何时完全恢复的最佳估计。然而，我们低估了恢复到完全恢复状态所需的时间，因此提出的估计是不正确的，必须推迟。我们在做什么来防止它再次发生？从这起事件中，有很多东西需要学习和改进。我们已经采取措施限制AWS帐户对关键数据的删除权限，并将对AWS帐户使用更细粒度的权限。我们将重新评估我们授予每个帐户和角色的权限，并确保这些权限是必需的最低限度。我们正在为目前没有备份的几个剩余数据库设置自动备份。此外，我们计划开发和演练从备份中快速恢复的方法。此外，我们将在接下来的几个月里对我们的系统进行全面的检查，以确定弱点，并确保我们在将来不会受到类似事件的影响。我们计划几个月后在这个博客上分享这篇评论的结果。最后，我们还制定了事故响应的政策和程序，以减少客户接到停机通知所需的时间，以及服务恢复在线所需的时间。感谢您在整个停机期间对我们保持耐心。我们真诚地为宕机表示歉意，并理解我们的客户依赖于我们为他们的业务提供的服务。我们将竭尽所能改进我们的流程，以确保您将来可以依赖振幅。谢谢你的支持。