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

作者： 破子  2007-10-10

内容导航：

项目型管理方式的挑战

第1页： 项目型管理方式的挑战 第2页： 运维资源的利用与服务台管理 第3页： 运维服务分析与软件化管理

文本Tag: 运维 行业观察 方案案例 软件应用 ITIL 运维服务管理 项目型管理 服务台管理 ITSM软件 破子

　　编者按：亲爱的读者，也欢迎您来稿来电，联系本文编辑（MSN：bunnybunny505#hotmail.com  TEL：021-33680077*265），跟大家分享您的经验。

　　【IT168 专稿】以下基于我们公司的情况讨论运维服务管理，可能不是非常具有代表性，只是希望找出运维服务管理中经常碰到的难点，以及对应的解决方法。前段时间，一位朋友说了一个观点，运维服务是自动化程度最低的一个行业，很有意思，那运维服务会不会也是管理最薄弱的一个行业呢？

　　我接触运维服务的时间不长，但个人总觉得我们把运维服务搞得复杂化了，没有看透业务本质。在运维服务行业，真正意义上的管理者非常缺乏，我说的“管理者”，是用对象的方式看待业务与流程的。有时我们过于强调行业经验的重要性，事实上在管理领域，行业的特性对管理者提出的特殊要求没有我们想象的多。

　　运维服务尚未真正形成行业，多数的领导者不以管理见长，多是从底层或技术部门提升而来，视野与管理理念缺乏，妨碍了运维服务管理的成熟与发展。以下我将对运维服务管理的一些难点展开说明。

　　一．项目型管理方式的挑战

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

　　而项目是一个临时的组织，这种人力的汇聚与释放都比较麻烦，起用一名人力需要相当长的磨合期。而公司的任务往往是周期性的（最小时间单位很大），这时人力释放并不意味可以马上投入利用，这种痛苦没有经历过很难体会到，这比你在ERP中排生产计划还要难。

　　运维服务一般是以项目的形式管理的，项目内的作业与部门或公司的管理往往存在偏差。如果部门或公司处于强势地位，项目内的作业往往会被冲击，或者被动敷衍配合公司的管理。比如培训，站在部门或公司的角度希望搞员工能力提升的培训，这种计划安排，往往与项目内希望做的培训有非常大的出入。

　　项目的一线主管，往往认为公司或部门不是帮助他们，而是一个麻烦制造者。一旦项目数量大时，这种情况越普遍。因为项目越多，上层对规范、标准化的愿望就越发强烈，当一线主管花费越来越多的管理资源，配合公司的规范与标准时，对项目的控制力就会下降。一旦发生问题，上层领导就会认为是缺乏规范与标准化所致，形成一个恶性循环。

　　我经常看到一种现象，当某个项目发生个严重运维事件时，马上会短时间把管理资源堆积起来，对事件进行深入到可怕的分析，然后制订出一个非常完备的制度，要求每个项目进行落实。这种做法会起良性作用吗？

　　我怀疑，因为反应过度了，也有些缺乏理性。资源永远是有限的，你把多数的资源花在防止概率很低的问题上，而让那些概率较高的问题没有相应的管理资源去控制，你采用的措施会妨碍你达到目的。

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

　　我觉得此时领导者的作用非常重要。作为高层领导，由于缺乏细节信息，对自已的运维服务管理缺乏信心，一旦发生问题，就会过度反应，这种现象是非常可怕的。作为运维服务的管理部门，一定要想清楚自已应该做什么，你的管理边界在什么地方。你是一个政策制订者，不应该越过项目的边界去干涉项目的内部事务。

　　管理部门负责服务体系的维护与执行监督，及所有服务资源的调配，这才是最重要的。更细节层面，管理部门应该只扮演辅助角色。

1

1 2 3

【内容导航】

第1页： 项目型管理方式的挑战	第2页： 运维资源的利用与服务台管理
第3页： 运维服务分析与软件化管理

©版权所有。未经许可，不得转载。

[责任编辑： 邓胜]