1. 配额限制

每种云上的资源，能用多少是有限制的。

这是云厂为了防止资源滥用，降低租户之间的相互影响。

比如，一个账户下的企业项目数、弹性主机的数量、弹性公网 IP 的数量、弹性公网 IP 带宽的大小等。

因配额不够导致的资源申请失败，很常见；但在弹性业务高峰期，这个问题就会变得很严重。

如果是自己开发了控制平面，内部的云管平台，尤其要注意这些配额限制，做好监控。

2. 共享导致的性能问题

云厂有些资源区分独享和共享，共享的价格比独享的便宜很多。

很多时候，我们出于成本考虑选择了共享的资源，但却给自己挖了一个坑。

华为云的共享负载均衡开启性能保障模式后，提供并发连接数 5 万、每秒新建连接数 5000、每秒查询数 5000 的保障能力。如果超过这个限制，业务侧就会报错。

共享类的资源都可能出现类似的问题，SLA 无法保障，或者性能无法保障。

3. 资源强制升级

云厂为了修复版本漏洞、跟进新特性，会强制升级一些资源。

云厂的强制升级，通常是热更新，会提前通知使用方，但使用方不一定会关注。

强制升级其实是一个负责任的行为，需要使用方持续投入精力跟进，但使用方往往会忽略这个事情，认为其吃力不讨好。

海外的厂商，比如 AWS 就会强制升级 RDS 等数据库，这些数据库的升级，会导致数据库闪断，短时间内无法访问。而 EKS 的升级，是通过替换底层的 EC2 实例来实现的，又非常的平稳。

关注云厂的通知，积极干预、主动升级比被动升级要好很多。

4. 云厂之间的参数差异

不同于自建的基础设施，整齐划一，云厂的基础设施参数、配置差异很大。

比如，重启华为云主机之后，NetworkManager 会覆盖 /etc/resolv.conf 中的 DNS 配置。这其实是配置 DNS 的地方不对所致，但在其他云厂却没碰到这个问题。

再比如 AWS 支持巨型帧，MTU 可以设置为 9001，但华为云不支持。

建议自定义基础设施的配置，而不是依赖云厂的默认配置，包括网络、存储、安全组、基础镜像等。事前圈定好这些配置，比事后对齐配置要好很多。

5. 云厂硬件故障

如果你是大客户，很有可能会经常收到类似这样的提示:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

尊敬的xxx用户：
您好！您账号下xxx区以下RabbitMQ实例由于底层物理机故障，需要迁移
影响：长连接1/3闪断，部分未及时消费消息丢失。
辛苦知悉。实例信息如下：
UID: xxx
Region: xxx
产品: RABBITMQ_GROUP
有归属项目的实例:
项目名称： 默认项目
   实例ID: xxxx
   实例名称:
   子类型：xxx

云厂经常会出硬件故障，AWS 尤其多，机器实在太旧了。虽然云厂做了冗余和热迁移，但发生时，并不能保证 100% 不受影响，业务会有感知。

在选择资源规格时，如果能选多 AZ 就选多 AZ，如果能选多 Region 就选多 Region。核心业务要用钱和冗余换稳定性。

6. 云厂软件故障

云厂的代码也是人写的，有人的地方就有 BUG。

这是近期一个事故的报告:

1
2
3

故障根本原因: 代码缺陷。

触发场景: 创建弹性伸缩组活动时，需要下发云主机信息、实例创建、查询实例信息以及同步 ES。由于这个过程耗时过长导致写入 Redis 数据的时间晚于伸缩组中 5 台云主机的创建完成时间(多个接口耗时偏高，累加效果导致整体耗时超出预期)。 控制台收到云平台开机完成消息后，处理弹性伸缩组逻辑时需从 Redis 获取对应信息...

云厂的态度很好，但是不解决问题，只能尽量减少类似事件。越是非头部厂商，软件问题可能会越多。

建立起对云厂功能的 SLO 指标，对于核心的功能，直接影响业务稳定性的功能要建立监控、告警体系，即时发现、即时反馈给云厂干预解决，否则等业务有问题，事情就变得很紧急了。

7. 欠费导致无法新建云资源

想不到吧，还有因为欠费导致无法新建云资源的坑。欠费不影响已有资源，但是影响新建资源。

我就经过过两次因欠费导致无法新建云资源的事件，一次是国内的账户，一次是海外的账户，海外入账周期比较长。

云厂商提前一晚通知，3，4，5月账单未支付，目前 xxx 账号已欠费，目前我们商务这边已经在申请信用额度扩容了，需要等2天；

第二天就因为欠费，导致弹性扩容失败，整个上午大家都在催公司打款、催云厂扩充信用额度、转移业务流量。挺浪费运维人力。

公对公的对账周期长，很容易出现欠费的情况，无上限增加信用额度肯定是不可行的。每次欠费都让云厂紧急处理，会降低云厂对你的服务质量。

建议和公司财务、云厂协商好，按期付款，信用额度能支持一个周期就好。如果厂商有催款通知，不要拖欠赶紧打款。

8. 云厂变更时，人为操作失误

缓存服务失联，相关的服务全都异常。云厂解释，搬运其他设备时，同时误操作了线上的四台核心交换机。

“同时关四台核心交换机”，无论是不是外包干的，都是云厂流程上极大地失误。

不多久，另外一个云厂也是因为人为操作失误，导致了大面积的服务不可用。

原因是，在修改一个带宽配置时，本来是 40Gbps 修改为 50Gbps，但是操作人员误操作，修改为 5Gbps，导致了大面积的服务不可用。

云厂的这些解释非常离谱，但也不排除他们在掩盖一些更低级的失误。