3 月初，闹得沸沸扬扬的「微盟删库」事件终于有了一个解决方案，也让不少技术人唏嘘不已，一个上市公司的数据备份和项目管理流程居然如此不堪。
事故经过
先来看下此次事故的时间线。
- 2 月 23 日，因公司员工恶意破坏公司线上生产环境及数据，导致公司系统服务不可用。目前，该犯罪嫌疑人已被公安机关刑事拘留。
- 2 月 25 日，紧急恢复了核心业务的线上生产环境，新用户使用不受影响，并提供老用户临时过渡方案。
- 2 月 28 日，恢复了所有业务的线上生产环境，并且开放了老用户登录，以及恢复了微站产品的所有数据。
- 截止到 3 月 1 日晚 8 点，在腾讯云团队的协助下，全面找回数据。
- 3月2日，进行数据恢复上线演练，在此期间系统会停止服务。
从数据恢复的时间上看，微盟的数据备份肯定有重大问题，不然也不会在腾讯云的协助下这么久才找回全部数据。
数据备份
对于一家业务型的公司来说，数据的丢失，可以说是致命的打击！更何况是一家上市公司！
客观说，微盟这家公司的数据备份意识太淡薄了，备份流程等肯定也有重大问题，否则也不会出现这次严重事故。
正常情况下，数据库应该根据业务设置读写分离、主从库，且定期备份全量数据库。
我上家公司最开始的时候虽然只有一个库，但是一周也会备份几次。甚至融资尽调的时候，还是一个库，所有的数据都是这个单库查出来的，现在想想都后怕，万一出点问题，那融资可能就黄了。后来随着业务慢慢发展，数据量逐渐变大，项目重构，数据库读写分离，主从库等策略也都安排上了。
数据备份的意识必有再三强调，绝对是重中之重，不仅是数据库的数据，任何跟公司业务相关的数据都要妥善保存并定期备份。
权限管理
涉及到线上数据的，必须要有相应的权限管理。
举个例子，在使用项目后台管理系统的时候，要根据人员的身份设置不同的操作权限。例如客服只能查看用户的和订单等相关信息，没有修改权限，客服主管有部分数据的修改权限；活动运营人员，只能开放活动配置权限和相应活动的数据查看权限等。
此外，在申请后台管理账号的时候，也要进行邮件审批，申请人发邮件写明申请人信息及申请的权限，由其部门主管审批，然后再由技术部门主管审批，审批后交由负责管理的人员统一进行账号和权限配置，并将账号信息发送给申请人。
关于线上数据库相关操作，开发人员如果要进行 DDL 或 DML 操作，需要向其技术主管进行申请，审批通过后由 DBA 或运维人员进行执行操作。
简单介绍下 SQL 语言的几种操作数据库的能力：
- DDL：Data Definition Language
DDL允许用户定义数据，也就是创建表、删除表、修改表结构这些操作。通常，DDL由数据库管理员执行。
- DML：Data Manipulation Language
DML为用户提供添加、删除、更新数据的能力，这些是应用程序对数据库的日常操作。
- DQL：Data Query Language
DQL允许用户查询数据，这也是通常最频繁的数据库日常操作。
当然，以上都是我之前工作的一些经验，不同公司可能有不同的流程，但是归根结底，就是让相关人员知晓跟数据相关的操作，从而避免数据泄露和数据库误删。
项目管理
微盟事件，看似是在数据备份和权限管理方面出了问题，但是在我看来，这不过是整个项目管理流程上暴露的冰山一角。
我个人从一个 Android 开发转做项目经理，最开始的时候也没有一套可以依据的项目管理流程。但是随着在项目开发的过程中不断总结，不断改进，逐渐总结出了自己的一套项目管理的流程，可能并不完全适合他人照搬，但涉及到的部门协作和管理流程是类似的。
一个项目从需求收集到开发测试，直至最后的上线，也就是 DBA 或运维人员进行线上数据库操作和程序的发布，其实只是整个项目管理中的一部分。后面的文章会将会详细说明每个步骤中的注意事项。
项目管理流程最难的部分不是在整理流程，而是在执行方面，一个制度很容易就能制定出来，但是要执行起来困难还是挺多的。
就我个人经验而言，最怕的就是技术领导不重视、不按流程走，如果是偶尔的紧急需求那无可厚非，但经常不按流程走，那就很危险了。所谓上梁不正下梁歪，技术领导都不当回事，下面的技术经理和开发人员会当回事吗？
长此以往，可能不会出现微盟那么严重的删库事件，但是线上数据误操作肯定会有的。退一步讲，人非圣贤孰能无过，出问题也是常有的事，但是就怕出了问题不优先解决问题，而是先甩锅，还不总结教训，这就很可怕了，更可怕的是这还是技术领导的所作所为。
这次的微盟的事故，其 CTO 有很大的责任，他对数据备份和项目管理流程肯定不够重视。
权限管理和项目管理的存在就是为了规避某些可以避免的误操作，人确实会犯错，但是能避免的错误为什么不去尽力避免呢？不论是对个人还是对公司，能严格执行权限管理和项目管理流程，并且培养基本的备份意识，都是有好处的。
欢迎访问的个人博客：掘墓人的小铲子
