10年经验总结：企业级IT系统运维怎么搞？（it运维总结报告）

其实不能说这是错误的理解，IT 运维人员的工作小到修电脑、理网线，大到部署整个数据中心。

负责运维的设备，小的从个人电脑，大的到数以亿计的高精尖计算设备（比如 IBM 的大型机 Z13）。

从运维的工作层次来分，又分为硬件运维、桌面运维、系统运维、数据库运维和应用运维。几乎所有的和系统相关的问题，都与 IT 运维人员有关。

根据公司 IT 系统规模的不同，有的运维团队不到 10 人，有的甚至达到数百人。每晚通宵达旦，为 IT 系统保驾护航。

但是始终还是有很多的人和同事会质疑：为什么我的电脑还这么卡？网络速度还这么慢？某某系统还是上不去，很影响业务运营等等。

这些质疑让运维人员很尴尬也很无语，有些问题甚至类似客户没有插网线，抱怨上不去网。

有时候甚至会胡思乱想，究竟运维的意义是什么？这么努力怎么还这么受气？

前段时间与运维方面的朋友一起交流的时候，大家总是时不时的诉苦，抱怨运维苦逼，没有成就感，甚至经常成为“窦娥”、“背锅侠”的代名词。

种种抱怨和不满，也促使我更加的想表达一下如何做好 IT 运维方面的经验和个人见解（不一定对，欢迎拍砖），尤其是企业级的 IT 系统运维。

因为企业级的 IT 系统运维不但系统分支多，而且够复杂。业务频繁变更，要求 IT 系统必须随需应变。

本文作者将分为如下几个部分剖析企业级IT系统运维者如何才能体现真正价值？

• 运维的价值
• 什么是运维
• 运维方法浅谈
• 总结

运维的价值

我毕业后就一直从事 IT 系统运维方面的工作，从当初的桌面技术人员到现在的运维总监，一路荆棘，回想起来已有超过 10 年的运维经验了。

虽然谈不上老道，更说不上是大咖，但是也总结了一些自己对运维工作的理解，对运维价值的理解。

多年的摸爬滚打，我对运维总结成了两句话：“技术只是手段，业务才是王道”。运维的好坏评定标准其实就是你给公司及业务带来了哪些价值及哪些影响。

业内有很多的运维专场，每年不下数十场。从之前传统运维到现在的敏捷运维甚至 AIOps，这些都是在说运维的方法。

通过这些方法让运维变得更灵敏、让运维人员更好的理解用户的需求。但是万变不离其宗的道理是，这些行为都是围绕着不同的业务需求而展开，为了满足不同阶段业务的发展而设计。

无论是小企业还是大企业，很多时候，运维人员的确做了很多的事情，处理了很多紧急的事件，甚至都是在凌晨才动手，确实非常辛苦，真所谓是“累成狗，起的比鸡早，睡得比猪晚”。

但是这些事情真正为业务创造了多少价值呢？老板知道吗？可能这个就是运维人员该好好思考一下的了。

当然，我并不是否定我们运维在做的事情，毕竟我也是做运维出身的。这些事情的确是运维人员必须要做的。

但是我的观点是不能陷在这个自我感觉良好的漩涡中——自认为运维做了很多的事情，非常的辛苦，甘做幕后英雄。

如果有这样的想法，那一定是运维人员自己的问题了。运维不光是需要技术上的不断改进与创新，更需要思维观念的改变，学会站在业务的角度思考问题。往往在这个改变的过程中，运维的价值就会逐步的得到体现。

在这里，我总结了一下多年来自己做运维的经验分享给大家，踩过的坑，背过的锅，还历历在目。

希望大家可以避开这些问题，做好企业 IT 系统的运维，体现运维的真正价值给公司。

什么是运维

运维是一件对知识面要求很高的工作，它要求运维者不仅要懂得基本的系统与网络知识，还要对运维的业务系统有较深的理解，知道整套业务系统的工作模式与工作原理。

这也是对运维人员学习能力的一种考验。一听到故障描述，就可以大概知道问题的故障点所在。同时知道如何通过技术手段及清晰的逻辑方法去发现和解决问题。

运维是一件对自动化要求很高的工作，随着 IT 技术的不断发展，越来越多的方便运维的技术应运而生。

从互联网时代开始，业务系统的交付和迭代也变得越来越频繁，从每月的迭代一次，甚至到了每天迭代多次的场景。

如果没有自动化的手段快速响应与处理，对用户的影响可想而知。自动化的主要目的个人认为主要是三个：

效率提升

初期自动化主要解决的是和日常运维例行工作相关的操作。

比如各种平台的资源分配&回收、统一配置管理、CI&CD（持续集成&发布）、操作系统的部署、系统空间的扩容与缩容、简单应用部署、文件分发等等，这些都是运维最基础的工作，也是自动化最容易实现和集中的领域。

个人觉得凡是那些偏日常和重复的工作都应该自动化，解放运维的生产力，提升运维效率，降低人为失误，让运维的同事可以有更多的精力去学习更多的技能。

做更有价值的事情，无论互联网时代还是大数据时代，人才毕竟是最贵的。

目前自动化的解决方案都相对完善了很多，所以可以放心的去实践和应用。对于重要的领域和操作，一定要经过严谨的测试才能应用，否则自动化带来的灾难也是不可估量的。

可靠可控

可控对于运维人员来说是再重要不过的了，自身经验是，如果运维一套不可控的系统，无疑是攥着一颗不知道什么时候会爆炸的定时炸弹，时刻担心它会产生不可预知的后果。

可控要细说我觉得大致可以分为稳定性可控、性能可控和安全可控。

稳定性可控

作为企业级的运维人员，我们要运维的系统不但数量多，而且网络架构复杂。

包括的硬件更是多样，除了熟知的服务器、存储、网络设备、负载均衡设备等，可能还有很多是运维人员没有接触过的新玩意。

而这些硬件又承载了各种应用，组成了各类不同的系统供用户访问，复杂程度不言而喻。

如何让这些设备在损坏的情况下也不影响业务，不影响运维人员陪女朋友看电影。

做到心中有数，掌控硬件损坏会对系统有什么影响，需要多少时间来修复等等。

性能可控

合理的分配系统资源产生合理的性能对系统的稳定性起到了至关重要的作用。

一个系统慢与快并不是运维人员最担心的，而是时快时慢是最可怕的，因为那种状态是最不可控的状态，这样的系统是不可能承载企业核心或者重要的业务的。

最典型的应用场景就是云计算平台的资源分配。一旦平台资源被错误的分配，对业务的影响是不可估量的，排错过程也是运维人员最头疼的。

安全可控

现在运维圈子流行的模块化管理、运维自动化、可视化甚至是基于大数据决策的运维，本质上都是希望达到运维可控的目标。安全是唯一一个贯穿运维全部过程的模块。

所以运维人员每日都会花费特别多的精力在系统的安全建设和防御上，比如防止哪些未授权行为，所有的操作必须通过堡垒机，关键操作必须通过审计等等。

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，一定会让你受益匪浅，尤其是运维人员。

ITIL 环形图

在整个系统的运维过程中，流程由始至终贯穿整条链路。它是对运维人员的保障，同时也是对所做变更合规可控的保证。

合理的流程设置不仅节约了运维成本，也可以推进事情有序的进行，达到预期效果。那么如何制定符合实际需求的流程呢？这个就仁者见仁，智者见智了。

我把整个过程分成三个阶段：

• 要做啥？就是说这个流程要完成什么任务，目的是什么，切记一定是一个或者唯一的任务，不是多个任务。比如要安装软件、要变更配置、要发布程序等等。
• 谁来做？就是说要完成这个事情，需要涉及到哪些部门的哪些人。请切记，流程一定要落实到人，否则就是空谈。
• 多长时间？一个流程从开始到结束一定是有个时间约束的，也就是说这个流程被要求多长时间内必须完成。

一般这个往往和业务系统的 SLA 有关，达不到要求可能会扣银子，那就不好玩了。

当然流程不是固定不变的。随着 IT 业务和人员的变更，要学会对流程进行优化和改进，以适应最新的 IT 环境和业务要求。

技术

正所谓工欲善其事，必先利其器。如今是一个知识爆炸的时代，想获取什么知识只需要打开浏览器即可。

不像以前还要频繁的出入图书馆，我记得当年自己经常去的就是新华书店啦（主要是因为那里可以坐下来慢慢的看书，而且还可以将其抄录下来），暴露年龄啦！

现如今很多的企业都在强化以用户服务为中心，专业技术为驱动的理念，可见拥有过硬的技术是多么的重要。

这里所说的技术，我主要想从两个方面入手，一个是指人员自身所掌握的技能，另一个是指对主流技术的剖析与实践能力。

人员自身技能

运维对技术的要求还是很高的，不是谁都可以做运维的。首先运维人员要对自己所负责的系统有较深的理解，全程参与系统的设计、实施与运维。

正所谓打铁还需自身硬，就像武侠名著所说，每个武侠人物都会有个看家本领，比如乔峰的“降龙十八掌”，段誉的“六脉神剑“。

运维人员也是如此，一定要具备相关领域的技术积累，有较丰富的设计或者排错经验。

同时要具备较为灵敏的技术嗅觉，不敢说需要十八般武艺样样精通，但是也要对相关辅助技能略知一二，此称为硬实力。

光有硬技能其实只能证明你可以解决系统的硬性问题，但是不具备更好的解决问题的能力。很多重大的问题几乎都与外界系统相关联，甚至是强关联。

这个时候单纯的技术能力就很难解决了，需要运维人员具备以下软实力：

我认为首先要具备的就是沟通能力：记得刚工作的时候，我们部门的技术人员被戏称为“傻、呆、倔”，脑子里装的都是代码和命令，什么风花雪月、人情世故都成功的过滤了我们。

随着困难增多，坑踩多了后，才知道沟通是多么的重要。良好的沟通可以很快与多部门协同工作，了解大家的共同点和痛点，对症下药，可以更快速的解决问题。

合作心态很重要：这么多年，我一直认为团队作战远比孤军奋战要强，效率要高。尤其现在很多的公司都有分公司，IT 运维人员往往也是分布式的。

总部与分公司员工之间只有保持合作心态才可以高效、快速的发现问题、解决问题。

同理心让沟通事半功倍：很多人认为同理心是企业中负责用户体验部门的技能，实际上随着互联网技术的发展，IT 与业务的紧密融合，运维人员是非常需要同理心的。

当运维人员接到故障报告或者通知，需要及时与客户沟通，站在客户的角度理解问题，解决问题，避免无谓的抱怨与投诉，提高运维满意度。

善于写作的基础：无论是系统还是项目从孵化到交付都离不开文档的支持。运维人员应该具备良好的文档写作能力，可以将系统设计说明清晰，问题描述清晰，解决方案条理清晰。

运维人员如果每天都往机房跑，一定是有问题的。多数时间应该是在学习、探索，自我提升、总结问题，避免二次发生。这些都需要文档的记录与支撑。

认真做事的态度：认真做事的态度在任何的行业都是通用的好模板。记得一本书上说过“你做事的态度，决定你的高度”对于运维人员来说，一定要高度热爱自己的工作，如果你不热爱它，肯定不会认真的去做。

这不是一句口号，而是要以结果为导向，具备不达目的不罢休的精神。有些运维上的问题，就是某个细节所决定的，只有认真才能从众多乱麻中，找到线索，解决问题。

主流技术的剖析与实践

运维人员一定要对现在的主流技术有一定的涉猎（云计算、边缘计算、大数据、AIOps、人工智能、深度学习等等），要与时俱进。

经常参与线上或者线下的相关讨论和交流学习。了解目前流行的 IT 技术，并学习它，思考如何将其用于企业的业务中，为企业创造价值，提升运维效率。所以具备主流技术的捕捉能力，也是运维人员的必修课之一。

监控

正所谓与其后悔于已然，不如防患于未然，监控的目的就是防患于未然。通过监控，运维人员能够及时了解到企业网络的运行状态。

一旦出现安全隐患，可以及时预警或者是以其他方式通知运维人员，让运维监控人员有时间处理和解决，避免影响业务系统的正常使用，将一切问题的根源扼杀在摇篮当中。

监控的方式很多，软件更多。如何选择监控对象、设计监控指标就需要运维人员根据不同业务的实际情况自己去实践了。

但是一定要记住，现在的监控工具可以在监控指标触发时，自动修复一些故障，但是它最多帮你做些简单的自动化任务，更高阶的自动化任务需要运维人员具备较深的脚本和系统知识。

所以监控作为运维人员的眼睛，要时刻保持 12 分精神，运维人员要定期对监控系统进行“照料”，避免“视觉疲劳”，影响监控效果。

备份

正所谓天有不测风云，人有旦夕祸福。备份是一种保障机制，一般用不到，用到就是大事。

备份可以说是运维人员的最后一根救命稻草，用好这最后一根稻草可以起死回生，用不好就会死无葬身之地呀。

其实一点也不夸张，公司将重资产都交给运维来做，是对运维的信任，运维人员自然要对这些资产和数据负责，对公司负责，这也是运维价值的一种体现。

现在备份软件很多，国产的、国外的，所以选择一款适合自己业务需要的备份软件很重要。

不是什么数据都需要备份，要首先甄别出哪些数据需要备份，确定备份范围。

制定好备份策略，不同的数据需要不同的策略设定。选择靠谱的备份介质，到底是选择磁带、硬盘还是光介质等，这些都是需要运维人员根据业务需求而制定。

总结

以上这些算是自己对这十年运维经验的小小总结，很多内容不可能一次说完，也不可能全部写下来，毕竟运维这东西很多还是看自己的感悟和直觉。

在运维方法浅谈章节中，我仅仅是总结了自己做运维用到的一些主要方法，并未涉及具体的技术。

可能有些朋友会问，为啥没有体现当下流行的 CMDB、可视化运维、ITSM 等。

其实这些都只是工具，一种让运维更透明，让运维人员更轻松，让老板更放心的运维工具。在实际工作中，可以根据需要自行采购或者自己开发，满足业务要求。

最后和运维的朋友分享一段心里话：“运维是一件细致的工作，不允许一丝马虎。运维人员一定要富有勇于创新的精神和对工作的激情，有了这些东西，我相信，你一定是个非常优秀的运维人员。”

结尾祝做运维的朋友在运维的道路上越走路越宽，技术更上一层楼。也祝自己在以后的工作中学习到更多，分享更多给大家。

作者：张志强

简介：从事信息技术服务及管理工作，多年的云计算、虚拟化架构设计、企业信息化建设、自动化运维经验。熟练掌握 X86、Power、存储、虚拟化等硬件设备调优与配置。拥有丰富的混合元架构及管理经验，信息安全及网络架构的设计与运维。