解决IT黑洞问题的关键在于说清IT的投入产出，其中主要是说清运维服务的内容、种类和标准以及相对应的成本，这样才能让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 费用都纳入标准的项目管理流程。
有了这个最小颗粒度的数据以后，成本分摊问题就好办了。举例来说，如果我们在“物”的资源方面能搞清楚任何一个员工在出某张保单的过程中应该分摊多少主机、多少数据库、多少网络、多少终端等项的费用，那么要分析某个机构的费用，就把机构内所有员工的费用加起来；分析某个应用系统的费用，就可以把相关应用系统项下所有员工的费用加起来……这样一来，我们所需要的任何“物”的资源的分摊结果自然就都不是问题了。
实际工作中，当然不可能各个机构以及各个应用系统都有自己独立的资源，有很多资源都是共用的。也就是说， 对任何 “物” 的资源来说，对于给定的机构 （人员）和应用系统来说都可以分为“共用”和“专属”两类。所谓“分摊”的过程，其实就是层层把“共用”资源分解为“专属”资源的过程。等到分解工作做完了，分摊过程也就完成了。举个极端点的例子来说，对于最基层的一台终端，也可能有“共用”或“专属”两种属性。而这种层层把“共用”分解为“专属”的过程，具体到每一个对象的每一层，是完全可以通过业务量或使用时间等进行合理分摊的。
当然，这里还有一个问题。由于完成一笔业务需要从前台到后台若干环节的资源，而其中每个环节如后台数据库主机等一般来说有不同厂商不同型号的产品，相同环节的不同类型的资源就需要折算。 要解决这个问题，需要用到现在流行的虚拟化技术，如果能把每个环节中的资源都进行虚拟化，就可以依据使用量或业务量对每个环节内部的资源进行“横向”的折算。最终可以在机构和应用维度上计算出不同环节虚拟资源单元的使用量，从而进行合理分摊。
但即便如此，还没有完全解决问题。因为就算实现了 “横向” 环节的合理折算， 但在相同的服务水平下， “纵向”维度上也可能有不同的组合。举例来说，给后台主机加几个 CPU 和给网络加几 M 带宽对用户来说完全有可能是一样的感觉提升，但成本却差别很大。“纵向”的不同环节之间是无法虚拟化的， 如果要做到合理折算，就必须要对服务水平进行精确的测量，并假定前台用户感受相同的情况下后台的资源组合是等效的。 也就是说，我们必须搞清楚“产出”到底是什么，才能在相同服务水平下选择最合理的“纵向”组合。
同样的，我们可以类比“物”的资源的分摊来解决“人”的资源分摊问题。从前面的讨论来看，解决“物”的分摊问题的思路是先做虚拟化，找到虚拟“单元”，这是从成本上进行分析。难以虚拟化的部分，则采用等效的方法，即对用户来说感受相同的资源组合，我们也认为是等效的，这是从效果上进行分析。类似的，解决“人”的资源分摊问题也可以采用同样的方法。对人力资源来说，所谓虚拟单元就是“工时”，如果我们把运维工作规范化、标准化、工单化，其实这个虚拟单元也就找到了。而众所周知的是，ITIL 本来就是用来做运维规范化标准化的，这也就同时也回答了我们前面提出的“ITIL”之后怎么办的问题。那么，会不会有人借机像过去的人民公社一样， “刷单” “骗工分” 来提高绩效呢？要解决这个问题，就不能光管过程，而是同样要从结果上进行分析。如果有了定量的“产出”标准来进行约束。对运维产出有意义的才能计算工作量，“刷单”的情况也就可以得到有效抑制了。
四、产出的定量评价标准
上面谈到投入问题时，提出投入分摊的一种方法是要计量产出。其实，如果没能计量产出，即便我们用其他方法搞清楚了当前情况下的分摊比例，问题也还远没有结束。这是因为能够做“分摊”，其实就有一个假定的前提， 也就是用户对于目前的服务水平认为是合适的，可以接受的。但如果我们没能对当前的产出进行计量，也就是当前的服务水平究竟是什么都没说清，分摊本身是无法持续的。这是因为，假定我们认为存在的就是合理的，就按现有服务水平进行分摊，但用户嫌服务水平低了怎么办？嫌分摊费用高了怎么办？如果调整，该如何调整？换句话说，“分摊”不是最终目的，“计费”才是最终目的；“分摊”只意味着一种相对合理的摊派，“计费”才是一分价钱一分货的市场化行为。
很多领导常说对 IT 要求不高，不出事就行，孰不知对 IT 来说，“不出事”已经几乎是对运维管理的最高要求了。如果总是觉得“不出事”是应该的，日久天长，IT 服务就越来越像空气，有了也不知道，没了它又不行。花了那么多钱买来一堆“空气”，难怪企业管理层要恼火。其实，不同应用，不同用户对于“不出事”或者说是“出事”的感觉和要求千差万别，也导致了 IT 成本投入的迥乎不同。不对此进行定义和计量，笼统地说不出事，不宕机，显然不是公平合理的做法。
实际上， ITIL对运维管理的产出还是进行了定义的，这就是 ITIL 的服务交付部分，包括财务管理、持续性管理、可用性管理和能力管理。通俗点来说，在不考虑业务系统功能需求的前提下（那是开发服务的部分，不属于本文讨论的范畴），用户对给定业务系统性能的需求可以概括为“断不断”、“慢不慢”和“够不够”。如果业务和 IT 已经约定好了对业务发展规划的描述，那么 “够不够” 的问题其实又可以归结为 “断不断” 、 “慢不慢”的问题。
但是，简单把指标归为“断不断”和“慢不慢”还是不够的， 还应当满足以下几个条件：首先， 指标的设定、采样和计算应当是客观而非主观的，如果随便哪个用户说“慢”就是“慢”，哪个 IT 也吃不消。但实际上这就是很多企业的现状：用户随心所欲，IT 疲于奔命。其次，指标应当满足“业务能理解、IT 可计算”的要求，如果业务难以理解指标的含义，或者 IT 不能计算产出和投入的对应关系，这些指标就难以发挥其应有的作用了。最后，指标还应当可以归一化。好比高考，尽管考试科目有很多门，但录取就是靠分数线，一分就是一分，科目的区别在于所占权重不同，但结果都是分数。尽管可以对某些科目设定最低要求，但最终评判的标准应当是归一化的。
我们搞 ITIL，搞运维管理规范化，规范的目标是什么？或者说 ITIL 之后怎么办？应该有一套定量的评价标准。 我们搞IT的投入产出分析， “产出” 到底是什么？也应该有一套定量的评价标准。其实，根据刚才的分析，要计算“投入”，也需要有“产出”定量评价标准，这几个方面的要求，在“产出”的定量评价上走到了一起。只有对“产出”有了定量的评价标准，才能知道为什么要规范，规范到什么程度为止，以及不同领域间规范程度的关系；也只有有了定量的评价标准，才能对“产出”进行客观的分析，对“投入”进行合理的分摊。
实际工作中，能够比较好满足要求的指标其实就是对业务系统运行状况监控的定量描述。如果监控了业务系统的关键环节，并对关键环节的响应时长进行监控和采样，这些采样结果就是计算“产出”指标的基础。这个指标应该说是相对比较合理的。有了这个基础指标，不仅可以定义“慢”，还可以根据采样点的分布，慢的程度等等定义各种不同的“慢”，甚至也可以据此定义什么叫“断”。
运维 “产出” 的问题可以归结为 “断不断” 、 “慢不慢”和“够不够”的问题，“够不够”的问题其实又可以归结为“断不断”、“慢不慢”的问题。而有了对业务系统关键环节的监控之后，“断”也可以归结为一种特殊意义上的“慢”，而“慢”本身则可以通过对采样点的统计进行各种各样不同的定义和计算。也就是说，这些采样点就是 IT 与业务之间的桥梁，成为“业务能理解，IT 可计算”的技术基础。
总结上面的讨论，IT 黑洞问题的产生主要是因为IT 难以说清自身的投入产出关系， 而根据 IT 冰山模型，又主要是 IT 运维管理难以说清自身的投入产出关系。ITIL作为运维管理的最佳实践， 可以把运维管理规范化，并成为运维管理这项“业务”的业务系统需求。但 ITIL只能说清运维管理规范化的方向，并未建立投入产出的数学模型。建立投入产出模型的关键在于定量描述“产出”。有了定量描述的产出，再辅之以规范化标准化的运维工作，就可以实现合理的横向折算和纵向折算，并合理分摊投入。而对业务系统关键环节的监控可以作为模型的指标基础。运维管理有了定量的“产出”指标，也有了规范化操作的基础，投入产出模型的建立就是一个时间问题了。然而，如何在实施 ITIL 的过程中逐步规范，逐步优化；如何确定“人”的资源的虚拟单元，制定合理的考核指标和考核体系以最大限度调动员工的积极性；如何使资源的投入组合和“产出”指标进行合理关联，并使以上这些都朝着客户需要和能够承受的方向不断优化，这些都是要在实践中逐步摸索解决的问题。
本文选自《中国金融电脑》, 2015年4期，版权归原作者或出版物所有
暂无评论内容