此时，距离微盟内部人员贺某删库事发已经是第五天，“28日24时恢复老用户数据”的承诺，无法如期完成。
过去五天，业界关于微盟的讨论主要聚焦在三点：
1.核心运维人员为什么要删库？
2.微盟技术架构及管理上有哪些疏漏，何以让一个运维人员把系统整瘫，行业应该吸取哪些教训？
3.经历6天144小时的服务暂停，给微盟影响多大、对商户影响多大？
要回答以上三个问题，我们首先要复习一下微盟是一家什么样的公司？
微盟，成立于2013年的SaaS服务商，2019年1月在香港主板上市，目前市值122.44亿港币，较25日的138.33亿港币缩水约16亿，折合人民币约14亿元。2019年上半年，该企业总营收6.57亿元人民币。
其主要业务是在微信等平台上为电商、零售、餐饮、本地生活、酒旅等企业搭建小程序，并为其提供精准营销服务，根据微盟提供的数据，目前微盟已经为超过300万商户提供这类服务。
这也意味着，在2月23日，微盟核心数据遭内部员工删除（以下简称“微盟事件”），其SaaS产品不可用之后，有7万注册商户的线上商城、小程序门店等无法访问。（查看钛媒体此前文章→《SaaS服务商微盟遭员工“删库跑路”，300万商户哭了......》）
“之前计划通过公众号在小程序商城上推接下来的一波活动，现在都被耽误了。我们应该会转向其他平台做这个活动了，比如天猫、京东、有赞等。”一位使用微盟服务的糖巧商户对钛媒体表示。
受事件影响，微盟股价下跌，截止钛媒体发稿，微盟市值较25日已经缩水约27亿港币（约合人民币24亿元）。
截止28日4点微盟股价。较25日市值138.33亿港币，目前市值缩水约31亿港币（约合人民币27亿元）
微盟事件不是必然事件，却是移动互联网时代的产物。
在很多人认为SaaS市场会因为疫情而火爆的时候，微盟删库事件也让大家更加认识到云上数据安全的问题更需要引起足够的重视，因为只要上了云，数据一旦出问题，就相当于银行倒闭，就是倾家荡产的风险。
一次本可以避免的安全事故
舆论对犯罪嫌疑人贺某“删除数据库”的原因猜测不断，直到有人将此事与甚至“微盟某高管传言”联系到一起，甚至引发了 SaaS 圈外人集体“吃瓜”——当几百万商户都在关心“我的网店还能不能恢复”时，让原本一桩技术事故，最终朝向娱乐化发展。
27日下午，微盟创始人兼CEO孙涛勇发布长文回应，就内部员工“删库”的原因向外界公开了一个模糊的官方定论。
关于删库原因，孙涛勇表示，“该员工春节期间一直没有回家，由于疫情阶段不能外出，只能一个人在房间独处了30多天，加上本身经济上的困扰，就做出了这种举动，事后他也说跟公司无任何仇恨，我想他是在选择一种自己解脱的方式吧，这也是为什么事后没跑路，也很快承认了犯罪事实。”
图片来源@微盟CEO孙涛勇回应
截止目前，这是微盟关于本次事故的全部回应；而上海公安官方尚未对该案件做出任何公开。
某互联网创业公司 CTO 向钛媒体记者评价微盟事件时称，“看到事故出来，心里一紧。” 但该人士对钛媒体表示，把一项严重的技术事故归因于一个员工身上，“这不符合技术常识。”
一位从业超20年的IT咨询公司高管也告诉钛媒体，“彻底删除”这件事，在计算机时代根本不存在，只存在“数据恢复起来的复杂程度不同”。
那么，到底谁要为数据安全事故背锅？当下，电商企业普遍上云需求迫切，我们到底该如何认识所谓的“删库”事件？
“稳定”，是云服务厂商最重要的生命线
删库代码其实只有短短的一行：“rm -rf/*”，但使用不当，造成的结果却会天翻地覆。
例如2017年1月31日，全球第二大的开源代码托管平台GitLab内部的一位系统管理员，在给数据库做日常维护时，一时不慎运行了数据库目录删除命令……结果是虽然几经抢救修复，论坛上原本高达300GB的数据只保留下来 4.5G，直接导致当时的GitLab被迫下线。
因此，SaaS平台公司对于删库这种行为，是从技术和管理上都做了很多限制的。基于贺某能够删库成功，且微盟需要“至少六天”来恢复数据这一结果，也引发了业内讨论。
明道云CEO任向晖通过个人公众号发文称，“大多数成熟 SaaS 企业都会建立科学的部署架构，内部分工和运维规范。如果没有这些规范存在，组织无法获得任何第三方的质量认证。”
任向晖在文章中，用“易懂的文字”来说明了真正的“规范”应该做到三个方面：
1）高可用的架构。
通过几乎实时同步的主从服务关系（应用和数据都可以实现），让单一服务出现问题的时候可以瞬间切换到其他镜像服务。这个架构也可以用来均衡不同访问路由的负载。
2）在异地增加冷备份。
这个冷备份虽然有一定的延时，但是可以起到关键的数据保全作用。为了足够的安全，冷备份应该不止一份。为防范服务商系统性故障，冷备份最好分布在不同的云主机服务商。明道云的数据备份分布在UCloud、阿里云和腾讯云三个服务商。虽然冷备份非常偶然地被使用，但SaaS公司都在支付这些冗余存储的成本。
3）最关键的管理分权。
原则上，生产服务器的运维管理权只限于极少数人即可，因为研发团队并不需要访问真实的生产环境，他们在模拟的研发环境中调试即可。计算机安全体系允许将主机运维、数据库管理和其他系统管理的权限全部分开，分别授予不同的人员，并且所有的访问行为均会保存日志，就连日志数据也是可以分权管理的，这使得单个人破坏全部服务的可能性为0。微盟事件的主要原因肯定是疏忽在这个环节。
在通俗一些说，上述问题1与2属于技术范畴，而问题3则属于公司内部管理问题。任何一环出现问题，都会增加SaaS平台的数据风险和安全风险，而安全事件的根源，往往在于管理。
另一篇评论文章基于微盟事件声称，“99%的SaaS都有安全隐患”。但显然，业内人士大多并不认同这样的说法。
对此说法，任向晖认为，“这是偷换了一般安全隐患和安全灾难的区别。计算机网络和软件的漏洞的确是常见的，但它们的破坏力非常有限，即使是严重的D0级（需要当天立刻修复）缺陷，也不至于造成完全的数据灭失后果。”
同样向电商行业提供SaaS服务的有赞平台，也在微盟事件后第一时间，收到了来自多家客户、投资人方面的疑虑和咨询。
CTO 崔玉松在接受钛媒体采访时说，“为了逼自己重视，2013年我们给自己列了第一信条‘系统稳定高于一切’，2017年1我们推出‘有赞护航’计划，如果出现微商城核心服务不可用，影响了客户的生意，就按照不可用时间给予对应102.4倍的补偿。这是整个信息服务行业里没有的最高规格的‘承诺’。我们有严格的访问控制，做了角色分离、权限隔离，杜绝少数人就能进行高危操作，制定了严重宕机的处理预案。”
崔玉松也告诉钛媒体，有赞的CTO和CEO都没有可能用一台电脑、一套账号密码完成彻底删库动作。
在IaaS云的层面，有赞的主要的服务商有腾讯云、Ucloud两个，而且在两家平台上相互备份。
“（我们的数据）在每个服务商的不同的机房里有备份。退1万步讲，即使一个云服务商出现问题，我们在技术上都可以自动切换到另一个云服务上，并且从技术的角度、从数据的角度，我们可以在5分钟之内基本上恢复95%的流量。”
崔玉松对有赞平台抗风险能力的预估是，“遇到非常极限的灾难的时候，我们可能最长的时间——按我们现在预估——大概30分钟可以完全恢复。”
管理问题是根源
对微盟事件的归因，业界主流声音是：没有施行管理分权。
钛媒体查阅公开资料发现，微盟的确存在这种权限管理过松的可能。微盟 CTO 黄骏伟曾在一次公开分享中提到，微盟正处于高速成长期，微盟的技术团队从最初的三四十人已经扩充到了六七百人。
为了应对研发管理的繁杂，让技术研发跟上公司快速扩张的脚步，微盟施行了项目负责人制度。在这一制度下，每个项目汇总到一个负责人，并使得该负责人能够调动尽量多的资源来协同他做事。“每个团队事事都还要汇报到CTO这里，那无疑是非常低效的。”黄骏伟说。
而身为核心人员的贺某，或许恰是某个项目具有高权限的负责人。
“删库”事件影响下，百万级的平台商户均陷入了网店关闭、无法登陆和交易瘫痪的窘境，对于微盟提出的“6天才能恢复数据库”，6天（甚至还不确定的周期），对于任何一家平台商户而言，损失惨重。
针对“至少6天”来完成数据恢复的公告，一种说法是，微盟没有做数据双活方案/异地备份，才导致删除一个主库之后，多天无法恢复；也有人认为，微盟使用了便宜好用的MySQL，没有用商业级别的Oracle或DB2。
更确切的消息，据《中国经营报》报道，微盟的底层架构采用的是混合云模式，部分自建部分上云，而微盟被删的数据恰好是没有上云的自建部分，这种做法会导致没有上云部分的数据在被删除之后无法及时恢复。
“如果在云上，云数据库的备份功能能够保证哪怕是删了数据，也能回滚到之前的某个时刻，把损失降到最低。”一位云计算业内人士表示。
截图来源@知乎
针对这一问题，@腾讯云 在官方账号中也对云数据库这一问题进行了回复。腾讯云称，”在微盟事件中，微盟使用的云数据库在这次事故中没有受到影响”。这一声明或侧面证实，事故中实际上出问题的是微盟本地化部署的数据。
当下，混合云模式是云计算界较为青睐的资源部署模式。但钛媒体呼吁，采用本地化部署以及混合部署的企业，一定要做好本地部署数据的备份和防护，降低类似事故风险。
有赞CTO崔玉松针对中小商家的经营数据安全，提出了如下建议
1）要注意店铺管理员的角色分离、权限隔离，定期查看后台的操作日志；
2）需要高级管理员的验证码来做二次验证的，一定要搞清楚员工在做什么重要操作；
3）通过API授权的方式，从有赞云调取店铺数据到其他第三方应用，应注意调取的接口类型。和安卓手机权限一样，多余的权限不要授予。
4）严格控制有表格数据导出权限的高级管理员的数量，密切监控数据导出的用途。
5）离职员工要第一时间删除管理员权限。
时间不等人
微盟研究院在2019年5月发布的《2018微信小程序行业应用发展研究报告》显示，超过一半的企业商户对小程序保持高度关注，在已应用微信公众号（订阅号/服务号）的商户中，57.18%同时开通了小程序；另外，95%以上的商户有意愿将企业未来的营销推广预算向小程序倾斜。
因此，受数据库事件影响最大的是单一架构在小程序上的商户。
市场的火爆，事件对整个行业的震动，已经无法让大家冷静面对商场沉浮。
微盟发布事故公告当天，同属SaaS平台服务领域的有赞发布了“给微盟商家的江湖救急”计划。公告中表示，有赞将为微盟商家提供2周免费开线上商城的服务，帮助他们重建小程序和店铺；但如果商家在次过程中想要长期使用有赞服务，却有顾虑到微盟软件服务未到期，有赞可以适当补贴对应服务器来减少损失。
一位希望匿名的商户告诉钛媒体，当他对外发布了“商城不可访问”的信息之后，立即收到多家 SaaS 平台的沟通意愿，但具体信息不便透露。
这充分反映出，在小程序搭建、店铺私域流量的运营这片处于行业上升期的市场，竞争惨烈。
中国小程序服务商不完全统计（由钛媒体TMTBase制整理）
据媒体不完全统计，类似小程序服务商这样的企业除了有赞、微盟两家发展比较快之外，还有点点客，商派云、即速应用、序多多等多家服务商也参与其中。
有媒体评论称，假如微盟商户在此次故障中试用了另外一家的服务，那么对微盟最大的影响将是面临客户流失。
在疫情之外，又突发数据库安全问题，SaaS行业在不到一个月时间内黑天鹅事件频发。受影响的几万家商户们被迫面临选择：迁移还是等待？
事故已经发生，而根据部分受影响商户在社交媒体上的抱怨，事故后平台方面的信息不公开、不对称正在让商户与平台之间产生“信任危机”。一部分商家已经在考虑迁移问题。
而关于微盟在两次公告中提及的“赔偿问题”，一位跨境电商公司创业者、某平台SaaS小程序商户对钛媒体表示，“赔偿问题不是最重要的，商户最在意的是‘信任问题’。”包括该跨境电商商户在内的一部分商家，已经在着手准备向有赞等平台迁移。
该商户还认为，“安全问题是相对的，毕竟我们使用的是工具。除了风险如何防范，我们更关心的是出现问题后平台怎么能补救，有没有能力预知可能的风险。”该商户透露，两年前在上线小程序的同时，自行购买了服务器对系统数据进行了备份。
“大商家”收到来自微盟恢复期到3月中旬的通知
一位做水产生意的微盟商户向钛媒体透露：“大商家都收到‘恢复期到3月中旬’的通知了，只有我们在傻等着，只看到官网公告，并没有收到任何通知。”
在中小企业“上云”的主流趋势之下，微盟事件的影响，已经远超我们的估计。
黑天鹅事件考验了整个SaaS行业的抗风险能力，而这些能力往往并不体现在股价上、销售方案中，真正决定平台竞争力的，是这些潜于水下但事关生死的能力——技术架构是否完善、数据安全能否保障、企业管理是否良性，都是不能儿戏的平台责任。
责编：张阳