为什么没人做物流网站,农民工找活平台,国外网站做盗版,久雅科技软件开发外包前言
最近#xff0c;阿里系的语雀出了一个大瓜#xff0c;知名在线文档编辑与协同工具语雀发生故障#xff0c;崩溃近10小时。。。。最后#xff0c;官方发布了一则公告#xff0c;我们一起来看看这篇公告#xff0c;能不能有所启发。 目录 前言引出一、语雀P0故障回顾…
前言
最近阿里系的语雀出了一个大瓜知名在线文档编辑与协同工具语雀发生故障崩溃近10小时。。。。最后官方发布了一则公告我们一起来看看这篇公告能不能有所启发。 目录 前言引出一、语雀P0故障回顾1、发生肾么事了2、官方公告说了啥 二、解构官方公告1、怎么回事2、解构改进措施 三、聚焦 “可监控可灰度可回滚”1、可监控2、可灰度3、可回滚 总结 引出 1.在保证分区容错下无法同时做到一致性和可用性。系统设计时只能选择一个目标在P一定会出现的情况下A和C之间只能实现一个这就是CAP定理。
CP: 强一致性弱可用性牺性部分机器的可用性保证数据一致性如zookeeper、es、NaocsAP: 强可用性弱一致性牺牲一致性保证可用性如Eureka
2.可监控可灰度可回滚
一、语雀P0故障回顾
1、发生肾么事了 2、官方公告说了啥 各位语雀的用户
10 月 23 日语雀出现重大服务故障且持续 7 个多小时才完全恢复给用户使用造成极大不便对此我们深感抱歉。经过复盘我们在这里向大家进一步说明故障原因、修复过程和改进措施。
故障原因及处理过程
10 月 23 日下午服务语雀的数据存储运维团队在进行升级操作时由于新的运维升级工具 bug导致华东地区生产环境存储服务器被误下线。受其影响语雀数据服务发生严重故障造成大面积的服务中断。为了尽快恢复服务我们和数据存储运维团队全力进行数据恢复工作但受限于恢复方案、数据量级等因素整体用时较长。具体过程如下
14:07 数据存储运维团队收到监控系统报警定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线14:15 联系硬件团队尝试将下线机器重新上线15:00 确认因存储系统使用的机器类别较老无法直接操作上线立即调整恢复方案为从备份系统中恢复存储数据。15:10 开始新建存储系统从备份中开始恢复数据由于语雀数据量庞大此过程历时较长19 点完成数据恢复同时为保障数据完整性在完成恢复后用时 2 个小时进行数据校验21 点存储系统通过完整性校验开始和语雀团队联调最终在 22 点恢复语雀全部服务。用户所有数据均未丢失。
改进措施
通过这次故障我们深刻认识到语雀作为一款服务千万级客户的文档产品应该做到更完善的技术风险保障和高可用架构设计尤其是面向技术变更操作的“可监控可灰度可回滚”的系统化建设和流程审计从同 Region 多副本容灾升级为两地三中心的高可用能力设计足够的数据和系统冗余实现快速恢复并进行定期的容灾应急演练。只有这样才能提升严重基础设施故障时的恢复速度并从根本上避免这类故障再次出现。为此我们制定了如下改进措施
1、升级硬件版本和机型实现离线后的快速上线。该措施在本次故障修复中已完成
2、运维团队加强运维工具的质量保障与测试杜绝此类运维 bug 再次发生
3、缩小运维动作灰度范围增加灰度时间提前发现 bug
4、从架构和高可用层面改进服务为语雀增加存储系统的异地灾备。
赔偿方案
为了表达我们的歉意我们将向所有受到故障影响的用户提供如下赔偿方案
针对语雀个人用户我们赠送 6 个月的会员服务。操作流程进入工作台「账户设置」点击左侧「会员信息」在会员信息页面点击「立即领取」即可获得赠送服务。
针对语雀空间用户由于情况比较复杂我们会单独制定赔偿方案。请空间管理员留意语雀站内信。
这次的故障让我们深切地感受到了用户对语雀的依赖以及语雀肩上的重大责任。再次向所有语雀用户表达我们诚挚的歉意。我们将持续提升语雀的服务质量和服务稳定性不辜负每一位用户的信任
语雀团队
2023 年 10 月 24 日
二、解构官方公告
1、怎么回事
10 月 23 日下午服务语雀的数据存储运维团队在进行升级操作时由于新的运维升级工具 bug导致华东地区生产环境存储服务器被误下线。 14:07 数据存储运维团队收到监控系统报警定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线【说明人家有运维监控系统】 14:15 联系硬件团队尝试将下线机器重新上线15:00 确认因存储系统使用的机器类别较老无法直接操作上线立即调整恢复方案为从备份系统中恢复存储数据。【有备份系统保存所有历史数据】 15:10 开始新建存储系统从备份中开始恢复数据由于语雀数据量庞大此过程历时较长19 点完成数据恢复 同时为保障数据完整性在完成恢复后用时 2 个小时进行数据校验【数据校验数据完整性】21 点存储系统通过完整性校验开始和语雀团队联调最终在 22 点恢复语雀全部服务。【数据恢复开始联调】用户所有数据均未丢失。【硬件有价数据无价】
2、解构改进措施
通过这次故障我们深刻认识到语雀作为一款服务千万级客户的文档产品应该做到更完善的技术风险保障和高可用架构设计尤其是面向技术变更操作的“【【可监控可灰度可回滚】】”的系统化建设和流程审计从同 Region 多副本容灾升级为两地三中心的高可用能力设计足够的数据和系统冗余实现快速恢复并进行定期的容灾应急演练。只有这样才能提升严重基础设施故障时的恢复速度并从根本上避免这类故障再次出现。为此我们制定了如下改进措施
1、升级硬件版本和机型实现离线后的快速上线。该措施在本次故障修复中已完成 2、运维团队加强运维工具的质量保障与测试杜绝此类运维 bug 再次发生 3、缩小运维动作灰度范围增加灰度时间提前发现 bug 4、从架构和高可用层面改进服务为语雀增加存储系统的异地灾备。
我们看到事故复盘中出现了**【【可监控可灰度可回滚】】**这是什么意思可监控如何实现可灰度是啥意思实际怎么操作可回滚是啥我们会在下一章分析。 另外这里反复提到了容灾、高可用这和CAP理论息息相关1998年加州大学的计算机科学家Eric Brewer提出分布式系统有三个指标。
Consistency(一致性)Availability(可用性)Partition tolerance(分区容错性)
其中最为重要的是Partition tolerance(分区容错性)也是所有分布式系统必须满足的条件 Partition(分区)因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接形成独立分区。 Tolerance(容错)容错表示在集群出现分区时整个系统也要持续对外提供服务。
在保证分区容错下无法同时做到一致性和可用性。系统设计时只能选择一个目标在P一定会出现的情况下A和C之间只能实现一个这就是CAP定理。
CP: 强一致性弱可用性牺性部分机器的可用性保证数据一致性如zookeeper、es、NaocsAP: 强可用性弱一致性牺牲一致性保证可用性如Eureka
通过上面的分析我们看到语雀采用的是高可用容灾的策略也就是AP模式保证强的可用性本次事件就是造成了大面积的不可用。 详细的CAP理论可参考下面博客
分布式事务——CAP理论 解决分布式事务的思路 Seata组件初识 和 部署 三、聚焦 “可监控可灰度可回滚”
1、可监控
监控Monitoring收集、分析和使用信息来观察一段时间内的运行进度并且进行相应的决策管理的过程。监控侧重于观察特定指标。
可观测性Observability通过分析系统生成的数据理解推演出系统内部的状态。 可使用的工具JVisualVM、JConsole、skywalking、Prometheus和Grafana来实现Java Web应用程序的监控
JVisualVMhttps://visualvm.github.io/ 参考文章 https://zhuanlan.zhihu.com/p/512714915#
2、可灰度
什么是灰度发布
灰度发布又名金丝雀发布或者灰度测试是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing即让一部分用户继续用产品特性A一部分用户开始用产品特性B如果用户对B没有什么反对意见那么逐步扩大范围把所有用户都迁移到B上面来。
灰度发布是对某一产品的发布逐步扩大使用群体范围也叫灰度放量。灰度发布可以保证整体系统的稳定在初始灰度的时候就可以发现、调整问题以保证其影响度。
灰度期灰度发布开始到结束期间的这一段时间称为灰度期。
灰度发布的意义 灰度发布能及早获得用户的意见反馈完善产品功能提升产品质量让用户参与产品测试加强与用户互动降低产品升级所影响的用户范围。
灰度发布的策略
按照流量阶段性发布先随机给5%的用户使用新版本没问题后再依次给20%、50%、75%的用户使用新版本最后100%按照用户的业务属性灰度VIP优先等…
3、可回滚
就是想git一样可以把版本进行回退。 总结
1.在保证分区容错下无法同时做到一致性和可用性。系统设计时只能选择一个目标在P一定会出现的情况下A和C之间只能实现一个这就是CAP定理。
CP: 强一致性弱可用性牺性部分机器的可用性保证数据一致性如zookeeper、es、NaocsAP: 强可用性弱一致性牺牲一致性保证可用性如Eureka
2.可监控可灰度可回滚
