避免在生产系统上直接输入命令进行系统管理

一个机构在生产系统上直接输入数据库命令进行维护的场合越多，就越能证明该机构的运维能力薄弱，应用系统的功能不完备。

笔者在实践中发现一些中小银行机构因为系统不完善，在出现业务差错时经常在生产数据库中用SQL命令进行数据修改，这是一种非常危险的做法，一旦失误就会造成灾难。

系统管理维护双人操作机制的落实

如果非要在生产系统上输入命令进行管理时，不要指望运维人永远不犯错，应该进行双人操作，一人输入命令，一人进行审核，检查执行命令的设备和操作对象是否安全，在审核者同意后再执行命令。

最好的做法是把系统管理维护操作程序化，以技术手段托底，把事情交给经过测试的程序来做，这些程序的测试就在平时的应急演练中进行，通过应急演练验证维护程序的功能是否完备。统维护是高强度的工作，是否能确保在紧急状态下有后备维护人员来接替疲劳的维护人员？

2.进行危险操作（对生产数据库直接输入命令进行数据变动或者变更配置等）时系统管理人员工作的精神状态是否良好？

3.是否带病工作或者服用了会导致精神状态不佳的药物？是否饮酒后工作？

4.运维人员是否有删库跑路的动机？

备份机制是否有效

有些机构的备份机制很多，但是华而不实，造成了三个和尚没水吃的尴尬状况。

千招会不如一招精，能把一两种备份恢复机制在应急演练中练精摸透，扬长避短，在数据库出现问题时真正解决问题，远比华而不实的备份机制有效。

系统维护人员的生理和心理问题

企业的运维团队应考虑这几个问题：

1.在紧急状况下进行系

针对数据库灾难的应急预案是否完整

很多机构的应急预案，大多数是针对自然灾害等不可抗力和设备损坏及网络中断而制定。

对于因系统管理失误造成的数据库损坏，是否制定了应急预案，应急预案是否可行，平时的应急演练是真演实练还是走过程都要进行深入地思考。

对关键应用服务器上的危险命令进行限制

对于生产环境下的“rm-rf”类的命令，应改造，例如把rm命令改个名字，再写个脚本替换，脚本里面做判断，如果有人执行“rm -rf”命令，就调用rmdir去删除等。

开发人员使用生产数据库的权限问题

一般来说，开发人员是不允许操控生产数据库的，顺丰科技数据中心的开发人员拥有删除数据库生产数据库权限，说明负责机构的数据库权限管理有很大的缺陷。

关于运维自动化

笔者认为，目前实现运维自动化有些操之过急，其原因是运维自动化目前缺乏成功的案例，可靠性不得而知，基于目前在的状况，先实现运维程序化，再考虑运维自动化，是一种比较保险的策略。