当云服务也不靠谱之后——云生态视角看Gitlab事件
Gitlab.com最近出了点大故障，五层备份机制都挡不住一个误操作。
云计算时代和旧时代变化很大，一斑可窥豹一叶可知秋。我无意继续重复这次事件，而是从各方反应来看云计算时代IT行业的新特性，以及对应各个群体的建议。
通过此事我看到有三方面的新特性。
第一，高水平运维人员严重缺失，大家热衷于炫技而非做实事。
第二，相比自建服务，采购云服务责任极小，会刺激技术人员继续上云。
第三，企业级云服务场景中技术运营角色的缺失。
一切问题都可以归结成人的问题，这次故障也不例外，当Gitlab说自己做了五层备份措施，我就想到了五个和尚没水吃。
运维工程师本来是一个风格保守、专注业务可用性的行业，在传统企业服务领域里一言九鼎。个人互联网业务要求“多快好省”，旧式运维过于保守甚至懒惰了，但互联网运维只记住了“多、快、省”，偏偏把“好”的标准定错了。互联网运维从学习到面试到工作，大家都喜欢诸如高可用、弹性扩展、运维自动化、超大并发、云计算等等炫酷技术，这样容易出业绩也容易拿高薪；而无论是学习还是面试都只能把单个知识点考到，等到生产环境才能验证你的全局统筹能力。
回到这个故障上看，五层备份有很大目的是炫技，快看，我把所有备份方法都用起来了；如果每层备份的可靠性都超过99.5%，做两层备份就比出车祸几率小，做三层备份肯定没美苏核战的几率大。但从对方披露的公开资料来看，每层备份的可靠性在50%到90%之间。
云计算厂商是个企业服务供应商，无论是IaaS、PaaS还是SaaS，都应该传统IT服务的优点捡起来，多关注服务可靠性和业务可用性。
缺乏合适运维的问题很难解决，因为业务保障能力很难靠培训习得，应聘谈薪和自主创业时，做功能保障的人才非常吃亏。笔者在两年前听某云计算公司的CTO说，他和CEO俩人刚开公司时连二三层网络都分不清，多做快做新功能才能拉到用户和风投。
从用户的角度说还好了，云计算本来就是为了解决人力短缺问题的，IaaS云平台让你少考虑系统可用性，PaaS平台让你少考虑服务可靠性，SaaS平台让你只关注账户密码的安全性，做业务保障的人你可以少招一些。
本次出故障是一个SaaS平台搞砸了，但是很有趣的一幕出现了！99%的客户采购决策人不会因此挨骂，90%的客户不会做跨厂商容灾。如果你内网自己搭建个Gitlab服务，丢数据是要写检查甚至被辞退的，但采购公网服务出故障了像遇到天灾一样，大家都只能认倒霉。
笔者曾经观察到某RDS笨拙的平滑扩容，笔者也知道很多云负载均衡只有LB没有HA，但是懂行的人根本不在意此事，懂得越多怕的越多啊，我的人品肯定比某云平台更好吗？我只是扶老奶奶过马路，这些厂商可都是几千万几个亿的做慈善啊。
采购云服务有一个心照不宣的秘密就是维护责任外抛，甚至采购评估责任都可以外抛。客户采购云服务可以专注功能和核心业务，让云服务厂商做业务保障总好过没人做业务保障。
现在GitLab用户的心态和30年前采购数据库的那些人心态一样，这个厂商这次不靠谱，不代表换个新厂商就靠谱，而且老厂商总会知耻后勇吧，此起彼伏的挖电缆新闻没吓跑几个客户。云计算服务还不成熟，让客户对厂商的期望值其实并不太高，希望厂商们努力逐渐对得住客户。
第三个新特征就比较绕口了，企业级云服务场景中技术运营角色的缺失。笔者接触的人员有限，但各个云计算厂商没有明确的可以为技术运营负责的人员。如果你是游戏运营人员，技术人员说某个功能不可用你很快能听懂；如果你是IDC运营人员，监控人员报某用户流量异常你也可以很快处理；如果你是网站运营人员，现在全站瘫痪优先恢复哪几个频道可以快速和技术沟通。但是云计算是一个新兴产业，厂商和客户都在摸索中前行，没有公认的运营规范。GitLab遇到的只是最浅层的问题——有异常流量要手动处理，这个过程中手滑了出故障了，但笔者无责任乱猜了一下，如果有精确的正常流量定义，那根本不需要手动处理异常流量啊。
这个岗位职责既需要了解平台技术现状，还要了解客户业务需求，还要对平台资源甚至商务促销都有很深的把控力度。
先说了解平台技术现状和客户业务需求，这个容易理解一些。大部分人不知道软路由处理不了SynFlood一类海量碎包，那么你在SLA里不可能加上网卡包量限制条款。某云平台总是爆出虚拟机系统盘回档的故障，那是因为本地磁盘就是一天一备份，我们应该引导客户将数据放在数据盘、RDS、NoSQL和OSS。企业客户是讲道理的，不会跟厂商漫天要价，但他们会要求厂商言而有信，我相信假以时日，技术出身的售前工程师可以顶上这个缺位。
这里比较难理解但也有足够威慑的是平台资源统筹管理。一个用户拿七位数的资金就能合理合法的瘫痪国内任何一家公有云平台，因为大家都喜欢开放注册，也都是秒级按量付费。后续操作细节就不说了，不想教坏小朋友，内行自然懂的。资源超卖是合理合情的行为，有超卖就要承担品质下降乃至崩盘的风险的。要防范品质下降乃至崩盘只有两条路，第一是少超卖多预留资源，并增强快速扩容演练，第二是如何不失体面不被用户骂抠门，尽量约束用户的操作。但是这事谁来做，谁来扛责任？貌似COO和CTO要打起来了。
云计算是一片生机无限的星辰大海，沉舟侧畔千帆过，病树前头万木春，每一次故障都是一次机遇。
前面说了几个云行业的新特征，后续是我给业内玩家的建议，这些玩家包括云计算大运营商、小运营商、自建私有云和甲方工程师。
对大平台大运营商来说这绝对是好事，客户不会因为友商出事而放弃上云这一历史进程，但会因此类事件而更理性的评估云服务的售价。
前文说过客户将维护责任外抛，大家都对云平台的高可用性报以过大期望值。虽然厂商宣称都有各种双活和容灾，但我们仍然经常看到挖掘机大显神威的新闻。这些做高可用的钱如果不花可以继续降低用户成本，如果客户真要做高可用那我们可以给商品抬价，现在钱花了一半事情也只做一半很尴尬也很浪费。
放长远去看，云计算最早是抢夺VPS和虚拟主机用户的，这类客户更敏感价格，让全行业的虚机卖的太便宜了。高附加值的企业客户是不知道有隐患才敢买廉价服务的，这主要怪圈地时期云厂商过度忽悠，但一次故障一堂课他们会逐步评估风险的。云平台不能只满足VPS蝇头小利，顺应客户需求，帮客户降低风险，新推出的产品贵一点无所谓。
对小平台来说这当然也是好事，现在和大平台做质量对比的利器又多了很多。大小平台都宣称自己有塞上长城一样的保障能力，但客户是无法直接触摸和验证的，小平台只要引导合理，大平台的优势反而会变成劣势。
小平台最好放弃公开免费注册，放弃只用一两个虚拟机的小客户，专注做自己营销线能覆盖的大客户，这样可以极大降低运营维护成本。
小平台可以说自己比大平台更稳定，因为维护100个点的群集就是比维护1000个点的更简单；小平台就100个客户，每个客户的业务固定负载稳定，总好过10万个客户做布朗运动。
小平台在某些时候成本会比大平台还低，比如说本地政策扶持、特定资源便宜、特定资源闲置等等，这时候跟企业客户算大平台的成本账，大平台再说自己技术好所以卖得贵，你就随便搜个故障新闻截图甩他脸上。
当高品质客户认为使用单一平台可靠性不够，他们会选择第二家供应商放少量资源或者做备用平台。对于小平台来说，能和大平台并列进入客户的供应商名录就是巨大胜利，合同金额早晚能提上来的。
私有云厂商总是乐见公有云吃点小亏的。公有云服务存在维护责任不可知、服务质量不可控，甚至平台资源不可控的问题，自建私有云会成为高端客户的重要选择。私有云项目里，维护责任完全在固定的企业法人和团队自然人，服务质量只要肯投钱就能保证可控，深入业务模式可以更好的调配平台资源，资源超卖的事情根本不用考虑。自建私有云厂商跳出了公有云压价竞争的泥潭，早早上岸专注做企业IT服务。
说到最后就是敬爱的甲方，各位云计算用户们。云计算本质上只是个工具，GitLab故障中也用到Azure和S3的备份方式了，但最有含金量的工作是评估备份的有效性，并且记住定期检查备份是否成功。这些技能很难学习和评估，那我们的工作就不会被计算机替代。
我们因为各种原因必须上云，那我们的一些压力就可以交给云平台来扛着，这一条和上一条并不矛盾，因为聪明人总能找到新的突破口。
比如说自己做Mysql双主多从很繁琐，现在用RDS了就可以专注做分库分表分事务了。我们既不能盲目怀疑RDS不可靠给自己增加成本，但也不相信简单托付给云平台可以解决一切问题；我们要做两层坚实可靠的备份机制，再规划一套跨平台快速迁移的容灾策略，这比摆弄某个炫目的玩具更有意义。
机会总是留给有准备的人的，诸位努力吧。
附加声明：本文中提到所有匿名云平台的黑历史，只是说明云计算技术还在不断完善中，所有案例分布均匀，每个厂商雨露均沾，断无抹黑某个厂商的目的，且历史不等于未来，大家都在技术进步；让企业客户意识到服务商的能力极限，是对双方共同负责。
解脱不是转身离开
而是向上成长
—— 头条科技 ——