昨日（周六）下午 4 时左右，有部分应用的云引擎服务出现间歇性错误「502 Application Not Responding」。我们收到报警后紧急上线调查原因，最终在下午 4 点 40 分左右修复了故障，让云引擎服务恢复正常。

本次故障从问题大面积爆发到恢复大约持续了 50 分钟，受影响的服务仅涉及云引擎，其他云端服务均运行正常。使用了云引擎服务且该时间段内云引擎有流量的应用会受到牵连。本次故障给部分用户带来了影响和损失，我们感到万分惭愧，并郑重向这些用户道歉。

故障修复之后，我们立即召集所有相关工程师进行了问题总结和技术讨论，评估可行措施来防止类似问题再次发生。以下是本次故障的详细报告。

故障时间

2016 年 1 月 9 日下午 3:50 至 4:40（时长 50 分钟）

故障现象

云引擎服务频繁返回异常错误「502 Application Not Responding」。

影响范围

仅限于使用了云引擎服务且该时间段内云引擎有流量的应用。

使用了云引擎服务但在此时间段没有对云引擎发出请求的应用，或没有开通云引擎服务的应用，均不受影响。

故障原因

近期我们正在为云引擎开发新功能，以允许开发者自行扩展更多实例；同时我们为非生产模式下的云引擎实例增加自动休眠功能，以实现服务器资源的合理利用。为此，我们需要动态修改云引擎请求的内部路由规则，将应用请求交由正确的实例来处理，同时动态收集应用日志和统计请求状态，用于报警和展示。

2015 年 12 月 31 日，我们把这部分新开发的代码合并到了主干，但未能测试出里面隐藏的一个漏洞，即云引擎内部路由规则存在缺陷，在某些特殊情况下会导致多个模块之间对云引擎实例的状态判断不一致，从而触发自动休眠的监控进程不断地去强制停掉云引擎实例，而当客户端发来请求时系统又会继续重启实例，这样就引发了频繁的服务端报错。这部分代码在元旦节后被部署到生产环境，由于触发条件没有达到，所以问题一直没有暴露出来。直到昨日下午，有应用在进行推广，短时间内产生了大量请求，于是触发了临界条件，引出了问题。

紧急处理

• 手工修改了所有错误的路由信息。
• 暂停了收集实例运行状态的监控程序和自动休眠功能，确保实例可以一直运行。
• 紧急修复问题代码，确保新实例路由正确。

后续措施

为了保证今后服务的稳定性，我们还将完成以下措施：

1. 增加白名单，对流量大的应用不启用休眠机制。
2. 对云引擎实例的运行状态目前仅进行监测，不采取动作，并配以自动统计和人工分析，确保收集到的状态与实际相符。
3. 对实例休眠程序进行追踪和统计，辅以人工检查来确保操作正确。
4. 对应用请求量和结果状态进行实时监控，有突发情况时能实时报警。

最后，我们再次对受影响的用户表示道歉。我们会尽一切努力，保证云端服务的稳定，不辜负大家对我们的信任！