首页
下载应用
提交文章
关于我们
🔥 热搜 🔥
1
1
2
1'"
3
百度
4
习近平
5
百度傻逼
6
@纽约时间
7
上海
8
@诉说趣闻
9
bxss.me
10
../1
分类
社会
娱乐
国际
人权
科技
经济
其它
首页
下载应用
提交文章
关于我们
🔥
热搜
🔥
1
1
2
1'"
3
百度
4
习近平
5
百度傻逼
6
@纽约时间
7
上海
8
@诉说趣闻
9
bxss.me
10
../1
分类
社会
娱乐
国际
人权
科技
经济
其它
故意按摩让女生“产生欲望”后发生关系,算性侵吗?
洗牌电商圈!阿哲放话全网:挑战抖音所有机制!爆全品类大牌!
阿哲现身评论区,@一修!肉肉痛哭,无限期停播!回应舆论黑料,关闭私信评论区!
登热榜!某牙电母被S,榜一求爱遭拒!柚柚阿哲合体年度走红毯!
小敏感喊话阿哲,出镜抖音!欠钱不还,小白龙再被扒借贷官司!
生成图片,分享到微信朋友圈
4月14日 下午 6:20
4月14日 下午 6:40
4月15日 上午 6:50
4月15日 下午 7:00
4月16日 上午 7:10
4月16日 下午 7:20
4月17日 上午 7:30
4月17日 下午 7:40
4月18日 上午 7:50
4月18日 下午 8:00
4月19日 上午 8:10
4月19日 下午 8:20
查看原文
其他
腾讯云4月8日故障复盘及情况说明
腾讯云
2024-04-14
4月
8日15点23分,腾讯云团队收到告警信息,云API服务处于异常状态;随即在腾讯云工单、售后服务群以及微博等渠道开始大量出现腾讯云控制台登录不上的
客户
反馈。
经过故障定位发现,客户登录不上控制台正是由云API异常所导致。云API是云上统一的开放接口集合,客户可以通过API以编程方式管理和操控云端资源,云控制台通过组合云API提供交互式的网页功能。
故障发生后,依赖云API提供产品能力的部分公有云服务,也因为云API的异常出现了无法使用的情况,比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近87分钟,期间共有1957个客户报障。
从客户的视角来看,云服务大概可以分为数据面和控制面,数据面承载客户自身的业务,控制面负责操作云上不同产品。比如目前使用最广泛的IaaS服务基本上都是以直接面向数据面为主,控制面仅在客户购买或需要对资源层面进行调整操作时会涉及。此次发生故障的控制台和云API是对控制面的影响。
通俗来讲,如果把云服务类比为酒店,控制台相当于酒店的前台,是一个统一的服务入口。一旦酒店前台发生故障,会导致入住、续住等管理能力不可用,但已入住的客房不受影响。
这次故障中客户已经配置好的服务器等IaaS资源,包括已经部署运行的业务,没有受到云API异常的影响。其他以非云 API 方式提供服务的PaaS和SaaS服务,处于正常服务的状态。从数据上也验证了这一点。如图1显示,当天全产品进出流量趋势没有明显变化。
图 1:腾讯云全产品进出流量趋势图
但是,用API提供的服务类产品(需要“酒店前台服务“)有不同程度的影响,比如腾讯云存储服务调用当天有明显下
滑。期间售后团队协助部分客户做了业务容灾预案的实施,将受影响服务做调度以快速恢复客户的业务服务。从图2可以看出,当天存储服务调
用有一个明显的波动。
图 2:存储服务调用数据趋势图
问题复盘
整个处理过程如下:
1. 15:23,监测到故障,立即执行服务的恢复,同时进行原因的排查;
2. 15:47,发现通过回滚版本没能完全恢复服务,进一步定位问题;
3. 15:57,定位出故障根因是配置数据出现错误,紧急设计数据修复方案;
4. 16:02,对全地域进行数据修复工作,API服务逐地域恢复中;
5. 16:05,观测到除上海外的地域API服务均已恢复,进一步定位上海地域的恢复问题;
6. 16:25,定位到上海的技术组件存在API循环依赖问题,决定通过流量调度至其他地域来恢复;
7. 16:45,观测到上海地域恢复了,此时API和依赖API的PaaS服务彻底恢复,但控制台流量剧增,按九倍容量进行了扩容;
8. 16:50,请求量逐渐恢复到正常水平,业务稳定运行,控制台服务全部恢复;
9. 17:45,持续观察一小时,未发现问题,按预案处理过程完毕。
故障的原因是云API服务新版本向前兼容性考虑不够和配置数据灰度机制不足的问题。
本次API升级过程中,由于新版本的接口协议发生了变化,在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常,导致生成了一条错误的配置数据,由于灰度机制不足导致异常数据快速扩散到了全网地域,造成整体API使用异常。
发生故障后,按照标准回滚方案将服务后台和配置数据同时回滚到旧版本,并重启API后台服务,但此时因为承载API服务的容器平台也依赖API服务才能提供调度能力,即发生了循环依赖,导致服务无法自动拉起。通过运维手工启动方式才使API服务重启,完成整个故障恢复。
改进措施
综合盘点这次故障,最根本的原因是在版本变更过程中,没有有效执行沙箱验证和预案演练,暴露了在变更管理上的不足,接下来将从以下几个方面快速进行改进和完善,以减少故障的影响范围和影响时长。
第一,提升系统韧性
1、定期执行预定的变更策略模拟演练,确保在真实故障发生时,能够迅速切换到恢复模式,最小化服务中断时间。
2、优化服务部署架构,通过分层架构、代码审查和监控等手段, 避免API服务中潜在的循环依赖问题。
3、提供API服务逃生通道,当故障发生时,可供调用方快速切换。
第二,强化变更管理与保护措施
1、完善自动化测试用例库,在系统变更前通过沙箱环境对变更内容进行严格验证。
2、实施灰度发布策略,逐步推广新功能或配置更改,按集群、可用区、地域逐步生效,以便在发现问题时能够迅速回滚。
3、引入异常自动熔断机制,当检测到系统异常时,能够立即中断变更过程。
第三,增强故障响应与沟通能力
1、对故障处理流程进行全面升级,确保实时更新故障处理进度和预计恢复时间点,提升故障报告发布效率。
2、在对外发布的故障通知中,清晰阐述受影响的业务范围、故障根因及预计修复时长,保持透明度。
3、优化腾讯云健康状态看板(StatusPage)的信息展示逻辑,解除对云API等云服务的依赖,通过引入缓存和容灾机制,确保即使在云服务出现故障时,能准确、及时地传递故障信息。
继续滑动看下一个
轻触阅读原文
腾讯云
向上滑动看下一个
您可能也对以下帖子感兴趣
{{{title}}}
文章有问题?点此查看未经处理的缓存