IT服务管理的三大难题

一位熟悉IT服务管理的朋友曾对我说，服务管理是自动化程度最低的一个行业。我觉得这是一个很有意思的观点，那么，顺着这个往下想，运维服务会不会也是管理最薄弱的一个行业呢？

我接触运维服务的时间并不长，但是我个人总觉得我们把运维服务搞得复杂化了。其实，运维服务所涉及到的业务并不复杂，尤其是相对于制造业而言，更要简单得多，但为什么制造业的管理要比运维服务的管理成熟得多呢？

我觉得这是一个管理资源的问题，也是一个时间的问题，在运维服务行业真正意义上的管理者非常缺乏。我说的管理者，是指那些懂得用对象的方式看待业务与流程的人。有时我们过于强调行业经验的重要性，事实上在管理领域，行业的特性给管理者带来的特殊要求并不如我们想像的那么多。运维服务尚未真正形成行业，多数的领导者并不是管理见长的，多是从底层或技术提升而来的人员，视野与管理理念的缺乏，这也妨碍运维服务管理的成熟与发展。

以下我将就运维服务管理的一些难点及问题展开说明。

项目型管理

当一个组织是以项目的形式来运作时，在管理上的积淀是比较困难的。项目本身就是一个独立的权力结构，但并不是公司法定的，公司的组织机构是按部门、科室来划分的，公司的管理体系也多是以部门的职能来划分流程，这时权力的矛盾就一定会在业务运作时产生，发生资源的掠夺行为，要么部门难以管理，要么项目难以管理。

而由于项目是一个临时的组织，这种人力的汇聚与释放都比较麻烦，人不是一个机器部件，放在哪儿都是一样，起用一个新人需要相当长的磨合期，而且公司的任务往往是有周期性的，人力释放时并不意味着可以马上投入利用，这种痛苦没有经历过很难体会到，这比在ERP中排生产计划还要难。

运维服务一般是以项目的形式管理的，项目内的作业与要求，与部门或公司的制度或管理往往是存在偏差的，这时如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动地敷衍配合公司的制度或管理。

比如培训，站在部门或公司的角度，希望进行员工能力提升的培训，这种计划安排与内容，往往与项目内希望做的培训有非常大的出入。很多时候项目的一线主管们，往往认为公司或部门并不是帮助他们，而是一个麻烦制造者。一旦项目数量大时，这种情况更普遍。因为项目越多，上层对规范、标准化的愿望就越强烈，当一线的项目主管们花费越来越多的管理资源配合公司的规范与标准时，对项目的控制力就会开始下降，一旦发生问题，上层领导就会认为是因为缺乏规范与标准化，形成一个恶性循环。

我经常看到一种现象，当某个项目发生严重运维事件时，马上会短时间把管理资源进行堆积，对这个事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项目进行落实，这种做法真的有用吗？我怀疑，因为反应过度了，也有些缺乏理性。资源永远是有限的，你把多数的资源花在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制。当你想达到一个目的时，你会采取一种措施，但事实上你采用的措施往往会妨碍达到这一目的。

对于运维服务而言，让客户用一个最重要的词来说出他的要求，他们往往是说“稳定”。同样的道理，运维服务管理也是最需要稳定的，那种救火堵漏的做法并不可取，你先要稳定管理，再去谈改善。永远处于制度的发布与调整中，会让运维服务管理反而成为最大的运维风险。

作为运维服务的管理部门，一定要想清楚自已应该做些什么，你的管理边界在什么地方，你是一个政策制订者，不应该越过项目的边界去干涉项目的内部事务，这种做法最多只能取得短期成效，从长期而言，结果一定是负面的。管理部门负责服务体系的维护与执行监督，以及所有服务资源调配的控制者，这才是最重要的，在细节层面，管理部门应该只起到辅助的角色。

运维资源利用的两难

有时我在想，运维人员是应该忙还是闲呢？如果忙，那证明运维问题比较多，如果闲，证明运维问题比较少，但是资源可能没有充分利用。

那有没有一种可能，把每一个运维人员的工作安排得都不是那么忙，也不是那么闲呢。运维最大的成本就是人力的成本，想办法充分提高工时利用率，这本是无可厚非的。但真正分析下来，做到这一点不太现实，甚至可以说是很困难的。

运维的作用，当然也有许多日常的事务，但更多的时候，运维的价值体现在出现问题时的响应与处理。在多数的运维服务中，运维对象并不是标准化的，尤其是在软件领域，这就决定了人员复用上比较困难。因为一个人员的脑子只能装进几个系统，同时每个系统的升级与处理故障的知识是每隔一段时间就更新的。

举一个例子：A系统每天的问题处理需要3小时，B系统需要3小时，现在是由两个不同的人员负责的，那是不是可以由一个人负责运维这两个系统呢，现实情况肯定是行不通，即便一个人可以掌握两个系统运维的知识，两个系统发生的故障的时间完全有可能重叠，还有其他的各种临时事务会挤在一起，造成服务问题，这种情况下人力的闲置就不可避免了。

所以，即便一名服务人员的资源没有充分利用，客户也会购买你一整个的人力，这似乎是可以接受的，但当这样的闲置情况很多时，作为一个商业公司，就一定会想办法去提高资源利用率，这方面好像除了提高人员的运维能力范围外，没有非常好的办法对应解决。

我们需要什么样的服务台

服务台设立也是一个比较复杂的课题，怎样的服务台才最有效，才能最节省资源。如果仅仅为了满足参观者的感官，可能让一帮戴着耳机的女接线员坐成一片，忙碌着，用甜美的声音问着好，这样看着像个服务台，也显得专业有气派。但现实情况中，这样的服务台形象是有，但很可能实质上未没有起到作用，是在浪费运维资源。

从只有几个项目，发展到有几十个项目时，服务台就会开始质变。项目非常多时，服务台的人员不可能听得懂客户在说些什么，尤其当你的运维服务不是标准化的产品服务时（比如桌面）。当一个客户打电话过来说“我的售车申报做不了”，服务台人员如果没有比较深入的项目知识，就会连是哪一个系统都搞不清楚，甚至连问题描述与等级都不知道如何定（注意服务台人员要在ITSM系统中派单），这时服务台可能直接转电话或者草草记录下来。

这种情况下，服务台人员的作用跟一个4万元的语音菜单没有区别。更有意思的是，有语音菜单时，语音菜单会在客户电话时提示，A系统请按1，这时就电话接入到服务台，还是接入到这个系统的一线工程师呢？如果服务台可以处理这个电话，事实上服务台就是一线，多数情况下服务台人员无法处理这样电话，除非你把所有一线工程师纳入服务台。

这里面好像有一些规律，在运维服务中，当你的服务台无法做一线支持时，这种时候不设立专门的热线员会合适些，或者把一线支持人员全部纳入服务台中，把服务台做成一个虚拟或混合形的。

做好运维服务分析

运维服务中，我们一直强调改善，改善就意味着一要清楚你的现状，二是要清楚你的目标，这两点是要基于大量数据分析的，而且运维服务都是基于项目的，而我们说的改善并不光是针对项目这么微观的层面，而是基于整体的层面，就是意味着你的数据有一个度量标准，这个标准适于不同的类型的项目，不然你根本无从知道整体状况。

这里ITIL中的SLM（服务等级管理）有一个指引作用，但这还不够，我认为要做到深入的运维分析，需要以下的几个要素。

其一，需要有一个精确的CMDB（配置管理数据库）。CMDB提供信息让你方便把每一次的事件定位，以便让你知道什么地方的什么组件出了多少问题，在项目层面可以提供精确的数据来做改进（哪一个模块是问题最多的），在管理层面，CMDB的附带信息会告诉你哪一类的设备是我们运维的薄弱环节（如果硬盘的故障比重较大，我们可能换供应商，或者提升运维人员的硬盘维修能力），

其二，需要有一个横向业务分类基准。要基于组织层面，规划出一个分类数据，以供每一个项目统一调用，比如事件的类型可以分为：故障、请求、咨询、新需求、投诉。这样可以跨项目统计每个周期内的每一个事件类型有多少。比如事件的分类：我们可以分为软件、硬件、网络、数据库、接口、业务等。

其三，需要时间资源的记录。这一部分的数据采集是最为困难，也是最有价值的，它与上面的信息交互分析，可以知道哪一类设备花去我们最多的时间资源（CMDB），可以知道我们硬件故障的平均处理时长是多少（事件分类），还可以知道新需求会花去我们多少时间资源（事件类型），除此之外，还有基于员工的绩效分析以及运维结算的数据统计，都需要基于此部分信息。

ITSM工具有用吗？

运维服务作业采用ITSM软件管理，这本是没有什么值得争议的，但是在应用时，的确有时比较两难。有人问我，用ITSM系统对一线的工程师到底有什么好处，如果是官方的解释的话，我会说出一大堆，但是真的是这样吗？

换位思考，如果我是一名一线的工程师，是不愿意使用这种工具的，我快速把事件搞定，不去填任何信息，来得多快，说什么知识库与CMDB，我没有这些一样可以处理故障。

上面说的是现实情况，我并不是否认ITSM工具，只是它真正的价值在于平台意义与运维服务管理的意义，而不在于具体的业务支持。我们会因为ITSM系统的上线，而降低运维服务成本吗？会提高运维服务的效率吗？我的回答是不会，起码短期不会。同样是修一台电脑，怎么可能因为上一个ITSM工具，以前只需要30分钟，现在就只要20分钟呢

人们一直没有真正理解管理软件的真正价值。管理软件首先要满足管理的需求，而不是具体业务操作的需求，你想提高桌面的运维效率么，SMS是解决这一方面问题的，上ITSM工具，是为了固化体制与流程，让服务体制更规范与标准化，形成一面镜子，把真实的运维现状反映出来，让运维服务真正意义上管理起来。如果说在某一段时间会增加了成本，那么这个成本是你必须需要付的，因为这是你以前欠下的债。

用一个不恰当的例子吧，学内功不能让你很快打倒一个人，学一个招式可能可以，但当你学十年的内功跟学十年的招式相比，前者会更具成效，而且当你招式了一两年后，你会发现你根本无法进步了，因为缺乏根基。

要想清楚你上ITSM工具是为什么，你要解决什么问题，如果你不是为了解决管理上的问题，也不是为了提高工程师效率，那么不是你的目的错了就是选择错了。只有当运维服务管理稳定成熟后，才能为你后续的一切提升以及成本效率提升提供源源不断的动力、方向、决策支持数据，而软件就是帮助你前行的有力工具。

ITSM工具，由于SLA的计算，对事件处理信息录入有比较苛刻的要求，这对一些经常需要在厂区跑来跑去的工程师来讲是比较麻烦的。比如桌面项目服务工程师，他们不可能随时带电脑在身上，外出服务时，都是电话派单过去，这时事件单关闭不及时，会引起SLA的计算失真问题，这些都是一些负面影响，在软件功能上很难有什么解决办法，需要有其他的对应方式。

选取了ITSM工具，如果领导者不坚定，最后应用可能得不偿失，如果没有强力实施到底，到时数据采集不到，管理分析无法有效进行不说，反而会让工程师怨声一片，两头不讨好。

其实退一万步说，最坏的结果是，即便没有有效支持业务活动，工程师要填写更多的信息了，但对公司来说有负面影响吗，我们不会因为上一个ITSM工具而多请几个人，也不会因为上一个ITSM工具多发一些加班费，所以成本其实是不会因此上升的，长期来说，收益一定是有的。