六天前，4 月 8 日下午，腾讯云出现服务故障，控制台出现无法响应的情况。该“大瓜”迅速在各个技术一线吃瓜群扩散开来，在技术圈引起了较大的关注和广泛的讨论。故障持续了近 100 分钟，给不少使用腾讯云产品的公司带来了较大的影响。今天，腾讯云官方发布了《腾讯云 4 月 8 日故障复盘及情况说明》，较为详细的描述了当时的具体情况。
以下是《腾讯云 4 月 8 日故障复盘及情况说明》正文：
4月8日15点23分，腾讯云团队收到告警信息，云API服务处于异常状态；随即在腾讯云工单、售后服务群以及微博等渠道开始大量出现腾讯云控制台登录不上的客户反馈。经过故障定位发现，客户登录不上控制台正是由云API异常所导致。云API是云上统一的开放接口集合，客户可以通过API以编程方式管理和操控云端资源，云控制台通过组合云API提供交互式的网页功能。故障发生后，依赖云API提供产品能力的部分公有云服务，也因为云API的异常出现了无法使用的情况，比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近87分钟，期间共有1957个客户报障。从客户的视角来看，云服务大概可以分为数据面和控制面，数据面承载客户自身的业务，控制面负责操作云上不同产品。比如目前使用最广泛的IaaS服务基本上都是以直接面向数据面为主，控制面仅在客户购买或需要对资源层面进行调整操作时会涉及。此次发生故障的控制台和云API是对控制面的影响。![]()
通俗来讲，如果把云服务类比为酒店，控制台相当于酒店的前台，是一个统一的服务入口。一旦酒店前台发生故障，会导致入住、续住等管理能力不可用，但已入住的客房不受影响。这次故障中客户已经配置好的服务器等IaaS资源，包括已经部署运行的业务，没有受到云API异常的影响。其他以非云 API 方式提供服务的PaaS和SaaS服务，处于正常服务的状态。从数据上也验证了这一点。如图1显示，当天全产品进出流量趋势没有明显变化。但是，用API提供的服务类产品（需要“酒店前台服务“）有不同程度的影响，比如腾讯云存储服务调用当天有明显下滑。期间售后团队协助部分客户做了业务容灾预案的实施，将受影响服务做调度以快速恢复客户的业务服务。从图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等云服务的依赖，通过引入缓存和容灾机制，确保即使在云服务出现故障时，能准确、及时地传递故障信息。
以上就是腾讯云官方说明全文。看得出来腾讯的这份事故报告写的还是有诚意的，较为详细的复盘了当时的情况。至少没有用“网络故障”这种万金油理由来搪塞和敷衍用户，一定程度上做的了对用户透明，在态度上，这一点是值得鼓励的。
毕竟，我个人认为官方只需要做好赔偿和解释工作，其实也不用对外发布这样的一个说明（不知道有没有来自上面的压力）。“云上走路”真的很难，尤其是这种直面大规模客户的“云产品”，一点点小小的问题，都会有引发舆情的可能，更别说这种大规模的故障了，舆情那是立马就来。
反正，就是心疼一下相关条线的产品、开发、测试同学吧。
![]()
·············· END ··············
推荐👍：高手过招的杀手锏，了解一下？
推荐👍：你只管打开，然后剩下的交给收藏夹。
推荐👍：准备去大厂和刚去大厂的，全文背诵，常看常新。
推荐👍：线程池参数请不要这样设置。
推荐👍：一个普通程序员磕磕绊绊，又闪闪发光的十年。
你好呀，我是歪歪。我没进过一线大厂，没创过业，也没写过书，更不是技术专家，所以也没有什么亮眼的title。
当年高考，随缘调剂到了某二本院校计算机专业。纯属误打误撞，进入程序员的行列，之后开始了运气爆棚的程序员之路。
说起程序员之路还是有点意思，可以点击蓝字，查看我的程序员之路。