尝试引入ITIL 探索中打造全新理念IDC [ZT FROM CIW]
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
早在20世纪90年代，国外IDC（数据中心）已经引入ITIL进行“软升级”。目前，国内一批意识和思路领先的规模较大的IDC已经尝试引入ITIL，在不断的探索中打造全新理念的IDC。
2006年上半年新一轮互联网投资热潮，拉动IDC业务快速回升。据预测，2006年中国IDC业务有望突破20亿元，并以30%的增长率高速发展。尤其是，随着短信、语音、视频、3G、电子商务以及外包业务的发展，IDC增值服务将迅速发展。未来IDC市场的竞争焦点就在于如何为企业提供优质的个性化增值服务。
增值业务的快速发展，必将挑战IDC传统以托管服务为核心的运作管理模式。目前 IDC业务收入仍以基础托管服务为主，其比重高达88.4%。在以托管服务为核心的业务模式下，用户普遍关心的问题仍然是网络带宽和网络稳定性。只要网络基础设施足够稳定、提供足够带宽、能够快速访问，那么用户就会比较满意。
但是，增值服务不仅要求IDC具备良好的网络基础设施，还要求IDC具有较高的运维管理水平，比如以客户为中心的服务流程、自动化的运维平台、高超服务技能的运维人员等。面临新一轮竞争环境，IDC必须未雨绸缪，全面启动升级战。未来谁能够赢得客户的满意，那么谁将赢得市场。
早在20世纪90年代，国外IDC已经引入ITIL进行“软升级”。目前，国内一批意识和思路领先的规模较大的IDC已经尝试引入ITIL，在不断的探索中打造全新理念的IDC。但是如何打赢这场“升级战”？如何与竞争对手区隔开来呢？让我们先看看目前IDC运维工作所面临的困惑。
http://cio.ciw.com.cn/UploadFiles_6003/200706/20070601103104273.jpg
传统模式的困惑
相比国外具有成熟运作模式的IDC，目前国内IDC的运行管理主要存在四个困惑（见下表）。
第一、运维人员技能不足。大多数IDC是在几十个运维人员的规模，很多人的处理能力不够，往往一个人就能做的事情却需要几个人才能完成，人员数量总是减不下来，误操作也比较多。
举例来说，某IDC在UPS（不间断电源）方面需要更换电源的一个模块，由于操作人员没有充分准备好变更计划，只简单向部门领导报告一下就去做了，当天导致UPS不能正常工作，IDC的一些重要客户发生宕机故障，又因为处理紧急情况的能力和技能不足，宕机一个小时之后才解决故障，影响客户正常业务运作，最后按照合同赔给客户一大笔钱。
国外IDC运维人员的技能都比较高，保守来算，国外一个运维人员所做的工作在国内可能至少需要两个人才能完成。
第二、以业务为核心的运维流程已不能满足需要。从IDC市场发展趋势来看，未来竞争的焦点是在同质化情况下怎么做得精细化，怎样时刻考虑客户感受，从客户角度制定管理流程和策略。
长期以来，国内IDC的运维流程以业务为核心，主要去支持业务，没有特别在意客户感受。很多IDC的运维流程完全跟着业务走，什么样的业务流程就有什么样的运维流程，很多类似事情也是不同流程。
比如，代维服务有一个运维流程；数据存储也有自己的运维流程。每项业务的运维流程都是按照业务的开通、合同修改等步骤而设，业务开通需要填一个单子，业务修改又是一个不同的单子，业务撤销也是一个不同的单子。
在这种情况下，当面对同一个客户的不同业务需求时，由于不同业务分散在不同的运维流程里，IDC无法快速有效地给予客户反馈和支持，客户会感到等待时间特别长、服务效率比较低。
另外，由于运维服务没有量化，比如明确规定多长时间响应客户？多长时间处理完某个业务？中间哪个环节需要和客户沟通，并通知客户进展情况；因此很多时候客户会感受到不被尊重或者没有得到关心，从而感觉到不满意。
因流程而引发的另一个问题是许多IDC的故障分级特别简单、含糊，某些IDC甚至都没有故障记录，只是通过客户的电子邮件进行处理，处理完之后给客户回封电子邮件就行了，这也不便于进行分析统计，对故障进行分类，发现故障原因何在。
尽管IDC提供一个比较稳定的环境，但由于没有做好这些细节，很多客户会感觉不满意，因此，国内IDC需要从客户角度来梳理运维流程，提升客户满意度。ITIL提供一套规范的流程，可以改变传统以业务为核心的运维流程。举个例子，业务的开通和修改，差别不是特别大，现在它们都提供不同的记录单子，ITIL会把二者的运维流程进行整合和简化，提高效率。
第三、自动化能力较弱。自动化体现在很多方面，不仅是流程自动化，还包括对资源信息的监控和管理。目前国内IDC自动化能力比较弱，在资源的分配、供给和调度方面，尚处在自动化初级阶段，大多采用一些网管监控、资源库等工具，这也导致运维的效率低，人员数量无法减下来。
一些监控信息的查询或者展现方面不是太理想，比如从管理层的视角展现出他们想关注的监控信息。另外，由于资源信息不准确，比如IP地址、网端、机架、机房等IDC提供业务所需要的重要资源，缺少自动化查询和统计手段，目前大多数IDC只是用Excel记录或者放在数据库里，这样运行半年之后，就开始断网或发生故障，其原因就是没有去采集和维护某些信息。
国外数据中心的自动化做得相当好。比如，当用户需要在服务器安装新软件时，国内IDC操作人员需要拿着安装盘去现场安装；而国外IDC会提供一些自动化工具或自助服务功能，请用户按照说明自动完成。
再举一例，用户把服务器托管在IDC租用带宽，可能会很关心流量问题，经常想了解一下每个月使用了多少流量，流量分布情况怎么样。对于这种简单的请求，国内IDC一般会在系统里出一个报表，再传真给客户，这些都是人力浪费；国外IDC一般请用户直接在网站上访问他们实时出具的报表，或者查询他们想要的信息。
http://cio.ciw.com.cn/UploadFiles_6003/200706/20070601103105599.jpg
IDC的ITIL特色
不同行业、不同企业都需要结合自身特点来实施ITIL，IDC也不例外。相比其他行业来说，IDC的ITIL实施具有四个与众不同的特点（见下表）。
首先需要结合eTOM模型来实施。eTOM是电信业务参考模型。大多数IDC的业务运作模式参考eTOM而建，运维管理体系、运维人员也都来自电信企业，因此，IDC实施ITIL不能脱离IDC实际情况，要结合eTOM来做。
其次，尽管ITIL的核心是十大流程管理，但是，在流程梳理时需要紧密结合IDC已经形成的日常运维流程来实施。IDC在托管服务方面已经具备非常成熟的运作模式，也形成了很多运维管理流程和规范。比如，运维人员出入室流程（类似机房的出入管理，但要复杂一些），设备的搬进搬出流程，业务的开通、修改和撤销等，这些都是目前IDC日常运维中核心的、经常需要执行的流程。
在引入ITIL时，IDC不能完全照搬ITIL十大流程，必须对日常运维流程进行梳理之后，灵活地和ITIL结合起来。比如，在引入ITIL之后，人员出入室流程可能需要单独列为一个服务流程，因为这是IDC经常要处理的事情，以便于用户去IDC维护他们自己的服务器，或者来IDC参观等。
再举例来说，在ITIL流程设计中，一个变更管理流程需要体现出开通业务、修改业务等不同情况的处理方式。而业务开通、修改和撤销是IDC日常工作的主要内容，已经形成一套操作习惯和认识，如果简简单单地用ITIL的变更管理流程来代替这些操作，就会很难推进下去。相反，要让员工感觉到虽然增加了一个变更管理流程，但是以前的操作习惯没有太大变化，而不是不知道从哪下手。
实际上，IDC实施ITIL流程最关键的是对已有独立的业务流程进行梳理和整合，重点抓住流程的操作步骤和控制环节，但又不会太大地改变原来的操作习惯。比如人员出入和设备的搬入搬出都可以放在服务请求管理流程里，在这个流程里，只要能体现出来“在不同人员出入的情况下，不同设备搬入搬出的情况下，相应地需要审批哪些内容，哪些需要密码确认”，就可以了。
举例来说，IDC业务开通要做8件事情：准备电源、IP地址、上架，通知用户开通了业务、验证等。如果一般企业实施ITIL变更管理流程，就不会考虑这8件事情，只会考虑是否提交变更请求，有没有人做变更的复查，并进行相应的风险审批，评估之后安排时间就可以去做变更，做完了之后再审查一下。
但是，IDC可能不会接受这种变更流程，因为如果按照这种流程去做，他会觉得业务的开通、修改比较模糊化。因此，这些具体的操作步骤，建议放在变更管理流程里不同的模板中来做。也就是说，只有一个变更管理流程，但是在这个流程中，业务开通要做8件事情都可以直接看到，也可以一步步去操作。这样，运维人员就不觉得难以把握，或者是效率低了。
总之，IDC整个运维流程会遵循ITIL流程，但是不会改变原来操作的方便性，而且会更加规范，比如，以前风险评估可能只要写在一张纸上就完了，现在需要实时记录。
第三，强化资源管理。IDC的核心业务就是出租资源，因此必须管理好资源。否则，资源不准确或出了问题，就会影响业务发展。IDC的资源管理与ITIL配置管理非常相似，但配置管理对资源的控制相对比较严格。实际上，大多数IDC资源管理做得不到位，最大的原因是有些信息的自动化采集和更新没有做到位；另外，IDC对资源的控制力度也非常弱。
比如，对于业务变化和设备变化，IDC缺乏强制措施去要求运维人员更新资源库；大概每半年IDC会花费很多时间和精力从头到尾梳理一遍资源库，否则如果有新客户申请某些业务，IDC就无法准确回答有多少资源可用。
因此，在资源管理方面有两点建议：要有自动化资源采集工具，也要有一套资源分析和优化机制。
第四，关注组织架构设计。现在很多IDC的组织架构是比较传统的企业组织结构，比如按照不同技术领域划分为不同部门，各个部门之间的沟通和协调方面不够顺畅。
ITIL所提供的组织架构是把人员划分为一线、二线、三线；一线人员记录服务的呼叫，并处理简单故障；二线人员处理一线解决不了的问题；三线人员解决难度较大的问题。另外，ITIL还针对不同流程设置相应的流程经理，去推动每个流程的实现。这种方式可以提高处理故障的效率，而且使相同数量人员的服务能力极大提高。
但是，需要注意的是，如果IDC完全按照ITIL来设计组织架构肯定有难度，因为很难找到合适的流程经理来承担这样的事情。因为流程要执行得好，主要不是靠执行人，而是靠流程经理不断优化流程。
在当前的实践中，建议IDC在初期可以建立跨职能部门的团队。他们负责两方面事情，一是协调不同流程执行的问题；二是在解决问题的时候负责整个故障的分配和处理。他们一起对某个问题进行分析和处理，问题出来之后，先到这个团队进行分析和处理，然后再由相应技术部门做后续的故障处理。引入这种方式的目的是让运维人员迅速反应，这在人员意识和技能还不能满足要求时，不失为一种过渡方法。
http://cio.ciw.com.cn/UploadFiles_6003/200706/20070601103106975.jpg
IDC实施ITIL三阶段
对于IDC来说，实施ITIL主要分三个阶段（见下表）。
第一阶段是建立清晰的服务目录、服务水平协议和IT财务管理流程。
服务目录是IDC在运维服务方面能够提供哪些产品，或者是提供哪些具体的服务，这些产品或服务最终会涉及到基础设施，比如带宽、机架、防火墙、杀毒服务能力等。服务水平协议是针对不同的服务产品，能够提供什么样的服务能力，比如80%的客户满意度、多长时间内响应故障等。
服务目录、服务水平协议是回答“IDC能提供什么样的服务”；IT财务管理流程是回答“这些服务是怎么收费的”。
实际上，国内IDC已经具备以上两个方面内容，但是不够规范和细致。比如他们在服务水平协议中承诺的服务条款比较随意，有时候为了能够拿下这个项目，就承诺许多，但实际能力可能又做不到。因此，服务水平协议方面还应该借鉴ITIL的思路，尽量做到科学化。
大多数IDC的IT财务管理流程比较简单，因为现在主要是托管业务，按照流量收费或者包月就可以了。对于不同客户怎么收费的问题，还没有细化。
而未来增值业务的计费就比较复杂和多样化，比如怎么对不同用户收费，收费原则怎么定，怎么分摊等问题必须精细化，因此，财务方面的分摊和计费办法就会更加复杂。在这方面，必须将技术手段与合理的计费方法结合起来，参照ITIL的框架进行实施。
第二阶段是完善监控和服务支持体系。目前很多IDC都建设了监控体系，能够采集到需要的数据，也能监控到整个网络的故障，这方面基本上没有太大问题。
但是，从ITIL角度来看，IDC在运维监控方面仍有待完善，比如需要建立事件管理、问题管理、变更管理，并完善资源库，使后台的维护工作与IDC日常运营工作紧密结合起来。
在完成前两个阶段的工作后，IDC基本上已经能够良好运转，同时也能够让客户获得一个比较满意的服务和体验。
第三阶段是从IDC长期发展的角度来看，重点需要进行可用性管理和容量管理。在这方面，国内IDC可以借鉴一下国外IDC的好的实践经验。比如，一些资源动态分配、调度的能力，要尽量实现自动化，尽量减少执行烦杂的手工操作；安装一些软件时，不要每次都重新去装，通过自动化的安装和调度来降低可能出现的误操作等。
值得学习 08年的资料
我转来做个记录：） 回复 alex 的帖子
:)写的不错 :victory:对于IDC 了解的信息不多，此篇文章提供了不少有用的信息，感谢！
Alex, 关于IDC 的完整资料，能否传一份给我呢？ 可以私聊，谢谢！ mingya 发表于 2011-5-10 13:58 static/image/common/back.gif
回复 alex 的帖子
写的不错 对于IDC 了解的信息不多，此篇文章提供了不少有用的信息，感谢 ...
IDC目前都以叫DC为荣了
有兴趣可以看看最近facebook开放自身的IDC资料
还有google不甘后人同样开放的相关资料
很多信息……
页:
[1]
2