去年今日的杭州云故障不同
题都城南庄
去年今日此门中,
人面桃花相映红。
人面不知何处去,
桃花依旧笑春风
1. 故地重游凑热点
去年杭州云的故障是天灾,一帮从未做过云计算的爱好者们,积极发言教育云厂商如何做云产品的监控状态页,我当时还写了篇文章《用信心应对云故障》,抽这些爱好者的耳光。因为面对单Region故障,这就是天灾,大客户该反思的是为什么没做多云冗余。
今年杭州(不仅是云)集团这情况肯定是人祸,能跨Region同时出故障的,只能是三种组件:计费、鉴权、一群产品逻辑依赖同一款产品。仔细想想,“计费”和“鉴权”也属于“一群产品逻辑依赖同一款产品”。这三种组件哪个暴雷,都会向社会输送几个年薪百万的人才……
以前我是不屑于凑热点的,但我的书快写好了,总得粉丝多一些、声量大一些,这样才好做广告啊。而且我做分析,总比那些云计算爱好者们更靠谱一些。
2. 去年今日故障性质不同
去年的故障是单节点的性能和稳定性问题,归根结底就是成本问题。无论客户怎么抱怨,云厂商是做生意的,不可能无限度追加投入资源。虽然外界阴谋论一大堆,但据说杭州云内部只是认栽,我觉得这挺好的,如果因为偶发故障而处分倒霉蛋,以后公司就没人敢省钱了。杭州云是业内风向标,他要是因为一次资源故障就不敢收缩节俭了,其他云厂商也得带到沟里去。
今年的故障,我c……“人面”不知何处去啊……脸真没了。
我那本书里有写,Region就是网络资源集合、AZ就是计算(和存储)资源集合。能出现同时跨越多个Region的故障,这事就和资源、成本没什么关系了,只能前文提到的三类故障——“计费、鉴权、一群产品逻辑依赖同一款产品”。
这种事确实挺倒霉的,因为这些服务一般只属于“辅助必选型云产品”,平时姥姥不疼舅舅不爱,公司也没多大的资源投入。但是再倒霉也得立正挨打,技术工程师就要承担技术工程师该承担的责任。
我本来写了1000字的故障可能性分析,但觉得真正故障原因没出来,不想装懂王。我就给大家找个乐子,这是《大萌1566》杨金水让李玄享受一把的配图,这幅图并不是要损那几个倒霉的工程师。我必须聊出这个梗头来,很多次故障死的都是背锅、点炮、拔橛、甚至是旁观看热闹的人。杨金水今天能卖了李玄,过几天他也得装疯啊。
3. 大客户也扛不住多节点群炸
去年的故障,我在我的文章里就明说了,没有一个大客户因为单节点故障而导致自己业务中断的。哪个IT大牛说自己的业务因为一个单点故障而中断了,其实是在自抽耳光,只能证明自己穷到做不起多云冗余,或者就是个不会做多云冗余的技术水货。
今天的故障估计会击穿一部分大客户,但这事我得给说个公道话,谁做多云冗余也很难想到一群节点集体炸雷。这种故障发生后,客户技术部门能快速把业务迁移走就是死里逃生了,都死里逃生了。客户的业务部门就别苛求业务不中断、数据不丢失了,即使你增加IT预算,也无法应对这种意外故障,逼技术团队也没用。
4. 杭州集团自己要不要跨云部署
今天的故障和去年有一个“重大且彻底”的不同。
损失最惨重的不是客户,最大的苦主是杭州云所属的集团业务。幸亏故障不是昨天发生的,否则都能上电视、惊动茶馆请你喝茶了。这也是我写此文反复隐晦的原因,那些用敏感词蹭流量的公众号,你们都不直到自己蹭的是哪一层敏感词。
这次故障带出的最大问题是,现在杭州云成了新的业务单点。我跟杭州云不多的交集,就是当年他们业务部门想跨云部署业务,结果被内部叫停了。随着这次故障出现,集团还不要100%上本家云?是应该切40%的负载到友商云,还是自己再建一个私有云出来?
如果切40%的负载到友商云,或者业务部门的技术团队再建一个私有云。我看来看去,那几个浓眉大眼的中立云就挺好的。看客们别说人家技术不行,人家就卖裸金属+vlan隔离+本地盘行不行?
但这样做的缺点是,马上要上市,为个业务稳定性就降几十亿营收……其实还有个方法,杭州云可能和友商换量,这边降了几十亿营收,你就再切几十亿自己的营收过来。
还有一些更鬼的联想我就不好明说了,万一切量给别的云,结果别的云jiagegengdi、fuwugenghao、nichuguzhangbierenbuchuguzhang怎么办?
想来想去,挺可惜也挺倒霉的,要是没这个故障,或者是友商出这个故障就好了。
5. 云厂商别再热情洋溢的写罪己诏了
我在书里吐槽了好几次,但快被编辑给删完了,我的原文就是这个意思:
云厂商向全社会公布自己的详细故障范围和详细故障原因,这真是吃饱了撑的……。云厂商既遇到过数据中心故障,也遇到过硬件供货延迟或者固件bug,你们见到过你们的供应商热情洋溢的写罪己诏吗?在客户来看,你们说的废话就是:
“对不起,客户,我昨天一不小心把你撞到粪坑里去了,我撞你的角度是xxx,事后我反思了xxx。我认错,我认罚,我在电话里自罚三杯哈哈哈……”
云厂商写详细的故障报告,大部分人根本就看不懂,只知道你们确实出故障了。当年雍正写《大义觉迷录》的目标是为了证明自己,结果吃瓜群众都笑出了哼哼声。特别是一些追热点的自媒体,你们说的内容越多,他们越能从内容中纠错,显摆自己是个高级技术专家。
云厂商对于故障的公开解释和回应,应该只说明故障时间和大致范围就够了,故障报告整体不超过100字就够了。客户需要从报告中确认故障时间和故障范围,吃瓜群众从这100字里也找不到任何继续炒作的梗头。
云厂商真正要做工作的地方,是给简要故障报告盖上公章,然后由销售带队去客户现场,带着10页ppt,用“活人的嘴(而非网络通告)”给客户讲1万字的故障原因、复盘结论、改善方法的报告。如果云厂商连商务上的鞠躬道歉都不会的话,要不要找个“鞠躬仙人”培训一下。