文档介绍：

种故障的人、大多会给 rm 上个别名 A liasrm=\'rm -i\' 同理、cp 和 mv 也可以有同样的选项：
aliascp=\'cp -i\' alias mv=\'mv -i\' 对window而言，shift+del文件或者书目对任何系统而言，无备份干脆修改文件等
三、备份并验证备份的有效性
不管是硬件还是软件总有意外崩溃的时候，怎么办？备份！！！备份的学问很大、根据不同的维度可以分：冷备和热备、实时和非实时、物理和逻辑、全备增量备。
备份有了、可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 复原，简洁的验证就是找个空库复原出来。

四、对生产环境永保敬畏之心
这是避开应用系统发生故障的一条铁规，也是被开发、运维人员简单忽视的地方。要坚决杜绝干脆在生产环境做开发、测试和bug修复，这些操作只能在开发和测试环境做，否则一旦出事，将欲哭无泪。
五、交接和休假最简单出故障
接手别人的工作要一而再，再而三的确认变更方案，请教人并不见得就是实力不行的表现；
· 休假前最好各种可以做好的事情，最好能够打算一份文档，指明在什么状况下怎么做和联系哪些人；
· 在别人放假的时候接手工作，“能拖则拖”，实在须要执行：必需不厌其烦的跟原系统管理人员确认各个操作细微环节。 ·
六、肯定要有监控手段和报警措施
运维人员赖于生存的工具就是报警和监控。
报警可以让你刚好知道系统出现了什么异样、以便刚好跟进、把故障扼杀于摇篮；
· 监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替、早做优化。 ·

报警和监控是衣宽带水的好兄弟、相铺相成、相互促进。
七、运用自动切换技术需谨慎
为了保障数据库平安，往往会运用HA或者RAC之类的技术，但是这类技术能否真正在关键时刻起作用，则是须要经过反复验证和确认的。并不是根据文档要求做好了就够的，许多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。假如到事后才发觉这一点，将悔之晚矣。
八、要有偏执狂的精神，方案要检查，检查，再检查
有这么一个人： ① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人
② 在测试机上写好脚本，召集大家 review 操作步骤和脚本 ③ 测试完成以后拷贝到生产环境
④ 登录对应机器，“打开，关闭，打开，关闭”该脚本
⑤ 跟相关人员再次确认执行的操作，依次，时间点，可能的影响和回滚是否都打算好了
⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本 ⑦ 最终才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出

期间姿态端正，呼吸急促而匀称，眼神凝重。操作的人不觉得累，倒是一边观摩的人很累。
九、简洁即是美
我们总是面临各种诱惑：新的系统架构，新的更智能的吩咐和工具，最新的硬件平台，功能更全的HA软件...你可以在线下安装，测试，怎么做都行。但是假如想要在生产环境下运用起来、请三思！！
能够运用系统内置吩咐的话，就不用考虑其他要