语雀崩溃7个小时的原因是什么？？

1 语雀是什么

语雀是蚂蚁集团旗下的在线文档编辑与协同工具，使用了“结构化知识库管理”，形式上类似书籍的目录。用户量在千万级别，是非常强大的。身边有不少朋友是付费会员，有许多公司也付费在使用语雀作为知识库进行文档的存储。

2 语雀崩了

我在10月23日下午3点左右使用的时候，发现语雀官网访问不到了，页面显示5xx的错误。

其他使用语雀的小伙伴也纷纷表示语雀访问不到了。之后，语雀官方也发布了声明，安抚用户，表示问题正在紧急处理，数据不会丢失。

到当日晚上9点多还没有恢复，届时故障已经6-7个小时，按照可用性算起来，三个9（99.9%）勉强保得住。【三个9的可用性意味着系统在一年的时间内，最多只能有约8小时的停机时间（也就是365天 * 24小时 * 0.1% ≈ 8.76小时）】

关于这次事故的原因，网上的猜测和分析出现了很多，有条很搞笑的：

3 语雀恢复

到当日晚上10点左右，全线恢复。官方在昨天晚上（10月24日晚）已经通报了故障原因、处理过程以及改进措施，详见：关于语雀 23 日故障的公告

故障原因简单来说就是新的运维升级工具 bug 带来的一系列影响。其实，究其根本原因还是高可用架构体系设计、运维以及项目规范，甚至是团队管理和制度上存在严重的问题需要去改进和完善。

不过，语雀这次的补偿方案也还不错，部分截图如下：

4 经验教训

作为一位软件开发从业者，语雀的这次事故让我们深思：

• 自己的文档资料是否需要多平台备份、本地存储？

• 如何保证服务的高可用？

备份是保障数据安全的重要手段，无论是个人文档资料还是工作文件，都建议进行多平台备份并且至少保存一份在本地，之后我个人资料妥善保管。

在服务上线前避免服务因为上线修改导致全线崩溃是非常重要的，这需要实施一些最佳实践和策略，确保在上线修改时系统能够保持稳定。

以下是一些方法来避免这种情况的发生：

1. 测试和沙盒环境：

• 在上线修改之前，确保在测试环境和沙盒环境中进行充分的测试，包括功能测试、性能测试和压力测试。这可以发现潜在的问题并及时修复。

2. 持续集成和持续部署：

• 实施持续集成和持续部署，自动化测试用例，确保每次提交代码时都会进行自动化测试。持续集成可以及时发现和修复问题，避免问题在生产环境中爆发。

3. 灰度发布：

• 使用灰度发布策略，将新版本逐步引入生产环境，先在小部分用户中进行测试，如果没有问题再逐步扩大范围。这种方法可以在问题扩大到所有用户之前就发现和解决问题。

4. 回滚计划：

• 在上线修改之前，制定好回滚计划。即使经过测试，也可能在生产环境中出现意外问题，有一个快速回滚的计划可以在问题发生时迅速恢复服务。

5. 监控和警报：

• 设置系统监控和警报，包括性能指标、错误日志等。当系统出现异常时，及时收到警报可以迅速响应问题，缩短故障恢复时间。

6. Code Review：

• 实施代码审查（Code Review），通过团队的集体智慧发现潜在的问题和漏洞。多个人的审查可以帮助发现单人可能忽略的问题。

7. 文档和知识共享：

• 记录每次修改的内容和过程，形成文档，确保团队成员了解修改的影响和潜在风险。知识共享可以避免类似错误在未来的项目中再次发生。

8. 持续学习：

• 持续学习新的技术和最佳实践，保持团队的技术水平。时刻了解业界的新动态，以便应对新的挑战和问题。

通过以上方法的结合使用，可以降低上线修改导致全线崩溃的风险，并在问题发生时更快地做出反应，保障系统的稳定性和可靠性。

---

关注我，我们一起学习。