上周，体位在三天内下降了三次。以下是发生的事情：大约两个月前，我们注意到我们的数据库（托管在Amazon的RDS上）增长迅速。为了防患于未然，我们计划在9月8日星期六调整它的大小。我们期望这次手术能提高体位的整体表现，并且几乎没有停机时间。所有迹象表明，调整规模的工作进展顺利，但在9月10日星期一，即9月10日，随着来自欧洲和东海岸的早晨流量达到高峰，我们的Amazon RDS Mysql数据库开始陷入困境。在将应用程序速度放慢到无法忍受的速度后，数据库问题最终导致了体式的下降。我们在发现缓慢迹象后几分钟内就开始了调查。我们的关键数据库指标似乎都没有异常，但我们确实看到从数据库到底层EBS存储卷的平均读写延迟有所增加。如果我们最近的一些代码更新增加了数据库的负载，我们做的第一件事就是恢复上周四以来所做的每一次更改。当问题持续存在时，我们开始怀疑周六的调整大小操作影响了EBS卷的性能。接下来，我们触发了到辅助数据库实例的手动故障转移。在过去，我们曾经遇到过其他RDS客户争用导致的性能问题，而故障转移到新硬件有助于解决这些问题。这一次，影响微乎其微。上午10:30，在我们成功地阻止了交通之后，体式又恢复了。但就在我们开始让所有人都回去的时候，GoDaddy的DNS崩溃了，这是一个完全无关的事件，它影响了我们（以及互联网上数百万个其他网站），切断了任何试图通过浏览我们的主页来访问体式的人。我们在试图解决自己的潜在问题时所做的更改在中午左右又触发了一次非常短暂的停机。我们花了整个星期一的时间来诊断早上中断的根本原因，并减少体式对数据库的依赖。尽管我们在后者上取得了成功，但第二天早上，体式又放慢了脚步。我们决定将我们所做的一些基础设施更改回滚，以防它们导致问题。当我们启动回滚时，部署中增加的负载刚好足以导致到数据库的连接堆积，在上午8:16，Asana再次失败。多亏了我们前一天所做的改进，这次的停机时间不那么严重了。我们再次堵车，大约30分钟后，体式又恢复了。到了周三早上，体式已经接近正常了，尽管我们仍然看到了一些虚假的性能问题，导致应用程序速度减慢。性能问题非常严重，因此我们决定部署额外的更改，以减少数据库负载。不幸的是，部署这些更改的行为再次将我们的数据库负载推到了阈值之上，导致了10分钟的停机。到了星期四，我们过去三天里所有人的努力都取得了成果。我们开始看到数据库性能的巨大改进，但是由于mysql内部的低级别锁争用，我们仍然看到数据库请求时间的周期性峰值。到底发生了什么事？虽然我们不能绝对肯定，但我们相信，用户数量的增长和数据库缓存的丢失（当我们调整数据库大小时）导致了mysql中锁争用的突然、急剧的增加。亚马逊使用专有技术为RDS运行的文件系统提供动力，但没有提供有关该技术在调整大小操作期间如何工作的文档，这一事实使问题更加复杂。此外，缺乏对数据库的根访问权限使我们更难理解问题的原因。但每一次危机都会带来机遇，上周的停机事件促使我们加快基础设施和生产监控能力的大幅改善。以下是我们目前所做的：与AWS和外部数据库顾问积极合作以了解问题。在我们的报告基础设施中添加了实时分析，使我们能够更快地诊断性能事件和识别异常活动。提高了我们限制请求的能力，降低了将来性能问题升级为全面停机的可能性。修正了web服务器中的一个错误，当我们在极端负载下部署新代码时，请求失败的可能性更大。减少了数据库写入的次数并提高了查询性能，以减少数据库中的内部锁争用。在我们的生产指标中添加了数百个新的计数器，以便更容易确定将来性能问题的原因。我们仍在做的是：迁移到一个新版本的Mysql中，我们希望它能减少内部锁争用，并提高我们解决问题的能力。探索减少数据库和底层存储层之间请求频率的其他方法。最终确定跨多个数据库实例划分用户数据的计划，以便将来根据需要添加额外的容量。加速从GoDaddy迁移到新DNS提供商的计划。我们深知，始终如一的稳定对每个依赖体位的人来说都是至关重要的，出色的表现将对我们公司的命运起关键作用。上周的宕机是我们团队所面临的最具挑战性的时刻，但挫折——尽管痛苦——却让我们更加强大。团队的每一个部分，从工程和产品到市场营销、销售和用户运营，都投入到工作中来，让体位法恢复正常，让我们的客户随时了解情况。我们使我们的基础设施更具弹性，我们的监控能力更强大。我们加深了对亚马逊RDS的了解，并与AWS团队建立了更牢固的关系。我们知道上周你和我们在一起很受伤。如果您有任何问题、反馈或顾虑，请告知我们。我们一直在倾听。