一个机构在生产系统上直接输入数据库命令进行维护的场合越多,就越能证明该机构的运维能力薄弱,应用系统的功能不完备。
笔者在实践中发现一些中小银行机构因为系统不完善,在出现业务差错时经常在生产数据库中用SQL命令进行数据修改,这是一种非常危险的做法,一旦失误就会造成灾难。
如果非要在生产系统上输入命令进行管理时,不要指望运维人永远不犯错,应该进行双人操作,一人输入命令,一人进行审核,检查执行命令的设备和操作对象是否安全,在审核者同意后再执行命令。
最好的做法是把系统管理维护操作程序化,以技术手段托底,把事情交给经过测试的程序来做,这些程序的测试就在平时的应急演练中进行,通过应急演练验证维护程序的功能是否完备。统维护是高强度的工作,是否能确保在紧急状态下有后备维护人员来接替疲劳的维护人员?
2.进行危险操作(对生产数据库直接输入命令进行数据变动或者变更配置等)时系统管理人员工作的精神状态是否良好?
3.是否带病工作或者服用了会导致精神状态不佳的药物?是否饮酒后工作?
4.运维人员是否有删库跑路的动机?
有些机构的备份机制很多,但是华而不实,造成了三个和尚没水吃的尴尬状况。
千招会不如一招精,能把一两种备份恢复机制在应急演练中练精摸透,扬长避短,在数据库出现问题时真正解决问题,远比华而不实的备份机制有效。
企业的运维团队应考虑这几个问题:
1.在紧急状况下进行系
很多机构的应急预案,大多数是针对自然灾害等不可抗力和设备损坏及网络中断而制定。
对于因系统管理失误造成的数据库损坏,是否制定了应急预案,应急预案是否可行,平时的应急演练是真演实练还是走过程都要进行深入地思考。
对于生产环境下的“rm-rf”类的命令,应改造,例如把rm命令改个名字,再写个脚本替换,脚本里面做判断,如果有人执行“rm -rf”命令,就调用rmdir去删除等。
一般来说,开发人员是不允许操控生产数据库的,顺丰科技数据中心的开发人员拥有删除数据库生产数据库权限,说明负责机构的数据库权限管理有很大的缺陷。
笔者认为,目前实现运维自动化有些操之过急,其原因是运维自动化目前缺乏成功的案例,可靠性不得而知,基于目前在的状况,先实现运维程序化,再考虑运维自动化,是一种比较保险的策略。