后ITIL时代的保险IT运维管理创新

一、 IT黑洞与IT冰山

　　IT黑洞在今天早已经不是什么新鲜的话题了，但它的由来却很少有人去探个究竟。一般来说，企业的其他主要成本都可以和企业提供的产品或服务定量挂钩，唯独日益增长的IT成本始终难以说清。这对企业的管理层来说，是个非常让人恼火的问题，知道IT不可或缺，但成本难以说清，产出也难以说清，每笔投资对应的回报到底是什么谁也不知道，IT黑洞就是这么产生的。

　　IT实质上是一种服务，企业自身是需求方，而企业IT部门则是提供方。这个服务也在“市场”上交易，但企业没有别的地方去买，企业IT也没有别的地方去卖，这个市场其实是企业内部的“垄断市场”。虽然这种服务和交易实质上存在，但交易双方对于服务内容、服务种类、服务标准和服务价格却很少有一致的认知;或者更现实点说，大多数企业还没有意识到应该去理清这些内容并达成一致。

　　IT服务主要包括开发服务和运维服务，或者说功能服务和性能服务。如果把IT比作一座冰山，那么开发服务或者说功能服务就是冰山浮在水面上那部分，效果一目了然，但其实所占成本比例有限。相对而言，运维服务或者说性能服务就是水下那部分冰山，隐藏很深，结果并不直观，但却占用了大量成本。一般来说，广义上的运维服务投入通常占据IT投入的九成左右。

　　开发服务的效果要通过运维服务才能很好体现，这个道理对大多数人来说并非常识。12306网站就是IT冰山中开发和运维服务关系的一个很好的例子。它刚上线时频频崩溃，很多人说这么个网站几个工程师几天就能做好，原铁道部居然几个亿都搞不定，但他们不知道做网页本身确实没什么太大难度，然而系统架构和后台资源满足如此巨大的并发访问量可不是件容易的事。

        由此可见，解决IT黑洞问题的关键在于说清IT的投入产出，其中主要是说清运维服务的内容、种类和标准以及相对应的成本，这样才能让IT这座冰山完整地呈现在眼前，这也是本文主要讨论的内容。

二、 ITIL之后怎么办?

　　谈到IT的运维服务或者说运维管理，就不能不提ITIL。ITIL作为运维管理最佳实践，在运维管理领域中的重要性可以说是无可替代。ITIL究竟是什么?它当然是运维管理的最佳实践，可以供大家借鉴和参考。但如果从另外一个角度来看，ITIL本身也可以视为是对运维管理的信息化描述——换句话说，如果把运维管理视作一种“业务”，ITIL就可以看作是这项“业务”的“业务系统需求”，实施ITIL的过程其实也可以看作是为“运维管理”这项“业务”开发业务系统的过程。

　　说到开发业务系统，对IT管理人员来说最具有讽刺意味的就是：IT给各业务部门开发了各种各样的业务和管理系统，但其实IT自身的信息化水平在企业所有业务中往往是最差的。不仅如此，业务系统一般都会要求自行开发或进行本地化改造，但运维管理这项“业务”通常是直接使用国外“先进”的系统，而罔顾本地人员的素质和现实条件，而且大家都认为天经地义。

　　更重要的是，就算ITIL实施到位解决了运维管理“业务系统”的需求问题，但由于这项“业务”本身在信息化之前就没有投入产出的核算。因而即便有了“业务系统”，也不意味着立即就能解决投入产出的问题。换句话说，ITIL的实施本身并不能解决运维管理的投入产出问题。因此，在对实施ITIL结果的描述中，我们往往可以看到这样的字句：提升某某能力，减少某某时间，加快某某响应，优化某某流程……

        按照通常意义上的理解，这些叙述是指在其他条件不变的情况下，实施ITIL前后运维效果的改变和提升。但是，既然企业实施了ITIL，对运维管理自身进行了规范和优化，那么相关的其他条件为  什么就不能变化呢?难道现有的投入数量和种类就一定是合理的吗?我们提升了这些，加快了那些，都是企业需要的吗?企业是否需要这么多，这么快?或者企业是否需要更多，更快?如果我们能给出的并不是企业需要的，我们能不能调整，该如何调整?或者更直接点说，ITIL之后怎么办?这个问题不能等到ITIL完全实施完毕以后才回答，而是要在实施过程中，乃至实施之前就回答。只有这样，才能确保我们努力的方向能够适合企业，也就是我们“客户”的需要。

三、投入的分摊问题

　　ITIL作为运维管理的最佳实践，可以作为运维管理这项“业务”的系统需求。但光靠实施ITIL是难以解决投入产出问题的。并且，持续不断地优化是需要成本的，优化到一定程度以后，就面临着朝哪个方向继续优化的问题，或者说是继续优化所需资源的分配问题，其实也就是投入产出问题。为了研究这个问题，我们可以先从分析“投入”开始。

　　作为运维管理来说，投入还是比较明确的：“物”的资源，包括机房、机器、网络、桌面设备等;以及“人”的资源，包括购买的服务、内部人员和外包人员等。这些都可以有明确的数量，但光计算一个总数还不够，把这些投入合理分摊到各受益方才有实际的意义。

　　从逻辑上来说，这些分摊应该至少包括两个维度，一个是机构维度，也就是这些投入究竟是为谁服务的，从总部一路分下去，一直分到最底层的机构乃至具体的某个业务人员。另外一个是应用维度，信息化方面的投入自然都要体现在某个应用系统上，这些投入究竟是为哪个应用服务的，也是我们在研究IT投入产出过程中需要搞清楚的问题。两个维度的结合，就是成本分摊的最小颗粒度。当然，在实际工作中，还可以有其他维度，例如“项目”维度，这个维度的前提是管理足够规范，可以把任何一份IT费用都纳入标准的项目管理流程。

　　有了这个最小颗粒度的数据以后，成本分摊问题就好办了。举例来说，如果我们在“物”的资源方面能搞清楚任何一个员工在出某张保单的过程中应该分摊多少主机、多少数据库、多少网络、多少终端等项的费用，那么要分析某个机构的费用，就把机构内所有员工的费用加起来;分析某个应用系统的费用，就可以把相关应用系统项下所有员工的费用加起来……这样一来，我们所需要的任何“物”的资源的分摊结果自然就都不是问题了。

　　实际工作中，当然不可能各个机构以及各个应用系统都有自己独立的资源，有很多资源都是共用的。也就是说，对任何“物”的资源来说，对于给定的机构(人员)和应用系统来说都可以分为“共用”和“专属”两类。所谓“分摊”的过程，其实就是层层把“共用”资源分解为“专属”资源的过程。等到分解工作做完了，分摊过程也就完成了。举个极端点的例子来说，对于最基层的一台终端，也可能有“共用”或“专属”两种属性。而这种层层把“共用”分解为“专属”的过程，具体到每一个对象的每一层，是完全可以通过业务量或使用时间等进行合理分摊的。

　　当然，这里还有一个问题。由于完成一笔业务需要从前台到后台若干环节的资源，而其中每个环节如后台数据库主机等一般来说有不同厂商不同型号的产品，相同环节的不同类型的资源就需要折算。要解决这个问题，需要用到现在流行的虚拟化技术，如果能把每个环节中的资源都进行虚拟化，就可以依据使用量或业务量对每个环节内部的资源进行“横向”的折算。最终可以在机构和应用维度上计算出不同环节虚拟资源单元的使用量，从而进行合理分摊。

 1 2 下一页 尾页

扫码即可手机
阅读转发此文