2024-04-08 腾讯云API服务故障解析复盘
简介
2024年04月08日15:23，腾讯云团队收到监控告警，出现大面积登录不了腾讯云控制台故障。腾讯云4月8日故障复盘及情况说明
影响
依赖云API服务的部分公有云服务无法使用，比如云函数、文字识别、微服务平台、音频内容安全、验证码等。此次故障一共持续了近87分钟，期间共有1957个客户报障。
根因
- 本次API升级过程中，由于新版本的接口协议发生了变化，在后台发布新版本之后对于旧版本前端传来的数据处理逻辑异常，导致生成了一条错误的配置数据，由于灰度机制不足导致异常数据快速扩散到了全网地域，造成整体API使用异常。
- 发生故障后，按照标准回滚方案将服务后台和配置数据同时回滚到旧版本，并重启API后台服务，但此时因为承载API服务的容器平台也依赖API服务才能提供调度能力，即发生了循环依赖，导致服务无法自动拉起。通过运维手工启动方式才使API服务重启，完成整个故障恢复。
故障修复
- 15:23 监测到故障，立即执行服务的恢复，同时进行原因的排查；
- 15:47 发现通过回滚版本没能完全恢复服务，进一步定位问题；
- 15:57 定位出故障根因是配置数据出现错误，紧急设计数据修复方案；
- 16:02 对全地域进行数据修复工作，API服务逐地域恢复中；
- 16:05 观测到除上海外的地域API服务均已恢复，进一步定位上海地域的恢复问题；
- 16:25 定位到上海的技术组件存在API循环依赖问题，决定通过流量调度至其他地域来恢复；
- 16:45 观测到上海地域恢复了，此时API和依赖API的PaaS服务彻底恢复，但控制台流量剧增，按九倍容量进行了扩容；
- 16:50 请求量逐渐恢复到正常水平，业务稳定运行，控制台服务全部恢复；
- 17:45 持续观察一小时，未发现问题，按预案处理过程完毕。
预防措施
官方虽然给出了后续的改进措施，但根据作者的一些理解，改进还远远不够。下面是作者的一些思索：
- 灰度验证 完善灰度验证策略，后续所有的变更均应该在预发环境或者沙箱环境对变更内容进行严格验证。实施灰度发布策略，逐步推广新功能或配置更改，按集群、可用区、地域逐步生效，以便在发现问题时能够迅速回滚。引入异常自动熔断机制，当检测到系统异常时，能够立即中断变更过程。
- 循环依赖 优化服务部署架构，通过分层架构、代码审查和监控等手段，避免API服务中潜在的循环依赖问题。
- 故障注入 定期执行预定的变更策略模拟演练，确保在真实故障发生时，能够迅速切换到恢复模式，最小化服务中断时间
- 统一架构 所有集群，可用区，地域在技术架构上应保持一致。
- API 前后兼容性 无论是版本升级或回退都应该考虑API兼容性，避免因数据处理不一致导致整个集群不可用。如2023年滴滴机房故障，根因kubernetes 升级到新版本后，又不慎部署了旧版本导致数据处理不兼容最终所有容器重建。