2016 年 3 月 29 日晚间，LeanCloud 平台上的多个应用进行了推广活动，激增的访问量给我们的数据存储和实时通信服务带来了较大压力。从 20:50 至 22:15 有多次流量高峰出现，我们多台 Web 服务器的网络吞吐包超过虚拟机的能力极限，内外网通信中断，从而导致 HTTP 服务多次出现间歇性故障（数据存储 API 以及依赖于它的服务也都间歇性不可用）。具体情况汇报如下：
20:53 - 21:03（持续约 10 分钟）数据存储 API 服务约 50% 的请求超时。21:17 - 21:40（持续约 23 分钟）数据存储 API 服务约 50% 的请求超时。22:00 - 22:15（持续约 15 分钟）数据存储 API 服务约 12.5% 的请求超时。故障总共持续约 48 分钟。
本次故障只影响中国节点，美国节点的所有服务均工作正常。在故障期间凡是向 LeanCloud 平台发送过请求，并使用了数据存储服务的活跃应用都受到了影响；我们的统计服务也在短时间内无法正常接收来自应用的事件上报。
2016 年 3 月 24 日下午 2:24，LeanCloud 的文件存储及 CDN 上游服务商之一受到了恶意攻击，导致 LeanCloud 中国节点的部分应用无法正常访问文件。当日晚上 8 点服务商修复了故障，LeanCloud 的文件存储随即恢复正常。
14:24 至 19:55（持续约 5 小时 31 分钟）
使用中国节点、在故障期间有文件访问请求的部分应用受到了影响。中国节点上的其他服务，如结构化数据存储、云引擎、聊天、短信、推送、统计等均未受影响。美国节点一切正常。
2016 年 2 月 26 日下午五点左右，我们的聊天服务出现了短暂异常，导致部分终端用户在获取指定聊天记录时，可能会得到整个应用的聊天记录。此次故障持续了十多分钟，具体情况如下。
16:45 至 16:58（持续约 13 分钟）
使用了聊天服务，且在服务异常期间发生了聊天记录查询请求的所有应用
2016 月 2 月 19 下午 3 点左右，LeanCloud 所有服务突然不可用。我们的报警系统即刻捕捉到异常并发出告警，我们由此进行紧急修复，于半小时后将全部服务恢复到正常运行状态。此次故障影响范围较大，性质严重，我们将详细情况汇报如下。
15:17 至 15:50（持续约 33 分钟）
除了单纯的静态网站托管服务未受影响之外，其他所有服务，包括结构化数据存储、文件存储、云引擎、聊天、短信、推送、统计等功能都暂时无法使用。
昨日（周六）下午 4 时左右，有部分应用的云引擎服务出现间歇性错误「502 Application Not Responding」。我们收到报警后紧急上线调查原因，最终在下午 4 点 40 分左右修复了故障，让云引擎服务恢复正常。
本次故障从问题大面积爆发到恢复大约持续了 50 分钟，受影响的服务仅涉及云引擎，其他云端服务均运行正常。使用了云引擎服务且该时间段内云引擎有流量的应用会受到牵连。本次故障给部分用户带来了影响和损失，我们感到万分惭愧，并郑重向这些用户道歉。
故障修复之后，我们立即召集所有相关工程师进行了问题总结和技术讨论，评估可行措施来防止类似问题再次发生。以下是本次故障的详细报告。
12 月 25 日凌晨 5 点 30 分至上午 8 点整，数据存储服务器的某一分片突然发生故障，导致所属的 1468 个应用无法向云端写入数据。我们在 5 点半收到报警后着手开始处理故障，最终在 8 点修复了这一问题，故障时间共持续 2 小时 30 分钟。
故障期间，受到影响的应用无法向云端保存和更新数据，但仍可以进行查询，并可使用不依赖于数据存储服务的其他功能。其它应用和服务均不受影响。
8 月 7 日上午 8 点 30 分左右，聊天服务出现不稳定状态，8 点 59 分我们内部监控系统显示服务不可用并报警，工程师随之上线处理。之后陆续收到用户反馈，说终端用户无法连接上 LeanCloud 聊天服务器。经我们检查确认是由于某台服务器出现了网络故障而导致连锁反应，我们工程师在定位故障后即刻进行了服务重启和扩容，最终在 11 点 50 分让服务彻底恢复正常。
这是一次非常重大的事故。为了将问题说清楚，我们先来介绍一下 LeanCloud 聊天服务的架构。
8 月 6 日上午 10 点 55 分开始，LeanCloud 数据存储、网站等服务都突然变慢，之后持续 15 分钟整个存储服务都基本不可用；从 11 点 10 分开始存储服务逐步恢复，至 11 点 23 分才彻底正常。
出现这一事故的原因，与我们的智能索引优化有关。大家可能知道，我们使用 Mongodb 来存储结构化数据。为了方便开发者的使用，我们会根据应用查询性能数据来自动为数据表进行索引优化。因为近期有部分客户数据增长迅猛，我们的智能索引优化系统监控到部分查询耗时较长，便给出了索引优化建议。上午 10 点 55 分，智能索引系统开始自动为这些用户的部分数据表创建索引。但是由于此次操作实际执行时间过长，导致索引创建失败，并引发了 Mongodb 中大量操作的堆积，令整个 shard 处于崩溃状态。很快存储集群的故障就波及到了前端的 API Server。
7 月 22 日周三 20 点 10 分，我们的实时通信服务 CPU 消耗升高，消息处理延时增加，也影响到与它关联的消息推送服务，慢慢导致最终推送队列出现了任务堆积，部分消息无法在第一时间推送出去。一小时后（21 点 15 分）也有用户给我们反馈，在终端用户那里能感受到，聊天过程中会有明显的间歇性卡顿。我们工程师一直在密切关注服务状态，紧急追查原因，最终在 2 小时之后彻底解决这一问题。
导致这次故障的原因，与当天凌晨 7 点我们为实时通信服务的 java 进程调整了 GC 相关参数有关。经过持续的 JVM 监控分析，我们发现线上实时通信服务的 GC 配置比较简单，还有优化空间，所以决定将原来的吞吐量优先收集器改为 CMS 收集器，以使业务运行更流畅。到了晚上随着实时通信服务压力增大，我们发现该调整并未达到预期效果，FGC 更加频繁，且 GC 过后老代内存比例依然较高，这反而拖累了用户线程的处理能力；影响还波及到消息推送服务，使消息推送的速度急剧下降。
GC 参数调整之后，我们工程师一直在关注服务状态，晚上 8 点后突发的实时通信压力让新参数的弊端一下子暴露出来，但是因为当时正好是部分客户的业务高峰，我们担心重启服务会带来大面积的中断和重连，这与间歇性卡顿下的可用相比，可能会造成更大的损失，所以我们只能密切关注服务端状态变化，择机行事。等晚上 10 点左右压力回落之后，我们立刻重启了实时通信服务，回滚了 java 进程的 GC 参数，同时将推送服务的处理容限临时提高至 200% 来加速处理队列中已积压的任务。
因为只调整了实时通信服务的 java 进程 GC 参数，所以数据存储、云代码、统计分析、网站等其他服务均未受到任何影响。
从昨天（7 月 8 日）晚间开始，我们发现云引擎「在线定义函数」的编辑功能出现故障，用户无法在线实时修改自定义函数。受影响的功能仅限于「在线定义函数」这一项，云引擎的其他功能（如部署、运行等）以及 LeanCloud 的其他服务（如数据存储、聊天、推送等）均不受影响。
从故障发现之时起，我们的工程师一直在查找和定位原因，惭愧地是到 7 月 9 日下午 2 点左右还没有完全解决。因此我们做了代码回滚，从 2 点 47 分开始「在线定义函数」功能又可以正常使用了。等我们找出引起该问题的具体原因，会给大家做进一步的更新。
谢谢大家对 LeanCloud 的理解与支持！
2015 年 7 月 13 日 更新：
我们的工程师最终在 7 月 10 日晚上 6 点找出了问题根源：
在 0.5.5 版 JavaScript SDK 中，我们为了兼容 Promise+ 模式，将 save 保存操作变为异步调用，导致它在多 appId/appKey 切换的场景下会产生超时错误。而云引擎正是这种使用方式，所以出现了自定义函数不能保存的情况；但对于账户下只有一个应用的用户而言，因为不涉及切换 appId/appKey，所以并不会受到影响。我们通过回滚云引擎代码暂时解决了这一问题，以后会再择机将其整体升级到最新版。