Adjust 2018-06-21 事后调查报告

关键字

尊敬的客户与合作伙伴,

如先前允诺,以下是上周四事故的完整流程报告。

到底发生了什么?我们又会如何确保它不再重演?

在回答问题前,我们想先带您了解,过去13个月以来我们针对基础架构所做的改善,以及停电事故几周前所发生的事。


我们基础架构在过去13个月来的变革

2017年事故发生后,我们认真看待问题并提出增加系统冗余的对策。第一步是在三个完全相互备份(fully-redundant)数据中心运行所有的跟踪服务,我们选择阿姆斯特丹(AMS)、洛杉矶(LAX)以及我们位于法兰克福(FRA)的主要数据中心作为据点。如果主要的数据中心发生断电,就只有控制面板与部分不需要实时处理的重要功能服务会受影响。近期我们也开始在洛杉矶创建完整的控制面板备份,期望让我们在美国或亚太地区的客户能够更快速地读取关键业绩指标(KPI),附加的好处是法兰克福的断电不会再影响对控制面板的使用。

同时,我们升级了网络设置,现在我们可以自主控制全球Adjust服务请求的路由规则。一旦紧急事件发生,我们在短短几秒间便能将流量从一数据中心移转到另一个数据中心。

最后也最重要的,是我们将我们In-Memory数据中心的设置切换为完全的分布式网络。这意味着所有来自我们SDK还有合作伙伴的请求,会在三组相同的数据集群进行全球同步,使我们得以在保持一致,并有备份的情况下把流量从一个地点绕至另一个地点。因为实时同步有赖群组之间高带宽与低延迟的连结,所以我们选择三角途径搭配各两段独立连接:LAX – AMS、AMS – FRA 以及FRA – LAX。近期内FRA – LAX的连接将会连机运作。

为了要初始同步2组数据中心的集群,我们需要将一个据点的数据完整备份,再复制到另一据点。换句话说,我们要从磁盘读取約100TB数据,经由网络复制后再将数据复写回目的地磁盘,接着所有在传输时做的操作会重播以建立实时串流。我们目前的设置使用10 Gbit/s连接和当前市面上最快的商业硬件,然而由于数据规模庞大,还有集群进行备份同时必须回应大约每秒500K查询的限制,一个完整的同步化过程耗时约2到3周。


服务中断前几周都发生了什么?

我们在5月7日周一开始开始了重要的数据库系统更新。这项更新需要集群的完整重新同步。经过缜密计划和测试后,我们决定开始在LAX数据中心的升级。三个礼拜后,我們在5月24日完成更新与再同步,期间並未出现任何重大事故。10天后直到6月4日周一都没有任何异状,我们因此决定更新AMS集群。

6月6日当天,我们在AMS和LAX之间的光纤供应商Level3宣布在UTC凌晨4点15分到5点50分之间进行计划性的维护。很不幸地,我们另一个由Zayo提供的连接在当天凌晨0点15分也发生中断,肇因于位在荷兰的佛特尔(Zandvoort)与英国的洛斯托夫特(Lowestoft)之间的海底电缆在渔船下锚时被切断。该连接于8点40分恢复运作。

由于两组连接的中断重叠,LAX集群出现数据不同步,且需要被切断以避免出现追踪不一致。而当连接恢复后,我们无法重播缓存的事件,因而被迫重置整个同步过程。

很不巧地,这个发生的当下我们正在进行AMS到FRA的同步。因此FRA要同时处理所有跟踪请求以及LAX新的备份。等待AMS完成同步化是当时最好的作法,然而,在FRA和AMS之间的带宽在当时由于从FRA经由AMS到LAX流量变得格外紧张。


6月21日那天发生了什么事?

当天UTC9点29分,我们位于FRA的数据中心在计划性维护的过程中,发生人为错误造成的短路。这导致所有连接主要电源线的电子设备熔丝熔断。这些电子系统尽管有断电应对的设计,却无法承受人为引起的电流暴冲,我们在FRA的设备因此而停机。

电力在UTC9点41分恢复,我们的服务器/网络设备开始重启。由于电流暴冲,我们遭受了一定损耗,并不得不更换很多组件。

直到UTC10点17分,部分系统已恢复且控制面板得以重启。

很快地,我们开始回应点击跳转。受损硬件组件使得重启过程从几分钟推迟到几小时,因此起初跳转成功率并不高。

事情发生当下,我们检查我们先前(也是仅存的)数据库集群。故障的网络设备情况很严重,我们不得不手动进行重新配置,整个过程持续了约30分钟。

最大的挑战在于,当我们从“冷”状态启动数据库集群时,所有数据必须要从磁盘读取至RAM。为了保持一致,我们必须等到所有数据皆被读取后才启用集群。即使在最佳状态下,读取100TB也要花上好一段时间。恢复工作以超过每秒10GB的速度进行,耗时两小时, 最终在UTC12点48分完成。

当数据库重新连机,我们逐步地让所有的后端服务做好准备,以处理来自合作伙伴与SDK排队等候的请求。超过半数的请求在UTC14点40分收到回应,流量达到了平常的140%。UTC15点28分,所有的后端皆连机且完全运作,流量超过了平常的200%。

所有的服务在UTC17点38分完全恢复运作,处理的流量稳定在150%,追回超过75%因断电而失败的所有请求。


如何避免事件再次发生?

这次的停电用了最戏剧化的方式提醒了我们,Adjust在移动营销生态系统里所处的重要地位,以及我们供应的服务对于客户和合作伙伴的重要性。我们非常看重背负于身上的责任,为此我们采取了许多措施以优化正常运行时间。

我们的首要任务,是增加各点之间的带宽:将FRA – AMS升级至100 Gbit/s的同时,也将补齐FRA – LAX之间的连线。再者,我们会升级所有的数据库服务器,除了配备更高速的硬盘,也从SSD升级至NVMe技术。此外,我们会进一步研究如果某一地区的内部连接中断时,使用互联网连接的可能性。这些措施预期能在集群重设时有效减少同步的耗时,并增强对抗连接中断的复原力。

重新评估我们的升级策略的同时,我们也在研讨避免受相关事件冲击的对策。

除此之外,我们开始评估在亚太地区第四个数据中心的可行性。我们原计划是向该区域提供更快速便捷的控制面板,现在也将评估在当地设置完整跟踪功能的可行性。

最后,我们会在8月把服务器从目前的FRA迁移至市内另一处设施。这个迁移在一年前便已规划,但由于审慎调查可行地点、取得使用证书还有购买网络设备等因素而延宕至今。

服务中断期间我们也历经了电邮服务商故障的问题,导致许多客户无法收到我们寄出的沟通信息。为了扩展我们事故发生时信息的传播度,我们会严格地测试所有的电邮服务商,并创建新的Adjust状态页面。此页面将让您持续跟踪所有事故的更新以及更仔细的的服务状态。


结语

在此我真诚的向您-我们的客户以及合作伙伴道歉。我们不认为存在所谓的“合理的宕机时间”。我们会竭尽全力预防类似事件再次发生。

没有刀枪不入的系统,但我们会持续努力,让我们面对不幸或人为疏失(无论机会多微乎其微)时有更佳的应对方法。上周四墨菲定律挑战了我们,但我们会从中学习,变得更好、更坚韧。

我也想向每位客户与合作伙伴致谢,谢谢你们捎来的支持话语、又或仅仅是在艰困时刻展现对我们的耐心。这一切我们铭记在心。

倘若您有任何其他与事故相关的疑问,请写信至我的信箱:paul@adjust.com,又或直接与我们的客户服务团队联络。

衷心感谢您的支持与体谅,

Paul H. Müller

CTO & Co-Founder Adjust

扫一扫, 分享本文

关注adjust的公众号