中立分析腾讯云故障相关的事件

最近腾讯云的故障，让一堆云计算爱好者兴奋地远看指点江山、近看沐猴而冠。我比这群爱好者们更了解云计算，但是我尊重我的读者，你们从我这里看到的科普信息，不仅仅只有情绪价值。

在信息爆炸的时代，大家关注和信任某个媒体，媒体作者就应该帮读者筛选出更可信、更有学习意义的信息。本文的前两章内容解释清楚了故障范围，中间两章介绍IaaS和PaaS的产品分类是有意义的；最后的部分是希望读者们少看点口嗨新闻、少嚼点陈年烂梗。

本文的目录为：

1. 我拿到的故障现象

2. 实际故障范围不大

3. 感谢老铁的PaaS云证据

4. 客户该做多云冗余

5. 口嗨新闻没有用途

6. 陈年烂梗之服务状态页

7. 陈年烂梗之系统盘丢数据

---

1. 我拿到的故障现象

首先，无论哪次云厂商故障，我都是先找真实的故障现象，然后才有资格发表意见。我从个人渠道确认，也看了腾讯云的公开通告，本次的故障现象就是API系统崩了，导致一堆PaaS云产品业务中断了。

• API控制面大范围故障，比如控制台、云函数、微服务、文字识别、验证码等等服务都出现了严重的业务中断。

• 不依赖API的数据面业务未出现故障，比如运行中的云主机、VPC、云磁盘等等。

• 使用独立API系统的对象存储没受影响，CDN下载和直播客户端拉流不需要鉴权也不会受影响，大型视频客户有预授权额度也不受影响。

本次故障的发生时间很重要，公告里承认是15点20分发生故障，16点大部分恢复，有一个上海疑难节点拖到17点恢复。这种故障最大的伤害是无法使用API做查询和变更，本次故障的时间段客户很少有业务变更，让客户业务侥幸躲过了大部分故障，大部分客户是被控制台故障和API监控失败惊吓和误导了。

在腾讯云的公开通告中发布了一张“全云流量趋势图”，此图也可以作为参考佐证，从此图可以推测出，10-18点的客户需求非常稳定，相比其他时段，客户较少有调整资源的需求。

---

2. 实际故障范围不大

这次云故障似乎是“天塌地陷的危险”外加“万众瞩目的狂欢”，但这只是读者的错觉，这种故障对腾讯云的舆论影响比真实业务影响更大。

• 首先，因为本次故障不涉及数据面，运行中的云主机、容器、云磁盘、VPC等IaaS云产品，并没有受到影响。

• 其次，虽然IaaS云产品的管控功能会因故障而中断，极大地影响了客户的弹性伸缩需求，但是故障时间是15-16点（或严谨说是15-17点），用户一般不会在该时间段大规模申请和释放资源。

• 再次，CDN可以绕过大部分鉴权故障，因为HTTP下载和直播拉流（客户端观看）都不需要鉴权。大客户做主播端推流也是设置批量并发额度，不超过额度也不会调用鉴权API，而15-17点不会出现业务量超额的情况。

• 最后，这故障最大的影响是控制台和API系统。控制台故障报错，会吓到用户；API鉴权失败会导致客户的监控系统大批量误报，可能会因为误报而触发不必要的业务迁移。

本次故障主要影响的是CDN强制更新缓存、以及每次开播都鉴权的小视频客户。这次故障会导致“云函数、微服务”等计算类PaaS产品彻底停摆，各大云厂商的长期目标也是推广这几类计算型PaaS云产品，但是，这类产品现在还没有那么大的产品影响力，其最大的价值就是让开发者拿来学习实践。

对象存储使用了独立的鉴权系统，并不受故障影响。腾讯云的公开通告中提及，对象存储的调用次数趋势，在15-16点有目测10%的下跌，这并不是说对象存储也存在服务中断，而是被其他业务的故障牵连导致轻微用量下降；那些坚持没跌的90%存储调用次数，更是在证明大量的客户业务依旧正常工作。

---

3. 感谢老铁的PaaS云证据

这次腾讯云的故障和去年的杭州云故障，都让我体验到了一种“感谢道友，以死帮我证道”的舒爽，我给他们做辟谣科普，也是在验证我坚持的道理：

云厂商对IaaS云和PaaS云产品做分类，不是为了概念炒作，而是对产品设计、技术实现、客户包装乃至故障炸窝都有指导意义。我的新书《云计算行业进阶指南》（审批完结，在走印刷流程）有一个章节专门介绍IaaS和PaaS的分类方法，IaaS云产品以“规格和能力上限”为计量单位，PaaS云产品以“软件可识别的用户行为次数”为计量单位。

当云产品遭遇API系统崩溃（或者鉴权异常）故障时，因为IaaS云产品只需要API来管控业务变更，而PaaS云产品的每一个业务步骤都需要经过API系统，这导致两类产品的故障表现存在明显差异。

但是，我也需要硬核证据来证明我的主张有可信度。半年内两次典型又知名的云故障，几乎就是按照我对PaaS云产品的定义做定向爆破。上次我为了表示感激之情，公开给杭州云写辟谣文章，这次我也要公开给腾讯云做一次辟谣。

---

4. 客户该做多云冗余

没有不出故障的云产品，但客户业务部门不允许本司技术部门以“云厂商出故障”为理由中断业务服务。客户技术部门只能在故障发生前做好冗余设计，在故障发生时有快速切换预案，这才是最理性务实的选择。

在客户做云服务监控和多云冗余的工作中，IaaS和PaaS云产品也有明显的差异。

• IaaS云可以通过AZ（可用区)来实现云内故障隔离，但PaaS云产品没有AZ的概念，这让客户只能用多云冗余来规避PaaS云产品故障。

• IaaS云向云厂商开放了大量的监控信息，但PaaS云只露出简单的API接口，这让客户很难对PaaS云产品的真实可靠性做监控。

• IaaS云做业务迁移有复杂的步骤，但PaaS云的业务迁移很容易，甚至可以将多云切换的权限下放给客户端SDK。

客户并不太关PaaS云产品的后台技术说明和故障改进规划，因为客户没有任何鉴定和监控手段，各种故障后的复盘悔改，都只是无法证伪的商务礼仪。各种对PaaS云产品的“头脑风暴+环境设定+思维博弈”读起来很爽，但实际上毫无价值，客户做好PaaS云产品的多云冗余才是唯一可信的保障。

---

5. 口嗨新闻没有用途

每次云厂商故障，很多云计算爱好者都兴奋的像在过年。云厂商出故障了应该被嘲笑，但各位读者看这些口嗨新闻能获得什么有用途的信息哪？这些口嗨新闻里到处都是空洞的“劲爆和焦虑”，但是这些爱好者连故障现象都说不清楚，还会影响读者对现象和本质的判断。

这些口嗨新闻只是一个舆情事件，并不会影响到云厂商的销售经营。这些偶发故障只会影响这两周内的新客户签单测试的过程，并会导致极少数专业小客户迁移到友商云（然后等促销或者友商出故障时再切回来）。

云计算从业者无法从那些口嗨文章中学到任何技术建议，因为脱离实际生产环境的口嗨是没有价值的。IaaS云产品的生产环境相对雷同，所以IaaS技术的精进方向还有趋同进化，但是PaaS云产品并没有统一的技术路线。

计算机工程师也无法从这些口嗨新闻中学会任何解题思路，反而会产生“我行我也想上”的浮躁情绪。云厂商每次出故障，我都会做上一段时间头脑风暴，想想有哪些改进方案。但我从不公开发表意见当懂王，因为在架空环境里谈IT技术方案，这是在炫耀自己的无知。

---

6. 陈年烂梗之服务状态页

因为云计算爱好者们写口嗨新闻时知识储备匮乏，他们骂云厂商翻来覆去就那么几个事。这其中第一个烂梗是，服务健康状态页，这个烂梗很缺德。

每当云厂商出故障时，就会有云计算爱好者谈“云厂商怎么都不做服务健康状态页面”。我并不认可这种产品建议，先谈一下大致原因：

• - 各产品线有自己的API状态接口，如果客户没用好产品线自己的状态查询接口，这是包装培训问题不是产品设计问题。

• - 如果你是客户的技术工程师，你会如何使用这个汇总状态页？这是个轻度参考还是重度依据？乱加内容是在增加客户的用云难度。

• - 现在有个多产品线公摊的API和鉴权认证系统，就已经频繁出现全平台故障了；再新增个多产品线共同维护的状态页，是嫌弃误报漏报还不够多吗？

•  - 状态页面不是什么新功能，2014年就有友商大肆宣传这个功能了。但无论灯塔云还是国内云，都是没有客户使用，才导致这个功能逐渐荒废了。

我并不反感朋友们给云厂商提出的善意建议；我也不反对云厂商再去折腾一下这个荒废功能，“缓解客户的质疑焦虑”也是一种产品效果；我甚至不反感爱好者们反复呱噪这个状态页，因为这在证明他们的无知。但我明确说，做状态页就是在敷衍孩子。各位读者别老看各种《云厂商居然不知道做个状态页》的呼吁文，这种呼吁没有价值，你们应该找找有没有人写出过《亲身实践！使用服务健康状态页的实战心得》。

我真正反感的是，一些云计算爱好者在写口嗨文章时，“裹胁式引用”一些善意的建议。你们和云厂商吵架博出位，是自己愿意承担对应的敌视风险的。但你们在恶意骂战的语境下，反复大喊“某某大佬也提出过相同的建议”，这就是强行拉旁观者站队，让旁观者善意且随口提出的建议， 变成了你们和云厂商吵架时的证据。这样做真得很缺德，也容易没朋友。

---

7. 陈年烂梗之系统盘丢数据

因为云计算爱好者们写口嗨新闻时不了解历史事件，他们骂云厂商翻来覆去就那么几个事。这其中另一个陈年烂梗是，前Y数控丢数据。

每当爱好者们提到这个陈年烂梗时，似乎在和“可怜的客户”同呼吸共命运。但这个烂梗里根本就不存在客户，爱好者们每次提这个烂梗，都是给前Y数控增加被倒查深扒的风险。

腾讯云当年最大的失误不是丢系统盘的数据，而是公开故障细节给看客们找攻击挑刺的谈资。我是真佩服这个前Y数控，既要毁了自己的融资渠道，也要毁了自己技术团队的声誉，就为了“按闹分配+试试运气”。

• * 一个IT科技公司连续八个月才消费3569元，请问他能买多少云资源开展业务？我在2016年就开始教风投们如何解析IT类创业团队的资源采购账单了，就这种用云量信息，能找到IT技术圈的投资吗？（依稀记得，这是一家大数据技术公司，重要数据都放在腾讯云上，但网上已经搜不到该公司的详细信息了）。

• * 一个技术创业企业，将价值上千万的核心数据放在系统盘里，还没任何备份。这个工程师和CTO的履历上，敢明着写上这一段“给公司创收”的神奇经验吗？

• * 2018年云厂商丢系统盘的数据，有什么值得大惊小怪的？在2018年，即是AWS的EC2，也不保证系统盘不丢数据，而是建议客户将数据存在云盘或者对象存储。

我们当然为腾讯云的遭遇而感到幸灾乐祸，因为“这么弱鸡的理由居然能成功碰瓷……”。但我不会和坑蒙拐骗的行为共情，盲目带入身份、病态换位思考都是心智不健全的表现。本来这个什么数控公司已经安然撤退了，但这些云计算爱好者们如获至宝的反复提及此事，这实际是在坑谁哪？