微盟宕机事件相信大家都有所耳闻，这次事件在互联网圈也是一次不小的地震了，据悉这次事件让微盟业务宕机长达125小时，300万商户生意停罢，300万商家眼下只想尽快恢复生意，渡过这场难关，而微盟老对手有赞在此时递出了橄榄枝，毫不掩饰自己借机收割微盟客户的野心，微盟或面临一定程度的客户流失，这也直接导致了市值蒸发20亿港元，将影响今年Q1整体营收，为微盟难过的同时也在警醒自身，如何防预此类危机？

近几年来，由于技术人员故意或者有意造成的事故不计其数，微盟事件之前，2018 年 3 月，Stack Overflow 发布了他们的开发者调查报告，并首次提出了有关道德的问题。对于“开发人员是否有义务考虑代码的道德影响”这个问题，有近 80％的人回答“是”。不过，只有 20％的人认为他们最终在为不道德的代码负责，40％的人会在被要求的情况下写不道德的代码，只有 50％的人表示在发现不道德的代码时会举报。开发者的代码道德依然是条很长的路，删库代码其实只有短短的一行：“rm -rf/*”，但使用不当，造成的结果却会天翻地覆。

犹如2017年1月31日，全球第二大的开源代码托管平台GitLab内部的一位系统管理员，在给数据库做日常维护时，一时不慎运行了数据库目录删除命令……结果是虽然几经抢救修复，论坛上原本高达300GB的数据只保留下来 4.5G，直接导致当时的GitLab被迫下线。正因如此，猫云SaaS平台公司对于删库这种行为，是从技术和管理上都做了很多限制的。基于此次事件中贺某能够删库成功，且微盟需要“至少六天”来恢复数据这一结果，也引发了互联网业内讨论。

业内专家任向晖通过个人公众号发文称，“大多数成熟 SaaS 企业都会建立科学的部署架构，内部分工和运维规范。如果没有这些规范存在，组织无法获得任何第三方的质量认证。”任向晖在文章中，说明了真正的“规范”应该做到三个方面：

一，高可用的架构。

通过几乎实时同步的主从服务关系（应用和数据都可以实现），让单一服务出现问题的时候可以瞬间切换到其他镜像服务。这个架构也可以用来均衡不同访问路由的负载。

二，在异地增加冷备份。

这个冷备份虽然有一定的延时，但是可以起到关键的数据保全作用。为了足够的安全，冷备份应该不止一份。为防范服务商系统性故障，冷备份最好分布在不同的云主机服务商。虽然冷备份非常偶然地被使用，但SaaS公司都在支付这些冗余存储的成本。

三，最关键的管理分权。

原则上，生产服务器的运维管理权只限于极少数人即可，因为研发团队并不需要访问真实的生产环境，他们在模拟的研发环境中调试即可。计算机安全体系允许将主机运维、数据库管理和其他系统管理的权限全部分开，分别授予不同的人员，并且所有的访问行为均会保存日志，就连日志数据也是可以分权管理的，这使得单个人破坏全部服务的可能性为0。微盟事件的主要原因肯定是疏忽在这个环节。

在通俗一些说，上述问题1与2属于技术范畴，而问题3则属于公司内部管理问题。任何一环出现问题，都会增加SaaS平台的数据风险和安全风险，而安全事件的根源，往往在于管理。

我们需要有效避免悲剧重演，企业应该重新审视自己的防范预案是否合理，要在在技术、制度和流程规范这三个方面进行加强，保障用户的数据安全。