运维工作心得总结
运维工作直接关系到应用系统运行的正常稳定，但运维工作纷繁复杂，正规化、系统化相对比较弱，如何改变这种现状？从众多的运维工作者的成功失败中进行经验总结，并提升为运维规则，是提高运维水平，保障应用系统正常稳定运行的有效途径。
笔者通过自己的多年运维经验，总结出以下必须遵守的基本运维规则，可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。
一、系统变更、升级应先在同样的环境测试通过，执行前应有经过验证的回退预案
运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题，因此变更前，一定要在相同或者相似运行环境下进行测试，通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案，比如，做好系统备份、数据库备份、配置备份，固化变更前的运行现场，让变更有回头的机会。
二、对破坏性的操作要先确认符合预定方案，然后谨慎执行
什么是破坏性的操作？ 比如：
对MSSQLServer，执行update操作，因为不需要commit，所以特别容易忽视也特别危险，还有delete、drop等操作更不用说。
对 Oracle 而言：truncate table_name、delete table_name、drop table_name，这些语句执行起来轻松简单也惬意极了、但记住！即便数据可被回滚、代价也是非常大！
对 Linux 而言，rm -r 所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给 rm 上个别名 A liasrm=\'rm -i\' 同理、cp 和 mv 也可以有同样的选项：
aliascp=\'cp -i\' alias mv=\'mv -i\' 对window而言，shift+del文件或者目录 对任何系统而言，无备份直接修改文件等
三、备份并验证备份的有效性
不管是硬件还是软件总有意外崩溃的时候，怎么办？备份！！！备份的学问很大、按照不同的维度可以分：冷备和热备、实时和非实时、物理和逻辑、全备增量备。
备份有了、可以高忱无忧了吗？不行！尚须验证备份的有效性。一个总有那么几次、备份无法保证 100% 恢复，简单的验证就是找个空库恢复出来。
四、对生产环境永保敬畏之心
这是避免应用系统发生故障的一条铁规，也是被开发、运维人员容易忽视的地方。要坚决杜绝直接在生产环境做开发、测试和bug修复，这些操作只能在开发和测试环境做，否则一旦出事，将欲哭无泪。
五、交接和休假最容易出故障
接手别人的工作要一而再，再而三的确认变更方案，请教人并不见得就是能力不行的表现；
休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人；
在别人放假的时候接手工作，“能拖则拖”，实在需要执行：必须不厌其烦的跟原系统管理人员确认各个操作细节。
六、一定要有监控手段和报警措施
运维人员赖于生存的工具就是报警和监控。
报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮；
监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替、早做优化。
报警和监控是衣宽带水的好兄弟、相铺相成、互相促进。
七、使用自动切换技术需谨慎
为了保障数据库安全，往往会使用HA或者RAC之类的技术，但是这类技术能否真正在关键时刻起作用，则是需要经过反复验证和确认的。并不是按照文档要求做好了就够的，很多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。如果到事后才发现这一点，将悔之晚矣。
八、要有偏执狂的精神，方案要检查，检查，再检查
有这么一个人： ① 他在做一个变更的时候，会先提前一两周发送邮件并电话手机通知相关人
② 在测试机上写好脚本，召集大家 review 操作步骤和脚本 ③ 测试完成以后拷贝到生产环境
④ 登录对应机器，“打开，关闭，打开，关闭”该脚本
⑤ 跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了
⑥ 执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本 ⑦ 最后才在后台运行脚本，同时在另外一个窗口登录着，随时ps和查看结果输出
期间姿势端正，呼吸急促而均匀，眼神凝重。操作的人不觉得累，倒是一边观摩的人很累。
九、简单即是美
我们总是面临各种诱惑：新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件...你可以在线下安装，测试，怎么做都行。但是如果想要在生产环境下使用起来、请三思！！
能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了 脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做 Linux本身自带的字符界面比那些复杂的图形界面要简洁方便
如果能做到坚持这九条铁规，你的应用系统就能长久稳定运行了。
