由 dawei 事件引发了持续的热议，其中也不乏争议，针对关注度较高的问题，包括防止运维人员的骚操作、如何兼顾运维效率与安全、事件中的甲乙两方存有哪些不足、企业等保工作如何开展和有效落地等，dbaplus社群整理并归总观点如下，希望能给大家今后相关工作的展开和处理提供参考：
1、如何防止运维人员在生产环境搞测试、自己编写程序连生产库等骚操作?
权限控制+日常审计。对核心生产环境进行白名单机制，明确每一个终端每一个账号的连接以及进程，对异常情况进行阻断或监控。
除了grant权限以外，给予开发运维人员slave或dev环境。
通过运维系统和堡垒机隔离运维人员和服务器。程序要纳入代码管控，严禁文件上传下载。
2、运维人员应不应该为了工作之便在客户系统上使用自己编写的工具?
要有授权，要经过测试，要经过许可。据我了解电力行业的一些规范，要推行软件、工具，甚至要去电科院进行测试，获得证书才可部署试行。所以如果甲方要求不太严格，可以把自己的工具拿出来一起评审，没问题的话搞就行，切忌私自运行。
运维人员不应该有权限在客户的系统上运行自己编写的程序，所有程序必须是公对公的行为。包括各种脚本，都是需要进行代码review的，实验过没问题才可以上。
3、流程一旦复杂，势必会影响运维的效率，应该怎么设置运维人员的工作流程、权限划分才能兼顾到效率与安全?
甲方自身没有对系统的管控能力，还应用于核心系统，等于把命脉交在别人手里。所以甲方应该把日常工作流程化，有明确的操作流程，并对乙方的权限划分遵循最小化赋权，最好由堡垒机录屏，定期审计外包操作内容。
这个还是得看业务的重要性和核心生产环境的操作，一定要有确认、复审的流程，然后才能执行，这一块一定要严格。实际上有些方法是可以在技术方面杜绝一些高危操作的，比如细化权限分配和明示高危操作，不同的账号做不同的事情，精细化分工;阻断drop，rm-rf等高危操作。在核心问题方面，质量可以大于效率。
关于流程跟标注化或者规范化的实施及操作，长期以来我只奉行一个观点：凡是不能通过代码来表达的流程、规范/标准化都是在扯淡。公司项目多了，人也多了之后不可能每一个人都会严格遵循流程来的，一旦有一个人失误就会造成事故，因此现在很多公司都在推行DevOps不是没有道理的。
流程复杂尽量使用脚本操作，或者类似Python Ansible的工作。
4、事件中可以看出乙方存有哪些不足?
其实这个事故本来可以快速定位并解决的，结果耗时这么久!从解决该问题的运维人员的操作复盘来看，第一时间居然是通过plsql看问题，这显然是存在问题的。我想象的处理场景应该是外包公司有一套可靠的监控系统(通过员工复盘过程可以看出监控系统应该还是有的，但为何监控没有第一时间预警，这里也存在问题)，当发现异常后运维/DBA应该能通过平台去定位问题甚至解决问题，显然该乙方在平台化方面做的有所欠缺。