有故障的才是云平台
前言 躲热点真不容易
我不凑热议性新闻的热闹，习惯按照自己的节奏发文章，但朋友圈里热点尬聊看多了，我就有给泼一盆科普冷水的冲动。
最近云平台故障挺多的，阿里云故障完了，我想等两周再发本文，结果AWS美国挂了；AWS的热议刚刚消停，企鹅家也遭灾了；现在又等了五天了，我觉得不算凑热点了吧。
第一. 这是新闻不是丑闻
当某朵云故障时，我看到了太多从业者弹冠相庆，幻想着友商遭灾了就能白捡到个大单。但友商出故障这类事是新闻不是丑闻，客户不会为一次故障而放弃现有供应商。
这些年来，那么多数据中心都出过大量故障，有断电的、挖断光缆的、空调故障的、被封网的、DDOS打瘫痪的，有哪个IDC因为故障被迫退出市场的？ 标准IDC的SLA标准是电力99.99%，网络99.9%，断网1分钟IDC就会出故障报告，但断网八个小时也不会赔客户一分钱。客户很着急也谩骂，但故障只要不频繁发生谁敢触发服务器迁移，大部分只能自认倒霉。
第二. 云平台的可靠性
IaaS云平台就是在模拟数据中心、传统硬件和系统网络架构，这三大块可靠性都不太高。云上虚拟资源因为可以灵活调度，可靠性稍微提升了一点点。云厂商的云主机和公网IP的SLA承诺是99.95%，但其可用性定义和赔偿标准都比传统IDC精明。
对于大型企业客户来说，过去不信赖单一IDC，不依赖单台服务器，不跪拜单个网络，现在也不相信单一云平台可以做出100%的SLA承诺。
既然云平台还会出故障，客户就要做好多云采购和多云冗余，在技术实现上只会比多机房容灾更简单——因为云厂商比IDC更能深度服务客户。
第三. 要尊重企业客户
我在多篇文章中反复强调，云平台做不到100%高可用。我不介意说的刻薄露骨一点：
技术投机分子对个人站长和移动端开发者的欺骗该结束了，现在友商是系统架构师，买主也是技术部负责人。
OpenStack等云技术的早期步道者，很多都是既不了解Dev也不深入OPS的“冒险家”，因为无知，所以无畏啊。
前几年云用户都是APP创业者，云厂商一口一个“开发者”叫的很甜蜜，但又不停的忽悠人家。现在的采购决策人是老牌技术总监和架构师，知道从硬件到应用的一系列高可用该怎么定义怎么实现。
厂商最典型的就是各种吹9大赛，好多厂商都说产品的SLA是无数个“99.99999999...%”。
列这么多9到标书上很浪费油墨的，不如解释清楚服务可用性和数据持久性的区别。
这故障几率比第三次世界大战、恐龙复活、爱上外星人、宇宙湮灭的几率都小了；我没见过外星人，但云厂商故障见到一堆了。
对于企业客户来说，单台云主机的可用性到99.95%就超出期望值了，客户自己会把到群集可用性提高到99.999%。
第四. 无法忍受的服务态度
对于企业客户来说，客观技术故障是意料之中的，但涉及到服务部分就无法忍受了。
云平台出故障了不主动通报，而是让客户自己猜。云服务有虚拟化层，如果只是缓慢不是中断的故障该怎么猜？
对于故障时间、持续范围、故障原因都说不清楚或刻意隐瞒，该认错的时候不清晰，是想让客户技术团队背锅吗？
客户永远看不到真实故障原因，但明显的人为故障，明显的资源不足，明显的管理混乱，明显的胡编乱造都在削弱客户的信心。
云平台误导了客户的冗余策略，比如两个可用区依赖同一个网络出口或供电局。
有些文盲写出的报告在教育和指导客户，商务语气不对等，该担责任时却在甩锅。
第五. 危险背后总有新机遇
我一直很看好云计算这个行业，纵然它杂草丛生野蛮生长，但也生机盎然活力无限。从云平台的故障乱象，我们一样能看到新机遇。
现在选购云平台的决策人不会被苛责，五年前业务系统上云出故障了，决策人是要承担很重责任的，现在上不上云只是一种常规选型，不是技术冒险了。
多云冗余备份不仅仅是弱势云厂商的机遇，也是客户技术团队的机遇。过去客户要自己做应用冗余备份，工作复杂责任也重大，现在只要预算不太低，客户只做个心明眼亮的架构师，脏活累活都是云厂商来做，遇到敬业的云厂商还能担下大部分故障责任。
扩展阅读 附录：
去年春节Gitlab出故障，我发到花姐的公众号，核心观点至今不变《当云服务也不靠谱之后——云生态视角看Gitlab事件》。
每次故障都是机遇，解释的合理合情就好《危险背后的机遇--云服务故障危机分析》 。
云平台的客户已经变了，不只是开发者，更多是企业用户《中国云计算现状-6.客户篇》。