谈起运维工作,估计很多人会下意识的认为就是修电脑的、网管(上不去网,第一个被召唤的那种)。其实不能说这是错误的理解,IT运维人员的工作小到修电脑、理网线,大到部署整个数据中心。负责运维的设备,小的从个人电脑,大的到数以亿计的高精尖计算设备(比如IBM的大型机Z13)。从运维的工作层次来分,又分为硬件运维、桌面运维、系统运维、数据库运维和应用运维。几乎所有的和系统相关的问题,都与IT运维人员有关。根据公司IT系统规模的不同,有的运维团队不到10人,有的甚至达到数百人。每晚通宵达旦,为IT系统保驾护航。但是始终还是有很多的人和同事会质疑:为什么我的电脑还这么卡?网络速度还这么慢?某某系统还是上不去,很影响业务运营等等。这些质疑让运维人员很尴尬也很无语,有些问题甚至类似客户没有插网线,抱怨上不去网。有时候甚至会胡思乱想,究竟运维的意义是什么?这么努力怎么还这么受气?前段时间在群里和论坛上与运维方面的朋友一起交流的时候,大家总是时不时的诉苦,抱怨运维苦逼,没有成就感,甚至经常成为“窦娥”、“背锅侠”的代名词。种种抱怨和不满,也促使我更加的想表达一下如何做好IT运维方面的经验和个人见解(不一定对,欢迎拍砖),尤其是企业级的IT系统运维。因为其不但系统分支多,而且够复杂。业务频繁变更,要求IT系统必须随需应变。
我毕业后就一直从事IT系统运维方面的工作,从当初的桌面技术人员到现在的运维总监,一路荆棘,回想起来已有超过10年的运维经验了。虽然谈不上老道,更说不上是大咖,但是也总结了一些自己对运维工作的理解,对运维价值的理解。多年的摸爬滚打,我对运维总结成了两句话“技术只是手段,业务才是王道”。运维的好坏评定标准其实就是你给公司及业务带来了哪些价值及哪些影响?业内有很多的运维专场,每年不下数十场。从之前传统运维到现在的敏捷运维甚至AIops,这些都是在说运维的方法。通过这些方法让运维变得更灵敏、让运维人员更好的理解用户的需求。但是万变不离其宗的道理是,这些行为都是围绕着不同的业务需求而展开,为了满足不同阶段业务的发展而设计。无论是小企业还是大企业,很多时候,运维人员的确做了很多的事情,处理了很多紧急的事件,甚至都是在凌晨才动手,确实非常辛苦,真所谓是“累成狗,起的比鸡早,睡得比猪晚”。但是这些事情真正为业务创造了多少价值呢?老板知道吗?可能这个就是运维人员该好好思考一下的了。当然,我并不是否定我们运维在做的事情,毕竟我也是做运维出身的。这些事情的确是运维人员必须要做的,但是我的观点是不能陷在这个自我感觉良好的漩涡中。自认为运维做了很多的事情,非常的辛苦,甘做幕后英雄。如果有这样的想法,那一定是运维人员自己的问题了。运维不光是需要技术上的不断改进与创新,更需要思维观念的改变,学会站在业务的角度思考问题。往往在这个改变的过程中,运维的价值就会逐步的得到体现。
在这里,我总结了一下多年来自己做运维的经验分享给大家,踩过的坑,背过的锅,还历历在目。希望大家可以避开这些问题,做好企业IT系统的运维,体现运维的真正价值给公司。
运维是一件对知识面要求很高的工作,它要求运维者不仅要懂得基本的系统与网络知识,还要对运维的业务系统有较深的理解,知道整套业务系统的工作模式与工作原理。这也是对运维人员学习能力的一种考验。一听到故障描述,就可以大概知道问题的故障点所在。同时知道如何通过技术手段及清晰的逻辑方法去发现和解决问题。
运维是一件对自动化要求很高的工作,随着IT技术的不断发展,越来越多的方便运维的技术应运而生。从互联网时代开始,业务系统的交付和迭代也变得越来越频繁,从每月的迭代一次,甚至到了每天迭代多次的场景。如果没有自动化的手段快速响应与处理,对用户的影响可想而知。自动化的主要目的个人认为主要以下几个个:
运维是一件对精细化要求很高的工作,那么什么是精细化管理呢?引用一段官方解释“精细化管理是源于发达国家的一种企业管理理念,它是社会分工的精细化,以及服务质量的精细化对现代管理的必然要求,是建立在常规管理的基础上,并将常规管理引向深入的基本思想和管理模式,是一种以最大限度地减少管理所占用的资源和降低管理成本为主要目标的管理方式”。现在的IT运维已经进入了精细化管理的时代,而不是以前的大锅饭年代了。分工明确,注重细节、注重过程、注重质量。通过技术手段对全部的信息进行收集,管理员可以随时知道目前系统的运行状态。从而提高运维管理的整体水平和效果,实现了灵活的弹性扩容能力。
运维是一件对责任心要求很高的工作,各行各业都对责任心有很强的要求,运维也是如此。因为不同系统的应用等级不同,影响范围也会不同。如果运维人员因为疏忽大意导致业务系统崩溃,所带来的影响可能是灾难性的。比如银行的结算系统、股票的交易系统等等。
我认为一个运维人员技术可以不是那么精深,做事可以不是那么敏捷,但是一定要有一颗较强的责任心,否则一切归零。
随着信息技术的发展以及企业业务的不断扩张,运维人员所面临的系统架构越发的复杂,关联度越发紧密。从技术角度上,对运维人员的要求也会越来越高,需要个个都是精兵强将,对业务系统了如指掌。现在的运维已经不像N年前那种被动式的运维了,需要运维人员快速转变观念,学会通过主动运维的方式应对复杂多变的IT问题,保证业务系统的稳定。需要更多的站在客户的角度思考问题,解决问题。当然,每个人的经历不同,职责不同,所以对运维的理解也会有不同,我们可以将运维说的高大上、高精尖,也可以将运维说的稀疏平常、平易近人。高精尖、高大上是在于运维使用了很多非常牛X的技术,在业务系统没有感知的情况下实现了业务的变更、升级。终端用户可以在无感知的情况下继续进行自己的支付操作、游戏操作等等。稀疏平常是在于用户每天都有机会和运维人员打交道,或多或少,或深或浅都会有不同程度的交集。哪天不和运维人员发个牢骚、抱怨一下就会觉得自己没有来上班一样。以下是我总结归纳的一些不成规律的运维经验,不成方法的运维手段。正如前文所述,不同的人就会有不同的见解,不同的经验就会碰撞出不同的火花。欢迎运维爱好者一起讨论、拍砖。
结合自己多年的经验,总结了一些运维经验,希望可以抛砖引玉得到更多爱好者甚至专家的指点,促使我不断的进步。下文方法主要分为五大类:文档、流程、技术、监控和备份。
文档
正所谓兵马未动,粮草先行;一个好的系统或者项目,必定有很多的文档进行支撑。比如系统建设前期,一定要做好系统的需求文档、设计文档、实施文档。在系统建设中要依据前期的文档进行实施和设计,并生成系统相关的问题总结文档和更新实施文档。系统建设完成后,要基于系统的业务能力和使用对象编写操作手册和运维手册等。有些业务在交付的过程中,并未按照要求提供相关的文档,系统上线后问题层出不穷,导致运维人员手忙脚乱,不知道从何下手处理,往往会让运维人员绕很多的弯路,错失良机。文档也分好多种,比如配置文档、实施文档、设计文档、系统规范性文档、项目管理文档等等。基于种种,所以要求运维人员一定要具备相应的文档编写能力和整理能力。同时一定要严格按照之前的文档进行实施,有问题要学会及时沟通,并把修正后的问题更新到文档中。
以前文档的管理大多数是放在用户的本地,高级点是放在共享的NFS或者FTP中。但是很多的功能受到技术限制,不能满足高效、敏捷、互动的要求。通过知识库的一个文档管理功能,不仅可以解决如上问题,还可以将不同运维人员的经验和知识转化为生产力,协同办公。类似的软件比如Confluence、Wiki等。
流程
正所谓无规矩不成方圆;随着IT环境的不断扩大,业务变更的频繁度越来越高,就要求运维人员一定要基于一个既定的规则来干活,而不是完全按照业务的要求,被扯来扯去,拆东墙补西墙,毕竟业务人员专注点与运维人员的专注点不同,责任也不同。这规则就称为流程。在IT界最有名也最实用的流程莫过于英国政府部门CCTA在20世纪80年代末制定的ITIL了(即IT基础架构库(Information Technology Infrastructure Library, ITIL,信息技术基础架构库),当然现在由英国商务部OGC(Office of Government Commerce)负责管理,版本也从当初的V1到了现在的V3。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。这次我不是要细讲ITIL的内容,有兴趣的朋友可以Google、Baidu一下,认真研读ITIL,一定会让你受益匪浅,尤其是运维人员。
在整个系统的运维过程中,流程由始至终贯穿整条链路。它是对运维人员的保障,同时也是对所做变更合规可控的保证。合理的流程设置不仅节约了运维成本,也可以推进事情有序的进行,达到预期效果。那么如何制定符合实际需求的流程呢?这个就仁者见仁,智者见智了。我把整个过程分成三个阶段:
1.要做啥?
就是说这个流程要完成什么任务,目的是什么,切记一定是一个或者唯一的任务,不是多个任务。比如要安装软件、要变更配置、要发布程序等等。
2.谁来做?
就是说要完成这个事情,需要涉及到哪些部门的哪些人。请切记,流程一定要落实到人,否则就是空谈。
3.多长时间?
一个流程从开始到结束一定是有个时间约束的,也就是说这个流程被要求多长时间内必须完成。一般这个往往和业务系统的SLA有关,达不到要求可能会扣银子,那就不好玩了。当然流程不是固定不变的。随着IT业务和人员的变更,要学会对流程进行优化和改进,以适应最新的IT环境和业务要求。
技术
正所谓工欲善其事,必先利其器;如今是一个知识爆炸的时代,想获取什么知识只需要打开浏览器即可。不像以前还要频繁的出入图书馆,我记得当年自己经常去的就是新华书店啦(主要是因为那里可以坐下来慢慢的看书,而且还可以将其抄录下来),暴露年龄啦!现如今很多的企业都在强化以用户服务为中心,专业技术为驱动的理念,可见拥有过硬的技术是多么的重要。这里所说的技术,我主要想从两个方面入手,一个是指人员自身所掌握的技能,一个是指对主流技术的剖析与实践能力。
人员自身技能:
运维对技术的要求还是很高的,不是谁都可以做运维的。首先运维人员要对自己所负责的系统有较深的理解,全程参与系统的设计、实施与运维。正所谓打铁还需自身硬,就像武侠名著所说,每个武侠人物都会有个看家本领,比如乔峰的“降龙十八掌”,段誉的“六脉神剑“。运维人员也是如此,一定要具备相关领域的技术积累,有较丰富的设计或者排错经验。同时要具备较为灵敏的技术嗅觉,不敢说需要十八般武艺样样精通,但是也要对相关辅助技能略知一二,此称为硬实力。
光有硬技能其实只能证明你可以解决系统的硬性问题,但是不具备更好的解决问题的能力。很多重大的问题几乎都与外界系统相关联,甚至是强关联。
这个时候单纯的技术能力就很难解决了,需要运维人员具备以下软实力:
主流技术:
运维人员一定要对现在的主流技术有一定的涉猎(云计算、边缘计算、大数据、AIops、人工智能、深度学习等等),要与时俱进。经常参与线上或者线下的相关讨论和交流学习。了解目前流行的IT技术,并学习它,思考如何将其用于企业的业务中,为企业创造价值,提升运维效率。所以具备主流技术的捕捉能力,也是运维人员的必修课之一。
监控
正所谓与其后悔于已然,不如防患于未然,监控的目的就是防患于未然。通过监控,运维人员能够及时了解到企业网络的运行状态,一旦出现安全隐患,可以及时预警或者是以其他方式通知运维人员,让运维监控人员有时间处理和解决,避免影响业务系统的正常使用,将一切问题的根源扼杀在摇篮当中。监控的方式很多,软件更多。如何选择监控对象、设计监控指标就需要运维人员根据不同业务的实际情况自己去实践了。但是一定要记住,现在的监控工具可以在监控指标触发时,自动修复一些故障,但是它最多帮你做些简单的自动化任务,更高阶的自动化任务需要运维人员具备较深的脚本和系统知识。
所以监控作为运维人员的眼睛,要时刻保持12分精神,运维人员要定期对监控系统进行“照料”,避免“视觉疲劳”,影响监控效果。
备份
正所谓天有不测风云,人有旦夕祸福;备份是一种保障机制,一般用不到,用到就是大事。备份可以说是运维人员的最后一根救命稻草,用好这最后一根稻草可以起死回生,用不好就会死无葬身之地呀。其实一点也不夸张,公司将重资产都交给运维来做,是对运维的信任,运维人员自然要对这些资产和数据负责,对公司负责,这也是运维价值的一种体现。
现在被备份软件很多,国产的、国外的,所以选择一款适合自己业务需要的备份软件很重要。不是什么数据都需要备份,要首先甄别出哪些数据需要备份,确定备份范围。制定好备份策略,不同的数据需要不同的策略设定。选择靠谱的备份介质,到底是选择磁带、硬盘还是光介质等,这些都是需要运维人员根据业务需求而制定。
总结
以上这些算是自己对这十年运维经验的小小总结,很多内容不可能一日说完,也不可能全部写下来,毕竟运维这东西很多还是看自己的感悟和直觉。在运维方法浅谈章节中,我仅仅是总结了自己做运维用到的一些主要方法,并未涉及具体的技术。可能有些朋友会问,为啥没有体现当下流行的CMDB、可视化运维、ITSM等。其实这些都只是工具,一种让运维更透明,让运维人员更轻松,让老板更放心的运维工具。在实际工作中,可以根据需要自行采购或者自己开发,满足业务要求。最后和运维的朋友分享一段心里话,“运维是一件细致的工作,不允许一丝马虎。运维人员一定要富有勇于创新的精神和对工作的激情,有了这些东西,我相信,你一定是个非常优秀的运维人员。”