4月8日15点23分，腾讯云团队收到云API服务异常状态报警，随即，腾讯云工单、售后服务群、微博等渠道开始出现大量无法登录腾讯云控制台的客户反馈。
经过故障定位，我们发现客户无法登录控制台是因为云API异常。云API是云上统一的一套开放接口，客户可以通过API以编程方式管理和控制云资源。云控制台结合云API提供交互式的Web功能。
此次故障发生后，一些依赖云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服务全部恢复，但控制台流量剧增，容量扩大了9倍；
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等云服务的依赖，并引入缓存及容灾机制，确保在云服务发生故障时，故障信息能够准确、及时地传递。
