原创 东半球第二正经の  牛顿顿顿  昨天

2月23日，大批商家发现微盟服务器崩掉了，一时间，相关商城、小程序都无法登陆。

问题突发之后微盟官方一开始还甩锅，迟迟没有修复，这让300W+使用微盟的商家停摆两天，损失惨重。

01

一直到了25号，微盟才露面，暗戳戳的发了一个“自愿公告”：

仔细研究一下这些公告，我们能发现很多“反常”的地方：

首先这个程序员的行为就很反常。

根据公告的信息，这个DBA是用自己的账号，在晚上七点，通过个人VPN进跳板机删的库，事发之后很快被定位，第二天就被抓起来了。

用自己的账号，没用多重跳板伪装，而且你看这个作案时间，对于整天加班熬夜的程序员们来说，下午七点等于刚上班啊，大家都在干活，你去删库砸锅，这跟把身份证贴脸上去抢银行有啥区别？

同归于尽啊，还是咋滴？

然后就是扑朔迷离的删库动机，一开始微盟发公告说是：因个人精神、生活等原因。

后来27号，微盟的老板孙涛勇又解释是因为这个程序员深陷网贷，在家里闷了30多天，然后就把数据库删了。

这个就有点欺负大家的逻辑了，程序员借网贷他删你数据库干什么呢？

给平淡的生活找点刺儿吗？没有因果关系啊。

如果是缺钱的话，老哥这么高的权限，在后台随便搞点什么数据拿下来卖一卖，投入产出不比删库高吗？为什么去做这种损人不利己的事情呢？

难道删库只是为了找刺激？

再一个就是恢复的时间，23号出问题，预计到28号才“可能解决”，这意味着什么？

懂点行的都知道，该类问题只要备份机制还奏效，有完整备份，直接回滚就可以，最多一两个小时就能完事儿，如果需要这么久，往往意味着破坏的非常严重。

整个事件梳理下来看一看：

这个老哥用自己的账号，明目张胆删库，而且一出手就是下狠手，击穿所有的应急预案和备份，直接把系统删崩，回滚都没得滚，摆明了是想要玉石俱焚。

一时间行业里也是各种猜测，流传着不少八卦，目前靴子还没有落地，大家还是谨慎吃瓜比较好，静观事情发展：

一个员工，独立操作，就能把一家上市公司的数据破坏到这种程度，甚至可以连备份一块搞掉，权限隔离怎么做的？无论他是一个什么角色，都意味着微盟在后端管理的极度混乱。

这等于是把公司，还有几百万客户的命都交到了这少数几个人手上。

我坚持一个原则：人，永远是商业活动中最大的变数

不管什么时候，都不能把命让别人攥在手里，我见过太多人吃过这方面的亏了。

02

我早些年调查过技术服务这个行业，这里面有些技术外包公司，路子非常野，“骚操作”特别多。

很多人根本无法想象，一个不稳定的程序员会给一个公司带来这么大的冲击。少数几个人，只要掌握了关键环节和关键技术，就能拥有巨大的破坏力和谈判筹码。

当时我调查的是一些中小规模的外包服务公司，当时他们赖以生存的整个商业生态是非常恶劣的。

一般来说项目合作初期，甲方会先付一部分定金，然后乙方就开始根据甲方需求，投入人力物力推项目。

到了项目中后期，往往需要自己掏腰包垫资，才能完成项目。

如果顺利的话，最后成功拿到尾款，还能赚点辛苦费，但是很多时候，事情不会这么简单，东西是做出来了，服务也到位了，爸爸们往往拿了东西，把嘴一抹，立马就变脸拖账期，乙方还得继续当舔狗，想尽一切办法要尾款。

尤其是广告公司，他们一般体量比较小，话语权又低。

财大气粗的甲方爸爸们也不是直接说不给，就是账期特别长，这两年我见过的被账期拖死的广告公司，已经有几十家了。

技术外包类公司也一样。

但是，技术外包和广告公司扮演的角色还不一样，对于很多互联网公司来说，数据是核心资产，系统是运行的命脉，技术扮演的角色非常关键。

根据牛顿第十二定律，我们可以得知：破坏永远比建设更容易。

基于此，一些路子比较野的技术外包公司就玩起了“黑吃黑”。

这些公司会在开发初期的时候，直接就埋好后门，哪怕是项目交付了，正式投入使用了，要确保自己手里仍旧掌握着主动权。

爸爸们要是不按照合同，按时打款，拖延账期什么的，那就等着系统三天两头出问题吧。

很多地方底层的商业生态就是这样，一手交钱一手交货最好。

这种周期比较长的项目，先给钱的往往拿不到货，先给货的就拿不到钱，这话，很多做服务类乙方的一定感同身受，他们总是扮演一个被“拿捏”的角色。

如果说为了要尾款，留后门是出于无奈，那么路子更野的那些人，留定时BUG，逻辑炸弹，偷偷下载倒卖数据给竞争对手，那就是赤裸裸的坏了。

一鱼八吃，在他们那里，从来就不是梦。

03

一般来说，外包公司把项目做好之后，进入交付使用阶段，还会签一个长期维护的合同，费用通常在几十万。

常规的维护一年也能有个几万块，主要是服务器运维、域名、常见的bug修复，应急事件处理等等。

一般来说，甲方开发系统，后期的维护会直接给负责开发的公司。

因为这个钱是easy money，能拴住客户，榨到更多剩余价值，于是为了拿到这个长期维护的合同，很多外包公司就会故意把程序写得非常晦涩，或者是隐藏一部分关键内容，放一些只有自己内部知道的BUG。

这样，来确保只有自己能吃到这块肥肉。

因此自己人去做维护没有一点问题，但只要甲方敢换人，一定三天两头出问题。

程序写的绕过来，绕过去，对方删也不敢删，改也不敢改，很难定位到真正的问题所在。

这个时候，甲方就被吃定了。

主要是因为“沉没成本”，开发系统的大头都花了，客户基本就已经被牢牢绑定了，根本没法再找别人插手这个东西。

常规被吃点运维费用还能接受，但是，骚中自有骚上人。

04

有些外包公司，简直是天天在违法的边缘疯狂试探，他们不光想要吃维护费，还会搞“钓鱼修复”。

头几年一般比较老实，过个三四年，甲方就会发现，系统开始频繁出问题了，外包公司就会借着电脑系统老化，兼容性问题，数据库需要优化，数据规模大了需要扩容等理由。

然后假模假样搞优化和修复，趁机再大赚一笔。看上去忙活大半个月，其实可能只是注释掉自己当年留下的一个定时Bug而已。

有自己技术团队的大公司，可能还好点，但是完全技术外包的中小公司，钱该花的都花了，这个时候真是一点办法没有.自己没有懂行的人，根本察觉不到，察觉到了也没法验证，就算验证了，打官司也很难赢。

而外包公司这样一通操作下来，一年又能多挣个几万块。

行业里面有很多这样的外包公司，干个3年5年，手里攒着几十个客户，后面光吃维护，一年纯挣个几十万不成问题，抱着聚宝盆美滋滋的吃红利，这是一些外包公司的生财之道。

05

这个操作其实是相当普遍的，也不仅仅存在小公司，关注行业消息的可能知道，前几年西门子也遇到过类似的事情。

不要以为西门子就是做冰箱的，家电业务只是西门子很小的一个板块，真正牛逼的地方是软件、信息系统和行业解决方案。

西门子之前有一个管理订单用的电子表格需求，其实也不复杂，就是用自定义脚本更新库存和订单的信息，之前是外包给一个合同工设计的。

完成之后五六年的时间一直运行挺正常的，后来表格开始频繁崩溃，然后西门子只能重新找他做维护，陆陆续续一共花了4万多刀，直到后面事发突然，紧急修复，有其他工程师要到了管理密码，才发现程序里面藏了一个逻辑炸弹，会在特定的时间或者是特殊情况下诱导系统崩溃，然后事情才败露。

类似这样的还有很多，02年的时候UBS PaineWebber 的一个员工，在公司1500台联网的电脑里面，偷偷摸摸把其中1000台植入了逻辑炸弹。

然后想搞个大事故，整成负面新闻，配合起来做空公司的股价。

2002年3月4号，他植入进去的程序开始大规模删文件，结果到最后公司也没出什么大问题，股价稳如老狗，最后事情败露，自己赔进去了2万多刀，还判了8年多。

结合着这个骚操作，我们再翻过来看一下微盟这段时间的股价变化：

历史，还真是有趣呢。

这些技术起家，有资深技术团队，监察系统比较完善的大公司相对而言会好很多，如果是非技术公司找外包的话，对方大概能有1万种办法，让你跪下来叫爸爸。

所以说很多时候千万不能小看程序员。

秃秃的脑袋下，往往藏着大大的力量。

06

虽然大家都在强调规范管理，权限隔离，多人验证，但在实际操作当中，对于中小公司互联网公司来说是很难做到的。

因为规范的流程意味着效率的降低，大多数公司，你真正参与进去的时候就会发现，很多制度表面上看起来严丝合缝，但是在关键位置的人，能找到1万种方法把这个系统搞崩掉。

然而保证人不出问题是非常困难的，在我的经验里，人是所有的商业要素当中变数最大的一环。

所以我一直有这样一个原则：真正的靠谱需要把别人的不靠谱也cover掉。

所以，我在解决问题的时候，尤其是比较重要的环节，一定会留预备方案，只要一个关键环节没有双保险，我就会重新考虑整件事的可行性。

只要一个环节出问题就全部完蛋，这种事情我是绝对不能接受的。从墨菲定律定律来理解，一件事，只要有可能往坏处发展，那么只要时间够长，这件事就一定会发生。

不要拿命来赌概率。

这些年很多规模不小的企业都选择直接购买SaaS的解决方案而不是自建系统，但是微盟这个事情出现之后，我们是不是要重新考虑一下，SaaS要不要把数据管理的权限归还给客户？定期允许客户自行备份相关的数据？或者提供更多灾备手段？

对于互联网公司来说，数据是最核心的资产，而且是不可再生的。

核心的商业资源一定要掌握主动权，把数据交出去，就是把生命线交出去。

公告中讲到是28号修复，截止到发稿，很多商家的小程序仍旧还是维护状态，对于使用服务的企业来说，停摆这么久，无疑是巨大的损失。

一些公司干了3年5年的数据、订单、用户信息都存在你这里，万一出了问题，如果一点补救措施都没有的话，那些企业怎么办呢？损失谁来赔付呢？

不管是黑天鹅也好，灰犀牛也罢，程序员删了库也好，老板跑路了也好，机房失火了也好，谁的责任先不说，总要有一些补救的办法吧？

商业合作信任是必要的，但一定也是有限度的，无限度的信任就是把脑袋交出去。

这次危机，应该是整个SaaS行业需要认真考虑反省的一个时机。