SRE 实践:服务可靠性案例课
白园
前百度资深运维专家,前快手资深 SRE 专家
1271 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已更新 16 讲/共 29 讲
SRE 实践:服务可靠性案例课
15
15
1.0x
00:00/00:00
登录|注册

13|变更场景(三): 连续绊倒两个云厂商的故障

你好,我是白园。接下来我们进入变更的第三个场景——程序和数据类型的变更。今天我就来给你分享一种非常有意思的故障,这种故障连续绊倒了两个云厂商。

故障回顾

2024 年 4 月 8 日,某云团队收到告警信息,云 API 服务处于异常状态。随即在某云工单、售后服务群以及微博等渠道开始大量出现某云控制台登录不上的客户反馈。经过故障定位发现,客户登录不上控制台是由于云 API 异常导致的。云 API 是云上统一的开放接口集合,客户可以通过 API 以编程方式管理和操控云端资源。
故障发生后,依赖云 API 提供产品能力的部分公有云服务,也因为云 API 的异常出现了无法使用的情况,比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近 87 分钟,期间共有 1957 个客户报障。
同样的事情也发生在另一家云上,不过是在 2023 年,云产品控制台访问及管控 API 调用出现异常。原因代码的逻辑缺陷,生成了一份不完整的白名单,进而影响了整个云 API 服务。

案例解析

原因解析

故障的原因是云 API 服务新版本向前兼容性考虑不够,以及配置数据灰度机制不足的问题。本次 API 升级过程中,由于新版本的接口协议发生了变化,在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常,导致生成了一条错误的配置数据,由于灰度机制不足导致异常数据快速扩散到了全网地域,造成整体 API 使用异常。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
  • 解释
  • 总结

1. 故障回顾:连续绊倒两个云厂商的故障,导致云API异常,影响了大量客户和公有云服务。 2. 原因解析:故障的原因是云API服务新版本向前兼容性考虑不够,以及配置数据灰度机制不足的问题。 3. 问题解析:缺失的检查机制、数据隔离策略不足、循环依赖问题、升级与回滚问题等。 4. 优化措施:预防数据格式错误、控制上线影响、提升恢复速度等方面的优化建议。 5. 值得学习的地方:故障通知的透明度和及时性,以及故障处理流程的完整性和决策思考。 6. 思考题:执行顺序和学习别人的案例如何应用到自己的业务上的思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实践:服务可靠性案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 若水清菡
    回答如你需要进行配置变更、代码发布、数据更新,那么你的执行顺序是什么?这个问题,从工作经验上来说: 首先要确认依赖关系,一般情况下数据更新不会去改变数据原始的结构,更新难度最低,可以放到最后更新。配置变更和代码发布依赖较多,经常需要对配置数据进行热更新,加一些参数或者减少一些参数都需要代码层面去支持。这样考虑下来最好的更新顺序就是:先代码更新(提供对新老配置和数据的兼容),然后是配置更新,数据更新;后期的数据patch更新,会先更新数据,后更新配置。
    2024-08-12归属地:北京
收起评论
大纲
固定大纲
故障回顾
案例解析
原因解析
显示
设置
留言
1
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部