运维操作规范十大原则.docx

运维操作规范十大原则.docx

《运维操作规范十大原则.docx》由会员分享，可在线阅读，更多相关《运维操作规范十大原则.docx（10页珍藏版）》请在冰点文库上搜索。

运维操作规范十大原则

运维操作规范十大原则

LT

运维安全：

远离故障的十大原则

故障是运维人员永远的痛。

相信每一个运维人员的KPI中都有一项：

可用性。

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

我们怎么避免故障，沃趣科技简单列举了以下几条，与大家共勉！

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

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

3、设置好命令提示 

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

5、对生产环境存有敬畏之心

6、交接和休假最容易出故障，变更请谨慎

7、搭建报警，及时获得出错信息。

搭建性能监控，了解历史，获得趋势，预测未来

8、自动切换需谨慎

9、仔细一点，偏执一点，检查，检查，再检查

10、简单即是美。

第1条，变更要有回滚，在同样的环境测试过。

也是运维最繁琐，最苦逼的地方，所有的变更都必须有回滚的办法，在同样的环境下测试过。

没有做过的东西，总是会在你意想不到的地方给你一次痛击，在阿里巴巴的这么多年运维经验告诉我们，所有没有做过的变更，出错的概率最大。

所以我们需要给变更以回滚的可能，在各个步骤可能出错的情况下，考虑回滚到最初状态。

优秀的运维人员对不考虑回滚的的操作都是敬而远之的。

从某种意义上来说，运维是一门经验的学科，是一门试错的学科。

第2条，对破坏性的操作谨慎小心。

破坏性的操作有哪些列？

对数据库来说有：

DROPTable，Dropdatabase，truncatetable，deletealldata；这些操作做完了以后几乎无法考虑怎么把数据都回滚回去了。

就算回滚，代价也是非常大的。

你执行这样的语句非常简单，但是回滚恢复数据缺非常困难。

Linux的命令rm可以-r（recursive）递归的删除某一个目录，-f（force）强制删除，但是你有没有删错过文件。

我们遇到过一个文件名中末尾有空格的情况，而有的同事rm-r习惯性的会在文件名后面加＊，这样就成了rm-raa*，所有当前目录的数据都被删除掉了！

经过这次故障以后我们给rm做了别名：

aliasrm='rm-i'

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

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

aliascp='cp-i'

aliasmv='mv-i'

第3条，设置好命令提示。

让你时刻知道你在操作哪个数据库，让你知道你在哪个目录下。

MySQL字符客户端允许你设置提示符，默认的提示符就是一个光秃秃的mysql >，为了让你清楚的知道你当前是以哪个用户名，哪个IP（可能是localhost，127.0.0.1或者具体的物理IP），你当前操作的是哪个schema，以及当前的时间，你可以设置数据库的

非实时备份有可以分为在线延时备份和离线备份。

在线延时备份是搭建数据库的一定时间延迟的热备份，比如MySQL就可以搭建一个延迟一天的slave，一直保持着备库与主库的延迟在一天。

可以利用pt-slave-delay工具来实现这个功能。

另外，离线备份是目前大家用的比较多的，可以利用mysqldump进行逻辑备份或者xtrabackup进行物理备份。

为了空间的原因和快速恢复考虑，你还可以利用xtrabackup进行增量的物理备份。

备份有了，是否就可以高枕无忧了？

还是不行。

你需要验证备份的有效性。

没有一个备份能够保证它备份出来的数据能够100%恢复出正确的数据，特别是物理备份的概率相对来说，更低，xtrabackup备份一个月总有那么几次来大姨妈，不能给你很好的服务。

所以，备份并不只是备份，它还包括备份的验证，它如果不能恢复出正确的数据，就只是浪费空间而已。

备份的验证最简单的就是找一个空闲的库，来恢复出来，mysql启动以后检查部分数据。

如果不需要这么严谨，对于xtrabackup来说，你至少得验证它–apply-log能够恢复上去吧？

同样，备库的数据一致性也需要经常检查一下，mysql的replication并不保证100%的数据一致性，你可以去翻翻mysqlstatement复制的bug列表，有些数据在主备不同的环境上分别执行，数据就会不一样。

可以考虑用percona的工具pt-table-checksum来检查主备不一致，用pt-table-sync来同步主备数据。

第5条，对生产环境存有敬畏之心。

这应该是运维者进入行业首先需要具备的素质。

但是我们还是需要把它拿出来强调一下。

有机会的话，你可以梳理一下：

∙你的生产环境上有哪些账户，这些账户是否都确实需要登录到机器上来？

这些账户即包括linux用户还包括数据库账户。

∙你的root用户是否开放给了某些用户，这些用户安全吗？

∙你的用户密码是否经常修改，是否加密不让具体的操作人员直接看到，密码强度时候足够，密码重试次数达到一定次数是否黑名单；

∙你的生产环境和线下环境是否隔离，数据库是否和外网隔离？

∙是否一些工作明明能够在开发库和测试库做，却被放到生产环境上去了。

∙是否有专门的人负责线上应用的发布，从而避免开发人员直接接触生产环境

这些都是你避免出现csdn密码泄漏，在业界的名声一落千丈的法宝。

第6条，交接和休假最容易出故障，变更请谨慎。

这个是经验之谈。

我们在总结故障的情况时，发现在公司部门有变化时，工作交接（不管是休假，工作职责变化还是离职），故障的出现频率会比正常情况下多50%以上。

有人说，这是因为机器或者应用是有感情的，舍不得离开的运维者。

我们不谈感情，简单的理性分析一下。

公司或者部门难免会做一些调整，变化是世界上唯一不变的事情。

而运维人员是一线做事情的人，部门调整或者领导的更换可能导致工作的着重点不同，做事的方式和评测的标准变了，适应过程中难免会出现一些考虑不周到的地方，出故障也是情理之中了。

而工作交接，对运维人来说，其实是一个非常费时费力的事情，你需要把所有平常做的工作都梳理清楚，甚至包括你的一些经意不经意的操作习惯，这样的话，下一个人才可能接手的下来。

比如：

你可能认为备库正常情况下没有访问，于是让某些并不重要的任务（一个月一次抽取部分数据到线下测试？

）直接连备机IP进行操作。

下一个人接手，认为备机就是备机，操作起来不会有任何问题，结果下一次任务抽取就是一个故障出来了。

再举一个我们遇到了事例吧：

同事A出国休假了，休假期间估计联系不上，他留了文档，并告诫说某几个库和表是比较核心和容易出问题的，没有特殊情况最好等他回来再做变更。

正好，休假期间，开发人员找到同事B，要求他重置一个字段的某一位（bit），并打包票说这个bit没有用，同事B拒绝，并背上了不配合的骂名。

同事A回来吓了一身冷汗，原来这个字段已经被另外一个离职的开发使用了。

所以，运维部门和运维人员对变化需要尽量放平心态；接手别人的工作要一而再，再而三的确认变更方案。

请教人并不见得就是能力不行的表现；休假前最好各种可以做好的事情，最好能够准备一份文档，指明在什么情况下怎么做和联系哪些人。

在别人放假的时候接手工作，“能拖则拖”，实在需要执行：

必须不厌其烦的跟原运维者确认各个操作细节。

第7条，搭建报警，及时获得出错信息。

搭建性能监控，了解历史，获得趋势，预测未来。

运维的最高境界不是故障来了，泰山崩于前而不惊，苍老师勾引你而抗日；而是没有故障，让故障消失在萌芽之中。

请给那些默默无闻，每天想着我们的系统还存在哪些隐患，怎么解决，怎么及早发现的运维人员鼓掌。

他们是最可爱的人。

而他们赖以生存的工具就是报警和监控。

Oracle发展了这么多年，awr和相关的性能参数都相对比较全；MySQL现在也已经迎头赶上，配套的工具越来越多。

报警可以让你及时知道系统出现了什么异常。

比如slaveio报警，在数据库replication异常的时候就会提醒你：

IO线程出现了问题，可能是网络问题，主数据库问题等，slavesql报警会提醒你replication的SQL线程出现了问题，可能是主备不一致，slave被停掉了，存储过程在备机有异常或者其他问题。

这样你收到报警就可以及时跟进，而不至于主备长时间不一致，主库坏掉了想要切换到备库的时候却不能切换。

性能监控可以让你了解系统的历史性能信息。

分析故障发生时的各种现象，确认故障的真正原因；了解变化趋势，发现故障的苗头，及早优化和调整。

比如你如果使用了PCI-E的Flash卡，你可以监控logical_written_bytes，logical_read_bytes，physical_written_bytes，physical_read_bytes以便获得flash卡的每秒的逻辑读写和物理读写字节数。

对于MySQL你可以监控Com_delete+Com_delete_multi,Com_insert+Com_insert_select，Com_update+Com_update_multi，Com_select来获得每秒的MySQLDML删除，插入，更新和查询的次数。

报警和性能监控其实不不完全独立的，很多性能的监控项也可以报警出来。

比如linux的iostat中的await_time可以作为性能监控采集起来获得系统IO响应时间的变化曲线，当该值达到20以上的时候，也可以报警出来，让运维人员跟进是磁盘阵列中坏了一块，还是异常的数据拷贝影响了系统的IO性能等。

nagios和cacti是目前MySQL领域使用最广泛的报警和性能展示系统。

percona最新推出percona-monitor-plugins（

第8条：

自动切换需谨慎。

现在数据库的HA很多都是进行自动切换的，这样运维人员深夜起来手工切换到备库的机会就会少很多。

切换也会快速很多。

但是，它带来的副作用也不容忽视。

现在业界使用的HA软件非常多，heartbeat由于很多SA兼作DBA的运维比较熟悉，在MySQL自动切换也是不少的。

一般来说，它会通过mysqladminping来探测MySQL是否存活，如果发现异常，那么他就会切换VIP和MySQL资源到备库。

但是此时备库的数据延迟是否为0，主库crash之后binlog的数据是否全部都同步到备库上去了，备库的read_only是否关闭，这些heartbeat都不管。

我们想象一下，主库上应用提交了一笔订单，结果发生了切换，这笔订单没有同步到备库上，卖家也就损失了一个销售单，对客户，对公司都是非常大的影响。

当然，自动切换也不能全盘否定，它能够更快速的将应用切换到新的热备份备库上，应用的不可用时间大大缩短。

只是我们要好好利用这一把双刃剑，仔细评估它的影响，降低或者去除副作用，让它为我们服务。

第9条，仔细一点，偏执一点，检查，检查，再检查。

之前我跟一个资深的运维学习线上操作的时候，觉得这家伙有点变态，他在做一个变更的时候，会先提前一两周发送邮件并电话手机的通知相关人；在测试机上写好脚本，召集大家review操作步骤和脚本；测试完成以后拷贝到生产环境；登录对应机器，“打开，关闭，打开，关闭”该脚本；跟相关人员再次确认执行的操作，顺序，时间点，可能的影响和回滚是否都准备好了；执行前还要退出这个机器，然后再登录进去，“打开，关闭”脚本；最后才在后台运行脚本，在另外一个窗口登录着，随时ps和查看结果输出。

期间姿势端正，呼吸急促而均匀，眼神凝重。

操作的人不觉得累，倒是一边学习的人很累。

当我做到一定程度，我也开始这样了。

医学上，这种好像叫做强迫症。

唉…，提前通知会让大家都有准备，也避免了临时相关人员过来说这个操作和其他操作有依赖需要调整操作时间的问题；召集大家review步骤和脚本是为了让大家一起来看看整个过程中还有哪些依赖没有考虑到或者哪些细节没有注意到，三个臭皮匠顶一个诸葛亮在运维来说是金科玉律；“打开，关闭，打开，关闭”是为了一再确认脚本拷贝过来是否正确，目录时候正确，思考在测试环境运行和在生产环境运行有什么不一样的；退出再登录机器是为了确认我登录的机器确实没有错；在后台运行是担心网络突然中断，我的脚本运行到一半怎么办；调整呼吸和端正姿势是为了对这个操作的敬重，对自己工作和运维工作的尊重。

以MySQL使用flash卡为例吧。

flash算是一个比较新的事务，提供的IO比普通磁盘是几个数量级的提升。

要想在生产环境使用，首先我们需要对他进行详尽的评估和破坏性测试，设置各种参数，考虑他们在各种场景下使用的配置；24小时不间断的进行半个月读写操作，中途突然掉电；高并发，高吞吐量下的测试；温度湿度极限测试；预留空间释放测试等等。

然后我们会尝试在测试库上部署试用，收集和修改各个配置已达到最稳定，最高性能的配置；运行稳定以后我们才考虑在线上备库使用，并且主备要求异构；适当的时机切换为使用新的flahs卡为主库，万一出现了问题，还可以切换回原主机。

这里也跟大家简单介绍一下screen命令，这个命令会在服务器段开启一个session，就算你的网络断掉了，你的脚本也会自动在后台运行。

screen-Swoqutech可以开启一个woqutech命令的后台session；如果你的网络断掉了，你可以用screen-drwoqutech连上之前的session继续进行操作。

IBM的文档库中有一个非常靠谱的文档：

第10条，简单即是美。

最后一条有点禅的意境了。

它和Unix的思想不谋而合。

我们总是面临着各种诱惑：

新的系统架构，新的更智能的命令和工具，最新的硬件平台，功能更全的HA软件等。

他们总是以各种各样的方式吸引我们，mostexciting，unbelievable，让你欲罢不能。

你可以在线下安装，测试，怎么搞都行。

但是如果想要在生产环境下使用起来，那就得经过非常详细，非常漫长，各种方式验证其稳定性的过程。

能够使用系统内置命令的话，就不用考虑其他要专门下载安装的软件了；脚本本身就能完成的功能，就没有必要专门找一个功能丰富的软件来做；linux本身自带的字符界面比那些复杂的图形界面要简洁方便；MySQL的一些分区，生僻函数，没有必要的话不要使用。

最后用文中的一句话送给运维的同学：

如果你没有测试过你的备份，就等于没有备份。