网站建设课程报告,自定义网站建设团队,a站是哪个app,2023年8月新闻热点事件大家好#xff0c;我是洋子
最近语雀不是出了个号称 “载入史册” 的 P0 级事故嘛 —— 连续宕机接近8个小时无法使用#xff0c;作为一个大厂知名产品#xff0c;这个修复速度属实让人无法理解 故障公告原文#xff1a;https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMc…大家好我是洋子
最近语雀不是出了个号称 “载入史册” 的 P0 级事故嘛 —— 连续宕机接近8个小时无法使用作为一个大厂知名产品这个修复速度属实让人无法理解 故障公告原文https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw 很快官方就发布了《故障公告》。有一说一这个公告写得还是挺不错的按照时间线梳理出了各时间节点的处理过程
14:07 数据存储运维团队收到监控系统报警定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线14:15 联系硬件团队尝试将下线机器重新上线15:00 确认因存储系统使用的机器类别较老无法直接操作上线立即调整恢复方案为从备份系统中恢复存储数据15:10 开始新建存储系统从备份中开始恢复数据由于语雀数据量庞大此过程历时较长19:00 完成数据恢复同时为保障数据完整性在完成恢复后用时 2 个小时进行数据校验21:00 存储系统通过完整性校验开始和语雀团队联调。22:00 恢复语雀全部服务用户所有数据均未丢失。 在改进措施一栏中先不说具备两地三中心的高可用能力洋子发现了9个核心关键字可监控可灰度可回滚可以说是维持系统可用性的最基本的保命措施
先举个例子讲一下这三种能力的用处
可灰度
将系统的新版本全量部署给所有用户之前先仅对一小部分用户进行试用。这样可以通过收集这部分用户的反馈和监控数据就能评估新版本的稳定性并及时进行调整和修复从而减少对全体用户的潜在风险。
灰度发布又有很多策略。比如经典的按流量阶段性发布先随机给 5% 的用户使用新版本验证没问题后再给 20%、50%、75% 的用户使用新版本逐渐放量直到覆盖 100% 的用户。
还有很多策略列举几个常见的
1按照用户的业务属性灰度比如 VIP 用户先用、老用户先用。
2按人群灰度比如特定地域、特定年龄、特定偏好、特定客户端的用户。
3按渠道灰度比如通过某平台注册的用户先体验等等。
灰度做的好可以避免很多线上问题及时控制影响。因此很多知名产品发布时都会采用灰度或者内测的策略这也就是为什么有些同学能第一时间体验到微信新功能有些同学却没有
可监控
可监控是指能够实时地收集和展示系统运行时的数据和指标以便开发和运维同学可以及时发现系统问题、更快进行故障排查和性能调优。需要监控的信息可以包括系统性能指标内存、CPU、带宽等、业务日志、错误信息等。
可回滚
线上系统出现问题时可以将已经部署的新版本回退到之前的稳定版本。这样做可以快速恢复系统减少对用户的影响并给开发同学足够的时间来排查和修复问题
如果我们的系统具备这样的能力按照一般的研发测试流程在我们测试完成测试后如果是服务端则进入上线阶段如果是客户端则进入发版阶段。在上线和发版阶段一般来说都是需要先进去一个小流量的范围先影响一小部分用户若期间测试验证没有问题则扩大范围直到全量这就是灰度发布的意思如果灰度期间有监控报警则可以及时回滚止损回退到线上的历史版本避免影响线上用户
如果我们的系统不具备这样的灰度的能力一方面只能一次性推全新版本看起来省了不少事但一旦出现问题影响线上的全部用户。如果没有监控出现问题后我们无法第一时间及时感知只能被动等着线上用户来反馈问题。如果没有回滚能力有Bug只能等着再次上线修复也会拉长造成影响的时间
语雀作为阿里旗下的产品有千万级用户的体量内部不应该没有这样的监控平台、灰度发布和部署管理平台总之令人匪夷所思另外这次Bug的原因是由于运维工具有Bug是否经过充分的测试该不会又有个小同学背锅了
最后面对这样超级严重的事故我想说一定要牢记先止损先止损语雀给的赔偿方案还是比较有诚意的直接给六个月会员用语雀的小伙伴可以去领取了
