去年今日的杭州云故障不同
题都城南庄
去年今日此门中，人面桃花相映红。人面不知何处去，桃花依旧笑春风
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万字的故障原因、复盘结论、改善方法的报告。如果云厂商连商务上的鞠躬道歉都不会的话，要不要找个“鞠躬仙人”培训一下。