杜绝此类运维 bug 再次发生；
3 、语雀月日原因有个员蓝立即调整恢复方案为从备份系统中恢复存储数据 。公布故障对于一款拥有千万级用户的人用产品 ，最终在 22 点恢复语雀全部服务 。户赠运维团队加强运维工具的送半质量保障与测试 ，
1 、但受限于恢复方案 、在完成恢复后 ，我们和数据存储运维团队全力进行数据恢复工作 ，该措施在本次故障修复中已完成；
2 、在会员信息里点击立即领取即可获得赠送服务 。操作流程：进入工作台账户设置 、为了尽快恢复服务 ，服务语雀的数据存储运维团队在进行升级操作时 ，尤其是面向技术变更操作的 “可监控 ，缩小运维动作灰度范围，开始和语雀团队联调，19 点完成数据恢复；同时为保障数据完整性 ，请空间管理员留意语雀站内信 。
改进措施 ：
通过这次故障我们深刻认识到 ，定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线；14:15 联系硬件团队尝试将下线机器重新上线；15:00 确认因存储系统使用的机器类别较老 ，15:10 开始新建存储系统，造成大面积的服务中断 。由于语雀数据量庞大 ，具体过程如下：
14:07 数据存储运维团队收到监控系统报警 ，并进行定期的容灾应急演练 。不知道这次过后有多少用户会离开语雀 。无法直接操作上线，从备份中开始恢复数据，此过程历时较长 ，
这次故障也让大家知道了语雀使用的容灾架构是同 Region 多副本容灾而不是异地容灾方案 ，只有这样 ，
前天语雀发生重大故障导致长达 7 个小时无法正常访问 ，没办法语雀只能从备份系统里恢复存储数据，
当然语雀的这次问题也再次为个人和企业用户敲响警钟 ，设计足够的数据和系统冗余实现快速恢复 ，
下面是语雀公布的故障说明 ：
10 月 23 日下午 ，点击会员信息 、导致华东地区生产环境存储服务器被误下线 。并从根本上避免这类故障再次出现 。整体用时较长 。着实让人有些震惊 。实现离线后的快速上线 。由于新的运维升级工具 bug ，语雀称后续将升级为两地三中心的高可用能力 ，
补偿问题：
对于语雀个人版用户全部赠送半年会员 ，数据量级等因素 ，为语雀增加存储系统的异地灾备 。可灰度，升级硬件版本和机型，提前发现 bug；
4 、
针对语雀空间用户由于情况比较复杂，从架构和高可用层面改进服务 ，可回滚” 的系统化建设和流程审计，发生如此长的故障时间 ，
昨天晚上语雀在其公众号解释了故障原因 ，应该做到更完善的技术风险保障和高可用架构设计 ，
