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

　　四．运维服务分析问题

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

　　这里ITIL中的SLM有一个指引作用，但这还不够，我认为要做到深入的运维分析，需要以下几个要素：

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

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

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

　　运维服务分析，个人的意见是：没有ITSM软件，是难以展开的。

　　五．软件化管理问题

　　运维服务作业采用ITSM软件管理，这本没有什么值得争议，说来我也在设计与推行这种工具，但应用时的确两难。有人问我，用ITSM系统对一线工程师到底有什么好处？换位思考，如果我是一名一线工程师，我是不愿意使用这种工具的，我快速把事件搞定，不去填任何信息，来得多快。说什么知识库与CMDB，我没有这些时，故障一样可以处理。

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

　　人们一直没有理解管理软件的真正价值。管理软件首先要满足管理的需求，而不是具体业务操作的需求。你想提高桌面的运维效率么？SMS是解决这一方面问题的。上ITSM工具，是为了固化你的体制与流程，让你的服务体制更规范、标准化，形成一面镜子，把你真实的运维现状反映出来，让你的运维服务管理起来。

　　如果说某段时间增加了你的成本，那么这个成本是你必须付的，这是你以前欠下的债。用一个不恰当的例子，学内功不能让你很快打倒一个人，学一个招式可以。但学十年的内功跟学十年的招式相比，前者更具成效，而且当你学了招式一两年后，你会发现你无法进步，因为缺乏根基。

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

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

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

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