TOUBU头部（ID：toubu2019)
“daß die Geschichte die Eigenheit hat,repetiert zu werden,so lange,bis die Lektion begriffen wird.”
德国哲学家黑格尔的这句格言有多个汉译版本，其中一个最犀利也最广为人知：
人类从历史中所得到的教训就是——人类从来不记取历史教训。
可以说，在每一个由“人祸”导致的危机发生之前，警报可能已经拉响了N次。如果不长记性，这危机也不会是最后一次。
2月23日18点56分，微盟（2013.HK）研发中心的运维人员贺某通过个人VPN登入公司内网跳板机，对数据系统进行了删除操作。
随后，微盟商户便发现店铺后台无法登陆，甚至连微盟官网也无法打开。当天晚上商户们呼天喊地，受新冠疫情影响，线下门店生意停滞，本来靠线上店铺还能带点生意，这次宕机无疑将微盟的商户们推向更深的困境。
一般情况下，互联网公司发生宕机事件，恢复时间多是“分钟级”，至多为“小时级”。微盟显得很狼狈，一周也没完全搞定系统问题。
这只“黑天鹅”使微盟市值损失十多亿，教训不可谓不深刻。数百万商户愤怒又无助，微盟仓惶应对，焦头烂额，上市公司的泡沫被戳破了。
有果必有因，这只“黑天鹅”能够飞出来，有其存在的环境和条件，我们从微盟的过去能找到一些端倪。而这次危机造成的其中一个“果”，便是微盟商户的流失。
此次危机前，已发数十次安全警报
过去这几年，微盟网站系统被曝光的漏洞多达数十次，也曾发生过宕机事件，这些并没有改变微盟的安全观。
2014年2月16日，一位名为“her0ma”的白帽黑客在乌云平台（现已关闭）曝光了微盟某页面SQL注入漏洞，该漏洞危害等级为“高”，用户的各种信息有较高的泄露风险。
那年2月19日，微盟成为腾讯微信官方认可的五家微信电商服务商之一。然而在3月31日，微信云对微盟做出下架处理。微盟下架的第二天（4月1日），微信云官方发布公告，称：
“对部分存在严重安全隐患和违反相关法规的服务商进行了下架处理......部分服务商缺乏安全意识和安全防护能力，出现过使用户数据安全受到严重威胁的现实情况”。
在被问到下架微信云的原因时，微盟引导舆论称“后台系统进行架构调整，不能完全迁移至腾讯云”，对平台漏洞一事避而不谈。
据亿邦动力网报道，微信云此批下架的服务商中，包含首批接入的微盟。微盟的下架原因得以证实。
商场如战场，最关心你、最懂你的人要数竞争对手了。面对微盟的态度，同样作为微信营销平台的微微易再也看不下去，于4月10日在微博发了一篇《五问微盟》的讨伐檄文，称“微盟不作死就不会死”，“这闲事微微易管定了”。
微微易的问题主要是敦促微盟正面回应乌云曝光的微盟平台漏洞，该高危漏洞可导致管理员账户、密码以及商户姓名、住址、电话、交易记录的泄露，让微盟消除此事给第三方开发平台行业造成的不诚信影响。
当年的4月11日，微盟举办全国首届代理商大会，公司在会上辟谣微盟被微信云拉黑，时任微盟技术副总裁的黄骏伟才终于承认微盟存在安全漏洞，称在发现漏洞的第二天完成修复并启动了密码重置机制。
令人匪夷所思的是，不到一个月，微盟又被曝光出现高危漏洞。5月3日，白帽黑客“U神”（现为补天平台白帽黑客）向乌云平台提交了微盟漏洞信息，微盟主站SQL注入可致大量信息泄露。第二天，微盟进行了漏洞确认。
该漏洞将商户的银行账户、付款信息等都暴露出来。
微盟的安全漏洞不止于此，“TOUBU头部”发现，在企业级互联网安全测试平台漏洞盒子上面，微盟在两年多的时间里，被白帽黑客提交的漏洞高达18个。
每一次风险警报都是一次安全提醒，按理说微盟查漏补缺后该百毒不侵，为什么还会飞出“黑天鹅”？这就涉及微盟对技术所抱持的理念。
云供应商五大考量维度，微盟把安全排第四位
随着微盟业务场景的多元化及SaaS软件的开发，云计算为微盟提供了基础资源支持，使其在初期依靠有限的资源投入，在市场竞争中活了下来。
微盟经过了市场厮杀，深谙资源来之不易，投射企业经营上，就形成了务实甚至有些短视的决策风格。
在软件业务迁移到腾讯云之前，微盟和腾讯云已经在安全、CDN（内容分发网络）、云主机等领域有所合作。后来，微盟采用了腾讯云的“混合云”和天御系统等方案。混合云是一种云计算模型，它融合了公有云和私有云的优势，具有高可扩展性，也拥有公有云一样的成本效益。
微盟CTO黄骏伟在接受中国专业IT社区CSDN专访时，分享了微盟对于云供应商的考量维度，他按重要性对各要素排列后依次为：1.稳定，2.成本，3.便捷，4.安全，5.服务。
安全仅被排在第四位，在成本和便捷之后。
企业有什么样的经营理念，就会做出什么样的经营决策。这次危机看似“黑天鹅”，不如说是一个必然，偶然的是谁来点燃导火索。
系统稳定压倒一切，控制成本是互联网公司长期发展的基础，这两点不难理解。把便捷性放到安全性前面，要么源于对系统和运维人员出错率的高度自信，要么是出于某种侥幸心理——哪有那么巧会出事。
关于便捷这一维度，黄骏伟的原话是：
我们看重日常使用操作和维护的便利性，云操作不仅是运维人员要操作，还有我们的开发人员要对其数据抓取、统计、分析。这必然要求有良好的人机界面和丰富的SDK、文档，让微盟的小伙伴在很短的时间内快速上手，使用和维护整个云网络。
黄骏伟也清楚混合云模式下公司面临的挑战，他对媒体说：“混合云将带来全新的硬件更新、网络带宽消耗、互联质量提高、管理维护思路等挑战。当然我也相信，微盟已经感受到了变化的气息，并且做好了应对的准备。”
这次危机表明，微盟远远没有做好应对变化的准备，也没有真正意识到管理维护思路面临的挑战。
商户流失难以避免
贺某在“删库”之前，不知是否经过激烈的思想斗争，是否想过此举带来的后果。他这只蝴蝶扇下翅膀引起了一场风暴，而事件最终导致什么结果，他本人和微盟都难以控制。
尽管发布了数据安全保障和赔偿计划，微盟商户的流失仍难以避免，甚至很难挽回，“TOUBU头部”认为主要源于以下几点：
1.微盟本身存在较高的商户流失率。
根据微盟发布的财务报告，微盟最近几年SaaS产品的商户流失率都不低：2017年的流失率为27%；2018年的数据也约为27%；2019年1月，公司在香港联合交易所上市，在上市公司光环的背书下，上半年的流失率从2018年同期的13%下降至约9%。
请注意，微盟对商户流失率的计算方式为：
流失率 = 报告期内未留存付费商户数量/过往年末的付费商户数量
即上半年的流失率是用上半年的流失数据除以上一年末的付费基数，分子小而分母大，流失率自然就低。
实际上，到年末用全年流失数据参与计算时，这样的流失率才算客观。虽然微盟2019年全年数据还没公布，本来就较高的流失率会雪上加霜。
2.未能取信于人。
泡沫戳破之后，微盟在本次危机中的表现一言难尽。
2月23日傍晚19:00发生宕机事故，微盟拖到25日才向投资者发了一则公告，称“2020年2月25日晚上24:00前公司的SaaS业务生产环境将修复完成，所有新用户将可继续使用本公司的SaaS 业务。本公司预计老用户的数据修复将可在2020年2月28日晚上24:00前完成。”
如果没有把握的话，时间节点就再放宽一点，微盟屡放鸽子，商户在群里气炸了。
商户们认为微盟在玩文字游戏，的确，微盟在公关文案中还是比较注意用词的，甚至很多媒体都掉坑里。看下图：
有多少人很自然地把“微盟数据已经全面找回”，理解成了“全部找回”？“全面”一词用得很妙，给人“全部”的感觉。
在微盟提出的数据安全保障计划措施中，微盟强调：加强灾备体系建设，做到多云异地冷备。结合微盟此次宕机表现，其百度搜索栏此前的介绍——多地互备——当时真具有这个能力吗？
3.市场竞争依然激烈。
从企业内部来看，微盟虽然自称“新经济SaaS第一股”，但其应收仍以精准营销为主，本质上仍是广告代理公司。由于科技公司比广告代理公司有更大的想象空间，微盟更想突出自己的科技色彩，微盟仍需苦练内功。
从外部看，行业竞争依然激烈，友商抢客户不得不防，从有赞的“江湖救急”书就可见一斑。原本在商户看来，上市公司实力雄厚，系统会安全稳定，经此事件，上市公司也不过如此，对商户来说，会考虑把鸡蛋放在不同的篮子里。
另外，据网经社2月17日报道，其通过对微盟2019年全年真实用户投诉案例大数据分析，公布了“2019年微盟消费评级数据”，微盟获“谨慎下单”评级。
这对微盟和微盟商户都不是一个好消息。
而如果微盟能从这次危机中吸取教训，也算是一个好消息了。
---- END ----
閱讀更多 頭部財經 的文章
