用信心应对云故障

1. 本文缘由

我写公众号的目的是技能和观点的长期分享，所以我从不追任何行业热点，而是习惯在事后总结和验证过去已发表的观点。

本文是从一些类似IOE年代的toB行业常识角度分析，当客户面对故障时的心态和云厂商该有的宣传角度，文末又对最新故障进展谈了一下个人看法。

这次A云深圳南郊节点出故障，满足了广大toB爱好者指点江山的诉求；但A云周日刚出的故障报告，又让我对本文有些犹豫和删改。

• 从观众们热情的建议倡导来看，就算他们是合格的toB代码贡献者，他们也做不好云计算或者类似“以工程师为操作用户的企业IT服务”行业。按照他们的思维方式和建议方法，云行业的产品设计、市场宣传和客户运营工作都要走到沟里去。

• 我的原文大意是“A云平稳过关，客户就是倒霉”，最早本文标题是《客户喊疼不如多云冗余》。但看完他家的故障报告，本来我担心别人误会我是收费发了挽尊软文，现在我这文章像个黑稿，我连夜把厂商名称和地点故障都改成代称了。

2. 故障不影响云厂商

这种层次的故障对事主A云就没多大影响，对友商倒是有点好影响。

2.1 云厂商只要承认故障的时间和影响范围，并按照合同承诺支付了客户赔偿，那么云厂商在商业信誉和合法合规上就没有任何瑕疵。

• ToC场景可以很感性说客户都是上帝，客户感受很重要；但toB场景下，企业客户买云服务只是买一种普通的原材料，供应商和客户是平等的交换。几年前云厂商因为不成熟，还喜欢大包大揽的忽悠客户同时忽悠自己，但现在云厂商已经很务实了。

• 这么说云客户比较难难以接受，那我拿云厂商和自己的供应商之间打交道举个例子：假设某云为开设新节点采购了一批服务器，但服务器供应商拖延交货20天，该云的机架和带宽都开始计费了，客户业务也受到了影响。云厂商只有50%的概率可以拒收这批延期服务器，更不可能让服务器厂商赔偿机架带宽空置的损失。

2.2 每次大型云平台出故障，网上都会哀鸿遍野，似乎天塌地陷一样，但实际上这种故障，对于大客户真不是多大事，对于小客户是一种无奈。

• 本次故障发生后，各种互联网大厂中厂都快速完成了节点切换，没有什么大厂发故障导致业务降级的通告。这种级别的故障，也就是让甲方执行工程师加加班，大型甲方的技术总监没受到多大的KPI威胁，还对公司内部秀了一把本团队的技术实力。

• 大型甲方并不断定A云会继续出故障，也不相信其他云能彻底规避故障，甲方技术将业务切走还是迁回，仅仅是一个应激执行行为，并不会上升到品牌信任的高度。

• 明星创业者搭便车蹭流量是正常反应，但一些“技术大牛”在这次故障中抱怨业务受损，其实是在自毁人设自砸招牌。作为技术大牛不应该不懂多云冗余和容灾备份，你们是暴露自己眼高手低到缺乏常识技能，还是囊中羞涩到没钱做冗余？

• 小客户和普通开发者确实就没能力做多云冗余，但他们更不愿意做换云迁移啊。这次故障后，70%的小客户还会留在出过故障的云平台，另外30%的小客户流失很可惜，但是这种损失很疼却不致命。

2.3 国内A云或者国际A云出故障，对于各种云友商是好消息，但这个好消息不是说友商踩踏友商，而是云厂商热情的建议客户做多云互备。

• 遇到规模更大、信誉更好的标杆云友商出故障，这对于云厂商是个死道友不死贫道的好消息。但是大家要想清楚一点，死的这个道友不是云厂商，而是“那个选择单云的甲方”。

• 客户不做多云互备，那就是客户的IT预算太少、技术实力太差或者决策人执行人过于懒惰。平时各云的销售只能委婉的提醒客户“天命不可知”，稍微花点钱做个多云互备吧！这下拿到真实案例了，立马变成“天命不可违”，申请点预算做个多云冗余吧！

3.  云故障时看甲方内部

云计算是“以工程师为操作用户的企业IT服务”，云厂商做客情关系分析和日常运营博弈，不能将其视为整体，而是必须区分“甲方业务部门”、“甲方采购部门”“甲方技术总监”“甲方技术执行人”四个角色的立场态度。

讲究点的“甲方业务部门”，都不允许“本司技术部门”以“云厂商或者其他供应商出故障”为理由中断服务。

讲究点的“甲方技术部门”，都喜欢通过权威供应商的适度故障，要求“本司业务部门”或者“追加预算”或者“降低要求”。

• 大型企业里的业务部门根本不关注云供应商，他们“只想也只会”收拾自家技术部门。比如说：云厂商有故障干我什么事？云厂商有故障，你们技术那么好，为什么不提前发现早做准备，为什么不帮人家解决一下哪？

• 权威供应商的拒绝服务和限制反馈，这是甲方技术部门能反击自家业务部门，要求追加资源和人力预算的机会。我在多篇文章中都写明了，云厂商要有意识的通过拒绝服务和合理的故障解释，给甲方技术团队争取福利和生存空间。

• 无论是故障还是其他工作，云厂商们经常会莫名其妙的孝感动天就跪下了，但磕头的理由啼笑皆非物我两忘，让甲方技术团队在内部博弈中被坑的够呛。

• 当年IOE在国内故障并不少，小型机会死机、存储会锁死只读、数据库要打热补丁，但是toB大客户根本就没有因此骂过IOE，甚至IOE卖的越贵、态度越傲慢，客户心里就越踏实。无论最早是哪个部门抠门省钱不批预算，客户业务部门在故障后都会狠骂给公司省钱的技术部门。

4. 故障报告要赢回信心

企业客户看企业级IT服务供应商（如企业级软件、IDC、公有云、集成商）的故障报告，看的就是信心而非真相。大客户根本不关心A云到底出的什么故障，他们只是需要一个继续待在A云的理由，否则只能做业务迁移。

4.1 首先，外部就不可能看到故障的全局真相。IT技术跨专业领域，外行客户和吃瓜群众就看不懂；就算友商提供以拆台为目的专业分析，IT技术涉及现场资源状态，非本项目组就没人知道实情。

• 无论是甲方采购、甲方业务还是大部分工程师，他们能看懂云故障报告的逻辑合理性就不错了，不可能深究真实故障原因。

• 说直白点，云厂商自己内部做追责复盘也是欺软怕硬，谁是元凶谁是陪绑，可能只有当事人本人清楚，领导和其他产品线也只能看个逻辑和理性。

• 我刚在群聊里劝一些想借本故障学习机房制冷系统切换演练的计算机工程师：别学了，学不会也没必要。就算组织次机房演练，你们全程都看不懂他们在干吗，只能盲目信任演练结果；而且你们又不能做日常监控，万一这些演练专家是兼职顾问，制冷设备是按日租赁明天就归还哪？

4.2 企业客户也讲道理讲逻辑，业务、采购和技术部门都可以接受“天灾”“钱灾”“技术灾”这类故障，这些故障不会影响客户信心。

• 所谓天灾，就是甲方认可的各种不可抗力，比如地震火山泥石流，比如战争和制裁，比如主管部门政策调整和运营商策略调整，早年间挖掘机也算一种天灾。

• 所谓钱灾，云厂商不可能无视成本做冗余灾备，各种罕见事件相互叠加，最终凑成了倒霉的故障。客户甚至会安慰自己，这些无法预料的故障也就很难重演，不可能天天运气这么差。

• 所谓技术灾就比前两者虚一些了，云厂商遇到了公认超级技术难题，导致出现了大范围故障。因为客户缺乏权威技术评估能力，此时主要看友商敢不敢大包大揽的承诺，客户才能确定能否容忍技术灾。

4.3 企业客户的业务、采购和技术部门都能听懂，而且且很难接受一些和能力态度有关的故障原因，最终因此降低对某些云厂商的信心。

• 战略和管理混乱，最典型的例子就是云厂商带着自我感动的耻辱裸奔。前些年云厂商企业宣传不成熟，某云花钱请人宣传自己是疯子、某云请同一批人宣传自己是傻子、某云请同一批人宣传自己是土鳖。企业内部搞文化建设的话述，拿来给跟toB客户做正式宣传合适吗，客户是感动还是惶恐哪？

• 缺乏资源总量，其本质是这个云厂商有没有实力承担客户业务。公有云的主力营收和服务基础都离不开数据中心和硬件资源投入，对技术专家的挖掘和挽留也属于资源的一部分。无论云厂商是没实力还是没意愿为云平台投入资源，客户就会对这朵云丧失信心。

• 提供劣势资源，其本质就是“店家给食客用了地沟油”。这里还有两个分支判断，分支一是云厂商供应链鉴别能力太差，花真钱买了假资源，分支二是云厂商自己的盈利模式不对，就是没舍得花钱买高质量资源，就喜欢用低质量资源来糊弄糊弄，这两个分支一样臭。

• 缺乏承诺和执行能力，就是云厂商敢不敢清晰承诺，能不能做到言必信行必果，这是各种用户对服务者的共同要求。云厂商拒绝客户的需求客户都不会生气，但云厂商模模糊糊承诺、黏黏糊糊执行，客户看到这个云厂商就会心烦。

5. 别做健康检查页面

这次故障中，很多热心观众都一拍大腿提建议，为什么不增加个“服务状态健康检查Status Page页面”？声势浩大到让故障报告里都特别做了回应。观棋不语真君子，这种建议真的是只有热情而已。

• 面对“不用论证需求迫切性”“可以随意解释演绎”的“功能加法”，云产品经理想怎么编就怎么编；基层云研发也很开心，调用接口拼接字符串多简单？感谢吃瓜群众，让他们找回了云开荒期那种闭着眼睛就能编写工作周报和晋升材料的舒爽感觉。但是羊毛出在羊身上，云产品成本高不降价，客户可要为此买单啊。

5.1 首先不能客户要什么我们就给什么，到底谁是云计算产品专家？企业客户信任尊重云厂商的基础，在于云厂商远超企业客户的产研专业性。

• 云厂商可以将不合理的客户需求解释后踢回去，也可以将甲方合理需求深化细化，甲方都会因此更加尊重云厂商。

• 如果客户提个什么要求，傻呵呵的供应商就无脑照办，反而会导致客户深刻的鄙视，客户拍大腿都能想到的需求，专业的供应商凭什么想不到，或者想到了但没排上优先级快速执行？

5.2 任何想提供商业服务的云产品，总要有个需求细化、可行性评估和预设使用方法。云厂商轻率的一个“Status Page”状态页面出来，既不能完整覆盖客户需求，技术上又容易错报漏报，客户技术部门还会因为“没有掌握云平台功能”而挨骂。

• 这个状态页是只要说明平台总体正常，还是细化到每一个UDP连接都做异常分析？现有的云服务API里，各种状态设定、信息采集和异常处理，能不能覆盖“服务状态查询需求”，是这些API缺乏应有功能，还是早就有功能但客户使用困难？

• 我们要做风险评估，添加的服务状态页，是否会给云厂商和云用户带来泄密风险？比如某大客户就在深圳南郊节点，突然增加了20G带宽，是不是这个大客户搞促销庆典了？客户的友商很可能拿着这些监控信息，把这个大客户具体参加促销的人数都摸清楚。

• 但凡正经做过几年监控，就知道写个单薄的checkXXX.jsp的误报漏报抖动和延迟显示的概率有多高。OpenStack也有doctor服务不停的模拟用户操作，经常操作失败报错，但处理这类故障信息的是云平台维护人员，不能让客户莫名其妙的发愁。

• 最重要的是，云厂商添加一个服务状态页的目的是让客户怎么使用？如果对接DevOPS，这个状态页自己是否可靠，是否会有延迟、误报和漏报，是否会导致DevOPS脚本误判？如果这个状态页的目的是让甲方工程师不停的用肉眼去看，那为什么不强化云平台现有的售后通知体系？

• 云平台做出来这种功能，并不会提高平台稳定性，只能被理解成“我已通知”的推托和免责。客户技术工程师需要也已经掌握各种产品查询API，但没必要掌握这个“无标准自定义”+“生僻”+“重复”的“Status Page”页面功能。甲方工程师学这玩意儿不可能升职加薪少干活，这个页面只会让他们在故障复盘时被业务骂的更彻底，还没理由转嫁压力到云平台。

5.3 从解释“Status Page”是个吃瓜群众而非业内人士的角度，我也能提供三条信息。

• 第一，国内某云在2014年就做过服务状态页，当初也有几篇PR稿一顿猛吹，我们也将其当做先进经验认真学习，然后就没什么市场和用户反响了，某云的那个页面现在还能正常打开。

• 第二，A云的公开故障报告也给了答复，默认用IM聊天工具和站内公告通知客户，早就有“Status Page”但内容刷新不及时，尽快上线新版页面。这就是一个已经实证很久没客户使用的功能，而且果然有我前文猜测的可靠性问题。

• 第三，很多人虽然对国内国外云都不太了解，但特别推崇境外灯塔云。我想知道为什么没人指责“国内云还没照抄”或者“国内云抄都没抄对”？因为有前两条信息打脸在前，我不敢说灯塔云没做过类似的产品，但灯塔云肯定没力推过健康状态页面。

6. 最新报告的隐忧

在看到周日发布的故障报告之前，我特别担心本文误会是收费发挽尊软文，但我看到故障报告以后，我有点担心这篇文章被理解成黑稿。

这个故障报告公开的原因是“机房制冷系统+消防系统”有严重故障，就正好碰到我前文4.3提到的，客户各部门都能听懂、客户各部门都很难接受的“提供劣质资源”。

• 提供劣势资源，其本质就是“店家给食客用了地沟油”。这里还有两个分支判断，分支一是云厂商供应链鉴别能力太差，花真钱买了假资源，分支二是云厂商自己的盈利模式不对，就是没舍得花钱买高质量资源，就喜欢用低质量资源来糊弄糊弄，这两个分支一样臭。

故障报告中，A云并未提及自己的机房是不是个优质机房，当年选型该机房的原因，比如机房的Tier认证级别，比如A云是否例行参加机房消防演练。这个报告发出来，对于甲方客户就是个很艰难的判断了：

• 如果这是个低品质机房，那就是A云给客户用地沟油炒菜；无论是识别不出来低质量机房，还是故意买的便宜机房，A云都会信誉受损。

• 如果这是个高品质机房，你都自己承认了机房会“带电下雨”了……机房没有气体灭火却水淹服务器这事就挺扯的，而且电器不断电就直接浇水容易出人命事故。

• BTW，A云故障机房的运营方和机房质量，对友商等业内人士根本不是秘密；如果该机房在深圳南郊很有实力，可能A云想开展业务还得继续忍着用该机房。

我们活学活用，参考4.2部分内容，可以从这几个方面脑补，如何能减少“提供劣质资源”的影响：

• 强扭天灾：A云拉友商下水，告诉客户同楼还有一群友商云也在享受带电淋浴服务，强行扭转客户的认知，将此事的性质从“提供劣质资源”扭转为“在那个城市这就是不可抗力天灾”。

• 算成本账：A云对少数核心大客户做面对面介绍，自己选购的已经是深圳南郊中档偏高的机房了，当地人干活就是这么不靠谱，我们有更贵的高档机房，客户要不要迁移到豪华可用区？

• 恐吓技术：A云对少数核心大客户做面对面介绍，自己为机房风火水电做了哪些深度投入，最好是故障前几天才做过某某演练，但就算这么精密的防控还是出问题了，让客户觉得换成友商云也少不了风火水电故障。

• 直面故障：A云给出下一阶段改进方案，要客户能听懂和相信，这个机房风火水电不会出故障了，或者自己会在多久时间迁移到风火水电达标的机房。

• 绕过故障：A云给出技术整改方案，就算一个可用区风火水电全部故障了，客户可以快速自动迁移到另一个可用区。

但我不推荐向客户解释直面故障和绕过故障这两种方法，并非我没有技术人员的荣辱心，而是toB企业的内部改进和客户收到的信息通报之间存在两个差距：客户缺乏技术评估能力，客户要的是绝对的信心。

结束语

ToB生意就是挺难的，并不是攒一堆高阶研发写几个软件、凑上海量资金买一批硬件就够了。

云厂商要平和的忍耐上游供应商的不可靠，又要体面的维持着客户对高标准服务的期望。