生产数据库是否该对开发人员设限?

dbaplus 2015-09-28 15:42:00
话题

Topic

一个DBA老师正在苦逼地恢复被开发删除的数据。作为一家有100人以上IT人员的公司,开发人员是否应该碰生产库?能做得到不碰吗?(本期话题贡献人:杨志洪)

 

 

 

精彩论点
 
 


【杨建荣】root,dba权限严格来说都是不能开放的,我们原来电信行业对sys、system都不能开放,会给一个单独的dba账户。

 

我们的开发是没有权限的,要做任何核心数据的查询都得提申请,有一些外围的会开放只读备库权限,权限精确到对象。我碰到过一个例子,因为需要访问不同用户下的表,最后dba给所有用户都是dba角色,不过开发似乎还是没有意识到。举个例子,某同事之前在国内某移动支持,想看看自己的手机号信息,一个sql语句下去,审计就发邮件了,为什么要做这个查询。我知道的做法是个人账号不开防火墙,只能通过某个指定的服务器去访问,可能还要跳几个网段。

 


 

【洪建唯】没有开发做出来的应用,要dba干啥?dba本身就是服务性的,再说了数据库软件难道不是开发做出来的吗?开发那套东西是以实现功能为目的的,比如开发工具,uml,各种框架,根本不去考虑sql执行效率之类的,所谓开发团队必须要有个开发dba辅助,上线后,那是运维dba去负责了。开发出功能,管理出性能开发和运维就是乾和坤的关系。没有做过开发的dba,不会理解很多东西。系统本身就是一体的,缺哪个东西都很难受的。整个系统必须满足用户的愿景,用户看到的体会到的是应用程序本身,根本不知道什么是数据库。所以首先需要开发去满足用户的功能,纯讲功能显然不行,系统必须要稳定,高效,就必须有运维人员。

 


 

【kingx】我认为开发不应该碰生产,生产数据库只有运维专业dba处理,开发要处理就走流程,把脚本发过来,运维审核后再执行。如果脚本内容有误,处理方式是全部回滚。而查数据,我是给他们一个ADG备库,考虑数据安全性,也只是针对个别开发。提供一个桌面虚拟化,限制他们直接取数据,要数据则要走流程。

 


 

【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自己的那一块业务)。但是几个大的银行倒是没有发现这个情况。

 

众说纷纭
 
 
 
 
 

【香草拿铁】现在应用迭代很快,因此应用总会有些问题,需要查询数据以定位问题,但也只能限于只读。个人建议还是要让专业的人做专业的事。

 
 
 

 

 
 
 

【田力】不接触生产很难。两方面考虑:管理上要有规范。这个规范不是法律,主要目的是为了争取主动权与话语权。技术上还是要有防误删的手段。

 
 
 

 

 
 
 

【北极熊】还是要让专业的人做专业的事。如果开发轮岗运维没有什么问题。运维轮岗开发就有问题、需要时间成本很大。

 
 
 

 

 
 
 

【yellow】开发人员不应该有非只读用户。相当一部分公司的开发承担着应用运维工作,特别是甲方。都有实名账户的。

 
 
 

 

 
 
 

【alex-t】开发提ticket, dba操作;权限一定要分清并严格执行。

 
 
 

 

 
 
 

【Yiwei Du】开发在生产库上只能给readonly,备份最好交给dba之外的team。

 
 
 

 

 
 

【robo】回收生产用户,对开发人员开放只读账户。

 
 
 

 


 

【鸣 谢】

在“DBA+社群”各大城市微信群进行的“周末话题”讨论活动中,得到了北京、上海、济南、福州、杭州、香港六大城市群的联合发起人以及群友们的积极参与和支持。在此,小编整理成文,并附上所有发表观点的人员头像汇总图,特此鸣谢!

 
 

 

各群话题发起人
生产数据库是否该对开发人员设限-1

 

发表观点的群友
生产数据库是否该对开发人员设限-2
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告