运维经验总结 篇1
适用场景:企业网络维护总结,日常运维管理总结,故障排查流程总结
演讲要点:定期性能监控检测,故障排查流程优化,网络设备维护规范
行文逻辑:检测网络状态→保存故障现场→隔离故障区域
一直做企业网络技术支持,这些年的工作经验告诉我:一个优秀的网络管理人员只有技术是远远不够的,良好的、科学的习惯有时候比技术更加重要。企业网络更多时候运行在常态下,网管更多扮演着网络维护者的角色,而不是消防队、救火队。这个时候,更需要网络管理员以严谨、认真、积极的态度做好网络的日常维护,而良好的习惯在其中起着决定性的作用。那么,企业网管应该养成哪些好习惯呢?下面分网络常态和非常态分别谈谈网管应该具有的好习惯。
1、常态下,未雨绸缪做好网络状况的检测
我认为衡量一个优秀网管的标准,不是看他排网络故障的效率有多高,而是看他维护的网络发生故障的频率有多低。当然,要彻底避免网络故障是不可能的,但是优秀网管可以让其尽可能少地发生。因为,毕竟网络故障已经发生,不管你的排故效率有多高,但或多或少都会对企业的生成造成一定的影响,特别是信息化程度越高的企业这种影响会越大。我认为,除了科学的网络架构与部署之外,常态下的网络状况检测是减少网络故障的有力保障。这也就是优秀网管平时应该做的工作之一。
其实并不是所有的网络故障都是突发性的,大部分故障都有一个累积的过程,是一个由量变到质变的过程。这就像一位“病人”,最初可能不会感到明显的“身体不适”,如果不进行检查是不能发现的。网络维护其实就像给人看病,排故是最后的选择,此前的检测是非必要的。特别对于服务器、路由器/交换机这些核心的网络设备,定期的性能监控是必不可少的。以路由器为例,网管们通过要对其进行优化,但优化是否会带来其他的隐性问题呢?所以如何及时发现路由优化方面的问题,就是网络定期项目测试中的内容之一,特别是大型网络中则更有必要。如果监控和测试呢?大家知道,许多网络设备如路由器、交换机、只能集线器等都支持snmp网管功能,但为了全面监测网络通道功能,还需要网络设备支持全面的rmon和rmon2,用这样的设备组建起来的网络其管理和故障诊断功能是很不错的。但现实的问题是,这样的网络设备价格是普通网络设备的6~10倍左右,企业不见得有这些it预算。因此,为了随时监测网络的服务应用流量及其比例、来源,工作记录以及必要
时进行解包分析,我建议网管们在重要的服务器通道或路由通道上安装监测接口。以便必要时可以随时将流量分析仪、网络测试仪接入通道进行监测和分析。这样,一来可以在常态下实时了解设备的运行状态,二来在故障排除时能够快速定位,使得故障的查找时间可以缩短很多,降低运维成本。当然,如果资金允许,我还是建议将流量分析仪长期接入通道对多个重要的网络设备进行全速率透明流量监测,这样便于随时了解设备健康状况。退一步,就算该设备出现故障,我们可以在1分钟之内快速定位故障。
与路由器/交换机类似,网管们要对其他是设备进行实时的监控或者定期的检测。网络监控可用专门的仪器(这当然是最好的),当然对于it经费紧缩的企业借用第三方软件也可以实现类似的功能,但是不管怎样,监控、检测是必须要做的。我的感悟,没有监控的网络是不健康的,是一个随时会倒下的“病人”。
2、排故时,不要盲动将网络排故成本将到最低
我遇到过很多这样的网管,当网络发生故障时,不能够冷静地分析问题,而是想当然地进行所谓的“排故”。其结果是不但问题没有解决,而且使得问题扩大化,最后束手无策请专家来维修。而且,由此付出的时间和经济上当投入,使得维护成本大大增加。老总脸色难看,搞得自己很没有面子也很被动。其实,网络排故就像医生为病人做手术或者警察破案,保持一个冷静的头脑是至关重要的,千万不要盲动。现场保存,调查取证,分析研究这是最基本的素质。
(1).评估与现场保存
首要对故障状况有一个大概的评估,是否在自己的能力解决范围之内,如果对自己解决问题没有信心,就不要动手。在专家到来之前,做好现场保存。并进行一定的调查取证,比如故障前的各种操作行为,故障触发时的各种信息,故障现象等。这样在专家到来之后,就能够将这些重要的信息反馈给他们,从而免去他们做类似工作花费的时间,为故障的快速排
除赢得时间。当然,在专家排错的过程中要仔细观察,大胆提问,不但要学习如何排除故障,还要搞懂故障发生的原因。这样,当今后遇到此类故障的时候,就能够自己解决。
(2).隔离与实验测试
最小化原则还有一个方面就是,不要让故障扩大,要马上将故障网络进行隔离。另外,不要因为的轻率操作,使得故障不可收拾。对于那些不是非常危急的故障,可以自己尝试解决。我的建议是,条件允许的话最好在实验环境中进行,通过实验室中的设备模拟出类似故障,然后进行排错。如果没有实验环境,在真实环境中进行操作,首先要做好相应的备份,然后进行网络隔离,最后才进行操作。还有,对自己在排故中的每一步操作做好记录。这非常重要,如果排故失败你就有可能回溯。就算不能回溯,在专家到来时,你至少可以告诉他你都进行了哪些操作,这对于专家快速排故是非常重要的。
(3).不能简单粗暴
做技术支持中,我经常看到这样的管理员:当网络被判为病毒发作时,就会首先启用多种杀毒软件进行查杀毒操作,无效。然后,把所有工作站格式化,重新安装其操作系统和应用软件。但由于问题出在服务器,所以仍然不见效。最后,不得不将所有机器(当然也包括服务器)格式化以后重新安装系统平台及应用软件。当然,这种简单粗暴的做法,应当为技术性的网管所不齿。说到底,这不应该算是网络排故,将一个也许很简单的问题扩大化了,由此增加的网络维护成本太大了。我认为,网络排故的两个基本原则是针对性和最小化。忠告网管们千万不要盲动,采取简单粗暴的做法。
当下,崇尚技术认为技术万能的网管不在少数。由于网络的复杂性,技术的有限性(哪怕你技术再高),仅靠技术不能解决所有问题。因此,我要说的是,如果没有良好的习惯,你一定会为此付出代价。技术与好的习惯对于企业网管,哪个更重要呢?当然不能厚此薄彼,只有两者并举才能成为优秀的网管。
运维经验总结 篇2
适用场景:系统维护总结,日常运维总结,故障排查总结
演讲要点:系统变更测试验证,破坏性操作风险控制,备份有效性检查
行文逻辑:测试变更环境→确认操作方案→验证备份有效性→敬畏生产环境→建立监控报警
运维工作直接关系到应用系统运行的正常稳定,但运维工作纷繁复杂,正规化、系统化相对比较弱,如何改变这种现状?从众多的运维工作者的成功失败中进行经验总结,并提升为运维规则,是提高运维水平,保障应用系统正常稳定运行的有效途径。
笔者通过自己的多年运维经验,总结出以下必须遵守的基本运维规则,可以大大减少缺乏经验的运维人员因为自身失误导致系统出故障的可能性。
一、系统变更、升级应先在同样的环境测试通过,执行前应有经过验证的回退预案
运维是一门经验的学科、是一门试错的学科。没有做过的东西、总是会给你出意想不到的难题,因此变更前,一定要在相同或者相似运行环境下进行测试,通过后才能在正式环境下执行变更。同时应准备好变更失败的回退预案,比如,做好系统备份、数据库备份、配置备份,固化变更前的运行现场,让变更有回头的机会。
二、对破坏性的操作要先确认符合预定方案,然后谨慎执行
什么是破坏性的操作?比如:
对mssqlserver,执行update操作,因为不需要commit,所以特别容易忽视也特别危险,还有、drop等操作更不用说。
对oracle而言:truncatetablename、tablename、name,这些语句执行起来轻松简单也惬意极了、但记住!即便数据可被回滚、代价也是非常大!
对linux而言,rm-r所有当前及其子目录的所有数据都将被删除。经历过这种故障的人、大多会给rm上个别名aliasrm= m-i同理、cp和mv也可以有同样的选项:
aliascp=cp-ialiasmv=mv-i对window而言,shift+del文件或者目录对任何系统而言,无备份直接修改文件等
三、备份并验证备份的有效性
不管是硬件还是软件总有意外崩溃的时候,怎么办?备份!!!备份的学问很大、按照不同的维度可以分:冷备和热备、实时和非实时、物理和逻辑、全备增量备。
备份有了、可以高忱无忧了吗?不行!尚须验证备份的有效性。一个总有那么几次、备份无法保证100%恢复,简单的验证就是找个空库恢复出来。
四、对生产环境永保敬畏之心
这是避免应用系统发生故障的一条铁规,也是被开发、运维人员容易忽视的地方。要坚决杜绝直接在生产环境做开发、测试和bug修复,这些操作只能在开发和测试环境做,否则一旦出事,将欲哭无泪。
五、交接和休假最容易出故障
接手别人的工作要一而再,再而三的确认变更方案,请教人并不见得就是能力不行的表现;
休假前最好各种可以做好的事情,最好能够准备一份文档,指明在什么情况下怎么做和联系哪些人;
在别人放假的时候接手工作,“能拖则拖”,实在需要执行:必须不厌其烦的跟原系统管理人员确认各个操作细节。?
六、一定要有监控手段和报警措施
运维人员赖于生存的工具就是报警和监控。
报警可以让你及时知道系统出现了什么异常、以便及时跟进、把故障扼杀于摇篮;
监控可以让你了解系统的历史性能信息、以历为鉴、可以知兴替、早做优化。?
报警和监控是衣宽带水的好兄弟、相铺相成、互相促进。
七、使用自动切换技术需谨慎
为了保障数据库安全,往往会使用ha或者rac之类的技术,但是这类技术能否真正在关键时刻起作用,则是需要经过反复验证和确认的。并不是按照文档要求做好了就够的,很多意外因素或者系统因素会导致自动切换技术并不能如期发挥作用。如果到事后才发现这一点,将悔之晚矣。
八、要有偏执狂的精神,方案要检查,检查,再检查
有这么一个人:
①他在做一个变更的时候,会先提前一两周发送邮件并电话手机通知相关人
②在测试机上写好脚本,召集大家review操作步骤和脚本
③测试完成以后拷贝到生产环境
④登录对应机器,“打开,关闭,打开,关闭”该脚本
⑤跟相关人员再次确认执行的操作,顺序,时间点,可能的影响和回滚是否都准备好了
⑥执行前还要退出这个机器,然后再登录进去,“打开,关闭”脚本
⑦最后才在后台运行脚本,同时在另外一个窗口登录着,随时ps和查看结果输出
期间姿势端正,呼吸急促而均匀,眼神凝重。操作的人不觉得累,倒是一边观摩的人很累。
九、简单即是美
我们总是面临各种诱惑:新的系统架构,新的更智能的命令和工具,最新的硬件平台,功能更全的ha软件...你可以在线下安装,测试,怎么做都行。但是如果想要在生产环境下使用起来、请三思!!
能够使用系统内置命令的话,就不用考虑其他要专门下载安装的软件了?脚本本身就能完成的功能,就没有必要专门找一个功能丰富的软件来做?linux本身自带的字符界面比那些复杂的图形界面要简洁方便?
如果能做到坚持这九条铁规,你的应用系统就能长久稳定运行了。
