【猎云网（微信号：ilieyun
）】9月18日报道 （编译：何弃疗）
昨天早晨，Asana当机了83分钟，从7点25分到8点48分。这是我们在过去两年中时间最长的一次当机，同时也是给客户造成最大影响的一次服务中断，是我们经历过的最糟糕的一次服务器崩溃。对此我们非常抱歉。我们明白对于我们用户的工作流程来说，Asana承担着重要的作用，此次服务中断浪费了所有用户的时间。我们很想告诉大家我们对于此次服务中断的看法，同时我们采取的避免下次类似事件发生的一些措施。
此次中断的重要原因归咎与我们在周三晚上部署的新代码。通常情况下，我们每隔两天就会部署新的代码，但是这一次部署比正常情况要迟了很多，导致推迟的原因是因为周三早些时间的一些恢复问题。新部署的代码中包含了一些能够帮助Asana提高安全性能的运行记录。然而这个代码中有一个bug，最终会导致运行记录被触发的次数远超我们的预设。新的代码部署完成之后，这个bug会占用我们的web服务器中大部分的CPU。但是因为问题发生在周三的晚上，这一时间段用户使用并不多，我们有足够的净空足以使CPU占用上涨不出大问题，因此我们也就没有及时的发现问题。
我们最先发现问题是在周四早晨的7点15分，超出平常水平的CPU占用率，连同着早晨（我们的高峰负荷）用户流量的上升，导致了访问延迟时间的增加，从而导致web服务器连接数据库所用的时间超出了平日正常水平。我们的一部分安全保障系统检测到了这一次异常连接上升，同时启动了非关键作业队列延后处理预案。这也导致了我们的搜索引擎失效，同时通知了我们的待命工程师。在这个时间点，Asana仍然还是可以访问的。
一开始待命工程师并没有意识到问题的严重性，因为我们的app还是可以正常运行的，因此这次事故的影响似乎仅仅局限在非关键作业队列。最初我们的调查围绕着数据库，因为这通常是造成问题的症结所在。过了最初的阶段，我们接到了另一个警告：API也当机了。还有一件令我们更加困惑的事情是，我们的工程还都在使用内部测试版本的Asana，这一版本与客户所使用的产品版本运行在不一样的AWS-EC2 instances上。由于内部测试版本上只有Asana自己的员工在使用，因此机器并没有过在。早晨7点35分时，我们的客户支持告诉我们的待命工程师，用户已经无法使用我们的app了。
7点40分，待命工程师们认为事故原因在于数据库过载。
7点47分，其中一个工程师注意到web服务器上运行记录正在逐渐增加，但是因为这一现象同之前的做的假设不符合，于是没有采取跟进调查。
7点57分，更多的工程师们加入了排查工作。
8点02分，一名待命工程师注意到web服务器的CPU已经接近最大值，于是立刻判断出是前一晚的替换代码出现了问题。
在8点08分至8点29分之间，我们尝试着找寻一个可以用来恢复的安全版本代码。但是因为在事故发生的前一天，我们使用了很多个版本的代码，因此我们也不清楚究竟哪一个版本是最安全的，因此我们只能去碰运气。
8点29分，一名待命工程师终于确定了事故的原因。与此同时我们也找到了最后一个没有包含错误代码的代码版本。8点37分我们开始恢复代码版本。鉴于故障的性质，在这种情况下，web客户端不会提示重新加载。终于在8点42分，我们将错误的版本加入了黑名单。
从这一刻开始，应用开始逐渐恢复正常。8点48分整个应用完全回到正常运行状态。
在事故解决之后，我们通过“5个为什么”方法进行反思和总结。我们相信此次事故中的失败是我们自己的责任。因此我们添加了更多的工具和安全机制来避免未来可能发生的同类事故。我们认为有三点是我们的系统和程序可以改进的地方：
1.在问题尚未波及到用户的时候就要发现问题所在。
2.减少待命工程师对问题作出相应措施的时间。
3.在发现问题之后，减少解决问题所需的时间。
我们明白我们的客户在每天的工作中都会用到Asana，但是昨天的Asana让大家失望了。因为我们的没有为大家提供一个稳定的服务，我们深感抱歉。我们以后会更加严格的要求自己，以期再次获得你们的信任。在未来的日子里，我们也会尽力确保这样的事情不会再发生。
