【Lei】 开发db与生产db应该物理隔离；开发db的数据库名应该与生产db不一样；开发db的上的用户密码（root用户，sys用户，system用户，应用程序的用户）应该与生产db不同。开发工程师如果确需上生产db，需经相关部门领导审批，同时应该有dba陪同并开启屏幕录像，并签订生死状：若是错误的删除了生产db的数据，一切后果由开发负责。

开发人员不应该有生产数据库服务器的登录帐号。数据库的连接权限只来给相应的应用服务器，只有自己的业务帐号连接数据库即可，权限当然是在满足业务的条件下越小越好，可以通过权限和流程保障，上线的应用通过配管部门上线。这是一个规范，你如果直接操作了，可以通过日志查出来，违反规范受处罚呗。

【太虚山寺】 有时开发会以开发环境没有生产数据，无法错误重现为由强行要求开权限。 我认为拥有公司级的数据库规范及其重要，如果账号密码开发都知道，万一开发偷摸上生产搞一下，那么出了问题 dba 是死得最快的。而且没有公司规定的时候，开发要上生产系统拦也拦不住，开发地位比我们高，一句我要上生产系统解决问题，不给上的话最后汇报到管理层错还是在我。但是如果有了规定，那么代表领导也认可，再有问题我们就不用担全责了。

【djs数据库】 开发人员可否碰生产数据，在于这个公司的管理制度。开发人员要具备生产意识，在运维岗位轮岗半年。开发运维人员经常互换，大家目标统一，责任共担，例如华为。开发，运维，销售都相互轮岗过（限制在一定比例）。IPD集成的开发模式，IBM推荐的流程。目前很多公司把开发运维人为隔离，却还是未能避免事件，那么，大家可否换一个思路管理？就像经常看到文章中描述的，生产降落伞的人自己去试用，这个质量应该很高吧。

【十一月肖邦】 一句话，开发用户是否有dba角色，有的话各位回去打板子；开发用户是否有root密码，开发用户是否在oracle组里；有的话，必须要打板子。必须要限制开发以及应用维护的权限。职责必须和职能分开，不然每天就去扯皮了。携程是最好的例子。经验告诉我，环境越复杂，控制必须越严格。很多公司开发的权限无比大。root,dba角色绝对不能放给开发。

【tony】 rotate不是没有可能，但一定是在知道范围下选择性体验，非完全替换。uat很重要，不需要有朋生产。开发再怎么发现数据错误都不能碰生产，都需要提交变更申请。由该做的人去做，哪怕只是一个dml。以前我在甲方时，是需要严格制定各种规范的。下面的人多，库也多，我们当时IT人员就差不多1000人，全国估计几千了，所以权责一定是分离的。每个 dba 都不可能有每套环境的账号，甚至IP都访问不了。

运维是一个大课题。运维与研发是相互牵制又相互发展的，而不是相互约束。生产、UAT、开发环境都是独立的，当然每个公司都有自己特殊的地方，有自己不同的管理方式，就看什么样的方式是最适合自己公司的。争执是无用的，只有每个部门从自身找改进的点才是最重要的，所以说IT部门是一个复杂的系统，除了规范和制度。当然，各公司的ODS和EDW是个特例。像华为、海尔、顺丰这样的ODS或者EDW，开发人员就会有一些权限可以登陆过去（当然不可能是SYS之类的，一定是focus自己的那一块业务）。但是几个大的银行倒是没有发现这个情况。