我通读了一遍，感觉整体结构和内容已经非常清晰了，考虑到读者对背景可能不是很了解，我有几个吹毛求疵的建议 1. 第一部分，“腾讯云控制台”可能不便理解，容易误解为整个腾讯云，最好像对API的解释一样，类似于“腾讯云控制台是用户用于购买、调整腾讯云产品的网页入口，它包装云API来实现对云产品的操作”，着重强调“网页”和“入口”，为后面不影响数据面做铺垫。或者是直接跟云API的解释结合到一起，控制台是前台，API是服务员。 2. 第二部分，“工程师定位到API故障是由一条管理系统同步过来的错误数据导致的，工程师随即对全网错误数据进行修复，删除错误数据”会不会显得错误太简单，如果能增加难度描述会让故障不那么随意，比如“由于海量的请求导致的自增id溢出”。当然这里还是以客观事实为准 3. 第三部分，可以先介绍一下云计算的容灾设计，包括地域隔离和控制面/数据面隔离，然后可以说首先我们的故障对数据面是完全不影响的，所以绝大部分云上业务是运行稳定的，影响的只是当时需要对控制面进行操作的场景，其次因为地域隔离，除上海以外，其它地域的影响时长也远小于整体故障时长。客户业务自己容灾的部分，个人认为没大必要讲。 **4月8日故障复盘及情况说明** 第一部分

4月8日15点23分，腾讯云监测系统监测到腾讯云云API产品服务处于异常状态；同一时间，腾讯云工单服务系统、售后服务群以及微博等渠道上，开始出现大量腾讯云控制台登录不上的用户反馈。 工程师经过故障定位发现，用户登录不上控制台正是由云API异常所导致。除了造成客户登录不上控制台外，工程师还发现部分通过云API调用来提供服务的公有云产品，也因为云API的异常出现了无法调用的情况，比如云函数、 NAT 网关、微服务平台、 音频内容安全、验证码等。 经过进一步定位确认，客户已经配置好的服务器等IaaS 资源，包括已经部署运行的业务，没有受到云API异常的影响。其他不依赖云 API 的 PaaS 和 SaaS服务，也处于正常服务的状态。 腾讯云控制台是用户用于购买和调整云服务的网页入口，技术上使用云API构建的，而云API是一种接口协议，它允许软件通过调用API接口对基础资源进行操作。可以将控制台比喻成酒店的前台，云API是服务员，当服务员（云API）停工时，依赖服务员的服务（包括前台）会受到影响（控制台服务中断，对云API有依赖的服务受到影响），但不影响已入住的客户正常使用房间，一些不依赖服务员的服务也不受影响（基础资源以及其他不依赖云API的服务不受到影响，比如服务器和存储服务）。 故障一共持续了87分钟，期间共有1957个客户报障。经过我们从流量角度复盘，腾讯云部分依赖云API的产品流量略有下降，整体保持平稳。 存储服务上传次数趋势图 [[unknown.png]] 腾讯云服务进出流量趋势图 [[unknown 1.png]]

第二部分 发现问题后，工程师按照预案进行快速处置，一部分人分析原因，另外一部分人采用回滚的方式优先让系统恢复正常。 大约15点47分，控制台所在集群回滚完成，监测系统显示，API恢复正常。 15点57，工程师定位到API故障是由一条管理系统同步过来的异常数据导致的，随即对全网异常数据进行修复。 大约3分钟后，除了上海集群之外所有的API服务恢复正常，工程师立即采用流量切换的方式，将整个上海集群切换至其他集群，优先恢复服务，同时继续排查原因。 后面排查出在上海集群之所以不正常是因为上海集群在回滚期间存在API 循环依赖，导致执行卡住，使得回滚和后续的数据修复动作都未能恢复服务。 16点45，上海集群的问题得到解决，上海集群的流量整体切换回去，API服务完全恢复正常。 在故障发生后，涉及API调用的云服务，比如云函数、验证码是在逐步恢复的，但用户的感知可能并不同步，这与API服务故障叠加了控制台故障有一定关系。 工程师在回滚了控制台相关集群之后，控制台的API服务已经恢复正常，但由于之前的累积和叠加的访问需求，控制台访问量过大出现过载，工程师随即以三倍预留资源进行扩容，让控制台访问正常。 不过控制台短暂恢复后，再次被流量冲垮，最后由工程师介入完成扩容动作。 至此，云服务完全恢复正常。 第三部分

云计算故障根据发生的原因可以大致分为三类，云底层基础设施故障、云上软件故障，以及上层业务故障。 第一类云基础设施出现故障主要包括IDC机房、机房内的服务器、可用区内外部的网络等出现故障，比如数据中心断电、通信光缆被挖断、服务器宕机等，这类问题虽然影响面较大，但是一般可以通过多可用区、热迁移、流量调度等技术进行应对。 第二类是在基础设施之上的软件层面出现故障，包括IaaS、PaaS等软件的不可用，比如数据库、操作系统、大数据等软件故障，架构设计出现bug，导致基础支撑平台的连续性受到影响，和第一类故障相比，这类故障一般影响范围大，修复难度也相对较大； 第三类主要指的是上层业务故障，这背后主要是业务上如何基于云多可用区，甚至跨云的特性来做好业务连续性方案。 这次云API故障主要是第二类故障。经过复盘主要原因是：云 API 团队发布一个管理端的特性，发布过程中，旧版本的前端系统在对数据进行变更的时候，导致新版本的后端写入了一条错误数据，该数据经同步机制扩散到现网服务节点后，导致进程异常退出，从而引发云 API 故障，并导致关联的控制台服务不可用。 综合盘点这次故障，最根本的原因是在数据变更过程中，没有有效执行沙箱验证和灰度发布，暴露了在变更管理上的不足，接下来将从以下几个方面快速进行改进和完善。 第一，快速制定完善的变更机制，持续执行变更预案演练，确保故障发生后能快速恢复。 第二，全面升级故障处理系统。及时更新处理进展和预计恢复时间，在故障公告中及时向客户同步故障影响范围、故障原因和恢复时间。解除腾讯云健康状态看板（StatusPage）对云 API 的依赖，增加缓存容灾机制，确保故障信息发布不受云服务故障影响。 第三，严格执行变更标准，所有变更都先经沙箱环境验证，严格执行灰度发布和异常自动熔断，保障变更问题的及时发现和阻断。

在客户服务过程中，我们也看到了使用不同类型服务的用户的受影响情况。荣耀的大数据融合桶、海外SNS因为API故障受到影响，售后通知客户后通过COS及时逃生、SNS切走业务恢复；杭州微拍堂，售后主动通知客户后，客户把短信登录业务在故障期间切走，在故障恢复后回切；库洛看到公告和传闻很紧张，过来询问并自检，因未使用API依赖服务客户确认业务无影响；大部分客户以使用IaaS产品为主，在API故障期间没有受到影响。