运维工作经验总结 运维工作直接关系到应用系统的正常稳▲定运行，但运维工作复杂，形式化、系统化相对薄弱。如何改变这种状况▂？从众多运维人员的成败经验中总结并↑升级为运维规则，是提高运维水平、保障应用系统正常稳定运行的有效途径。通过我多年的运维经〒验，笔者总结了以下必须遵守的基本运维规则，可以大大降低没有经验的运维人员由于自己的失误导致ξ　系统故障的可能性。 一、系统变更和升级要先在卐同一个环境下测试，实施前要有经过验证的计划。运维是一门经验学科，也是一◆门试错的学科。没有做的事情总会给你带来意想不到的问题，所以在进行更改之前，你必须在︼相同或相似的运行环境中对其⌒进行测试，并且只有通过测试后才能在正式环境中实施更改。同时，应该为失败的更改准备一个后备√计划。比如系统备份、数据库备份、配置备份等都要做好▃准备，把变更前的操作站点固化下来，让变更有机会回去。 二、破坏性操作必须按照预定计划确认，然后谨慎执行。什么是破坏∞性操作？例如：是的，执行操作，因为它们不是必需的，它们很容易被忽略和危险it运维，更不用说drop之类的操作了。就: , , drop 而言，这些语句执行起来既简单又舒适，但请记住！即使数据可以回滚，成本也是非常高的！对于 Linux，rm 将删除Ψ所有当前数据及其所有子目录。

经历过这种失败的人大多会给rm一个别名=′rm mv 也可以有同样的选项： 比如不备份直接修改文↘件等三、备份并验证备份的有效性，遇到硬件或软件总是意外死机怎么办？备份！ ！ ！备份知识非常丰富，可以分为不同的∩维度：冷备份和热备份、实时和非实时、物理和◣逻辑、全量和增量备份。有了备份，你能无后顾之忧吗？不！备份的有效性还有待验证。备份总是有很多次无法保证100%恢复。简单的验证就ζ是找到一个空的数据库来恢复它。 四、 永远敬畏生产环境 这是避免应用系统故障的铁律∞，也容易被开发人员和运维人员忽视。我们必须坚决杜绝直接在生产环境中进行开发、测试和bug修复。这些操作只能在开发和测试环境中』进行。否则，如果出现问题，我们将哭无泪。 五、 交接和休假是最容↙易失败的。接手别人的工作需要反复确认变更计划。向人们征求意见并不一定是无能的表现；最好准备一份文件，说明在什么情」况下如何操作以及与谁联系；在别人放假的时候接手，“可以延迟”，确实需要执行：一定要不㊣　厌其烦的跟原系统管理员确认每一个操作的细节。

六、要有监控方法和报警措★施。运维人员生存的工具是报警和监控。报警可以让您及时了解系统发生△了什么异常，从而及时跟进，扼杀摇篮中的故障；报警与监控是衣与水的好①兄弟，相得益彰，相得益彰。 七、使用自动切换技术时要小心为了保证数据库安全，经常会☉用到HA或者RAC等技术，但是这些技术在关键时刻能否真正发挥作用，还需要反复验证和确认。仅仅按照文件的要求做好是不够的。许多意想∴不到的因素或系统因素会导致自动切换技术无法按预期工作。如果你以后发现这一点，那▓就太晚了。 八、有偏√执的精神，计划要检查，检查，再检查。有这样一个人：在测试机上写一个※脚本，叫大家操作步骤和脚本，和相关人员重新确认操作、顺序、时间。检查可能的影响☆和回滚是否准备好。最后，在后台运行脚本并同时登录另一个窗口。在ps和查看结果输出过▼程中，姿势端正，呼吸急促均匀it运维，眼神凝重。操作的人不觉得累，但是看的〖人累了。 九、简单就是美我们总是面临着各种各样的诱惑：新的系统架构、新的ω　更智能的命令和工具、最新的】硬件平台、更全功能的HA软件……你可以离线安装、测试等等。但是，如果◎您想在生产环境中使用它，请三思而后行！ ！ Linux本身自带的字符界面比那些复杂的图形界面更简【单方便。如果你能坚持这九大铁律，你〗的应用系统就能长期稳定运行。