危险背后的机遇--云服务故障危机分析
前言
云计算是一种服务，服务不仅要一次性验收其服务能力，还要持续关注其服务品质。客户用IaaS云服务就跟用IDC一样，用谁家的云就知道谁家有故障，用一家就知道一家的短处才是正常，只有前一个厂商烂到无可救药，客户才会对新厂商充满认可和感激。
本文的目的就是归类IaaS云故障的表层现象和深层原因，客户知道云服务的短板才好做系统设计，云厂商出故障也要老实认错，别总把客户当外行来糊弄。
至于PaaS云和IaaS云的设计实现思路完全不同，不在本文讨论范围内。
客户的感知和建议
IaaS云的核心资源是云主机，其他IaaS资源都是依附于云主机的；云主机的可靠性略高于物理机，但并不是云主机永不宕机。
只要云主机采购量稍微上规模，云主机用户总会遇到一些故障。请谅解和忘记供应商的营销话述，云主机用户必须自己在架构设计层面规避这些故障。
网络抖动
现在云平台已经都用SDN组网，SDN本质是“软件定义网络”，其主打卖点是灵活管理和控制，其性能和稳定性并不是主打方向，SDN软件的质量也要略差与于传统厂商。云平台都会有网络IO超卖复用，而且用服务器CPU软解海量报文，其性能还是比传统网络略差的。云用户做架构设计时，建议通过开更多节点的方式分散单节点网络压力。
硬件故障
硬件故障无法彻底避免，依附于物理硬件的云主机也会意外中断。云主机可以在计划内跨硬件迁移，所以可以说云主机可靠性略高于物理机。但是云厂商可能买劣质资源，或者频繁迁移云主机，甚至后台操作误停机误删除，以前用物理机客户自运维的各种故障点依然存在。理论上云平台技术人员会很专业和敬业，但很难深入了解客户业务。云用户以前的硬件冗余设计仍然有效，而且可以利用多AZ/多region/多云等云上隔离方案。
资源不足
云资源的隔离不彻底且会超卖，带来了瞬时资源不足问题。比如说云主机突然变慢又恢复，导致客户的业务异常崩溃，云用户缺乏有效的监控手段，可能会想不到故障和云资源有关，或者无论什么问题都让云平台自证清白。
资源不足还会影响新建资源，很多DevOPS客户自动化申请资源，但如果账户配额不足或者区域资源不足，自动申请资源失败时有备选方案或者人工干预吗？
以前客户只要观测公网接入资源是否紧缺，自控硬件和内网的信息很清楚，上云以后硬件和内网也要多留心了。
软件BUG
相比客户自己粗选一个物理机的OS，云主机精选的虚拟机OS、宿主OS、Hypervisor的软件BUG并不多，大中型云厂商都有精选底层支撑软件的实力，但客户装物理机自选的OS都可能有驱动问题，三个精选软件的故障率真没一个粗选软件更高。
但是从云资源的管理、调度、监控软件，到客户界面，API管理、账户和后台策略层面，越往上走的软件质量还不如XXXX，此处省略一万五千字，客户自己揣摩吧。
厂商深层原因
厂商报故障就跟滚刀肉挨揍一样，脸疼了就把屁股凑过来，屁股疼了就捏捏脸，一般不会按住一只羊使劲薅羊毛，毕竟云报障也要负载均衡。但客户自己心里要有秆秤，厂商究竟是偶尔发挥失常还是烂泥扶不上墙，故障的性质对长久的服务品质很重要。
我列一下潜在的故障原因，哪些故障能忍，哪些故障不能忍，这些要云客户自己评估了。
技术原因
IaaS服务的核心主体功能（云主机、云硬盘、VPC），在没有特型要求前提下，是可以用开源方案搭建。如果是云厂商连个开源平台标准模块都部署失败，那就该换厂商了；如果是偶发的BUG，那确实客户要自认倒霉，因为友商也会遇到同样问题。
现在容易出问题的是云平台的运营维护和云厂商的自定义管理模块，客户就是缺合格运维才被逼上的云平台，但云厂商自己也缺人；在软件BUG这一部分我已经吐槽过做云平台外延模块程序员的技能水平了。这些地方出了问题该投诉投诉、该索赔索赔，逼着客户去招更敬业专业的工程师。
资源投入
云资源贩售过程中，合格的厂商可以让云资源物有所值，但巧妇难为无米之炊，原始资源投入不够云服务就不可能很稳定。面向中小客户的时候，云厂商很忌讳透露具体硬件成本，也尽量避免承认资源不足，但面对大客户时会很坦诚。
作为持久共生的大甲方，请关注乙方的成本红线，买家永远没有卖家精。如果甲方给够钱了，乙方仍然用劣质硬件IDC和过高超售比，小云厂商一般是老板带头节俭，而大云厂商很可能是执行层的人弄错了，作为甲方该闹就要闹。
人为原因
云厂商的人为故障总是糊涂账，但细心的甲方是能看出来端倪的。有时候厂商想遮蔽技术和资源的问题，会说是人为原因，缓过这一次故障赶紧修订BUG和准备资源；有时候明明是人为原因，但人为故障都是打脸实锤，厂商脸会肿而且要赔偿，可能会找个其他原因来给脸部降降温。
对于落实是人为导致的故障，甲方单纯的索赔追责并不能解决问题，因为云厂商总是比甲方的实际损失更小，甲方无法触及云厂商能倒腾出故障的部门。甲方只能根据云厂商销售和服务线的能力和态度，确认自己交钱了能否买到靠谱的服务。
最重是商誉
云计算既是资源又是服务，资源相对可以量化，但服务短期内看直观感受，长期看商业信誉。商誉分为企业商誉和个人商誉，云厂商的企业商誉都积淀不足，胜者也是比烂大赛中靠友商更烂胜出的，和IDC/CDN的比优大赛无法相提并论。大客户在吃够了厂商的亏以后，会选择信任能有个人商誉，能做出承诺、调动资源和平复问题的销售和服务人员。
有个客户非常信任某个小云销售，他告诉该销售，虽然某大云有高层合作，某大云也说报价肯定比某小云低5%；但是某大云的服务机制有问题，出故障从来都是衙门话，每次故障都要客户去乱猜和背锅。最终这个单子在客户执行层的暗助之下，该小云快速把业务切过来并坐实站住了，这份暗中相助就是靠个人商誉带来的信任。
我和大客户谈故障的时候，喜欢把详细故障原因刨析给客户，企业客户是讲道理的，不要把糊弄ToC用户的手段来对付ToB客户。面对意外故障，我们有信心向客户证明，换了其他厂商也一样会挂；面对人为故障，踏实认错是对客户的最后尊重，而公开事实也是逼着内部不会重蹈覆辙犯同样的错误。
过去大家卖IDC、CDN、服务器和软硬件积累的个人商誉，是可以应用到云计算领域的。而云服务的高科技光环褪去、产品同质化以后，企业的核心竞争力仍然是有商誉的销售-售前-售后团队，这类人才永远是稀缺资源。
附录
请各位多琢磨评估本厂的云服务到底哪些组件是靠谱的，不要让信赖你的客户受伤又受骗。如要学习云计算相关知识，可以多关注我往期云计算文章，比如说
云计算最重要的工作是配合销售和服务客户： 云客户需求引导管理--实战型IT太极拳
中国云计算现状系列汇总：
做云计算要花哪些钱，请看第一篇成本篇，原创链接。
云计算产品各有什么特色该如何分类，请看第二篇产品篇，原创链接
客户的采购人员如何看云计算，厂商如何锁定采购人员需求，请看第三篇采购篇，原创连接。
如果我们想吸引优质销售该做哪些配合？
时无英雄使竖子成名，但这也是机遇， 看云厂商花式作死的九种方法。