众所周知,故障是运维人员永远的痛!各公司的运维群里的一直存在的古老的话题“这个故障运维该不该背?”

运维是块砖,哪里用哪里搬。

不出问题你打杂,出了问题你负责。

没错,运维就是背锅专业户

 

相信每一个运维人员的KPI中都有一项:可用性

可用性高就是不出故障,各个公司对可用性和故障评级的标准都不相同,但是避免故障的方法却是殊途同归。

 

运维人员应该怎么避免故障?下面简单列举了以下几条:

 

01、变更要有回滚,在同样的环境测试过

所有的变更都必须有回滚的办法,在同样的环境下测试过。没有做过的东西,总是会在你意想不到的地方给你一次痛击,多年运维经验告诉我们,所有没有做过的变更,出错的概率最大。

所以我们需要给变更以回滚的可能,在各个步骤可能出错的情况下,考虑回滚到最初状态。优秀的运维人员对不考虑回滚的的操作都是敬而远之的。从某种意义上来说,运维是一门经验的学科,是一门试错的学科。

 

02、对破坏性的操作谨慎小心

破坏性的操作有哪些列?对数据库来说有:DROP Table,Drop database,truncate table,delete all data;这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了。就算回滚,代价也是非常大的。你执行这样的语句非常简单,但是回滚恢复数据缺非常困难。这些操作时就要更加谨慎了。

linux的命令rm可以-r(recursive)递归的删除某一个目录,-f(force)强制删除,但是你有没有删错过文件。我们遇到过一个文件名中末尾有空格的情况,而有的人rm -r习惯性的会在文件名后面加*,这样就成了rm -r aa *,所有当前目录的数据都被删除掉了!经过这次故障以后我们给rm做了别名:

alias rm=’rm -i’

这样在删除数据时,rm命令会提示你,是否确认删除该文件。

同样的cp和mv也可以有同样的选项:

alias cp=’cp -i’

alias mv=’mv -i’

这句话可以让你减少失误:“删库跑路,五年起步”

 

03、设置好命令提示

让你时刻知道你在操作哪个数据库,让你知道你在哪个目录下。开多个标签页的话,如果每个标签页的标题上内容一样,我们切来切去就有可能在错误的标签页上做操作,mysql字符客户端允许你设置提示符,默认的提示符就是一个光秃秃的mysql >,为了让你清楚的知道你当前是以哪个用户名,哪个IP(可能是localhost,127.0.0.1或者具体的物理IP),你当前操作的是哪个schema,以及当前的时间,你可以设置数据库的提示符为:prompt=“\\u@\\h : \\d \\r:\\m:\\s> ”。它可以直接写在my.cnf的[mysql]下,这样你每次连上MySQL就默认显示如下:

root@127.0.0.1 : woqutech 08:24:36>

设置了这个以后,这个问题概率就会小很多。

 

04、备份并验证备份有效性

是人总会出错,是机器总可能会有突然崩溃的那一天,怎么办?我们需要准备备份。备份的学问很大。按照不同的纬度可以分为:冷备份和热备份;实时备份和非实时备份;物理备份和逻辑备份。备份有了,是否就可以高枕无忧了?还是不行。你需要验证备份的有效性。没有一个备份能够保证它备份出来的数据能够100%恢复出正确的数据。特别是物理备份的概率相对来说,更低,xtrabackup备份一个月总有那么几次来坑,不能给你很好的服务。所以,备份并不只是备份,它还包括备份的验证,它如果不能恢复出正确的数据,就只是浪费空间而已。备份的验证最简单的就是找一个空闲的库,来恢复出来,mysql启动以后检查部分数据。如果不需要这么严谨,对于xtrabackup来说,你至少得验证它–apply-log能够恢复上去吧?同样,备库的数据一致性也需要经常检查一下,mysql的replication并不保证100%的数据一致性,你可以去翻翻mysql statement复制的bug列表,有些数据在主备不同的环境上分别执行,数据就会不一样。可以考虑用percona的工具pt-table-checksum来检查主备不一致,用pt-table-sync来同步主备数据。

 

05、交接和休假最容出故障变更,请谨慎

这个是经验之谈。在总结故障的情况时,发现在公司部门有变化时,工作交接,故障的出现频率会比正常情况下多50%以上。有人说,这是因为机器或者应用是有感情的,舍不得离开的运维者。

我们不谈感情,简单的理性分析一下。公司或者部门难免会做一些调整,变化是世界上唯一不变的事情。而运维人员是一线做事情的人,部门调整或者领导的更换可能导致工作的着重点不同,做事的方式和评测的标准变了,适应过程中难免会出现一些考虑不周到的地方,出故障也是情理之中了。

所以,运维部门和运维人员对变化需要尽量放平心态;接手别人的工作要一而再,再而三的确认变更方案。请教人并不见得就是能力不行的表现;休假前最好各种可以做好的事情,最好能够准备一份文档,指明在什么情况下怎么做和联系哪些人。在别人放假的时候接手工作,“能拖则拖”,实在需要执行:必须不厌其烦的跟原运维者确认各个操作细节。

 

06、搭建报警,及时获得出错信息

搭建性能监控,了解历史,获得趋势,预测未来。运维的最高境界不是故障来了,泰山崩于前而不惊,而是没有故障,让故障消失在萌芽之中。请给那些默默无闻,每天想着我们的系统还存在哪些隐患,怎么解决,怎么及早发现的运维人员鼓掌。他们是最可爱的人。而他们赖以生存的工具就是报警和监控。Oracle发展了这么多年,awr和相关的性能参数都相对比较全;MySQL现在也已经迎头赶上,配套的工具越来越多。

报警可以让你及时知道系统出现了什么异常。性能监控可以让你了解系统的历史性能信息。分析故障发生时的各种现象,确认故障的真正原因;了解变化趋势,发现故障的苗头,及早优化和调整。报警和性能监控其实不不完全独立的,很多性能的监控项也可以报警出来。