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

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

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

本文的目录为:

  1. 我拿到的故障现象

  2. 实际故障范围不大

  3. 感谢老铁的PaaS云证据

  4. 客户该做多云冗余

  5. 口嗨新闻没有用途

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

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

1bb3de7f1901d60123877c053a13a117.gif


1. 我拿到的故障现象

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

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

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

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

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

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

136f164a7d71eff85c029a6ad16ade01.png


2. 实际故障范围不大

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

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

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

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

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

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

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

bffafe18ce157d62072788ee241b1cec.png


3. 感谢老铁的PaaS云证据

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

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

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

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

df23dc26e1b88bc6f39bd8742badfc3d.png


4. 客户该做多云冗余

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

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

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

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

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

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

4b3971721812a3bc53ff5a9b192f2600.gif


5. 口嗨新闻没有用途

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

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

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

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

ccc67a69974e106c5a4683d5b3939d9b.gif


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

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

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

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

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

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

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

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

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

b0c9ca8fac453419c30fe07c4a89e5e8.gif


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

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

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

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

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

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

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

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

fc283a7e38dc60fdad908caf2ba2fef7.jpeg

  • 12
    点赞
  • 29
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值