今日，微盟发布有关微盟系统故障通告。通告指出，2月23日19点，系统监控报警，服务出现故障，大面积服务集群无法响应，生产环境及数据遭受严重破坏。
此外该公司旗下SaaS业务服务出现故障，预测对有关业务带来一定负面影响。
目前，公司正进行生产环节和数据修复工作，预计2月25日晚24点前生产环境将修复完成，所有新用户可恢复服务;预计2月28日晚24点前老用户数据修复可以完成。
此次事故经调查系微盟研发中心运维人员贺某所为，贺某于2月23日晚18点56分通过个人VPN登入公司内网跳板机，因个人精神、生活等原因对微盟线上生产环境进行恶意破坏。目前，宝山公安局已将贺某刑事拘留，犯罪嫌疑人承认犯罪事实。
反思：频繁吃一堑，如何长一智
在谈反思之前，在此次事件中有几个问题我们还要关注一下，为什么这么长时间还没恢复?
为什么一个人可以有这么大的破坏性?
从公告中，我们可以看到，到目前为止，仍在进行中的恢复动作就是做数据恢复。
所以有网友说不难推断，这次故障被破坏最严重的就是生产系统的数据库，而且一定是核心库，或许应用环境也被破坏掉了，否则影响不会像现在这么大。
1. 数据恢复这么晚，说好的灾备呢?
说道数据回复的时间长可能是以下几个原因造成的：
- 这个事件非常不幸，就是传说中删库跑路的操作，而且极有可能是直接做了rm -rf或者fdisk这样的基本不可逆转文件删除操作，更极端可能是主备一起干掉了。
- 数据库备份没有做好。可能压根就没有备份，只能从磁盘文件系统维度恢复;有全量备份，但是无增量备份，全量有可能是一个月、一周，三天等等，这中间的增量备份没做。
不管哪一种，只要是数据库备份机制不完善，没做过完整的恢复验证，真正要恢复的时候一定会花大量的时间找回数据。
2. 论一个人的破坏性?
从这次事件看，微盟这种规模的公司不太可能像大公司，一下招很多运维或DBA，然后每个运维和DBA都严格按照不同业务授权，也就是每个DBA只能访问有限的业务库。
小公司的成本不支持这种做法，而且招了这么多人也没这么多事情可以干。
所以，对于绝大多数中小型公司来说，普遍和必然的现象就是，一个运维或DBA管整个系统，并且拥有整个系统所有主机的最大权限，比如root。
说做好权限管控，要分层分级等等，这些玩法只针对大公司有效，因为大公司有钱，有量，有事情干，招一批人，分分工，分分权限，各管各的，完全没问题。对微盟这种类型的公司基本不可行。
3. 避免问题，我们可以做什么?
以上2个问题主要集中在运维人员权限太大，方便做了极端操作;公司没有有效的备份恢复机制。针对这两个问题，网上也有网友列出了自己的想法，小编罗列了几点。
- 使用云产品，微盟虽然跑在云上，但是很显然并没有直接使用云数据库产品，应该是用了云的裸金属或者是虚拟机，然后在服务器上自己搭建的MySQL数据库。因为从我们使用的经验看，当前任何一家公有云厂商的数据库产品，都会有比较完善的自动备份和恢复机制，而且根本没有机会去执行rm -rf 和 fdisk这样极端的操作。
- 做好备份。如果真心觉得自己有能力自建，那一定做好全量备份，增量备份，延迟备份，全量备份要多机房，异地备份，因为数据是核心资产，应用全删了还可以重新部署。
- 关于权限控制，中小型企业如果真的没法做到最小授权，建议上个主机安全管控软件，或者堡垒机，各个云厂商都有，类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的。
技术人自觉才是保护用户数据的最后防线
最近几年，由于技术人员故意或者有意造成的事故不计其数。2018 年 3 月，Stack Overflow 发布了他们的开发者调查报告，并首次提出了有关道德的问题。对于“开发人员是否有义务考虑代码的道德影响”这个问题，有近 80%的人回答“是”。不过，只有 20%的人认为他们最终在为不道德的代码负责，40%的人会在被要求的情况下写不道德的代码，只有 50%的人表示在发现不道德的代码时会举报。
如果代码对世界的影响不大，那么这也许就不成问题。打个比方，如果你写了一个对 100 个人不利的算法，虽然这事不怎么光彩，但产生的影响也是有限的。但是，如果你在拥有数亿用户的 Facebook、Google、微信上做同样的事情，结果就会很严重。
对于开发者来说，光是每天写业务代码就已经让人心力交瘁了。更何况不管在国内还是国外，技术在大部分时候都是为业务服务，开发者的话语权是拗不过盈利这条大腿的。但是，遵守职业道德是最后的底线，如果技术人员做不到这一点，那保护用户数据的最后一道防线就会崩塌。
所以，技术人的自我修养，在纷繁复杂科技产物的当下显得更加关键。
