从微盟删库事件看数据备份和项目管理
in 项目管理 with 0 comment

从微盟删库事件看数据备份和项目管理

in 项目管理 with 0 comment

3 月初,闹得沸沸扬扬的「微盟删库」事件终于有了一个解决方案,也让不少技术人唏嘘不已,一个上市公司的数据备份和项目管理流程居然如此不堪。

事故经过

先来看下此次事故的时间线。

从数据恢复的时间上看,微盟的数据备份肯定有重大问题,不然也不会在腾讯云的协助下这么久才找回全部数据。

数据备份

对于一家业务型的公司来说,数据的丢失,可以说是致命的打击!更何况是一家上市公司!

客观说,微盟这家公司的数据备份意识太淡薄了,备份流程等肯定也有重大问题,否则也不会出现这次严重事故。

正常情况下,数据库应该根据业务设置读写分离、主从库,且定期备份全量数据库。

我上家公司最开始的时候虽然只有一个库,但是一周也会备份几次。甚至融资尽调的时候,还是一个库,所有的数据都是这个单库查出来的,现在想想都后怕,万一出点问题,那融资可能就黄了。后来随着业务慢慢发展,数据量逐渐变大,项目重构,数据库读写分离,主从库等策略也都安排上了。

数据备份的意识必有再三强调,绝对是重中之重,不仅是数据库的数据,任何跟公司业务相关的数据都要妥善保存并定期备份。

权限管理

涉及到线上数据的,必须要有相应的权限管理。

举个例子,在使用项目后台管理系统的时候,要根据人员的身份设置不同的操作权限。例如客服只能查看用户的和订单等相关信息,没有修改权限,客服主管有部分数据的修改权限;活动运营人员,只能开放活动配置权限和相应活动的数据查看权限等。

此外,在申请后台管理账号的时候,也要进行邮件审批,申请人发邮件写明申请人信息及申请的权限,由其部门主管审批,然后再由技术部门主管审批,审批后交由负责管理的人员统一进行账号和权限配置,并将账号信息发送给申请人。

关于线上数据库相关操作,开发人员如果要进行 DDL 或 DML 操作,需要向其技术主管进行申请,审批通过后由 DBA 或运维人员进行执行操作。

简单介绍下 SQL 语言的几种操作数据库的能力:

DDL允许用户定义数据,也就是创建表、删除表、修改表结构这些操作。通常,DDL由数据库管理员执行。

DML为用户提供添加、删除、更新数据的能力,这些是应用程序对数据库的日常操作。

DQL允许用户查询数据,这也是通常最频繁的数据库日常操作。

当然,以上都是我之前工作的一些经验,不同公司可能有不同的流程,但是归根结底,就是让相关人员知晓跟数据相关的操作,从而避免数据泄露和数据库误删。

项目管理

微盟事件,看似是在数据备份和权限管理方面出了问题,但是在我看来,这不过是整个项目管理流程上暴露的冰山一角。

我个人从一个 Android 开发转做项目经理,最开始的时候也没有一套可以依据的项目管理流程。但是随着在项目开发的过程中不断总结,不断改进,逐渐总结出了自己的一套项目管理的流程,可能并不完全适合他人照搬,但涉及到的部门协作和管理流程是类似的。

一个项目从需求收集到开发测试,直至最后的上线,也就是 DBA 或运维人员进行线上数据库操作和程序的发布,其实只是整个项目管理中的一部分。后面的文章会将会详细说明每个步骤中的注意事项。

项目管理流程最难的部分不是在整理流程,而是在执行方面,一个制度很容易就能制定出来,但是要执行起来困难还是挺多的。

就我个人经验而言,最怕的就是技术领导不重视、不按流程走,如果是偶尔的紧急需求那无可厚非,但经常不按流程走,那就很危险了。所谓上梁不正下梁歪,技术领导都不当回事,下面的技术经理和开发人员会当回事吗?

长此以往,可能不会出现微盟那么严重的删库事件,但是线上数据误操作肯定会有的。退一步讲,人非圣贤孰能无过,出问题也是常有的事,但是就怕出了问题不优先解决问题,而是先甩锅,还不总结教训,这就很可怕了,更可怕的是这还是技术领导的所作所为。

这次的微盟的事故,其 CTO 有很大的责任,他对数据备份和项目管理流程肯定不够重视。

权限管理和项目管理的存在就是为了规避某些可以避免的误操作,人确实会犯错,但是能避免的错误为什么不去尽力避免呢?不论是对个人还是对公司,能严格执行权限管理和项目管理流程,并且培养基本的备份意识,都是有好处的。

欢迎关注我的公众号,及时获取最新文章推送。
0评论