【运维囧事】运维的苦乐之旅

人生就是一段充满苦与乐的旅程，在人生当中有痛苦也有欢乐，痛苦不一定是负面的，有的时候还会使你进步，增强应变能力。对一般人而言，人生一定要是快乐的才是有意义的，可是你仔细想想，有谁不是因为挫折而更加的坚强呢？走过运维的风风雨雨，与大家一起回忆其中的苦乐甘甜，那何尝不是一段段激情燃烧的岁月呢，记载着你我成长的故事。。。。。
一、不要轻易地放弃
运维中时常会面临各种各样的挑战和难题，很多时候感觉自己快陷入绝境了，很多时候静下心来思考问题又能出现伟大的转机。任何时候都不要轻易地放弃，也许你只要再深入一步看到问题的某个细节，事情并没有你想象的那么复杂。
一台AIX生产服务器上装有DB2数据库，由于开发人员的误操作，造成一个重要表的被删除，需要进行恢复。为了安全，不能在生产环境的数据库上进行操作，需要放到测试环境进行恢复。问了一下开发人员，表被删除的时间为5月31日下午8点35分左右，现在已是晚间9点05分了，距离事故发生时间点已过去半个小时，根据安全等级规定需要在两个小时内进行恢复。这种状况的恢复是典型的前滚恢复，需要使用完整的数据库备份和日志相结合，然后将数据库或者被选择的表空间恢复到某个特定时间点。如果从备份时刻起到发生故障时的所有日志文件都可以获得的话，则可以恢复到日志上涵盖到的任意时间点。
首先检查了一下数据库的备份情况，上周日有一个完整备份，从完整备份到故障点的所有日志都完好的存在，心里总算松了一口气，看来问题似乎很好恢复。
接下来在测试环境找一台与生产环境DB2数据库版本一致的AIX小机，把完整数据库备份和相应日志传输过来。（注：不同的数据库版本，物理日志格式不一样，在做恢复的时候容易报SQL2547错误，从而不能前滚日志）从生产环境传输到测试环境的完整备份和日志，大家还要注意修改文件的属主和权限，以避免无法读取的错误。
紧接着，进行完整备份恢复，并前滚日志到指定时间点，一切都很正常顺利。然后告知开发人员进行检查，过了一会，开发人员反馈说没有查到数据，仍然是删除后的状态。这回有点纳闷了，怎么可能会没有，时间已过去了半个小时，真是让人着急啊。旁边的电话响个不停，听的人脑袋都要炸了。接着又将前滚日志的时间点提前了半小时再恢复，还是没有数据，这时有开发说可以手工录入丢失的283条数据，难道要放弃数据恢复么？心里纠结的七上八下，但是我脑中闪过一个念头，不能轻易放弃，也许是我们遗漏了某个细节。于是静下心来思考了几分钟，心里突然有点怀疑，会不会是两个小机的时间不一致啊，因为前滚时用的是local time
立即检查两个小机的时间
Sun Jun 4 15:43:47 BEIST 2013 （生产机时间）
Sun Jun 4 15:44:01 CDT 2013 （测试机时间）
注意红色部分，BEIST和CDT并不是同一个时区，BEIST与CDT之间相差8个小时。因为时区的不一致导致时间不统一，所以出现了问题。立即修改了测试机的时区并同步了一下时间，再来一次恢复，果然数据有了，表也恢复了，一切OK
细节决定成败，遇事一定要冷静沉着，问题面前不要轻易的说放弃。

二、直面问题---解决与发现
运维当中，我们通常会面临解决不完的问题，身为救火队员的你可能天天吃力不讨好，被无数投诉和报表弄得疲惫不堪……面对问题关键的是我们的心态，是积极应对还是消极拖延，这关乎到我们的工作和存在的价值。
大多数时候，运维人员都在进行着简单重复的工作，且很难得到最终用户的肯定。曾有人用“穷忙族”形容运维工程师，工位上不见人影，一坐下电话不断，是不是你该解决的问题都有人来找你。这样的场景，大家应该都有体会。不管你接手的问题是复杂还是简单，我们首要的心态就是面对问题解决问题，而不是抱怨与逃避。做运维时，有时候很怕接到自己搞不定的问题，害怕客户投诉也担心自己出丑丢面子。一次接到一任务，要求帮客户排除一新上数据库服务器网卡不稳定的问题，这类问题大家一般都往网络上想，但经过网络部工程师检测网络设备、网卡和千兆网线都说没问题，最后就推到系统部，让查到底是什么原因。其他人都觉得这问题不好办，索性推脱了。当经理最后问到我时，我知道不能再推了，硬着头皮说让我看看，我觉得不是什么大问题。心里虽然打着鼓，但知道只能直面问题往前冲了，管他呢拼一把，大不了就是出回丑丢回面子。问明事情的缘由“原来是近期新上的DB SERVER服务器，在压测中发现网卡很不稳定，压力测试刚刚进行十几分钟后，服务器反应就变得非常慢，PING的时候经常丢包而且SSH连接也时断时续”，刚开始我以为是高并发时导致的db server无响应，可是看了一下CPU、内存和硬盘IO，发现都没有达到较高值，甚至比我们的预警值低很多，而且监测也表明DB服务器剩余资源很充裕！真是比较奇怪，那么引起网卡不稳定的原因到底是什么呢？
接着我又向相关工程师了解了一下情况，知道这台DB服务器是双机热备中的一台服务器，前几天刚做的2组千兆网卡绑定。据工程师说绑定前也做过压测，没有出现这样的问题。难道是绑定设置的哪个环节出问题了？于是我决定从千兆网卡绑定进行详细检查。依次检查了“ifcfg-bond0、ifcfg-bond1文件没有问题，又检查了ifcfg-eth0、ifcfg-eth1、ifcfg-eth2、ifcfg-eth3文件还是没有问题，再接着检查modprobe.conf配置文件也很正常，最后检查了rc.local文件，发现BOND0和BOND1文件中绑定的网卡有误，造成一个IP地址对应两个不同的MAC地址，显然会造成网络的延迟和不稳定，这就跟以往的ARP攻击比较像。最后终于发现了问题的症结，成功解决了问题，为自己也为团队赢得了好评和荣誉。
在一次次的解决问题当中，我们不仅在积累处理不同问题的经验，更重要的是我们在得到客户的认可和好的工作评价。所以不要怕问题，每个问题正是你的机会，发现并善于解决问题，我们也会得到客户的肯定和个人的成长。

要记住，老板需要的，是会解决问题的人。成功青睐的，也是勇于解决问题的人。

三、唯有学习，才能不断提升自己
作为一名运维工程师，通常需要掌握的知识比较杂,学习起来也感觉比较苦与累。
首先熟悉网络，对网络常用的负载均衡技术和分层架构要熟悉，结合网站的内容发布、管理及静态化技术、动静分离方案，对主流网络设备的配置和冗余应用比较熟悉，并熟悉高并发下的网络压力管理和流量控制。
其次熟悉服务器的批量部署。相信许多企业里都有自动化运维的需求，如批量安装服务器、批量装应用、批量传文件、批量监控等等，网上也有N多相关的管理软件，开源的如Nagios、Cacti、zabbix、zenoss监控，Cfengine、cobbler、Puppet统一部署管理软件，商业的就更多。它们都很强大，当然也各有利弊，需要结合自己企业的业务应用去具体调整和配置。
再次就是熟悉数据库的集群和后端存储架构。通常数据库和存储都是整个IT架构中比较核心的东西，数据库的性能和高并发下的稳定对企业来讲是非常重要的，它直接关系到用户的体验和价值转化。还有存储的性能将直接影响IO，影响读写的速度。作为一个运维工程师尤其需要对系统的性能、容错、并发等有独到的认识与解决办法。还有就是需要对技术发展趋势有很高的敏感性和预见能力，能不断推进运维管理水平的进步并提升运维的价值。
作为运维工程师，要想有更大的发展，不仅要懂技术也更需要懂管理，建立流程规范的IT服务和支持，并实现行之有效的持续改善和对机制进行监控。运维上，好的管理制度和方法需要贯彻和坚持，如果不善于管理和监督，很难保证好的运维体系能运作下去，这对运维工作也会产生波动和影响。当然运维工程师也需要具有领导能力与团队协作技能，能在关键时候对技术的选择作出及时、有效的决定，来把握问题解决的方向。

学习中的苦与乐都是相对的。以苦为苦，只能使我们消沉；不以苦为苦，就会使我们无视自己的不足；化苦为乐，则可能使我们在学习和工作中取得超常的成就。

苦尽甘来，耕耘时的苦是为了收获时的乐。运维的路上，有风有雨，更有我们的坚持，让我们苦乐相随！

【博客话题】 人在囧途之“运维囧”正在进行，欢迎大家参与，分享你运维工作中的囧事、趣事、经验谈！
详情查看：/article/4123671.html

本文出自 “滴水穿石孙杰” 博客，谢绝转载！