客户登录不上控制台正是由云API异常所导致，故障发生后，依赖云API提供产品能力的部分公有云服务。

　　也因为云API的异常出现了无法使用的情况，比如云函数、文字识别、微服务平台、音频内容安全、验证码等。

　　本次API升级过程中，由于新版本的接口协议发生了变化，在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常，导致生成了一条错误的配置数据，由于灰度机制不足导致异常数据快速扩散到了全网地域，造成整体API使用异常。

　　腾讯云称，发生故障后，按照标准回滚方案将服务后台和配置数据同时回滚到旧版本，并重启API后台服务，但此时因为承载API服务的容器平台也依赖API服务才能提供调度能力，即发生了循环依赖，导致服务无法自动拉起。

　　3.15:57，定位出故障根因是配置数据出现错误，紧急设计数据修复方案；4.16:02，对全地域进行数据修复工作，API服务逐地域恢复中；

　　6.16:25，定位到上海的技术组件存在API循环依赖问题，决定通过流量调度至其他地域来恢复；

　　7.16:45，观测到上海地域恢复了，此时API和依赖API的PaaS服务彻底恢复，但控制台流量剧增，按九倍容量进行了扩容；

　　8.16:50，请求量逐渐恢复到正常水平，业务稳定运行，控制台服务全部恢复；9.17:45，持续观察一小时，未发现问题，按预案处理过程完毕。

　　综合盘点这次故障，最根本的原因是在版本变更过程中，没有有效执行沙箱验证和预案演练，暴露了在变更管理上的不足，接下来将从以下几个方面快速进行改进和完善，以减少故障的影响范围和影响时长。

　　1、定期执行预定的变更策略模拟演练，确保在真实故障发生时，能够迅速切换到恢复模式，最小化服务中断时间。

　　2、优化服务部署架构，通过分层架构、代码审查和监控等手段， 避免API服务中潜在的循环依赖问题。

　　2、实施灰度发布策略，逐步推广新功能或配置更改，按集群、可用区、地域逐步生效，以便在发现问题时能够迅速回滚。

　　1、对故障处理流程进行全面升级，确保实时更新故障处理进度和预计恢复时间点，提升故障报告发布效率。

　　3、优化腾讯云健康状态看板（StatusPage）的信息展示逻辑，解除对云API等云服务的依赖，通过引入缓存和容灾机制，确保即使在云服务出现故障时，能准确、及时地传递故障信息。

　　对于腾讯云本次故障复盘及情况说明，有网友表示：“能对外公布过程，对用户透明，也是种进步”“有故障不可怕，关键是要能在故障中去真正总结、改进、沉淀，尽量做好下一次故障的规避和优化，这才是宝贵的经验和收获。”