别再把 IT 运维和 IT 服务管理混为一谈了一个是救火一个是防火我先讲个前几天刚经历的事。我们公司有一套业务系统某个下午突然出现大量超时告警服务台那边工单瞬间堆了十几个。运维同事的第一反应是冲进机房看负载、查日志、重启服务前后大概二十分钟系统恢复了大家松了口气。但业务部门的负责人却很不满因为同样的问题这已经是本月第三次了每次都是修好了却没有任何人告诉他为什么会坏、怎么防止下次再坏。这件事特别典型地反映了当前很多企业 IT 部门的真实状态——我们天天挂在嘴边的运维和IT 服务管理表面上说的都是保障系统稳定运行这件事实操起来却是完全不同的两种管理模式。前者盯着设备和技术后者盯着用户和流程。如果你正准备转行运维、正在组建 IT 团队或者在公司里负责 IT 相关决策我建议你先花几分钟把这两者的区别想清楚因为方向错了后面再怎么努力都容易白费。今天这篇文章我不打算给你教科书式的定义对比而是结合我自己在运维一线和管理岗位上踩过的坑把这两套管理逻辑掰开揉碎了讲清楚。1. IT 运维的内核和机器打交道的手艺活1.1 运维到底在维护什么很多人以为运维就是管服务器的其实运维的边界远比这个宽。从底层的机房环境、服务器硬件、网络设备到操作系统、中间件、数据库再到上层的应用系统、业务进程凡是让数据能跑起来的这一整条链路都在运维的职责范围内。我最早干运维那会干的活基本就是这几类装系统、配网络、调防火墙、修磁盘阵列、排查进程死锁、备份数据、处理机房断电。那时候的公司规模不大总共几十台服务器运维就我一个人什么都要会一点。干的年头多了你会发现一个规律运维工作的大部分精力不是在建设而是在应急——系统坏了要修性能慢了要调数据丢了要找备份恢复。1.2 运维的思维模式是面向对象的这里的对象不是编程里的 object而是指运维的关注点是某个具体的设备、某个具体的进程、某条具体的链路。运维关心的是这台服务器的 CPU 使用率为什么飙到了 90%那个数据库的连接数怎么突然就打满了这个应用的内存为什么一直在缓慢增长。这种思维模式决定了运维的工作评价标准很直观系统跑不跑得稳业务卡不卡顿数据丢没丢。你不需要关心用户提工单的时候心情怎么样你只需要关心这个故障的技术根因是什么怎么最快恢复。所以运维圈子里有句老话叫救火队长式的运维说的就是这种工作状态——哪里着火了就去哪里喷灭火器。举一个很生活化的例子。就像物业公司的水电工——水管爆了要赶紧关阀门电路跳闸了要赶紧合闸处理完大家就都安心了。至于这个爆管的水管用了多少年、该不该整体换掉那是另一层管理者该考虑的事。运维干的最核心的事情就是把这个关阀门、合闸的活儿干漂亮、干得快。1.3 运维工程师的成长路径和技术栈聊到运维就绕不开技术栈的问题。现在网上经常看到Linux 常用命令大全网络运维从入门到精通这类资料很多刚入行的朋友就是靠这些硬啃下来的。以我个人的经验一个合格的运维工程师至少应该具备这几块知识储备操作系统层面Linux 系统管理、用户权限、systemd 服务管理、文件系统和磁盘管理。这是最基础的看家本领命令敲不熟很多事情都做不顺。网络层面TCP/IP 协议基础、VLAN 划分、路由交换原理、DNS 解析、常见的网络故障排查手段。云时代虽然很多网络能力被抽象成了控制台按钮但底层原理不懂的话出了问题只能干瞪眼。中间件和数据库Nginx、Redis、MySQL 是三家马车。业务系统基本离不开这三样会装会用不叫会出了故障能在日志里快速定位才算入门。脚本化和自动化至少掌握一种脚本语言Shell 是底线Python 是加分项。Ansible 这类自动化运维工具现在几乎是大厂标配批量执行命令、统一分发配置靠的是这一类工具。这几年DevOpsSRE的概念很火很多运维朋友在焦虑自己的岗位会不会被替代。我个人的看法是纯粹的人工巡检式运维确实在退场但那是因为工具在升级运维这个职能本身不会消失反而对综合能力的要求更高了。2. IT 服务管理的内核把修好变成服务好2.1 服务管理的关注点是用户你去看 ITILIT Infrastructure Library信息技术基础架构库的定义它强调的是把 IT 能力以服务的形式提供给业务和用户且服务要符合约定的质量和成本。这里的关键词是服务不是技术。同样是一次系统故障从运维视角看是某个服务进程崩溃了我把它重新拉起来了从服务管理视角看是某个业务部门的关键应用中断了 25 分钟超出了约定的可用性指标我们要分析原因、改进流程、避免再犯。你看同一个事故两种叙述方式这就是管理模式差异最直观的体现。我见过不少技术很厉害但团队管理一塌糊涂的 IT 负责人问题往往就出在这里——他们习惯用运维的思维去做服务管理。系统恢复了就觉得万事大吉从不复盘故障带来的业务影响也不去优化流程。结果就是团队每天忙得团团转业务部门却觉得 IT 部门不作为、不透明。2.2 服务管理的流程骨架如果只用一句话概括 ITSM 的精髓那就是把 IT 服务从发起到交付的全过程标准化、流程化、可度量。这里最关键的不是用什么工具而是脑子里要有流程的概念知道不同的事情该走不同的通道。举几个最常见的流程你就明白了事件管理用户报了故障什么时候受理、什么时候响应、什么时候解决每一步都要有记录和时间戳。SLAService Level Agreement服务等级协议就是挂在事件管理上的标尺。问题管理同一个故障如果反复出现不能每次都在事件层面打地鼠而要升级成问题去做根因分析从根本上消除隐患。变更管理系统配置要改、版本要升级不是想改就改而是要经过评估、审批、回退方案设计这一整套流程降低变更带来的风险。服务台这是用户看得见的窗口。好用的服务台不只是接电话、记工单还要能对常见问题提供一线解答筛选出真正需要二线专家介入的复杂问题。2.3 运维和 ITSM 最容易被混淆的交叉地带现实中很多团队把上了个工单系统就理解为做了 IT 服务管理这是一个天大的误解。工单系统只是工具它承载的流程设计和管理理念才是 ITSM 的本体。同样是工单有的团队用出了接派单、干活、关单的快递员模式有的团队则用成了登记、分诊、处理、复盘、改进的分级诊疗体系。打个比方吧。运维就像医院里的急诊科医生负责接诊处理紧急病患服务管理就像医院的医务科负责制定接诊流程、安排医生排班、统计平均候诊时间、分析高发疾病并做预防。急诊科当然重要但一个没有医务科的医院不可能运转得好。从我的经验看这两者在组织架构里的关系也容易拧巴。小团队通常是技术骨干兼职干服务管理的活结果技术骨干天天写代码查故障根本没人管流程大企业则容易走向另一个极端——流程部门一把抓定了很多表格和审批节点结果一线运维被繁文缛节绊住了手脚光填表就填掉半天时间。3. 两种模式在实战中的碰撞为什么ITIL 在墙上运维在地上3.1 我在混合管理模式中踩过的坑我前几年在一家传统企业做 IT 基础设施负责人。刚去的时候公司刚花大价钱上了一套商业 ITSM 平台管理层觉得 IT 部门终于现代化了。但实际情况是运维团队几乎不用这套平台——大家还是通过微信群接需求、用 Excel 记故障只有完不成绩效考核的时候才去系统里补几张工单。系统上线一年里面的数据基本是垃圾进、垃圾出管理层想看个故障趋势报表都拿不出手。后来我花了很长时间去做访谈才知道问题出在哪。运维觉得工单流程太啰嗦一个小问题走流程比解决问题本身还费时间业务部门觉得服务台的响应太慢打个电话在微信里吼一嗓子比提工单管用得多。说白了流程设计脱离了实际场景工具再贵也白搭。这个经历让我学到一课ITSM 的落地不是技术问题是习惯和机制问题。只靠行政命令逼着大家填工单永远填不出真实数据。你得让流程本身提供价值比如通过工单统计发现了某个网络设备频繁告警促使你主动排查把它换了这种流程带来的好处被一线体会到了他们才会从心里接受流程。3.2 运维与 ITIL 的互补关系说到这儿我得把话说公道一点——这两种管理模式不是非此即彼的替代关系而是不同纬度上的互补关系。依然用医院类比急诊室救死扶伤要靠医生的个人技术这是运维能力但医院要提高整体救治水平必须靠流程和制度不能指望每次来一个心梗病人正好都碰上同一位置顶级专家当班这是服务管理能力。好的 IT 组织一定是两条腿走路运维能力保障今天不崩快发现、快恢复、技术过硬。服务管理能力保障明天更好有统计、有复盘、有流程优化。如果你是小团队可以以运维为主但至少要有服务管理的意识——比如记录每一次故障的处理时间和根因这就是最低成本的 ITSM。等你团队变大了、系统变多了服务管理的比重再逐步加大这时候引入正式的工具和流程才顺理成章。3.3 如何判断你们团队当前更需要哪一边不少朋友圈子里的朋友问我他们的公司该不该上 ITSM 平台、该不该成立专门的服务台团队。我给他们的判断标准很简单如果你的团队只有三五个人系统规模也不大故障基本靠喊就能解决那优先把技术底子打好把监控告警做好同时养成写变更记录的习惯就行。这时候硬上流程体系反而拖累效率。如果你的团队有十几个人、管理几百台设备或者几十套应用用户数量超过几百那就需要引入流程化管理了。因为这时候故障影响的扩散面很大没有流程记录你连哪个系统最不稳定这种基本问题都回答不了更别说做容量规划和预算申请。再多一个维度如果你的 IT 部门要对外提供计费服务或者要对集团汇报服务水平和成本数据那服务管理就是刚需了这时候 ITSM 平台的价值会得到非常充分的体现。4. 从修理工到服务经理落地 ITSM 的实战经验4.1 先梳理服务目录而不是先选工具我见过很多团队的失败路径是反的先花钱买工具再让团队硬用最后工具闲置。正确的做法应该是先梳理自己的服务目录——你面向用户提供哪些 IT 服务服务范围是什么质量标准是什么计费还是免费响应时效承诺多久服务目录是 ITSM 一切工作的起点。就好比你开一家餐厅先得有菜单才知道后厨要准备什么食材、前台要承诺多大上菜速度。没有菜单的餐厅客人点什么全凭厨师心情服务好坏基本靠运气。以我的实际工作经验来说一个中小型 IT 团队的服务目录至少应该包含这些条目账号权限开通和管理、办公终端支持、网络接入服务、业务系统访问和使用支持、数据备份与恢复服务、邮件与协同办公服务。每个服务条目下面建议明确服务的对象、服务时间、响应标准、费用情况。4.2 以事件管理为抓手别一上来就铺开全部流程ITIL 是个庞大的框架包含十几个流程如果一上来就全面建设团队很容易被流程淹死。我自己的经验是从事件管理和变更管理这两个流程作为切入点先把它们跑顺了再逐步扩展。原因很简单事件管理对应的是每天都会发生的用户报障是用户最能感知的 IT 服务触点做好了立竿见影变更管理对应的是系统变更这种高风险操作是运维事故的头号诱因管住了变更就能少一半故障。事件管理落地的时候有几个经验可以分享工单分类不要做得太细先设置故障报修、服务申请、咨询三大类就够了分类的作用是为了分派和统计不是给用户添堵。优先级设置务必简单明了建议先采用两级制普通和紧急如果有对外的 SLA 承诺再细化到三级。优先级设置过于复杂的代价是一线人员在几秒钟内做不出正确判断。每个工单从创建到关闭的每一步流转都要有对应的时间戳和责任人这样后续复盘才能有据可查。4.3 变更管理怎么落地才不会被一线抵制说到变更管理我必须替一线的运维兄弟们说句话变更流程如果设计得太死板确实会让人抓狂。很多运维宁愿扛着风险偷偷变更也不走流程就是因为公司的变更审批又慢又重等审批通过业务高峰期都到了。好的变更管理应该是分级分类的低风险变更比如重启一个非核心服务、添加一个测试环境账号可以做简化的记录式流程甚至事后报备都行。中风险变更比如升级常规软件版本、调整防火墙策略需要有变更申请、风险评估、指定变更窗口。高风险变更比如数据库版本大升级、核心网络架构调整、机房迁移必须走完整流程包括详细的实施方案、回退方案、演练记录、管理层审批、变更后的观察期。这个分级思想在 ITIL 里叫标准变更和紧急变更的区分。现实执行中最忌讳的就是把高风险的管控强度套用到所有变更上那只会把所有人都逼到流程之外去。4.4 度量指标避免为指标而指标管理大师说你度量什么就得到什么这在 ITSM 领域体现得淋漓尽致。但我见到很多团队的度量指标设计得非常有问题。比如考核运维的工单关闭率结果运维想尽办法把工单状态改成已关闭而不是真正解决问题或者诱导用户撤销工单。我认为对中小团队来说最值得关注的指标就三个MTTA平均应答时间从用户提工单到服务台首次响应花了多久。这是用户体验的第一印象。MTTR平均修复时间从故障发生到恢复的时间。这体现的是应急和排障能力。问题重复发生率同样根因的故障在统计周期内出现了几次。这个指标是指向问题管理的信号灯如果反复率高说明团队只做了救火没做防火。这三个指标能满足绝大部分管理需求。至于更细的指标比如工单按时解决率服务满意度评分等团队流程成熟之后再逐步引入也不迟。4.5 从运维向服务管理的角色转型最后聊一个很多朋友关心的话题运维工程师想转型做服务管理需要做哪些准备。我自己就是从运维工程师转型到 IT 管理岗的这个过程中最大的感受是——难的从来不是技术而是思维方式。做运维的时候我面对的是机器机器是讲逻辑的你对它好配置合理它就稳定你配错了它就报错做服务管理的时候面对的是用户、业务方、供应商、老板每个人都有一堆诉求和情绪很多事情没有绝对的正确答案只有各方都能接受的平衡点。具体建议给三条练表达你写的故障报告要能从技术语言翻译成业务语言。比如内存使用率达到 95%这种话业务听不懂你要说的是系统有卡顿风险建议下周扩容预计影响会消除。学财务服务管理免不了涉及成本核算一台服务器的采购和使用成本多少、一个系统的年度维护成本多少你要能算清楚这笔账否则没法跟财务和老板对话。懂人性流程设计的本质是改变人的行为习惯这就需要你了解不同角色的利益诉求。运维想要的是少背锅业务想要的是响应快管理层想要的是数据透明。好的流程是让三方都觉得这个流程对我有帮助而不是让三方都骂娘。我在实际管理工作中还有一个体会特别深真正优秀的 IT 团队是那种既有很强的运维能力又愿意花精力做服务管理的团队。光会救火的团队系统天天狂轰滥炸地告警大家疲于奔命光有流程和制度的团队出了问题没人解决得了用户一样骂娘。这两者就像是人的左右手缺了一只做什么事都别扭。所以看到这个标题的时候我希望你记着这句话——运维是你搞定事的看家本领服务管理是你理顺关系的为人处世之道两者都抓起来你的价值才会真正闪光。