[原创]数据中心管理——IT服务管理实践经验分享实录（一）

从传统概念讲，机房建设，网络建设，大型存储建设，从新的技术来说，虚拟化，自动化，包括开源，包括数据安全，网络安全，很多方面的元素可以去谈，这都是我们整个数据中心运维当中必不可少的。原来做Mainframe的时代，对IT服务管理需求并不是很强，为什么？不需要协调太多的人，也不需要设计太多流程，也不需要面临太多的沟通的环节。几个系统管理员管两台大型机，沟通环节少，紧凑高效，所以IT服务管理需求并不强烈。但是当公司在2001年引进新一代集装箱系统之后，变成了四五百台机器，大量的NT机和小型机。我们学过IBM大机人都知道，在大机年代，所有的系统error，你只要能熟读手册，当然那些原版的白皮书排气来很多的ErrorCode都是可以查得到的，但是当我们引进开放式系统，很多复杂的问题，涉及到网络，主机，数据库，甚至应用，很难定位其根本原因，而且随着团队的专业化分工，很多问题的沟通成本加大，没有高效管理流程，一大堆问题就出现了。我本人在这方面特别有感受，这也是我今天主要想和大家分享的，ITIL在企业管理如何定位，ITIL在企业里如何落地。进入运维的数据中心，可以感觉到在用原来的管理理念去管理数据中心是不行的，为什么？

刚才我其实已经简单的概括了一下我们实施的背景，其实没有当时2001年的数据中心大集中，IT服务管理的流程和理念也许至今还是会离我们很遥远，因此我个人认为，任何管理的改变和措施的实施都是要有一个背景，也就是一个推动力去推动。那当时我们面临一个什么样的挑战呢? 原来其实我们的IT系统是一个分布式的架构，在上海我们只要管到在上海远洋这块的业务就OK了，但是公司2000年做战略调整，实现集装箱及系统数据大集中以后，我们全球差不多400多个网点要集中来访问我们位于上海外高桥保税区内的全球数据中心，通过专线和VPN连进来差不多170多个网点，应当说中远是国内企业海外布点最广的公司。因此，我们面临第一大挑战是全球性。

第二大挑战是复杂性，大家可以看到，我们的应用是非常复杂的，根据麦肯锡06年的报告，集装箱行业的数据中心系统是最为复杂的系统，所以在我们整个系统里面，差不多大大小小有50多套系统互相交集，相当复杂。因此，动任何一个系统，就有可能影响到其他系统，可谓牵一发动全身，集装箱系统非常复杂，但是高性能的要求和我们银行，金融行业是没法比的，集装箱行业整个价值链特别长，他整个数据交易链条非常长，这就导致业务对系统的依赖程度特别高，对系统每个环节的可用性要求也非常高。当然，从单个交易的高可用性要求，我们无法和金融及证券交易所相比。此外，我们各种数据库IT团队和IT管理面临很大挑战，我们感觉应付不过来。都有，这其实当时不是我们定的，因为我们引进其他行业公司的应用软件一起打包引入的。同时，我们还有庞大的开发测试环境，预生产环境，灾备中心。

由于我们实施数据中心大集中，过程当中遭遇来自于各方面的阻力，包括对于新系统地service cal就像雪花一样飞来，无论是应用的，还是网络的，还是数据的，还是用户使用方法的。如果没有好的IT支持和服务管理流程，我们根本无法有效的支持用户和前瞻性的发现系统问题。于是2000年开始，我们就踏上了IT服务管理的实践道路。

现在ISO20000其实是蛮多的，因为这两年随着我们各大企业用户成熟度和提高，2002年谈ISO20000，在2000年的时候，其实还是很早的，那个时候和其他用户同行做交流，几乎提不到这个概念，是比较早的，大家看到这个模型，这是当时惠普ITIL模型，最早是给我们做咨询顾问，我们也是引进了一套产品，作为整个IT服务管理体系的工具平台。

很多咨询厂商都会讲到，我整个IT服务管理历程是怎么样的？应该没有最好的，只有最适合你的，最适应你的才是最好的。我觉得这应当是黄金法则。包括我和交通银行，金融的、证券他们交流也是，他们在说什么是最适合你企业的，那就是看每个阶段我们希望解决的最关键矛盾是什么，因为资源是有限的，想全上，但是你有那么多资源吗？所以要根据企业的自身情况，去解决你最关注的问题。当然，在规划上如果有条件可以整体规划，分布实施。

在2001年到2002年，在IT服务管理里面，我们做了Incident management-故障管理流程和Service Desk—服务请求流程（ITIL 10个模块中的2个）。前面说过，2001年我们开始做大集中，大集中要解决的问题就是收编，新的应用面临着很大的问题，一个就是客户化的问题，还有就是用户对系统不熟悉，培训不够，对系统抵触情绪很强烈，不愿意用你的系统，报出一堆问题，在建立这两个流程之前，各种问题像球一样互相传来传去，没有人统一跟踪，分析，往往一个问题导致的多种现象，分在一堆人手上处理，大家还不知道就是一个问题。因此，当时的状态是没有一个统一系统进行管理，没有统一团队进行管理，没有统一的沟通渠道，没有统一的记录平台，没有责任人，没有响应要求和解决要求，没有上报机制，没有跟踪机制，没有相应的绩效考核，没有相应的统计报表，也没有一线二线处理的知识库等等。而我们后来建了这套体系流程，配备了相应的组织架构，推广了有效的工具，问题得到大幅的缓解。我们相继在北美、亚太、欧洲建了一个区域支持中心对问题进行一线处理，处理不了的问题升级到我们一个集中的24*7HELPDESK， HELPDESK解决不了，再派发到二线支持，包括业务和IT。这套系统现在对于各位同行来说可能好像很普通，大多数数据中心都这么做了，可是在2001年、2002年的时候，还是很先进的。这两个流程的上线为我们的系统大集中做出了不可磨灭的贡献。

我们进行ITIL服务管理的第二个阶段是实施变更管理，也是我作为一名ITIL_master最为关注和认为控制数据中心风险最为重要的流程之一，另外一个是发布管理，稍后可以再讲。

变更管理，我不知道各个企业是不是已经上了。即使上了，有没有用的很好？这个差别还是很大的，其实变更管理我们在之前并没有重视。直到2003年，我们公司发生了解次到现在想起来都非常惊心动魄的“双10事件”，那次正好是特地选在国庆期间做一个存储改造“从DAS到SAN”的改造，后来发现我们那台核心主服务器不知道什么原因不能正常启动，我们想主服务不工作问题不大，按照应急预案，我们备用服务器2个小时就能完成接管，可是灾难的事情发生了，我们切换过去之后，虽然设备能够启动，但是应用根本起不来。原来，原来半年来在主服务器做的那么多变更，在备用服务器上都没有实施，或者实施后没有经过验证。由于没有变更管理流程，所有变更没有统一的记录，审核和批复，不管影响多大的变更，TEAM负责人同意就可以实施，不管是否影响到其它部件或者应用，由于没有变更管理，那台可怜的备用服务器成了摆设。由于没有变更，系统的问题不知道是什么原因造成的。CIO不能接受这个事实，所谓养兵千日，用兵一时却用不上，当时我们做运维的压力非常大。那次的事故后来整整影响了我们2天，才最终把问题找出来。那次以后，我们CIO明确要求，我们拿出整改方案。我们运维团队在整个事件当中深受教育，随即启动了变更管理流程，对数据中心所有对生产环境的操作进行严格的控制和记录。建立的方法，是先细后粗。即先把所有在数据中心可能做的变更全部列出来，大撒网，然后再经过讨论进行分类，哪些是重大变更，较大变更，日常变更，一般变更，还有哪些情况下允许紧急变更。变更的分类是根据其可能对系统产生的影响，而不是技术实施的难度。即使技术实施非常简单，可能产生的潜在风险很大，我们也应当把它列为重大变更。我们还成立了变更管理委员会，委员会的最高领导是我们的CIO，负责对重大变更的批复。变更流程做起来以后，大大减少了由于误操作，或沟通问题，或变更冲突，主备系统不一致等导致的系统可用性风险，同时，每周要做的所有变更每个干系人都会提前知道。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友