# 云问题复盘



## 1. 云服务和云控制台

我们可以把云服务类比为酒店服务，云厂商就像是一个大型酒店集团，在不同的城市都提供着相同服务水准的酒店，包含一系列从最基本的住宿、饮食到洗衣、叫车等全套服务。

云控制台是用户用于购买和调整云服务的网页入口，包含了页面上的各种交互和以云API方式调用不同产品。按照酒店的类比，它就相当于酒店的前台，是一个统一的服务入口，用户可以找前台办理入住、续住和点餐，但也不是所有的服务都需要通过前台来完成，比如用户只需要通过开好的房卡就能进入房间（计算），可以把行李放在衣柜（存储），也可以自己打车回到或离开酒店（网络）。我们可以大概把这两类服务分为控制面和数据面。

从容灾的角度来说，云服务提供的是两个维度的隔离，一是地域之间的隔离，二是控制面和数据面的隔离。

（图）

云上目前使用最广泛的IaaS服务基本上都是以数据面为主，控制面只有在购买和一些对资源层面进行调整的操作才会涉及，PaaS和SaaS根据不同的产品形态，有些更偏数据面，有些更偏控制面。

（数据）

一般来说，数据面故障要大于控制面故障，多地域故障要大于单地域故障，历史上机房掉电、骨干网络拥塞导致的用户业务中断是最常见的顶级故障。

## 2. 问题复盘

4月8日15点23分，腾讯云监测系统监测到云API处于异常状态，从而影响到整个控制台的正常使用；同一时间，腾讯云工单服务系统、售后服务群以及微博等渠道上，开始出现大量腾讯云控制台登录不上的用户反馈。故障一共持续了87分钟，期间共有1957个客户报障。由于对数据面没有影响，从流量角度复盘，腾讯云部分依赖云API的产品流量略有下降，整体保持平稳。（TODO：补充受影响产品占比和评价）

整个处理过程如下：

1. 15:23, 监测到故障。
2. 15:47, 回滚版本未解决问题。
3. 15:57, 工程师定位到问题原因，开始制定恢复方案。
4. 16:00, 除上海以外其它地域全部恢复。
5. 16:45, 处理完大量积压请求后，上海地域恢复。故障彻底恢复。
6. 17:45, 持续观察一小时，未发现问题，处理过程完毕。

（TODO：仅示意，待明确）问题原因是云API统一数据组件在持续运行了xxx天之后积累的数据量超出了底层缓存的存储空间，在缓存淘汰策略上有一个按时间排序丢失的bug，导致最新数据无法使用并扩散到全网各地域，从而造成全地域的控制面故障。



## 3. 改进措施

这次云API故障导致全地域控制台无法访问虽然未影响到数据面，大部分存量用户业务稳定运行，但对于用户的操作、新购以及依赖云API传输数据、AI产品功能等都有全地域的影响，仍然造成了很大的用户伤害和口碑影响。

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

第一，快速制定完善的变更机制，持续执行变更预案演练，确保故障发生后能快速恢复。

第二，全面升级故障处理系统。及时更新处理进展和预计恢复时间，在故障公告中及时向客户同步故障影响范围、故障原因和恢复时间。解除腾讯云健康状态看板（StatusPage）对云 API 的依赖，增加缓存容灾机制，确保故障信息发布不受云服务故障影响。

第三，严格执行变更标准，所有变更都先经沙箱环境验证，严格执行灰度发布和异常自动熔断，保障变更问题的及时发现和阻断。