运维服务管理的5大难点及对策

1、运维服务管理的5大难点及对策（总6页）本页仅作为文档封面，使用时可以删除This document is for reference only-rar21year.March运维服务管理的5大难点及对策以下基于我们公司的情况讨论运维服务管理，可能不是非常具有代表性，只是希望找出运 维服务管理中经常碰到的难点，以及对应的解决方法。前段时间，一位朋友说了一个观 点，运维服务是自动化程度最低的一个行业，很有意思，那运维服务会不会也是管理最薄 弱的一个行业呢？我接触运维服务的时间不长，但个人总觉得我们把运维服务搞得复杂化了，没有看透 业务本质。在运维服务行业，真正意义上的管理者非常缺乏，我说的管理者”

2、，是用对象 的方式看待业务与流程的。有时我们过于强调行业经验的重要性，事实上在管理领域，行 业的特性对管理者提出的特殊要求没有我们想象的多。运维服务尚未真正形成行业，多数的领导者不以管理见长，多是从底层或技术部门提 升而来，视野与管理理念缺乏，妨碍了运维服务管理的成熟与发展。以下我将对运维服务 管理的一些难点展开说明。项目型管理方式的挑战当一个组织以项目的形式运作管理时，在管理上积淀是比较困难的。项目本身就是一 个独立的权力结构，公司的组织机构是按部门、科室式划分，管理体系也多以部门职能划 分流程，这时权力的矛盾就会在业务运作时产生，发生资源的略夺行为。要么部门难以管 理，要么项目难以管理。而

3、项目是一个临时的组织，这种人力的汇聚与释放都比较麻烦，起用一名人力需要相 当长的磨合期。而公司的任务往往是周期性的（最小时间单位很大），这时人力释放并不 意味可以马上投入利用，这种痛苦没有经历过很难体会到，这比你在ERP中排生产计划还 要难。运维服务一般是以项目的形式管理的，项目内的作业与部门或公司的管理往往存在偏 差。如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动敷衍配合公司 的管理。比如培训，站在部门或公司的角度希望搞员工能力提升的培训，这种计划安排， 往往与项目内希望做的培训有非常大的出入。项目的一线主管，往往认为公司或部门不是帮助他们，而是一个麻烦制造者。一旦项 目数量

4、大时，这种情况越普遍。因为项目越多，上层对规范、标准化的愿望就越发强烈， 当一线主管花费越来越多的管理资源，配合公司的规范与标准时，对项目的控制力就会下 降。一旦发生问题，上层领导就会认为是缺乏规范与标准化所致，形成一个恶性循环。我经常看到一种现象，当某个项目发生个严重运维事件时，马上会短时间把管理资源 堆积起来，对事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项 目进行落实。这种做法会起良性作用吗？我怀疑，因为反应过度了，也有些缺乏理性。资源永远是有限的，你把多数的资源花 在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制，你采用 的措施会妨碍你达到目的

5、。对运维服务而言，你让客户用一个最重要的词说出他的要求，他们往往会说“稳定”。 同样，运维服务管理也是最需要稳定的，救火堵漏的做法不可取。先稳定你的管理，再去 谈改善。永远处于制度的发布与调整中，会让运维服务管理成为最大的运维风险。我觉得此时领导者的作用非常重要。作为高层领导，由于缺乏细节信息，对自已的运 维服务管理缺乏信心，一旦发生问题，就会过度反应，这种现象是非常可怕的。作为运维 服务的管理部门，一定要想清楚自已应该做什么，你的管理边界在什么地方。你是一个政 策制订者，不应该越过项目的边界去干涉项目的内部事务。管理部门负责服务体系的维护与执行监督，及所有服务资源的调配，这才是最重要 的。更

6、细节层面，管理部门应该只扮演辅助角色。运维资源的充分利用问题有时我会想一个问题：做运维的人员，是应该忙还是闲呢这是个很矛盾的问题。如果 忙，那证明你的运维问题比较多；闲吧，证明你运维问题比较少，但你的资源可能没有充 分利用。那有没有一种可能，把每一个运维人员的工作安排得都不是那么忙，也不是那么 闲呢运维最大的成本是人力成本，想办法提高工时利用率，本无可厚非。但分析下来，做 到这一点有时不现实，或者是很困难的。在多数运维服务中，你的运维对象不是标准化的，尤其是在软件领域。这决定了你的 人员复用是困难的，因为一个人员的脑子只能装进几个系统，而每个系统的升级与处理故 障的知识是每隔一段时间就更新的。

7、举这样一个例子：A系统每天的问题处理需要3小时，B系统需要3小时，现在由两 个不同的人员负责，那是不是可以由一个人负责运维这两个系统呢？现实肯定是行不通 的。即便一个人可以掌握两个系统运维的知识，两个系统发生故障的时间完全有可能重 叠，还有其它临时事务排挤在一起，造成服务问题。这种情况下，人力的闲置不可避免。虽然即便一名服务人员的资源没有充分利用，客户也会购买你整个的人力。但当这样 的闲置情况很多时，作为一个商业公司，就要想办法去提高资源利用率。这方面好像除了 提高人员的运维能力外，没有更好的办法对应解决。服务台管理问题服务台设立也是一个比较复杂的课题。怎样的服务台才最有效、最节省资源？如果仅

8、 仅为了满足参观者的感官，让一帮戴着耳机的热线MM坐成一片，忙碌着，用甜美的声音 问着好，确也显得气派。但现实情况中，这样的服务台很可能没起到作用，是在浪费运维 资源。项目多时，服务台的人员恐怕听不懂客户在说些什么，尤其当你的运维服务不是标准 化的产品服务时（比如桌面）。比如，一个客户打电话过来，说我的售车申报做不了”， 服务台人员如果没有深入的项目知识，估计连是哪个系统都搞不清楚，甚至连问题描述与 等级都不知道如何定（注意服务台人员要在ITSM系统中派单）。这时，服务台可能直接 转电话或者草草记录下来，其作用跟一个4万元的语音菜单没有区别。更有意思的是，语音菜单会在客户电话时提示：A系统请按

9、1，这时电话是接入到服 务台，还是接入到这个系统的一线工程师呢？如果服务台可以处理这个电话，事实上服务 台就是一线。多数情况下，服务台人员无法处理这类电话，除非你把所有一线工程师纳入 服务台。在运维服务中，当你的服务台无法做一线支持时，不设立专门的热线MM会合适些， 或者把你一线支持人员全部纳入服务台中，把服务台做成一个虚拟或混合型的。我们的情 况跟上述有些类似，服务台人员不了解具体的项目知识，需要把电话转到一线人员处；或 者告诉一线人员，由一线人员跟客户联系，最后客户都不打电话到服务台了。我个人倾向于把一线人员纳入服务台，取消单纯接电话性质的服务台人员，这会节约 运维资源，但这也会产生一些问

10、题，比如谁来监督事件的服务质量。运维服务分析问题运维服务中，我们一直强调改善，改善就意味着一要清楚你的现状，二要清楚你的目 标。这两点是要基于大量数据分析的，我们说的改善不是针对项目这么微观的层面，而是 基于整体的层面，这意味着你的数据有一个度量标准。这个标准适于不同类型的项目，不 然你根本无从知道你的整体状况。这里ITIL中的SLM有一个指引作用，但这还不够，我认为要做到深入的运维分析，需 要以下几个要素：需要有一个精确的CMDB： CMDB提供信息让你方便把每一次事件定位，以便知道 什么地方什么组件出了多少问题，在项目层面可以提供精确的数据做改进（哪一个模块是 问题最多的）；在管理层面，C

11、MDB的附带信息会告诉你，哪一类设备是我们运维的薄弱 环节（如果硬盘的故障比重较大，我们可能换供应商，或者提升运维人员的硬盘维修能 力）。需要有一个横向业务分类基准：要基于组织层面，规划出一个分类数据，以供每一 个项目统一调用。比如事件的类型，我们可以分为：故障、请求、咨询、新需求、投诉， 这样可以跨项目统计，每个周期内每一个事件类型有多少。比如事件的分类：我们可以分 为软件、硬件、网络、数据库、接口、业务。需要时间资源的记录：这一部份的数据采集最为困难，也最有价值。它与上面的信 息交互分析，可以知道哪一类设备花去我们最多的时间资源（CMDB），可以知道我们硬件 故障的平均处理时长是多少（事件

12、分类），还可以知道新需求会花去我们多少时间资源（事件类型）。除此之外，基于员工的绩效分析以及运维结算的数据统计都需要基于此部 份信息。运维服务分析，个人的意见是：没有ITSM软件，是难以展开的。软件化管理问题运维服务作业采用ITSM软件管理，这本没有什么值得争议，说来我也在设计与推行 这种工具，但应用时的确两难。有人问我，用ITSM系统对一线工程师到底有什么好处？ 换位思考，如果我是一名一线工程师，我是不愿意使用这种工具的，我快速把事件搞定， 不去填任何信息，来得多快。说什么知识库与CMDB，我没有这些时，故障一样可以处 理。我不是否认我设计的东西，只是它真正的价值在于平台与运维服务管理，而不

13、在于具 体的业务支持。ITSM系统的上线，会降低运维服务成本吗会提高运维服务的效率吗我的回 答是不会，起码短期不会。同样是修一台电脑，怎么可能会因为上一个ITSM工具，以前 需要30分钟，现在就只要20分钟呢人们一直没有理解管理软件的真正价值。管理软件首先要满足管理的需求，而不是具体业务操作的需求。你想提高桌面的运维效率么？SMS 是解决这一方面问题的。上ITSM工具，是为了固化你的体制与流程，让你的服务体制更 规范、标准化，形成一面镜子，把你真实的运维现状反映出来，让你的运维服务管理起 来。如果说某段时间增加了你的成本，那么这个成本是你必须付的，这是你以前欠下的 债。用一个不恰当的例子，学内

14、功不能让你很快打倒一个人，学一个招式可以。但学十年 的内功跟学十年的招式相比，前者更具成效，而且当你学了招式一两年后，你会发现你无 法进步，因为缺乏根基。要想清楚你上ITSM工具是为什么，你要解决什么问题，如果你不是为了解决管理上 的问题，而是为了提高工程师效率，那么不是你的目的错了就是选择错了。只有当你的运 维服务管理稳定成熟后，才能为你后续一切提升提供源源不断的动力、方向、决策支持数 据，而软件就是帮助你前行的有力工具。ITSM工具，由于SLA的计算，对事件处理信息录入有较苛刻的要求，这对需要在厂区 跑来跑去的工程师来讲是比较麻烦的。比如象桌面项目的服务工程师，他们不可能随身带 着电脑，外面服务时，都是电话派单过去。事件单关闭不及时，会引起SLA的计算失真问 题。这都是些负面影响，在软件功能上很难有什