人生就是一段充满苦与乐的旅程,在人生当中有痛苦也有欢乐,痛苦不一定是负面的,有的时候还会使你进步,增强应变能力。对一般人而言,人生一定要是快乐的才是有意义的,可是你仔细想想,有谁不是因为挫折而更加的坚强呢?走过运维的风风雨雨,与大家一起回忆其中的苦乐甘甜,那何尝不是一段段激情燃烧的岁月呢,记载着你我成长的故事。。。。。

一、不要轻易地放弃

   运维中时常会面临各种各样的挑战和难题,很多时候感觉自己快陷入绝境了,很多时候静下心来思考问题又能出现伟大的转机。任何时候都不要轻易地放弃,也许你只要再深入一步看到问题的某个细节,事情并没有你想象的那么复杂。

   一台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服务和支持,并实现行之有效的持续改善和对机制进行监控。运维上,好的管理制度和方法需要贯彻和坚持,如果不善于管理和监督,很难保证好的运维体系能运作下去,这对运维工作也会产生波动和影响。当然运维工程师也需要具有领导能力与团队协作技能,能在关键时候对技术的选择作出及时、有效的决定,来把握问题解决的方向。


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


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


博客话题】 人在囧途之“运维囧”正在进行,欢迎大家参与,分享你运维工作中的囧事、趣事、经验谈
详情查看:http://51ctotopic.blog.51cto.com/2009463/1254338