运维工作经验个人总结：远离系统故障的一些方法
一、变更要能回滚、先在同样的环境测试过
佛说：每次创伤、都是一次成熟，这便是运维人员的真实写照。
从某种意义上讲、运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你不期而遇的痛击，请保护现场，让变更有回头的机会。
二、对破坏性的操作谨慎小心
什么是破坏性的操作？
比如：对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！
对 Linux 而言：rm -r所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名。
alias rm='rm -i'
同理，cp 和 mv 也可以有同样的选项：
alias cp='cp -i' alias mv='mv -i'
三、设置好命令提示
在操作之前、先理清你所在的是主库、备库？当前目录？哪个 schema？session？时间？
比如：对 Oracle 来讲：
[plain] view plaincopy idle> set sqlprompt 'RAC-node1-primary@10g>>' RAC-node1-primary@10g>>
当然、你也可以在 glogin.sql里面设置。
对于 Linux 而言、bash 环境的提醒可设置 PS1 来知道当前目录、登陆用户名和主机信息等；
对 PS1 更多理解、请见：man PS1
四、备份并验证备份的有效性
人非圣贤、岂能无过？是机器总有计划内或计划外崩溃的一天。怎么办？备份！！！
备份的学问很大、按照不同的维度可以分：冷备和热备；实时和非实时；物理和逻辑。OLTP 7*24 在线业务、DB 就需要有实时热备。这样就可以了吗？
如果开发人员的一个不带任何条件的 delete 误删所有数据，此时你除了实时、还需要有非实时的备份、把 DB 从逻辑错误中恢复出来。
备份有了、可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。
五、对生产环境永保敬畏之心
会计人员在从业之前、都有个职业操守的训练。同理、这也应该是运维人员进入行业首先需要具备的素养。
比如：
于 Oracle 而言、你可以跑一个 RDA 巡检 DB 的健康状况；于 Linux 而言、是否有 password aging、隔离外网等。
六、交接和休假最容易出故障、变更请谨慎
接手别人的工作要一而再、再而三的确认变更方案。请教人并不见得就是能力不行的表现；
休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人；
在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原运维者确认各个操作细节。
七、搭建报警、及时获取出错信息；搭建性能监控、预测趋势
运维人员赖于生存的工具就是报警和监控。
报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮；
监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替嘛、早做优化。
报警和优化是衣宽带水的好兄弟、相铺相成、互相促进。
八、自动却换需谨慎
比如：Oracle 存储级的HA方案：Data Guard，主库提交了一笔订单，结果发生了 switchover，这笔订单没有同步到备库，那么卖家损失了一个销售单、对客户、对公司都是损失。
九、仔细一点，偏执一点，检查、检查，再检查
有这么一个人：
他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人；
在测试机上写好脚本，召集大家 review 操作步骤和脚本；
测试完成以后拷贝到生产环境；
录对应机器，“打开，关闭，打开，关闭”该脚本；
跟相关人员再次确认执行的操作、顺序、时间点，可能的影响和回滚是否都准备好了；
行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本；
后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出。
期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边学习的人很累。
十、简单即是美
这有点禅的意境、和 GNU/Linux 的思想不谋而合。
我们总是面临各种诱惑：新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件…你可以在线下安装，测试，怎么做都行。但是如果想要在生产环境下使用起来、请三思！！
能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了
脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做
Linux本身自带的字符界面比那些复杂的图形界面要简洁方便……
最后祝大家运维工作一帆风顺，多福多寿，不出故障。
