众所周知, 故障是运维人员永远的痛! 相信每一个运维人员的 KPI 中都有一项: 可用性. 可用性高就是不出故障, 各个公司对可用性和故障评级的标准都不相同, 但是避免故障的方法却是殊途同归. 我们怎么避免故障, 下面简单列举了以下几条, 与大家共勉!
1. 变更要有回滚, 在同样的环境测试过
所有的变更都必须有回滚的办法, 在同样的环境下测试过. 没有做过的东西, 总是会在你意想不到的地方给你一次痛击, 多年运维经验告诉我们, 所有没有做过的变更, 出错的概率最大. 所以我们需要给变更以回滚的可能, 在各个步骤可能出错的情况下, 考虑回滚到最初状态. 优秀的运维人员对不考虑回滚的的操作都是敬而远之的. 从某种意义上来说, 运维是一门经验的学科, 是一门试错的学科.
2. 对破坏性的操作谨慎小心
破坏性的操作有哪些列? 对数据库来说有: DROP Table, Drop database, truncate table, delete all data; 这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了. 就算回滚, 代价也是非常大的. 你执行这样的语句非常简单, 但是回滚恢复数据缺非常困难. 这些操作时就要更加谨慎了.
3. 设置好命令提示
让你时刻知道你在操作哪个数据库, 让你知道你在哪个目录下. 开多个标签页的话, 如果每个标签页的标题上内容一样, 我们切来切去就有可能在错误的标签页上做操作, 设置了这个以后, 这个问题概率就会小很多.
4. 备份并验证备份有效性.
是人总会出错, 是机器总可能会有突然崩溃的那一天, 怎么办? 我们需要准备备份. 备份有了, 是否就可以高枕无忧了? 还是不行. 你需要验证备份的有效性. 没有一个备份能够保证它备份出来的数据能够 100% 恢复出正确的数据. 所以, 备份并不只是备份, 它还包括备份的验证, 它如果不能恢复出正确的数据, 就只是浪费空间而已.
5. 交接和休假最容易出故障, 变更请谨慎
这个是经验之谈. 我们在总结故障的情况时, 发现在公司部门有变化时, 工作交接, 故障的出现频率会比正常情况下多 50% 以上. 有人说, 这是因为机器或者应用是有感情的, 舍不得离开的运维者.
我们不谈感情, 简单的理性分析一下. 公司或者部门难免会做一些调整, 变化是世界上唯一不变的事情. 而运维人员是一线做事情的人, 部门调整或者领导的更换可能导致工作的着重点不同, 做事的方式和评测的标准变了, 适应过程中难免会出现一些考虑不周到的地方, 出故障也是情理之中了.
所以, 运维部门和运维人员对变化需要尽量放平心态; 接手别人的工作要一而再, 再而三的确认变更方案. 请教人并不见得就是能力不行的表现; 休假前最好各种可以做好的事情, 最好能够准备一份文档, 指明在什么情况下怎么做和联系哪些人. 在别人放假的时候接手工作,"能拖则拖", 实在需要执行: 必须不厌其烦的跟原运维者确认各个操作细节.
6. 搭建报警, 及时获得出错信息
搭建性能监控, 了解历史, 获得趋势, 预测未来. 运维的最高境界不是故障来了, 泰山崩于前而不惊, 而是没有故障, 让故障消失在萌芽之中. 请给那些默默无闻, 每天想着我们的系统还存在哪些隐患, 怎么解决, 怎么及早发现的运维人员鼓掌. 他们是最可爱的人. 而他们赖以生存的工具就是报警和监控. Oracle 发展了这么多年, awr 和相关的性能参数都相对比较全; MySQL 现在也已经迎头赶上, 配套的工具越来越多.
报警可以让你及时知道系统出现了什么异常. 性能监控可以让你了解系统的历史性能信息. 分析故障发生时的各种现象, 确认故障的真正原因; 了解变化趋势, 发现故障的苗头, 及早优化和调整. 报警和性能监控其实不不完全独立的, 很多性能的监控项也可以报警出来.
来源: http://server.51cto.com/ManageDC-586169.htm