银华基金的实施案例

《银华基金的实施案例》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

银华基金卷起袖子做ITIL银华基金公司信息技术中心 目录牛市中不狂燥，熊市中不沉寂，好基金公司必备的素质3银华基金星罗网布的信息基础架构和复杂的业务应用环境3银华基金的混合IT运维模式5实施ITSM/ITIL后的银华基金IT运维服务管理体系概述5银华基金的IT运维服务管理对象7银华基金实施基于ITSM/ITIL的天汇帮助台系统路线图素描10银华基金资产及配置管理数据库（CMDB）的规划与实施——摸清家底、状态、库存、备品、关联11配置管理是基础11银华基金配置管理数据库（CMDB）构建思路12建立银华基金cmdb配置管理数据库的一些思考——识别和创建cmdb13以银华基金业务为线索，利用天汇帮助台软件进行可视化配置及其CI的规划和识别15总结：CMDB实施六忌17服务商与合同管理（待丰满）18银华基金变更管理流程的设计和实施（缺数据待改写）18ITIL流程管理简介18银华基金的变更管理流程的设计19变更管理流程的实施结果19结论（待改写）20银华基金IT服务统计报表——利用图形化的报表和度量标准跟踪时间、趋势和绩效20银华基金公司信息技术中心关于规划实施基于ITSM/ITIL管理系统的深入思考29系统维护的发展阶段29银华基金基于ITSM/ITIL的IT服务管理系统建设目标30系统架构的选择31系统流程控制31银华基金的服务台管理32基于ITSM/ITIL最佳实践的事件管理32系统化的“治本”方略——问题管理38变更管理39资产与配置管理39预防性维护及日常操作管理40利用天汇帮助台的事件/工单机制进行任务管理43知识库管理44满意度调查管理45恰当和有效的事故升级机制45IT运维帮助台系统平台与内部业务系统（OA、邮件、短信平台等）、监控工具（Netgate、英飞系统等）的无缝整合53 牛市中不狂燥，熊市中不沉寂，好基金公司必备的素质　　2006年牛市不期而至，笼罩了A股市场长达五年的阴霾随之一扫而空。大部分的股民望着飚升的股指感慨“只赚指数不赚钱”时，基金收益翻番却让不少“基民”笑得合不拢嘴。多个超百亿元规模的基金成功发行，100多亿份的基金当天结束销售也不是新闻了，银行门前甚至排起了久违了的长队。“基金”这个大多数中国人都不曾了解投资产品被推到了风口浪尖。　　当牛市的火热渐渐褪却，市场经历着令人痛苦不堪的“快熊”阶段，有关未来的收益，众多投资者再不敢奢望，也到了真正检验基金、基金公司和基金经理的时刻。银华基金公司，也许她在风光的牛市中不是最醒目的，而在熊市的煎熬之中，她却是61家基金公司中最为引人瞩目的。牛市中不狂燥，熊市中不沉寂，这是一个好基金公司必备的素质。这也正符合银华基金给投资者的一贯感觉——低调、中庸。银华基金正是秉承这种优雅、适度的风格，凭借诚信、规范、稳健、务实的经营信条，成立7年以来，从一个行业新生代成长为一个具有大资金管理能力的综合型资产管理公司，跻身于国内优秀基金管理公司行列。　　2007年正当大多投资机构还沉浸于牛市狂热时，银华基金公司却做出了一个冷静的决定，为拓展公司业务挥师北上，将总公司由深圳迁至北京，数据中心也随企业业务一同搬迁到北京。正是在公司稳健、务实做事风格的促使下，IT团队在不到3个月的时间里，顺利完成了北京数据中心的规划和建设工作，不失为业界的一个奇迹。　　2008年4月，在计世资讯联合业内专业机构举办的“下一代数据中心国际峰会”中，银华金基金数据中心凭借其在建设方面的成功实践和先进经验，一举获得“数据中心最佳实践奖”，获得这个奖项的还有英国巴克莱银行、上海证券交易所等一批知名金融机构。银华基金星罗网布的信息基础架构和复杂的业务应用环境在总部从深圳迁至北京后，银华基金在上海、深圳仍有分支机构，周南表示上海属于区域营销中心，主要做市场服务，所以自成一体系，使用OA系统和银华基金北京总部进行沟通。由于总部原址就在深圳，深圳分公司规模仍比较大，北京到深圳由数据专线进行链接，并纳入到北京总部公司的域进行管理，并进行日常的维护。所有的数据都集中在北京总部的IBMDS4800存储之上，相比业内其他公司，银华基金的信息基础架构无疑在一开始就处于方便进行管理的领先地位。除了内部星罗棋布的信息基础架构外，银华基金内部还有复杂的业务应用系统。其总体网络连接拓扑逻辑结构示意图如下： 4507-OA4507-A4507-B2960-12960-22960-310FRT-2801-SHRT-2801-BankRT-2801-SZRT-3640灾备2960-12960-22960-32960-42960-510FIPIPXNetscreen204天融信天融信IPS网联无限3845代理拨号深圳DMZLinkProof电信网通203.81.24.72/27E1172.16.1.11/24172.16.1.12/24172.16.1.13/24172.16.1.14/24172.16.1.15/24172.16.1.1/24172.31.2.11/24172.31.2.12/24172.31.2.13/24172.31.2.1/24172.31.2.2/24银华基金网络设备连接拓扑图203.81.24.65/27E2E3172.16.3.254/24172.16.100.17/28172.16.100.18/28E1E2E3E4E1E2E8172.16.100.2/28172.16.100.1/28219.142.5.62/30202.106.53.150/30172.16.100.66/28.65172.16.2.254/24172.16.100.49/28.50GE0/0FE5/46FE5/47172.16.2.X/24172.16.3.X/24172.16.200.X/2415F15FFE5/48E0172.16.100.33/28E1199.200.200.254/242960-6172.16.1.16/24IPSODMZ 银华基金的混合IT运维模式银华基金目前采用混合运维模式，即对所拥有的一部分IT资源自行运维；同时，通过与其他单位签署运维外包协议，将所拥有的另一部分IT资源（如桌面系统）的运维工作外包给其他单位。一般情况下，由本单位IT部门负责运维工作和外包管理，即本单位的IT部门和外包单位共同向本单位提供IT运维服务，这种模式下的运维环境如下图所示：在混合运维模式下，根据运维服务是否涉及各单位的核心业务、关键任务等因素，对外包服务管理的具体要求各不相同。对涉及核心业务或关键任务的外包服务，需要对外包服务的过程和结果进行精细化管理；对只涉及非核心业务和非关键任务的外包服务，只需要对外包服务的结果进行粗放型管理。实施ITSM/ITIL后的银华基金IT运维服务管理体系概述实施ITSM/ITIL后的银华基金IT运维服务管理体系 规定了IT运维活动涉及的各类实体，以及这些实体间的相互关系。相关的实体按照IT运维服务管理体系进行有机组织，并协调工作，按照服务协议要求提供不同级别的IT运维服务。组成实施ITSM/ITIL后的银华基金IT运维服务管理体系的实体包括运维服务管理对象、运维活动角色及运维管理组织结构、运维服务管理流程、运维服务支撑系统和运维服务五个要素。其中IT运维服务管理对象主要包括银华基金的IT基础设施、IT应用系统、IT用户和IT供应商。内部从事IT运维活动的部门和人员也作为运维服务管理对象。IT运维活动角色是指从事IT运维活动的所有单位、部门或者具体工作人员，一般包括IT运维服务提供者、IT运维服务使用者、以及IT运维服务管理者三类角色。各类角色在IT运维活动中所构成的组织形式构成了IT运维管理组织结构。IT运维服务管理流程是指联系银华基金IT运维服务提供者、IT运维服务使用者以及IT运维服务管理者之间开展规范化协同工作的机制和方法。实施ITIL后，完整的IT运维服务管理流程覆盖了银华基金IT运维服务的规划、设计、运行和持续改进等各个环节，IT运维服务管理流程的信息化已经借助天汇漫道软件公司定制实施的天汇IT运维服务支撑系统得以实现。IT运维服务支撑系统是支撑银华基金IT运维管理组织中各运维角色按照规定的IT运维流程开展IT运维活动的信息化系统，该系统由基于ITIL标准的天汇帮助台系统定制开发实施。一方面，天汇IT运维服务支撑系统要支持银华基金的IT运维服务提供者对其IT运维服务管理对象进行管理，以实现IT运维服务的能力；另一方面，要支持内部的IT运维服务提供者按照商定的服务级别协议方便地向其IT运维服务使用者提供IT运维服务；同时，要支持银华基金的IT运维服务管理者对整个IT运维服务的考核、监督和评估。IT运维服务是IT运维服务提供者向IT运维服务使用者提供的服务产品，相关的IT运维服务质量完全可度量，服务提供方式符合规定的ITIL流程。目前银华基金IT部门提供的IT运维服务包括IT基础设施运维服务、IT应用系统运维服务、安全管理服务、网络接入服务、内容信息服务以及其他综合管理服务。而IT运维服务的自动化实施主要依靠天汇IT运维服务支撑系统及相关第三方监控工具等。组成目前银华基金IT运维服务管理体系的五个要素的详细组成及其相互关系如下图所示： 实施ITSM/ITIL后的银华基金的IT运维服务管理体系银华基金的IT运维服务管理对象银华基金的IT运维服务管理对象包括IT基础设施、IT应用系统、IT用户、IT供应商、以及IT运维部门和人员，具体内容如下：(1)IT基础设施包括网络、主机系统、存储/备份系统、终端系统、安全系统、以及机房动力环境等。(2)IT应用系统包括OA及内部办公系统、网站、面向企业和组织的应用系统、面向公众的应用系统、管理类应用系统等。它们包括：投资交易管理系统O3.2登记过户管理系统直销管理系统网上直销系统基金估值系统（共同基金）基金估值系统（年金专户）基金估值系统（QDII）TA资金清算系统办公管理系统OACRM客户关系管理系统公司网站公司邮件系统客户服务系统callcenter行情系统股票库系统报表中心QDII业务系统研究报告管理系统咨讯系统(万德数据库)咨讯系统(朝阳永旭)咨讯系统(红顶)咨讯系统(北方之星)PROP平台代销机构数据交换平台深证通平台客服邮件系统网站DNSF10巨灵信息接收电话交易系统办公上网短信息发送平台域管理系统安全防护系统IPS办公网防病毒系统 交易网防病毒系统办公网补丁管理系统交易网补丁管理系统日志管理系统网络监控系统（NETGAIN)英飞系统AVAYA系统数据备份异地灾备文件共享(3)IT用户包括使用如上IT应用系统的用户。(4)IT供应商包括IT基础设施和应用系统的供应商以及IT运维服务的供应商。(5)IT运维部门和人员包括银华基金内部参与IT运维活动的相关部门和人员，以及提供IT运维服务的企业和相关人员。 银华基金信息技术系统架构示意图 　经过考软件就达到了300万美金。”而ITIL管理类似ERP，项目实施后期的服务不可获　　银华基金信息技术部以ITIL为理论基础和“纲”，不断细化流程管理。从08年年初开始考察ITIL，目前银华基金IT部门的所有人已经都通过了ITIL理论课程。取，其成本将会进一步提升。在权衡之后，银华基金转向了国内软件服务商，国内软件公司的ITIL管理软件更加模块化，可以面向客户进行开发，比国外厂商灵活很多，价格也仅为国外的几十分之一，而且包含了规划，按照表单做一些基础的服务。通过广泛的调研和比较，最终银华基金选择了北京天汇漫道软件系统公司（www.techway.com.cn）的基于ITIL的天汇帮助台套件。在天汇的帮助台套件中整合了事件管理、工单管理、资产配置管理（cmdb）、危机通告管理、问题管理、变更管理、日常操作、预防性维护管理、服务水平管理、满意度调查管理、自助服务等基本和可选功能模块，能为ITIL的实施提供工具。ITIL中包括了管理IT组织及整合IT与业务的方法论，包括服务策略、服务设计、服务变迁、服务运作以及持续服务提升五大领域。ITIL定义的是流程，而流程的实现不一定完全依赖于工具。换句话说，有些用户实现了ITIL，但所有的表都是手写的，只要能控制好流程，这是可以实现的。但天汇这类工具的价值在于，可以把流程做得更高效、更好控制。天汇提供的整合工具可以帮助用户在实现流程的同时，使流程控制更高效，并实现自动化。　　证券行业安全健康发展与IT系统建设密不可分，信息系统的安全保障问题已经关系到整个行业的稳定发展，信息系统安全与IT建设规划已经成为了证券业信息化发展的工作重点。银华基金公司数据中心的发展历程必将成为证券行业信息化建设的最佳案例。察国外多款管理软件后，发现这些管理软件功能比较完善，但银华并不像电信运营商那样拥有足够宽广的业务，也没有足够的岗位来对庞大的体系做支持。此外，在同服务商沟通时的报价也贵的惊人，“即使产品买的起，但服务仍然实施不起，像BMC的全模块ITIL管理银华基金实施基于ITSM/ITIL的天汇帮助台系统路线图素描客户与部门及分支机构数据的初始化或导入，客户与部门及分支机构服务水平或响应级别的设计资产与配置信息的初始化或导入运维员工的角色和职责的划分事件管理流程的设计日常管理流程及工作任务的设计预防性维护计划的设计供应商、服务商，保修业务的管理流程客户化统计报表的需求分析与定制问题管理，变更管理设计自动化满意度调查的设计邮件服务器的整合，如何利用邮件服务器进行事件升级 银华基金资产及配置管理数据库（CMDB）的规划与实施——摸清家底、状态、库存、备品、关联配置管理是基础在ITIL的五大运营流程中，最基本的是配置管理的CMDB，它存放着最全面的IT资产状态。影响CMDM的入口有几个，一是来自业务客户的呼叫、查询、服务台的应答；第二是沟通、更新、解决方案；第三是新系统的发布。　　这里面有一个核心概念叫CI，就是配置项。配置管理是围绕配置项展开的。要讲清楚配置管理，就要把它跟资产管理放在一起谈。通常我们说的资产管理，指的是设备、装备、机器、工具、材料等这些物质形态存在的资产，如打印机、笔记本、PC机等。但是，在ITIL里，这个资产管理概念显得线条太粗，需要再往下细分得更具体一点，如公路可以分为二级公路、三级公路，而细分的内容就叫配置项，比如一个服务器配置了不同端口，每一个不同的端口可能会有不同的链接，而端口就是服务器的一个配置项；另外，每一个服务器上面运行的系统也不一样，不同系统也是服务器的一个配置项。　　因此，配置项是所有活动的最基本的支撑，没有这个配置管理数据库的支撑，IT服务管理活动是不能展开的。　　但是，仅有配置项就想完成配置管理，是一件非常难的事情。只有把资产的关联关系在CMDB表达清楚了，才能在出现问题时把故障点及与它关联的这些设备找出来，并估计故障影响范围，及时作出调整。　　配置管理数据库里面有一个很重要的时间因素，包括资产项目是什么时候建立的，什么时候处于闲置状态，什么时候处于废弃状态。不能因为一个路由器的两个端口是坏的，就把这个路由器扔掉，你只能说把这两个端口作废掉。　　资产管理的重点是企业拥有什么，而配置管理的重点是资产处于什么状态。在配置管理中，资源配置的状态是动态的，所以必须有定期审核机制，而且必须有定期审核的人，这意味着凡是没有在配置管理数据库里登记的设备，都是公司的非法设备。否则的话，会造成公司的重要机密资料流失、重要数据流失。它跟变更管理和发布管理有比较强的耦合关系，因为变更管理最终要通过变更配置项来体现出它的变更是否到位；发布管理也要通过变更配置项来体现出它的发布是否到位，所以，到位不到位，就看配置项是不是及时得到了更新。银华基金在CMDB实施过程中共梳理了2500项资产及配置项，不但摸清了家底，还摸清了状态，即它在用不在用（比如发现了两台被人遗忘闲置的高档服务器），是库存还是备品等内容，也就是，要清楚这些资产项目之间的关联，比如局域网的交换机与后台服务器是怎么关联的，与前台笔记本是怎么关联的，与业务部门又是怎么关联的。利用配置管理数据库（CMDB），银华基金加强了基础数据的统一管理。以往各类信息数据分散管理，没有统一标准。从机构信息到设备、合同情况；从网络、主机、网点配置到下属业务部门各项信息，这些资料散而不全，相关人员 常常无法很快地在第一时间找到自己所要的数据，不仅影响问题处理，还直接影响了管理水平；同时，业务部门打电话申告故障时，每次还要反复提供自己的主要信息，维护效率也同时降低。对于一项信息多处记录，在信息变更时，也会造成信息错误，影响甚大。运用天汇帮助台系统中提供的配置管理模块后，对各类信息进行整合录入，摸清了家底，同时加强了基础设施的管理，从系统、网络、设备、机构、合同、软件等，各类信息一应俱全，为有关领导对信息的查阅提供了一个较为全面及时的途径，也方便了有关人员对信息的及时掌握。维护人员也能在故障出现的第一时间，对该故障点涉及的业务部门、电话（分级）、设备配置、工位（IP地址）等各类信息及时掌握，便于问题及时处理。银华基金配置管理数据库（CMDB）构建思路银华基金CMDB数据库中配置项信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接。针对目前大多数企业中IT配置数据以不同格式保存在桌面机、服务器、补丁包、操作系统和网络设备中的局面，CMDB把不同格式的数据统一采集到一个信息库中，打破了IT域之间的固有壁垒，有效管理IT资产。同时，通过对配置项信息的分析，快速定位系统故障来源。  要实现CMDB的成功构建，CMDB的设计和运作是必须攻克的两大难点。如果设计不当或无法有效运作，将极大地制约ITSM系统的管理能力，让IT运营的效率和效果大打折扣。由于CMDB是ITIL流程支持的核心，它需要为ITIL其他流程提供IT服务及基础架构层面的配置信息，所以只有CMDB记录的数据完整，才能准确地反映IT服务的真实状态。而所谓CMDB的完整，包含了配置管理范围的识别、CI属性的选取和CI关系的构建。第一步，确定配置管理的范围。这主要涉及CI的宽度和深度，以及CI的生命周期。需要说明的是，ITIL规范认为，CI的生命周期是从CI的接收到最终报废退出的全过程，但在具体实施过程中，由于流程管理主体的差异化，不同项目对CI生命周期的划分和定义会有所不同。在确定CI的宽度和深度时，设计者应当从企业IT服务的需求、企业IT服务管理水平和CMDB运营管理成本三个方面进行合理规划。具体来说，CMDB构建应该主要从IT服务角度考虑，IT服务本身也可以作为CI记录到CMDB中，同时IT服务涉及的IT基础架构及其相关的重要信息都应记录到CMDB中；必须认识到CMDB与企业IT服务管理水平之间紧密的联动。企业IT服务管理水平越高，其对CMDB的依赖程度也随之上升，对CMDB数据的准确性和完整性也越高。同时，企业变更管理的成熟度，包括变更管理范围和流程执行力度也将在很大程度上影响CMDB数据的准确性和完整性；成本方面，CI的颗粒度决定CMDB中信息的详细程度，而这些信息的有效维护取决于IT部门投入的管理成本。如果无法投入相应资源进行CMDB的维护，其数据准确性便无法保证，也无法发挥其应有价值。CI生命周期的确定主要包含对两个问题的确定。一是什么时候识别CI并记录到CMDB。在标准的配置管理流程中，CI全生命周期的理想状态应该覆盖从采购申请到报废退出的过程。但在实际实施时，流程执行主体的管理范围和职责将决定CI被识别的时间点；二是什么时候删除CI记录。这一时间点同样由流程执行主体的管理范围和职责所决定。例如，对于租赁的CI，IT部门并不关心它的报废过程，只关心其在生产环境中的运营状况，因此CI被租赁公司更换，则该记录就有可能被标记为删除。而CI记录的删除并不是数据的真正删除，而是将其标记为删除，这样做的目的是为IT审计提供数据支持。 第二步，定义配置项的属性。对于同一类型CI属性的定义，不同企业的定义方法可能截然不同。通常情况下，设计者需要遵循一个原则和一套结构。一个原则就是“精而不多”。如果我们将大量属性纳入CMDB，那么无疑将加大信息维护的成本。反之，如果属性过少，CMDB对流程支持的有效性就降低了。所以，所谓“精而不多”就是找到适合自身需求的平衡点。ITIL专家指出，CI属性的定义要注重选择的属性是否具备“面向服务的特性”。例如，一台商用服务器可能会包含上百个属性，但实际上经过筛选，对企业有实际意义往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。一套结构指的是，我们通常可以把一个CI的属性分为五大来源。具体的划分方法如附表所示。建立银华基金cmdb配置管理数据库的一些思考——识别和创建cmdb揭示IT组件存在于银华基金信息技术部管理界限内所有IT组件必须在确定需要利用配置管理手段跟踪控制的IT组件之前得到明确识别。除应用软件、操作系统、网络路由器、工作站和服务器之外，这里所指的IT组件还包括过程文档、参考指南、技术手册和构建文档。有关人员还应进行广泛审核，以期对部署在银华基金信息技术部管理界限内的硬件和软件类型加以分辨，并收集为这个环境提供支持的文档资料（包括过程和技术方面）。上述审核工作还应对IT组件之间的关联加以识别。确定需要管理的对象即使在银华基金信息技术部目前机房范围的小型IT环境中，对所有单个组件变更情况分别进行跟踪管理也不具备可行性。除将全面收集此类信息并将其载入CMDB 之外，数据库维护与更新成本同样令人难以承受。因此，应对必须置于管理状态下的组件子集做出选择。这就需要考虑对业务相关性和IT环境组件及其彼此之间关系的重要性予以充分考虑。最佳实践经验建议仅对具有下列特征的组件实施管控：     •为银华基金业务正常开展所必需。     •可支持IT服务提交。     •可能因对IT环境下的其它组件进行变更而受到重大影响。有关人员应定期对已决定纳入CMDB的组件进行审核。虽然CI识别活动主要由发布角色群体负责管理，但银华基金IT运维的其它团队模式角色群体也会参与进来 银华基金运维角色群体 在配置项目创建活动中的参与情况基础架构提供专业技术咨询，包括对CI关系识别与管理方式提供建议和指导。操作运转输送可供用于经营运转的CI。合作伙伴提供合作伙伴/第三方信息输入——特别是在合作伙伴负责管理当前CI的情况下。发布管理并掌控CI过程的标识辨析工作。安全保障输入有关安全CI和配置活动安全问题的信息资源。支持输送用于技术支持目的的CI资源，并直接为此项活动提供支持。服务从IT服务角度出发输送适用于所有配置项目的信息资源。 是否需要对某项资产实施跟踪控制？初始设置与准备活动应包括编制须被置于配置管理手段控制下的IT组件列表。新增组件与资产得到确认后，只有在其出现于列表的前提下才会被添加至CMDB。将某一IT组件纳入CMDB或从CMDB中清除的决定应定期接受审核，以确保该数据库能够为组织机构需求和对其加以运用的服务管理职能提供支持。确定需要接受管理的CI将某一IT组件加入CMDB需要将其创建为一或多个CI。为选择适当的CI，有关人员必须参考银华基金组织机构在变更跟踪控制方面惯于采用的细化程度。这样一来，在数据库中创建的CI将允许根据既定细化程度管理IT组件。以工作站为例。一个工作站通常包括多种组件：已安装就绪的操作系统、应用软件、处理器和内存。组织机构通常采用操作系统和已安装应用软件等代表整个工作站的配置项目对其进行管理。然而，在某些情况下，已被创建的CI可能直接代表每种组件，从而使组织机构得以在高度细化水平上对变更实施跟踪控制。诸如个人计算机硬件厂商之类的专业化机构可能需要CMDB包含允许（在极端细化程度上)跟踪监控变更情况的配置项目——也就是说，令配置项目的界定具体到已安装于某一特定型号个人计算机的图形卡、网卡和主板。尽管这种需求可以得到满足，然而，保持CMDB即时更新所需付出的高昂代价远远超出了在过高细化程度上实施变更跟踪监控所带来的优势。由于每个机构具有不同目标，因此，不存在可资界定合理细化程度的明确指导原则。当然，应在决策前将可用时间、资源和技术纳入考虑范畴。这是银华基金的IT运维组织机构在最初确定配置管理目标的过程中必须研讨的典型问题。说明：没有必要对组织机构视为低值易耗品的项目变量情况实施跟踪监控。为工作站配备的鼠标和键盘通常就属于此类低值易耗品。辨别CI之间的关系和依存性与资产管理相比，配置管理的一项关键优势体现为配置管理可针对IT 组件之间的关系进行建模。为实现这种优势，必须首先分辨出这些关系，并确保配置项目之间的关联如实反映现实状况。例如，倘若某个DNS服务器的Internet协议（IP）地址发生变化，就应对依靠这台服务器执行名称解析的所有客户端的DNS解析程序设置做相应调整。如果DNS服务器与其客户端之间的关系未被存储于CMDB，那么，某些客户端便有可能被遗漏，并因此无法访问网络资源。某些关系可能比较容易识别，而另一些关系却只会在针对IT基础架构所含组件进行调整时显现出来。为此，我们首先集中识别涉及银华基金重要业务的重要关系——确保组件及其所属基础架构正常运转所必需的关系，再根据实际需要添加其它关系。可通过在CMDB中创建配置项目关联的方式对IT组件之间的关系进行建模。每当建议对某个配置项目进行调整时，即可利用这些关联分辨出将会受到变更影响的配置项目。针对某一配置项目进行调整不一定影响到与之相关联的所有配置项目，为此，应制定可确保只会在影响分析过程中分辨出相关配置项目（将受到变更影响的项目）识别规则。例如，将工作站内存容量从256MB增加到512MB的调整就不会影响到与之相连的网络。然而，安装需要大量（专有）网络带宽的视频会议应用则会对网络产生实质影响。制定足以涵盖所有可能性的自动识别规则既不现实也不可能。识别可能受到变更影响的配置项目往往要求将自动判断规则与专业人员的经验技巧相结合。选择CI属性得到识别的每个配置项目均具有大量可供记录于CMDB的信息，内容涵盖项目名称、项目描述、项目所在地、配置设定及配置选项等属性。正如我们始终强调的，配置管理的价值完全取决于CMDB所含信息的质量和精确度。倘若所选属性过多，就可能为确保相关信息的准确性和及时性付出高昂代价。更明智的做法是只选择配置项目管理任务所必备且组织机构需要对与之相关的变更进行跟踪监控的那些属性。举例来说，用来描述某个应用软件的配置项目(CI)可能具有以下属性：唯一标识符应用名称版本号描述源文件（在既定软件库中所处）位置所有者此外，还可生成并存储用来汇总细微情况或包含由信息处理或筛选程序计算得出数值的属性。针对这些（已处理）属性的需要取决于每个组织机构的具体要求和对配置项目加以识别和定义的细化程度。以银华基金业务为线索，利用天汇帮助台软件进行可视化配置及其CI的规划和识别首先要确定支持业务服务的配置项，如应用服务器、网络服务器、路由器、数据库和数据库服务器等，然后就要确定在这些配置项之间存着什么类型的关系，比如说是“依托运行”、“主机”、“连接”、“管理者”等。这些关系有助于理解和降低与组成服务的配置项的变更*相关的风险。一旦CMDB 按照这样的做法初步成功实施，企业就可以考虑扩展项目的范围，以一种有效且高效率的方式来管理更多的配置项。这种渐进的方法可以让企业迅速地实现价值，同时还会获得进行更广泛实施所需要的经验。对于偏硬件的配置而言，它的CI结构规划是相对简单的，真正复杂的是软件业务类的配置项目，这种业务服务涉及网络，数据接口，几百个的数据库，众多的服务器与工作站，这时的配置规划就有一定难度了，但基本上我们还是可以发现存在一定的规律，那就是以业务服务为线索，在业务下面的一级节点中，按应用服务器、数据库服务器、接口服务器、程序、接口程序、数据库、专用设备、相关组件、相关网络等这样的思路去规划，再逐个细化，就可以理清整个项目的CI结构，这里需要注意的事情是共用CI的问题，当一个CI的运维权在某个项目时，这个CI的所有内部信息，别的项目只能调用，不能对其进行解释，比如上面说的DMS项目中会用到相关网络（A网路），A网络内部的所有结构与关系信息，都是由网络领域的团队进行规划设计的，DMS项目只能调用A网络本身这一个组件，这一个理念会非常重要，因为当项目众多，组件复杂庞大时，整个公司级的配置结构是难以合作同时构建的，这时需要制定相应的游戏规划，教每个团队按规则去绘制自已的整个树枝，最后会自动组装成一个参天大树，把最专业的事情交给最专业的人，用一种比较简单的逻辑，最后形成一个复杂的东西，每一个纬度只需要与一个续度建立关系，最后所有纬度会相互关联。这种最简单的逻辑构成的好处在于相互独立，分拆容易，同时容错性强，构建容易。下图是一个以银华基金内部业务为线索梳理的配置项目的CI结构示意，天汇帮助台系统提供了可视化的CMDB设计，从而方便IT人员对CI进行规划和识别。 总结：CMDB实施六忌清楚地定义短期目标和长期规划，对于CMDB项目的初期开展很关键。如果不能合理地定义目标和量化投入产出比（ROI），你的方案就很难得到管理层的同意。   为了确保CMDB项目实施的成功，防止不必要的项目拖延，企业在实施配置管理数据库（CMDB）时应该有一些预防措施，下面提出的6个方面的缺陷，企业在实施CMDB时应该极力避免。   缺陷1:不能识别CMDB的目标和收益   CMDB管理着企业环境内的众多配置项及其关系，这些配置项可以是服务、软件、硬件、系统、操作系统、应用程序、数据库、流程文档、安全文档、网络组件等。   在不同的企业之内，这些特定的配置项的重要性是不同的。CMDB不能也不应该管理企业内的每个资产、文档或流程。每一个企业都不应该对自己的配置项的特定目标和利益视而不见。   如果知道CMDB如何应用，比如理解变更的影响，就可以基于CMDB购买和实施的成本，对项目的目标进行成本－利益分析和衡量。清楚地定义短期目标和长期规划，对于CMDB项目的初期开展很关键。如果不能合理地定义目标和量化投入产出比（ROI），你的方案就很难得到管理层的同意。   缺陷2:让CMDB成为一个元数据的倾销库   为了获得最大的业务价值，要认识到CMDB中什么可以管理与什么应该管理两者之间的区别。一些企业在发起实施CMDB时，有时候会不加区别地将所有来自配置项（CI）仓库的数据全部输入到CMDB，而未能进行充分地关系文档化或者是对配置项的变化进行管理。CMDB应该只包含那些计划将要积极去管理的配置项。如果将所有的数据都倒入CMDB之中，没有一个规划，企业就会身处一个难以管理且价值不大的知识库之中。   缺陷3:忽视变更管理的需要   如果没有一个有效的变更管理流程，CMDB将很快就会与现实不同步。因此，CMDB和配置管理流程必须与变更管理流程紧密结合在一起。只有经过认可的变更可以进入CMDB，只有作为变更请求（RFC）的一部分的配置项才能进行更新。如果不能满足这些要求，CMDB的实施将会陷入一个向下的螺旋，直至失败。   缺陷4:不能获得利益相关者的支持   CMDB实施在企业之内会有很多接触点。与配置项相关财务、能力和可用性等属性都要求从分离的不同部门输入，如果关键的利益相关者从一开始就没参与，如果他们不能得到CMDB能为组织交付的真正价值，那么要让他们支持一个包含所有必要的属性和关系的CMDB的建设会很困难。   因此，在CMDB项目的开始，就要努力获得关键的利益相关者的支持。要向他们表明，CMDB将会使得他们持续不断地改善相关指标和关键绩效指标（KPI），这样你就能得到所有相关方面的支持。   缺陷5:难以更广泛地实施   在项目开始之初就能对其进行有效的引导和控制，比如说一个被清楚定义的业务服务的实施，这对于项目的成功是关键的。首先要确定支持业务服务的配置项，如应用服务器、网络服务器、路由器、数据库和数据库服务器等，然后就要确定在这些配置项之间存着什么类型的关系，比如说是“依托运行”、“主机”、“连接”、“管理者”等。这些关系有助于理解和降低与组成服务的配置项的变更*相关的风险   一旦CMDB 按照这样的做法初步成功实施，企业就可以考虑扩展项目的范围，以一种有效且高效率的方式来管理更多的配置项。这种渐进的方法可以让企业迅速地实现价值，同时还会获得进行更广泛实施所需要的经验。   缺陷6：在流程和培训的投入上吝惜   CMDB的成败取决于使用和维护它的人，如果这个人没有经过合理使用和维护流程的培训，那么，CMDB将会是低效的，其中的内容很快就会变得过时和不准确。正确的培训也有助于确保一个成功的实施，以及一次值得付出的投资。   能够避免以上六个方面错误的企业将会安全地完成CMDB的实施，并提高成功的可能性。这意味着他们能以更低的成本为业务提供所需要的服务，同时还能确保这些服务在一个符合要求的绩效水平上运行。服务商与合同管理（待丰满）银华基金变更管理流程的设计和实施（缺数据待改写）ITIL流程管理简介ITIL(InformationTechnologyInfrastructureLibrary)是一套IT业界的服务管理标准库。20世纪80年代中期，英国中央计算机与电信局(CentralComputingandTelecommunicat-ionsAgency，CCTA)为了提高英国政府部门IT服务支持的质量，而把英国各界在IT管理方面成功的方法归纳起来，变成规范，为企业的IT部门提供一套从计划、研发、实施到运维的标准方法。ITIL是根据实践而不是根据理论开发的，它来源于实践，又被用来指导实践。但它只列出各个服务流程最佳目标、活动、输入、输出和流程间的相互关系，而没有说明具体的实现方法。具体的实现方法要求各企业根据自己的实际情况进行设计和持续改进。ITIL的核心流程中属于服务提供的有服务级别管理、财务管理、持续性管理、可用性管理、能力管理5个；属于服务支持的有事件管理、问题管理、配置管理、变更管理、发布管理5个；属于管理职能的有服务台1项。在一个企业中同时实施ITIL的所有管理流程是很困难的，企业只能根据自已的具体情况，优先选出可能见效最快的几个流程，取得成效后再逐步完善其它的管理流程。其中，变更管理强调对系统必需的变更有可控性，尽量减少对服务功能的影响，其基本思想与系统维护的要求相吻合，也是系统投产初期所需要的。因此，实现变更管理流程表1变更管理流程总结报表—按紧急度分类就能有效地对应用系统进行运行维护。 银华基金的变更管理流程的设计在进行变更管理流程设计时，主要进行以下3方面的工作：1)确定以下变更策略：变更对象分类策略、前导时间策略、变更窗口策略、影响度策略、紧急度策略；2)设计以下主要角色：变更请求者、变更受理者、变更审批者、变更实施者、变更经理、变更管理流程负责人；3)确定变更的主要活动和流程。银华基金设计的变更管理流程如下图所示：变更管理流程上图以点划线分隔的泳道为各个角色所承担的任务，方框表示各个活动，实线箭头表示流程的方向，双点划线箭头表示与配置管理的关系。某项活动跨越两条泳道，表示两个角色均能承担的该任务。变更管理流程的实施结果变更管理流程的实现工具由天汇帮助台的变更管理模块进行客户化实施后投入使用。至2009年2月5日，通过变更管理平台，共记录和处理变更434件（这部分数据要改写），没有由于变更造成系统服务的中断。变更管理流程的总结报表如下表： 从上表中可以看出，紧急度为高的变更所占比例太大。这主要是因为目前的应用系统还处于投产初期，应用系统的某些缺陷必须及时得到修复。随着应用系统趋于完善和稳定，这类变更的占比应该逐步降低。实施ITIL变更管理流程后，银华基金的维护方式实现了以下的几个转变：(1)技术导向转变为流程导向。将各种技术管理工作，主机管理、服务器管理、网络管理等，进行了适当的梳理，形成了典型的流程，便于将支持工作规范化，提高工作效率。(2)被动处理转变为主动预防。由于定义了标准的支持流程，各种支持活动准确记录，可以实现知识共享，并可以进行事件故障的分析，预测可能发生的故障，从而采取适当的措施，预防事故的发生。(3)统一接口，集成服务。由于明确定义了各种职责，IT组织内部分工协作，整合企业的资源，可以对外提供统一的、集成的服务。(4)由用户向客户转变，实现不同级别的服务。按照与不同客户签订的服务级别协议，为不同客户提供相应级别的服务。对于没有按规定时限完成的服务，可以进行升级，以获得更大的支持。结论（待改写）系统维护的目标是使计算机工程能更稳定、更持久地发挥其预期的作用。在银华基金实施变更管理流程后，可以有效地协调、配合、跟踪多个维护人员对系统不同部分的变更，保证了系统整体的服务能力，减少了对用户的影响。实践证明，实现基于ITIL变更管理流程可以对计算机应用系统进行有效的维护。银华基金IT服务统计报表——利用图形化的报表和度量标准跟踪时间、趋势和绩效TW5统计报表目录一．资产管理： 1．资产编目汇总可以根据资产分类，资产描述，P/N，资产子分类四个条件统计得出报表，报表可按不同的类别，资产，资产描述，子类别来分组排序。如：下图意为要生成资产分类为INFRASTRUCTURE的所有资产报表，并按资产描述排序。生成的报表结果为： 一．事件管理：1．事件摘要汇总可生成某段时间内时间，状态为打开或关闭的所有事件的摘要信息报表，报表可按员工，组，客户，公司，部门，紧急度，分类排序。如：下图意为要生2008年9月1日到2009年1月19日所有状态为关闭（C）的报表，并按员工分组排序。生成的报表结果为： 1．事件数量统计（日期）可生成某段时间内的报表数量，并按照一周内每天，一天内每小时，一年内每月，一月内每周，将报表分组。如下图意为要生成2008年9月1日到2009年1月19日的报表数量，并按一周内每天生成事件数量来分组：生成的报表结果为： 3．事件数量统计：可统计某段时期内各员工/客户/部门/服务/紧急度相关的事件总数，关闭/未关闭事件数和升级事件数，如下图表示要生成2008年9月1日至2009年1月19日所有员工相关的事件数量。 生成的报表结果为：4．事件数量统计（分类）：可生成某段时间内，某一个分类下各子分类的事件数量。如下图，表示要生成2008年9月1日至2009年1月19日分类“服务请求”下所有子分类的事件数量报表。 生成的报表结果为：一．工作单管理：1．工作单数量 可生成某段时间内时间，状态为打开或关闭的所有工作单的数量报表，报表可按员工，组，客户，公司，部门，紧急度，分类排序。如下图表示生成2008年9月1日至2009年1月19日期间的各员工的工作单数量：生成的报表结果为：1．工作单明细 可生成某段时间内特定的员工，工作组，支持方式相关的打开或关闭的工作单，并可按照员工，组，客户，公司，部门，紧急度，分类分组排序。如下图，表示生成2008年9月1日至2009年1月19日期间信息技术部的所有工作单明细，并按员工分组排序：生成的报表结果为：通过这些报表企业决策者能够深入了解企业服务、基础设施元素与服务接受方（客户）之间的各种关系 能够做到按月、按周、甚至按日统计生成在IT服务活动的详细报表；比如说服务使用了哪些IT元素；哪些客户正在接受服务——支持等级、服务时间和成本；谁正在内部管理服务；谁正在支持服务等；企业决策者能收集服务过程中的随机状态和周期报告，分析解决其中原因，而不是像过去一样只能凭感觉和实际经验去处理问题。天汇帮助台本身有数十个个预先内置的由著名的水晶报表生成的报表模版，可以使管理者很容易的度量出他们组织机构的生产效率，找出瓶颈点，文档化记录组织机构提供的服务水平等等。更重要的是，所有的报告都可以通过浏览器访问浏览，从而使管理者在任何地点都可以实施有效管理。在企业服务管理过程中，产生及时、可靠、准确、双方认可的报表，以支持决策制定和有效的沟通是非常重要的。IT服务报表（ServiceReporting）对银华基金IT服务中所有可衡量的方面，提供当前或历史的分析。银华基金公司信息技术中心关于规划实施基于ITSM/ITIL管理系统的深入思考 系统维护的发展阶段随着计算机在各个领域的推广使用，为满足各种业务需求，计算机软件本身已经复杂化。例如当年的PC操作系统，DOS3.3只需要一张软盘，后来的Windows98安装文件也不过300MB左右，但随后的Windows2000和WindowsXP都以GB计。应用软件复杂化的同时，更加剧了系统维护的复杂化。统计表明，系统维护成本占整个软件系统成本的70%。随着软件开发成本的不断提高，应用软件系统的维护成本也将大幅度地提高。由于应用软件系统是一个人机系统，其系统硬件及程序代码只是软件系统的一个组成部分。在整个应用软件系统的开发与运转过程中，管理人员、管理组织等起着决定性的作用。随着外部环境及内部环境的变化，任何组织不可能只在一种不变的管理模式下运转。而软件系统维护是保证软件系统同步与管理变化的基础。设备管理阶段这是系统维护的初级阶段。从计算机出现的那天起，就开始了系统维护的初级阶段—设备管理阶段。那时，计算机设备非常庞大和复杂，处理的任务又相对简单，因此系统管理的主要任务是管理计算机硬件设备，而且主要是采用人工方式进行，主要关注的是硬件管理。系统和网络管理阶段20世纪60年代，信息系统开始兴起，计算机在企业中的应用也越来越广泛，这时系统维护的任务除了硬件管理外增加了对信息系统本身的管理。到20世纪90年代，随着网络在企业内和企业间的不断普及，网络管理成了系统维护的重要工作，特别是Internet广泛应用以来，企业纷纷采用分布式的系统管理和网络管理。此时系统管理和网络管理已经融为一体，无法再作区分。这种系统维护方式一般是以本单位系统管理人员维护为主，是典型的以技术为导向的管理模式，将二线支持与维护外包给专业技术公司。这种系统维护是被动的工作模式，侧重于事故的解决和系统的恢复，也就是所谓的“救火队”。只有在事故或故障发生后，才能紧急处理或解决，每次处理都像一次“救火” 。传统的系统维护方式主要有以下的缺点：1)没有明确的职责。对于大型的系统，都不可能只由某一个人进行维护。在多人组成的维护团队中，由于没有明确的职责分工，每个人好像什么都管，又好像什么都不管。没有人对问题进行跟踪，许多问题到最后可能是谁都不管了。极易造成用户的投诉，影响服务满意度。2)没有事件优先级定义。由于没有定义事件的优先级，只能是先报告的问题先处理。这样不是对所有的用户都公平。3)无法衡量维护人员的绩效。管理人员不能准确考核维护人员的绩效，企业也无法衡量维护团队的效绩，无法评估在系统维护中的投入产出情况。4)没有对知识和经验进行整理和共享。由于没有对维护的知识和经验进行整理和共享，使得故障处理方法只由当时的维护人员掌握，事后他自己也可能忘记。相同的故障由不同的人员处理时还要从头开始，降低了工作效率。某些专业知识只被部分维护人员掌握，对企业的业务运作构成风险。5)无法进行故障的分析和预测。由于没有对故障进行记录和分类，无法对已发生的故障进行分析，不能采取措施避免同类故障的再次发生，也不能发现潜在的故障。6)没有对IT资产进行统一管理。由于没有对IT资产进行统一管理，维护人员不能快速了解系统组件的配置状况，发现故障后不能及时与相关厂商和用户沟通。随着企业应用系统的发展，传统的系统维护方式面临巨大的挑战，已经不能有效地对企业应用系统进行维护。因此，产生了基于服务管理的维护方式。基于ITSM/ITIL的IT服务管理的维护阶段IT服务管理将传统的系统维护支持作为一种IT服务的提供，对系统的维护转变成对IT服务进行管理，以IT服务管理的方式对复杂的现代企业应用系统进行有效的维护。按照国际IT服务管理论坛的定义，IT服务管理是一种以流程为导向，以客户为中心的方法，它通过整合IT服务和组织业务，提高组织IT服务提供和服务支持的能力。IT服务管理对内进行流程化管理，将各种支持活动流程化，有利于提高效率，计量绩效。对外则将各种维护支持活动打包成服务，有助于准确计量IT服务的价值。银华基金基于ITSM/ITIL的IT服务管理系统建设目标　　从目前来看，靠IT来推动基金公司的业务创新，是不靠谱的，做好运维保障才是IT部门工作之本。在这个行业，IT带来的创新余地其实并不大。基金公司之间的竞争主要是基金产品、业绩还有服务方面的竞争，IT部门的重要作用就是保障好和支撑住。像银华基金这种集群的、异构的、复杂的企业应用系统，其日常维护工作的复杂性、多变性很高。对如此复杂的业务应用环境进行运行维护，不可能由单个人采用手工或者半自动方式的维护手段来完成，必须由多人协作才能完成对系统的维护和支持，并且一定要有相应的绩效考核衡量标准。因此，为了运行维护这种系统，必须组建相应的组织、制定相关规章制度和设计相关的管理流程，必须采用先进的管理理念和方法和软件支撑工具，才能正确、高效地运行维护这些系统，使它们发挥其应有的作用。　　实施基于ITIL/ITSM的运维服务管理，软的比硬的更重要。自从06年开始，由于行情火爆，大量资金涌入金融市场，基金投资者暴涨。各基金公司都处于救火状态，带宽、服务器、负载均衡等设备一直在扩充，目前由于行情清淡的关系，带宽、服务器都能满足用户的业务支撑。08年8月份，奥运期间数据中心的一切变更需求停止，银华基金就开始通过这段行情清淡的时间在IT服务管理规范下进行业务流程、岗位职责，服务规范的梳理。比如 要求每个岗位每天都要对关键性设备、业务做出检查，还要检查包括交易、账户的资金资产、基金的资产有何变动，还有周边的辅助业务，网站、网上交易，客户电话，OA、邮件等系统的所有的业务状态。此外，和上海深圳交易所都有卫星的通讯，和深圳办公室、托管银行都有专线要求工作人员对这些业务线路、节点进行检查、写日志。数据中心内部，所有电源、UPS通信线路、电话网络、交换机、路由器，小型机、数据库的服务器状态也要进行逐项检查，产生相应日志。　　尽管原有每日检查项目、清算、备份、数据传输都有相应的记录规范，但并没有构成体系。　　银华基金的目标是利用成熟的ITSM/ITI工具软件平后对这些日志、事件完成记录、复核、监督、检验的机制，并形成年终业绩考核。这需要有很多评估报告，要对硬件系统、运维系统安全性、人员的任务完成率进行评估，需要ITIL服务管理流程的数据来进行支持。简单地说就是要打造一个适合基金行业特点和实践的IT运维服务平台，把企业在各个地区分布的运维服务团队，无论属于哪一个客户群的，无论是属于哪一种业务领域的（桌面、网络、系统、软件），都统一纳入到一个相同的平台上。他们要基于相同的制度，基于相同的流程，基于相同的理念，用统一术语与方式去服务客户。 　　基金证券行业的IT运维服务业务有其特点，以前依靠手工发布ISO20000的体系文件，对人员做扎实的培训，把IT人员的各种作业规范统一起来，不是说不可能，但极难。IT运维服务数据极难分析与采集，一个显而易见的方式就是利用现成的ITSM/ITIL工具软件。 　　银华基金在选择利用ITSM/ITIL工具软件打造自已的运维管理平台时主要有以下几个方面考量： 　　①设计要求：要基基金行业的IT运维服务业务特点，把以往的管理经验置入其中，比如同时纳入诸如ISO20000的实施所得。　　②范围要求：这个平台要能管理所有的运维对象（各种类型的项目），同时要管理运维资源（人）。运维对象可以具体到具体每一个CI及其备件，运维资源具体到每一个人的工时利用。其它像服务目录与SLA等，都要纳入管理。　　③质量要求：注意是应用质量，不是指功能。 系统架构的选择 　　选择利用ITSM/ITIL工具软件应该是B/S系统架构，这是为了方便地理分散的员工使用，也是考虑到日后全国的用户可能会登录系统进行部份作业，比如参与调查，或者开放论坛等。采用B/S的架构日后的升级维护比较方便，用户登录也很方便。系统流程控制 　　在系统流程控制方面，一般放弃了采用工作流引擎的想法，一是不增加使用复杂度，二是硬性的流程事实上不现实。因为在运维服务活动中，单据的流转方式很难硬性定义，加上一人担负多个角色，去配工作流没有太多意义；同时一旦运转起来后，去调整流程的可能性较低，那样工作流引擎存在意义就很低了。　　　软件只是一个汽车，你想它跑得更快更好，需要有一条道路去配合在一起，这条路就是你的管理制度。许多寄望软件实现的控制点，一旦没有考虑清楚，最后会带来许多麻烦。所以要有先松后紧的策略，逐步增加控制，而且要以制度为先。 网络监控管理工具与IT帮助台系统（运维管理系统平台）的差别随着运行在网络计算环境中的关键业务应用日见增多，企业客户对IT系统的管理需求正与日俱增。面对IT系统监控和IT运维管理市场的日趋成熟，形形色色的软件开发商和系统集成商和将目光瞄准了网络系统管理软件的开发和推广。纵观国内市场上的各种网络系统管理软件，按其产品的使用特征和部署架构，可以分为工具级产品和帮助台系统级产品两大类。　　一类是传统的网管软件厂商基于陈旧的NMS（NetworkManagementSystem）理念推出的各种网络管理工具和系统管理工具，另一类则是四大国际厂商所把持的大而全的IT系统管理平台，而摩卡软件公司新进推出的涵盖网络管理、IT服务管理、IT运维管理的三位一体化的综合IT运维管理平台正位列其中。　　一、工具与平台的定义：　　工具类软件通常是为了解决网络管理领域当中的某个具体的技术问题应运而生，仅仅是“头痛医头、脚疼医脚”式的管理，缺乏全面的IT运维管理视角，缺少流程化的事件处理机制和IT运维管理体系，也不提供企业级的统一管理门户，无法实现面向企业整体IT基础设施的全局化管理。　　平台级软件是遵循随ITIL的最佳管理实践，为企业用户提供基于IT运维流程、以服务为导向的业务服务管理和IT运维管理支撑平台，其产品功能涵盖了网络拓朴管理、设备管理、可用性管理、性能管理、配置变更管理、事件管理、告警管理、日志管理、网络流量管理和操作审计等方面，已大大超出最初的狭义网管软件的范畴，最终帮助企业的IT部门实现IT管理的规范化、流程化和自动化。　　二、工具与平台的区别：　　网络管理工具与运维管理平台的差别主要体现在产品的设计理念、管理领域、部署架构三个方面。　　首先在产品的设计理念上，工具类产品设计的出发点是用来分析网络系统当中出现的各种问题和故障现象。其产品的重在分析问题，而并不涉及问题征兆的提前发现和问题根源的彻底解决，无法为用户提供完整的IT运维处理流程的管理。平台级产品则是从IT运维管理工作的实际需求出发，面向事故和故障的发现、追踪、分析、定位，直到最终解决的闭环的处理过程。MochaBSM作为IT监控和运维管理的平台，使所有的事故处理和服务请求都形成了严格的闭环管理：在问题发生之前，尽可能通过潜在征兆进行事前预警；在故障发生之后，通过规范化的IT运维流程处理机制，使故障能得到及时、有效的处理，并可对问题处理的每一环节进行追踪。 　　其次在产品的管理领域上，工具类产品依然遵从传统陈旧的管理概念，从技术元素的角度出发，将产品分割为网络管理工具、系统管理工具、针对不同应用的管理工具、性能管理工具等。平台级产品则是建构在E-Tom国际标准的OSS模型之上，实现了ITIL流程框架下的经典管理流程，包括问题管理、事故管理、配置管理、变更管理、发布管理、可用性管理、服务水平管理、能力管理、可持续性管理等，而工具类产品的管理领域往往只能涉及其中的一个或几个方面，管理领域的局限性较大。　　再次在产品的部署架构上，工具类产品将数据采集、处理、展现等层次功能合为一体，没有做功能及界面拆分，无法实现真正的分布式部署。工具类产品在对IT资源的监控上，也没有管理模型的设计，用户在数据采集、信息处理、界面展现等方面有个性化要求，均需要大量的二次开发工作量。平台级产品由于采用了CMS（CentralMonitoringServer）、DMS（DistributedMonitoringServer）三层的分布式架构，支持管理架构的纵向与横向扩展，不仅可实现大规模网络节点的统一管理，当网络不同区域被防火墙分开时，也能实现管理数据的正常传输。在资源模型的设计上，平台级产品基于J2EE（Java2EnterpriseEdition）标准，采用面向对象技术，将所有管理资源作为管理对象(Object)，使用XML技术将管理对象的指标、事件、状态等特征抽象为可动态更新的、仿真真实对象的系统资源模型，为所有的被管理资源提供了统一的、相似的管理模式。MochaBSM通过资源模型的架构，可以使复杂网络计算环境中的众多被管理对象能够平滑地协同工作，屏蔽资源管理的复杂性和差异性。　　三、MochaBSM做为业务管理和IT运维管理平台的优势：　　MochaBSM作为企业级的综合IT运维管理平台，通过Portal的统一展现，对基础架构和应用系统进行全面监控；提供服务的端到端响应时间管理，可量化的衡量服务请求的响应时间和服务质量，从而不断改善用户体验；遵循ITIL流程框架，将IT运维工作纳入IT管理流程，帮助IT管理员从被动式响应向主动式服务转变，帮助IT部门把ITIL理论的优势落实到运维管理的实处；通过科学的报告报表分析，使用户能够可视的了解IT基础架构与业务服务之间的变化关系，最终建立业务服务管理，实现企业IT系统的持续优化和长期规划。　　基于综合运维管理平台在上述方面的特点，与工具类产品相比，MochaBSM集网络管理、IT服务管理、IT运维管理三位一体的管理平台，具有以下几方面的优势：　　1）开放的管理体系架构，便于系统扩展升级。　　基于Java2EnterpriseEdition(J2EE)开发，可以在Tomcat、Weblogic、WebSphere多种Java容器上运行。由于Java的跨平台特性，MochaBSM支持在Windows、Unix、Linux多种操作系统上安装运行，是国内唯一可在Unix平台上稳定运行的IT管理软件。　　采用标准JavaDatabaseConnectivity(JDBC)接口，系统数据存储支持所有主流数据库，包括MySQL5、Oracle9i/10g等。　　采用全模块化功能结构设计，使产品的管理平台具有良好的扩展性和可伸缩性，并可与Mocha产品家族的其它产品（如MobileAccess、MochaSearch等）进行集成，满足更为广泛的客户需求。　　2）从业务视角管理IT，实现业务运营与IT运维双赢。 　　通过Dashboard把企业各项业务系统与所依赖的IT组件(网络/主机/应用)和所相关的部门关联连一起，提供直观可视化的管理视图，有助于IT部门和业务部门的良性互动。业务发生故障时，业务管理员通过事件相关性分析能及时了解IT故障所影响的业务系统、所涉及的业务部门和故障严重程度；IT管理员通过事件根源性分析可以从大量的事件告警中排查故障根本原因，确定业务恢复时间。3）量身定制的IT运维管理，快速适应业务发展变化。　　MochaIT运维管理（MochaITOM）从人员、技术和流程三个方面提高企业IT运维管理水平，逐步建立并达到以下目标：　　标准化——基于ITIL流程框架，为企业构建最佳的IT运维流程和管理平台。　　流程化——提供可视化的流程及表单设计工具，将工单、表单与流程相绑定，确保运维工作流程均可正确流转及复用，提升运维工作效率。　　自动化——基于ITIL的流程框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，MochaBSM会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助管理员完成日常的重复性工作（如备份，杀毒等），提高运维自动化水平。　　4）监控信息的统一展现与首页的个性化定制　　MochaBSM作为第三代网管产品，采用信息门户技术，实现了管理过程中的三个统一：　　统一访问界面——采用了统一的界面及功能设计，用户只需掌握了一种资源在系统中的监控方法，即可触类旁通。通过SSO（单点登入）实现了用户多套管理系统的统一访问入口，无需用户使用多套帐号口令，增强了企业信息系统的安全性。　　统一资源管理——集成企业现有LDAP，提高现有系统的可复用性；提供用户管理以及权限信息，通过角色将页签访问权限与资源访问权限相关联，实现对系统的统一管理与维护。　　统一信息展现——整合第三方监控系统，提供覆盖所有监控内容的统一页面展现。所有监控管理均在MochaPortal中进行，省却了大量界面切换工作，提高了运维效率；针对不同角色的管理人员，提供各取所需的不同内容。比如为部门经理提供服务仪表盘，辅助IT决策，为IT管理员提供资源可用性与性能指标，确定资源状态。　　MochaBSM通过Portlets设定，可为系统首页定制不同展示视图和页面布局，满足各类角色的管理需求。系统内置丰富的Portlets（8种类别，30个可配置Portlets）供首页展示之用，可直接在系统管理中设置，无需二次开发。  银华基金的服务台管理 　　事件管理与服务台管理是不同的概念，前者是一种流程，后者是一种职能，事实上事件管理的许多操作是由服务台人员完成的，服务台本身并不存在流程（注意这是站在ITIL流程的层面），服务台管理本身也是一个独立的学问。　　　　多数人以为服务台作用是单点受理以及快速响应，但这更多只是手段不是目的。服务台并不一定在物理上坐在一起，它可以是多种多样的，一定搞清楚服务台的目的是什么，它为什么而存在。IT服务不同于其它的行业，当用户打电话到携程与招商银行的的服务台时，跟打电话到一个IT服务商是不一样的。携程与招行的服务是“大众”与“标准”的，他们的服务台基本可以做到你电话过去就能响应，而IT服务商的服务台通常做不到，为什么？  　　因为你的服务更具“纵深”，所以对你的服务台提出了更高的要求，让几个完全听不懂用户问题与需求所在的热线非常快地接到用户电话是没有任何作用的，响应的定义是什么？如果仅仅是接听了用户的请求，而不做任何反应，这不叫响应。 　　IT服务业的服务台不同于传统行业，用传统行业呼叫中心的做法去设立IT服务业的服务台，一般是行不通的。尤其当你的业务领域复杂时，可能虚拟服务台是一个不错的选择，没有一定的硬性标准，要根据自已实际的业务需要来。一个真正好的服务台，可以节省你的服务资源，而且可以更快把客户请求结束掉。 基于ITSM/ITIL最佳实践的事件管理事件管理是创建、处理事件的模块，一个事件的生命周期全部会在此模块内。事件记录在整个事件生命周期中保持最新是很重要的，这样使所有支持人员都能看到当前正在发生的事情、谁当前正在处理该事件，以及先前曾尝试过什么和发现了什么。最新的记录还允许任何被联系的人员为请求发起者提供进度更新。让客户了解最新的进度情况是直接影响客户满意度的重要因素。更新应该定期提供，具体取决于事件的优先级。例如，高优先级事件可能需要每小时的更新，而中优先级事件每日接收更新，低优先级、长时间处理的事件需要每周甚至每两周的更新。银华基金在实施ITIL时仔细设计规划了以下的基础信息： ①事件的类型：事件管理在我们规划中，是一个非常重要的窗口模块。事件类型可以分为有故障、请求、咨询、新需求、投诉，基本上面向客户的事务都会在此发起，这种类型也是为了日后的统计分析。一级分类二级分类三级分类紧急度公司领导　　二级服务请求OA系统请求OA系统人员及权限变更五级OA流程调整请求五级投资交易系统请求交易系统人员及权限变更三级交易系统密码变更三级交易系统临时授权三级席位开设及撤销五级席位交易量信息五级其他交易系统请求五级CRM数据提取　三级办公区电子设施服务　五级电话系统服务请求　五级域用户管理服务请求　四级邮件系统服务请求　二级网站系统服务请求　二级客服坐席服务请求　二级深圳地区服务请求　五级 文档请求　五级软件系统升级交易系统升级三级TA系统升级三级直销系统升级三级估值系统升级（共同基金）三级估值系统升级（年金专户）三级估值系统升级（QDII）三级其他系统升级三级硬件升级　五级其他服务请求　五级故障申报业务系统故障投资交易管理系统O3.2一级登记过户管理系统三级直销管理系统三级网上直销系统一级基金估值系统（共同基金）三级基金估值系统（年金专户）三级基金估值系统（QDII）三级TA资金清算系统三级办公管理系统OA二级CRM客户关系管理系统三级公司网站二级公司邮件系统二级客户服务系统callcenter二级行情系统一级股票库系统三级报表中心三级QDII业务系统三级研究报告管理系统三级咨讯系统(万德数据库)三级咨讯系统(朝阳永续)三级咨讯系统(中经)三级咨讯系统(北方之星)三级PROP平台二级代销机构数据交换平台二级深证通平台二级客服邮件系统三级网站DNS一级F10巨灵信息接收三级电话交易系统二级办公上网一级视频会议五级短信息发送平台二级域管理系统四级 安全防护系统四级办公网防病毒系统四级交易网防病毒系统四级办公网补丁管理系统四级交易网补丁管理系统四级日志管理系统四级ITIL系统四级数据备份四级其他业务系统四级基础设施故障英飞系统四级语音系统一级卫星系统一级地面专线一级空调系统一级广播及背景音乐五级消防系统五级门禁系统五级视频会议五级其他基础设施五级硬件设备故障小型机一级PC服务器一级IPS一级路由器一级交换机一级防火墙一级WSD一级LINKPROOF一级垃圾邮件服务器一级HUB四级网络监控系统（NETGAIN)四级同程灾备四级异地灾备四级其他硬件设备四级桌面管理硬件及外设事件主板事件五级内存事件五级显卡事件五级硬盘事件五级接口松动五级无线网卡五级BIOS事件五级显示器事件五级打印机事件五级复印机事件五级 传真机事件五级扫描仪事件五级笔记本电池事件五级调制解调器事件五级光驱与光盘事件五级声卡与音响事件五级其他五级应用系统事件输入法事件五级安装驱动五级播放器事件五级连接打印机五级办公软件事件五级打印机软事件五级安装杀毒软件五级杀毒软件冲突五级邮件系统事件五级安装其他软件五级OA、COA事件五级安装网络打印机五级邮件客户端事件五级人为操作、指导用户五级打印机、复印机夹纸五级其他五级操作系统事件运行慢五级IE事件五级频繁死机五级系统补丁五级鼠标事件五级蓝屏/黑屏五级备份数据五级虚拟内存不足五级恢复操作系统五级更新操作系统五级USB无法识别五级指定的路径不存在五级系统无法正常启动五级桌面图标消失或无法打开五级安装操作系统及相关软件五级其他五级网络事件线路事件五级交换接口五级更换网段五级客户端事件五级 IP地址冲突五级入网验证事件五级其他五级病毒事件木马类五级蠕虫类五级恶意软件五级多种类别五级IE进程病毒五级系统注册表病毒五级其他五级新业务需求　　五级无分类　　五级 　　②事件的分类组别：由于项目众多，考虑到横向统计的需要，今后可能还需要进一步定义一个公用的事件分类，以便运维管理分析。比如可以划分为：硬件、软件、网络、数据库、接口、业务这几个大类组别，日后可能会进一步细化分类，以便做更深入的分析，但这个难度很大，需要时间的积累。 　　③事件的紧急度：按ITIL思想应该引入优先级（严重度与紧急度），但实施中发现这样定义非常困难，对指导工程师处理意义不大，还可能会误导信息，所以银华基金最后把事件硬切为5个紧急度等级。给出最粗的定义标准，然后由每个项目具体定义解释。这样每个工程师在作业时，就可以定义事件的等级。默认情况下，紧急度等级越高的事件，表示越严重，也表示要优先处理。虽然会相对粗放一些，但简单适用，而且可以在今后把SLA与此相关。 ④事件的状态：事件状态是为了表达事件单当前的处理状况，比如可以分为：创建、分派中、处理中、等待中、解决、关闭。这样可以形成看板与统计。状态编号状态属性状态描述新收到。o事件已记录，但是可能还需要澄清。已接受。o事件已记录，但是可能还需要澄清。已分配。o事件已分配给问题解决小组，并正在等待解决。活动或进行中。o解决事件的操作正在进行中等待证据。o操作已在等待获得附加证据时临时停止。已计划。o在到达计划的时间之前不能执行进一步的操作。挂起或中断。o操作已临时停止，直至某个事件或时间的到来。 已解决。c事件被认为已解决。服务台需要在终结事件之前与请求发起者确认解决方案。如果请求发起者对解决方案不满意，则将状态重置为“已分配”或“活动”。已终结。c请求发起者已验证事件得到解决，因此该事件已被终结。 　　⑤事件与CMDB的关联：CMDB的用处，在事件的应用就相当关键。事件发生时，要做一个关键动作，就是组件定位。需要搞清楚这个事件是发生在什么项目（CI）的什么地方（CI），需要事件创建者做出定位；然后派单时，根据你的CI定位，带出相关的责任工程师，与事件与CI的关联，给你的运维分析带来丰富的信息。你CMDB所有的信息与事件的信息可以交叉统计分析，比如上面说的事件的分类有硬件，那我想知道桌面项目一年中，硬盘发生了多少故障？希捷品牌的硬盘发生了多少故障？客户对哪一款软件的咨询次数最多？这些信息依靠事件中的组件定位，可以轻而易举告诉你。 ⑥事件与其它流程的接口：事件与变更、问题、知识库是存在接口的，比如事件处理过程中可以直接发起变更申请。（如下图） 事件管理可以和系统网管集工具等集成接口，如与银华基金目前使用的netgate网管软件及英飞整体机房解决方案等，这些工具和系统产生的报警日志可以自动转化为帮助台中的事件由特定的工程师去处理。　　⑦事件的时长与工作量： 在任何一个事件的处理时，对于时间有二个概念，一是事件的时长，即一个事件的处理周期（从8：00创建到12：00解决，4小时）；一是事件花费的资源量，即工作量（4小时的时长中，工程师可能投入了2小时来处理）。时长是为了SLA的计算，后者是为了运维资源的分析。 ⑧统计分析：银华基金利用天汇帮助台中的报表模块实施的事件报表的统计分析非常丰富，可以从CMDB的角度出发，去统计每一个项目、每一个设备的事件情况；还可以从客户的角度出发，统计某个客户组织或某个客户的事件情况；还可以从运维组织的角度出发，统计一个服务团队或一个服务人员的事件情况；可以从事件本身的信息出发，根据事件的类型、分类、等级、状态、来源（电话、邮件、WEB）去统计，还可以统计SLA方面的数据。天汇帮助台中预先内置了超过45个由著名的水晶报表生成的报表模版，可以使银华基金的IT管理者很容易地度量出他们组织机构的生产效率，找出瓶颈点，文档化记录组织机构提供的服务水平等等。更重要的是，所有的报告都可以通过浏览器访问浏览，从而使管理者在任何地点都可以实施有效管理。  系统化的“治本”方略——问题管理 　　问题管理处理逻辑其实是类似事件的，它的许多信息是继承事件，比如等级与类型等。在规划问题管理时，要想清楚问题的分类等级等信息跟事件是什么关系，问题管理的大概作业界面有哪一些，在系统流程上有哪几个步骤，如何留下问题的处理时长与工作量等等。　　还要想清楚问题与事件在程序处理上的区别，比如问题的创建后需要有一个审批的动作，问题不服从SLA，问题有知名错误的概念，这一部份的设计如果你的事件规划好后，问题管理是相对简单的，它的难不在于程序，而在于日后的应用。　　问题的统计报表，基本上与事件的纬度类似。 　变更管理 　　在ITIL中，变更与发布是两个独立的流程，根据银华基金的最佳实践把这两个流程合并为一个。事实上发布的控制在程序中可以实现的控制点是很少的，而且它与变更是紧密衔接的。在银华的最佳实践中中，变更的实施就是发布流程，即发布被理解为是变更的一个子流程。发布不仅仅是针对软件的，硬件一样也会有发布的概念，比如将一台新设备布署到生产环境中。　　对CMDB的控制，在银华基金业务层面全部需要通过变更来实现，CMDB实施的精确度很大程度上取决于变更的执行情况。为了让CMDB的信息更新得到有效控制，审批变更申请时，不光是审批变更的行为和内容；更重要的是审批变更执行后，是否根据变更的行动和内容信息把CMDB做了相应的更新。这样可以相对减少没有约束的对CMDB更新的行为。 　　变更管理的主要目的除了实现对CMDB的维护控制，另一个主要目的是授权与控制对影响基金正常业务的基础架构或其它服务的改变。 当工程师对具体设备做维护时，事实上你已赋予他改变基础架构的权利了，如果他把生产环境中的CI做了改变，就必须控制他及时对CMDB的更新，最后给予一个通道让他直接维护CMDB，但由变更审批人事后审核的做法简化了配置管理流程。　最具变更管理和配置管理代表性的业务情形如：要对一段网络做调整，但可能会影响到几个业务系统，这时需要发起变更申请，由涉及到的几个业务项目的责任人与网络领域的主管一同做变更的评估。如果认为有方法对应，可以进行此次变更的话，需要制作一个变更的实施方案，安排人员实施调整操作。实施完成，把CMDB中的信息更新。　　变更管理的统计报表，可以从发起源统计，可以从CMDB的角度发起统计，也可以从变更本身的信息进行统计，比如变更的状态、变更的分类、变更的人员等。 　资产与配置管理　　配置管理模块，核心的就是CMDB，银华基金在配置管理的流程层面的一些实施要点如下： 　　CMDB的审计：CMDB审计是需要规划好的，应该可以根据各种条件审计，比如根据某一类的业务组件，某一个业务系统的组件，还可以确定一定的数量进行审计（随机抽取），也可以决定一定的比率（随机抽取）。审计的目的是为了检查CMDB的数据正确情况，找出问题并修正。　　CMDB的锁定：CI在某些情况需要进锁定，比如变更时，比如审计时。为什么要这样呢？如果你对一个CI变更时，不锁定这个CI的信息，会发生几个地方同时对这个CI做信息更新，由于时间差，很可能把错误信息更新到CMDB中了；同时用户在变更过程中调用CI信息的话，也会发生误导。所以需要控制单线程对CI进行维护，在同一时间只能有一个对CI维护的动作进行。审计也是一样，如果你审计开始时，这个CI信息一直在动态变化，不锁定CI的话，审计无法进行，同时会审计出一个错误的结果。　　在天汇帮助台中配置管理的信息可以被许多模块调用，比如可以关联到事件、问题、变更、日常操作等功能模块中。CMDB的人机界面很方便调用、查询、操作。   预防性维护及日常操作管理 　　预防维护及操作管理为了处理那些非事件、问题、变更等事务，比如机房巡检、定期的机器清洁、检修。操作管理可以创建作业，作业的来源有两种来源。一种是直接创建的，比如临时要对一台设备做检测；一种是根据周期性作业计划产生的，比如服务器每日要检查数据文件、表空间使用情况、JOB运行情况、操作系统日志。操作管理与能力管理中的监视计划存在许多联系。　　通过天汇帮助台的预防性维护功能模块，银华基金可以对关键业务、设备及资产定义周期性的预防性维护计划及日常操作工单。比如服务器巡检，如果每4小时需要做一次，那么每周要做5*2次巡检，这个次数是事先定义好的。 每个业务项目的服务日历可能不同，每个业务 项目都可能存在一个服务日历。根据这个服务日历，可以在天汇帮助台系统中制作出一个周期性的预防维护计划，系统根据服务日历与计划内容，每天提前生成出作业指令给工程师。计划上还定义了标准的工时要求与作业要求，工程师每天把这样指令做完，然后把相关的作业关闭，并留下相应的实际工时，这就是操作管理的核心。预防性维护模块的设计是用来帮助针对关键资产,服务的维护保养时间表、维护保养的实施执行以及维护保养的服务记录进行管理。系统管理员将定义预防性维护的动作及时间表。预防维护的基本原理是首先定义一个预防维护动作,即维护所需要执行的动作,步骤和成本等；再定义一个预防维护计划,即为已定义的维护动作指定资产或服务,表示对该项资产或服务进行维护,并为其设定维护时间,周期,和执行维护工作的员工.而后,系统会自动按时生成预防维护工作单,分派给这个员工。选择相应的预防维护动作 在天汇帮助台中定义维护动作银华基金利用天汇帮助台定义的维护计划 由预防维护计划生成的预防维护工作单，自动分派给员工“秦鹏”预防性维护模块的主要功能点有制作计划、创建作业、作业处理、作业关闭、统计分析，这个模块可以把除事件、问题、变更之外的工程剩余活动有效管理起来，而且可以保证银华基金的日常服务作业得到强制执行。它可以针对每一个批量计划做分析，分析执行如何，花费了多少服务资源。要注意的是操作管理与事件管理没有程序接口，就是说如果工程师在巡检时发现故障，需要手工在事件管理创建事件，而不是自动去触发事件。 　利用天汇帮助台的事件/工单机制进行任务管理 　　任务管理的是为了管理企业的管理资源，一般可以针对公司自身的运维管理特点设计的。比如每年企业做许多管理改善的工作，做很多培训，开许多会议，可以分析一下花在管理上的资源是多少，希望把管理工时与直接生产工时做一个比率分析。这是管理效率提升的非常重要的基础数据。　　比如领导要求各个领域开展员工能力提升活动，在任务管理中，只需要主管生成一个任务事件，然后再该事件下建立任务工单派给各个业务主管，任务工单中标明要求完成的时间点；每个业务主管接到各自的任务工单就可以展开作业，作业过程的记录与工时会不断增加在这个任务工单的明细中，一直到完成审请关闭时；当每一个子任务工单都关闭时，父任务 事件就可以关闭，统计出花费的资源情况，这样任务就可以通过一个事件多个工单的结构多层分解，工单可以分解到每一名员工身上。这可以加强任务的控制力度，也会控制管理人员过度使用资源。　　任务管理更多是为了管理者的工作而设计的，这也是运维服务作业中最后一块没有被记录的话动。这样下来后，事件、问题、变更、操作、任务就构成了任何一个运维服务人员，无论他是领导还是一线员工的作业平台，只有监视所有的活动，其资源使用才被全部监视。　　任务管理的报表有针对任务执行情况的，还有横向分析任务类型的，即任务的资源占用情况。如果数据积累足够多时，这种分析展开，会让我们非常吃惊，因为运维服务的大量资源是被无效使用的。这样运维服务管理才有改善的方向与具体指标。 　知识库管理 　　知识库管理考虑现实情况，运维服务的知识有较强的时效性，更新较快。这里说的知识是针对故障处理方面的，并不是指员工的技能或知识培养方面，这与通常说的KM有不少区别。　　运维过程中的知识非常具有针对性，所以没有把通用的知识纳入考虑，都是从项目的角度提出来。知识的创建有三个来源，事件生成、问题生成、手工创建。无论知识是从事件或问题或手工创建，都会有一个审批的过程控制知识库的更新，还可以设置知识有效期限。另外，知识库的创建可以做一些统计与分析，看哪一个团队的知识复用较多，哪一种类型的知识较多。对于知识的利用，不建议纳入系统考虑，因为在软件中难以识别，靠点击意义不大。一个人打开知识看后，可能发现根本不是他想要的，或者他只是借鉴看一下，这时强迫按钮操作没有意义。通过专人分析整理问题知识库，迅速沉淀经验和知识。坚持每天记录发生的问题，隔段时间再进行归纳总结和分类，确实工作量很大，但是从长远来看，一个优秀的知识库才是一劳永逸的方法，把以前发生的众多问题进行归纳总结，找出规律对号入座，同时总结经验不断丰富。其实无论什么公司，员工对IT的需求都有一定的共性。只处理不分析、不总结、不改进的IT永远只能是重复劳动。而如果通过引入问题管理，建立一个知识库，将众多问题归纳总结，重要的是找出深层次的原因，包括现实的原因和潜在的原因。当发现更好的或新的应急措施时，及时记录更新在系统之中。这样不仅提高了效率，而且当经验积累到一定程度以后，将大大减少日常的工作量，IT服务人员的工作将变得越来越轻松。这时的“救火队”，就演变成“消防队”，从而做到主动预防，而不再是被动应付。加强公司各业务部门之间知识管理，提高运维效率。企业IT运行维护工作中经常有这样一种现象，同样的问题出现多次，若不注意沟通，每个人都会化很多时间来处理同样的问题，知识与技能可能只停留在每个人的头脑中，达不到知识共享；技术人员对于出现的问题忙于解决，而无暇去分析故障及问题产生的原因、或进一步优化的方法，只是被动地进行维护。随着银华基金业务发展，应用系统增多，工作量加剧，维护质量呈下降趋势。更严重的是，遇到晚上进行日终处理，值班人员碰到无法解决的问题时，会在深更半夜四处打电话寻找其他技术人员支持。技术人员的辛苦与怨言可想而知。 通过知识管理降低人员流动带来的损失。另外，人员流动对运行维护工作也带来了很大的难题，产生巨大的压力。通过配置项管理中的知识库管理，为我们解决了以上的难题，技术人员将工作中碰到的问题进行归纳整理，录入到知识库中，通过知识的积累与共享，使得值班人员能很方便地找到一些共性问题的处理方法，不但加快了解决问题的时间，而且减少了二线人员的工作量。根据系统中提供的事件管理与问题管理，IT部门定期对天汇帮助台中记录的事件、问题进行归纳整理，提出优化解决的方案，从而从根本上消灭问题，大大地提高了维护质量，响应速度进一步加快，实施后，连部内岗位轮换也变得较为容易。通过知识管理实现局部向全员主动管理的转变。如果说以前的银华基金IT服务还是IT部门一家的事情，那么实现了充分的知识共享和管理之后，IT部门逐渐将成熟的、通用的经验通过天汇帮助台的自助服务模块公布于企业的公共平台，就可以将部分有固定解决方法的常见问题分派给各部门自行消化解决。这样就从另一方面缓解了IT部门人力资源紧张的问题，并逐渐形成公司内部全员主动积极维护IT系统的良好文化，真正提高企业整体信息系统维护的水平。 　满意度调查管理 调查管理是要改变以前手工发邮件采集满意度调查的做法，利用天汇帮助台的满意度调查模块可以对象化，做得更灵活：可以设计许多问卷，可能是针对客户满意度的，可能是为了调研我们的服务方式改进方向的，也可能是为了解服务产品化的潜在空间的。问卷设计好后，可以生成调查任务，一个问卷可以被无限调用，而调查结果是针对调查任务而不是针对问卷的。可以使用天汇帮助台的客户满意度模块来生成一些由客户来填写完成的客户满意度调查，这些客户满意度调查可以向银华基金的服务支持团队提供许多有价值的满意度信息。满意度调查可以通过客户、分类、紧急度、员工以及员工组模块触发，或者也可以根据你的需要来触发满意度调查。一旦事件或工作单记录被关闭，天汇帮助台的客户满意度模块允许你根据存储在一个事件或工作单中的信息来设计并发送一些客户满意度调查表单。　　调查将直接发送超链接到客户邮箱（取自客户数据）。调研结果由系统自动生成。如果结果低于事先设定的预期值，系统将自动发送报警信息到相关人员处理。恰当和有效的事故升级机制升级 如果某一事件不能在规定的时间内由一线支持小组解决，那么再多有经验的人员和有更高权限的人员将不得不参与进来。这就是升级，它可能发生在事件解决过程的任何时间和任何支持级别。 升级分为职能性升级和结构性升级。两者的区别如下： 职能性升级（functionalescalation 又称为水平升级，技术升级）：职能性升级意味着需要具有更多时间、专业技能或访问权限（技术授权）的人员来参与事件的解决。这种升级可能会超越部门界限而且可能会包括外部支持者。  结构性升级（Hierarchicalescalation又称为垂直升级、管理升级）：结构性升级意味着当经授权的当前级别的结构不足以保证事件能及时、满意地得到解决时，需要更高级别的机构参与进来。 关于职能性升级和结构性升级可以举一些例子。例如：一个用户无法远程登录server。那会是什么原因呢。可能是网络不通。可能服务没起。网络组负责下三层。系统组负责系统。而应用组负责其应用。这些人可能会共同参与进来。而且还可能有些资深的专家进入。这些是职能性升级。搞了二天没搞好。用户投诉到老总。老总出面向用户解释。并承诺对无法使用的时间进行双倍的赔付。那这里就出现了结构性升级。应避免的结构性的升级。  恰当和有效的事故升级机制对事故的成功处理至关重要　　　在一般情况下，我们应该优先使用职能升级。只有在某些关键时间内事故不能即及时解决时才考虑使用层次升级。如果是后一种方式，最好尽可能早于服务级别协议规定的时间开始有关行动，比如外聘专家。　　恰当和有效的事故升级机制对事故的成功处理至关重要，同时也对服务支持能力的有效提高相当关键。如果升级太迟或者升级层次不够，就有可能导致IT服务延迟，不能满足服务级别的要求。另一方面，如果升级过快或过度，又可能导致服务支持资源的浪费，同时减少设立一线支持、二线支持和三线支持的作用。  事件管理经理对事件管理流程负有全部责任，他的目标是要为满足一个事件的职能性升级的需要做好预备工作，以避免结构性升级的发生。 1线、2线和N线支持   事件的处理流程线路是由所需要的专业级别、紧急度和权限等因素决定的。1线支持（也称为第1层次支持）通常由服务台来提供；而2线支持则通常由管理部门提供；3线支持则多由软件开发人员和系统结构人员提供；4线支持由供应商提供。公司（组织）越小，则可供升级的级别数就越少。在较大的公司（组织）里，事件管理经理可在相关部门指定故障协调人来支持自己的工作。例如，协调人在整个事件管理过程与处于各线的支持机构之间可充当接口的角色。每一个协调人协调他本身所在的支持团队。 有时候一个公司里的IT帮助台既接听电话回答用户咨询，又在无法通过电话沟通时亲自上门去给用户提供服务。还需要做回访等工作。那这里的级别数就很少。而在一些大些的公司中，先是呼叫中心来过滤和分类后发给服务台，由服务台来进行第一级的排除故障和跟踪事态的发展。无法解决可能会发给后续部门上门服务。或是发给研发去解决更专业的故障。研发也可能会就一些问题去询问厂商得到答案。建议建立接口人。接口人对自己的团队负责。 例如有时服务台需要找人上门服务。于是准备派单到下面的上门服务工程师。而工程师有若干个。个个推诿不愿去。造成了时间上的延误。可以设立接口人。工单都派到他手上。至于怎么分配。分配给谁。有内部来解决。接口人也可以由这几个人轮流担任。银华基金的事件升级设计： 一级分类二级分类三级分类紧急度一线升级提前提醒时间一线升级时间二线人员网上直销系统一级3分钟0:30:00周南投资交易管理系统O3.2一级3分钟0:30:00盛洪宁行情系统一级3分钟0:30:00盛洪宁网站DNS一级3分钟0:30:00周南办公上网一级3分钟0:30:00盛洪宁语音系统一级3分钟0:30:00周南卫星系统一级3分钟0:30:00周南地面专线一级3分钟0:30:00周南空调系统一级3分钟0:30:00李海平小型机一级3分钟0:30:00周南PC服务器一级3分钟0:30:00盛洪宁IPS一级3分钟0:30:00周南路由器一级3分钟0:30:00周南交换机一级3分钟0:30:00周南防火墙一级3分钟0:30:00周南WSD一级3分钟0:30:00周南LINKPROOF一级3分钟0:30:00周南垃圾邮件服务器一级3分钟0:30:00周南公司领导　　二级10分钟1:00:00周南邮件系统服务请求　二级10分钟1:00:00周南网站系统服务请求　二级10分钟1:00:00周南客服坐席服务请求　二级10分钟1:00:00周南办公管理系统OA二级10分钟1:00:00周南 公司网站二级10分钟1:00:00张勇公司邮件系统二级10分钟1:00:00周南客户服务系统callcenter二级10分钟1:00:00周南PROP平台二级10分钟1:00:00盛洪宁代销机构数据交换平台二级10分钟1:00:00李海平深证通平台二级10分钟1:00:00盛洪宁电话交易系统二级10分钟1:00:00周南短信息发送平台二级10分钟1:00:00张勇交易系统人员及权限变更三级20分钟2:00:00周南交易系统密码变更三级20分钟2:00:00周南交易系统临时授权三级20分钟2:00:00周南CRM数据提取　三级20分钟2:00:00周南软件系统升级交易系统升级三级20分钟2:00:00周南TA系统升级三级20分钟2:00:00周南直销系统升级三级20分钟2:00:00周南估值系统升级（共同基金）三级20分钟2:00:00周南估值系统升级（年金专户）三级20分钟2:00:00周南估值系统升级（QDII）三级20分钟2:00:00周南其他系统升级三级20分钟2:00:00周南登记过户管理系统三级20分钟2:00:00周南直销管理系统三级20分钟2:00:00周南基金估值系统（共同基金）三级20分钟2:00:00周南基金估值系统（年金专户）三级20分钟2:00:00周南基金估值系统（QDII）三级20分钟2:00:00周南TA资金清算系统三级20分钟2:00:00周南 CRM客户关系管理系统三级20分钟2:00:00周南股票库系统三级20分钟2:00:00周南报表中心三级20分钟2:00:00张勇QDII业务系统三级20分钟2:00:00盛洪宁研究报告管理系统三级20分钟2:00:00周南咨讯系统(万德数据库)三级20分钟2:00:00张勇咨讯系统(朝阳永续)三级20分钟2:00:00周南咨讯系统(中经)三级20分钟2:00:00周南咨讯系统(北方之星)三级20分钟2:00:00周南客服邮件系统三级20分钟2:00:00张勇F10巨灵信息接收三级20分钟2:00:00盛洪宁域用户管理服务请求　四级40分钟4:00:00周南域管理系统四级40分钟4:00:00周南安全防护系统四级40分钟4:00:00周南办公网防病毒系统四级40分钟4:00:00周南交易网防病毒系统四级40分钟4:00:00周南办公网补丁管理系统四级40分钟4:00:00周南交易网补丁管理系统四级40分钟4:00:00周南日志管理系统四级40分钟4:00:00周南ITIL系统四级40分钟4:00:00周南数据备份四级40分钟4:00:00周南其他业务系统四级40分钟4:00:00周南英飞系统四级40分钟4:00:00周南HUB四级40分钟1:00:00周南网络监控系统（NETGAIN)四级40分钟4:00:00周南同程灾备四级40分钟4:00:00周南异地灾备四级40分钟4:00:00盛洪宁其他硬件设备四级40分钟4:00:00周南OA系统请求OA系统人员及权限变更五级80分钟8:00:00周南五级80分钟8:00:00周南 OA流程调整请求席位开设及撤销五级80分钟8:00:00周南席位交易量信息五级80分钟8:00:00周南其他交易系统请求五级80分钟8:00:00周南办公区电子设施服务　五级80分钟8:00:00周南电话系统服务请求　五级80分钟8:00:00周南深圳地区服务请求　五级80分钟8:00:00周南文档请求　五级80分钟8:00:00周南硬件升级　五级80分钟8:00:00周南其他服务请求　五级80分钟8:00:00周南视频会议五级80分钟8:00:00李海平广播及背景音乐五级80分钟8:00:00李海平消防系统五级80分钟8:00:00李海平门禁系统五级80分钟8:00:00李海平视频会议五级80分钟8:00:00李海平其他基础设施五级80分钟8:00:00李海平桌面管理硬件及外设事件主板事件五级80分钟8:00:00秦鹏内存事件五级80分钟8:00:00秦鹏显卡事件五级80分钟8:00:00秦鹏硬盘事件五级80分钟8:00:00秦鹏接口松动五级80分钟8:00:00秦鹏无线网卡五级80分钟8:00:00秦鹏BIOS事件五级80分钟8:00:00秦鹏显示器事件五级80分钟8:00:00秦鹏打印机事件五级80分钟8:00:00秦鹏复印机事件五级80分钟8:00:00秦鹏传真机事件五级80分钟8:00:00秦鹏扫描仪事件五级80分钟8:00:00秦鹏笔记本电池事件五级80分钟8:00:00秦鹏调制解调器事件五级80分钟8:00:00秦鹏光驱与光盘事件五级80分钟8:00:00秦鹏 声卡与音响事件五级80分钟8:00:00秦鹏其他五级80分钟8:00:00秦鹏应用系统事件输入法事件五级80分钟8:00:00秦鹏安装驱动五级80分钟8:00:00秦鹏播放器事件五级80分钟8:00:00秦鹏连接打印机五级80分钟8:00:00秦鹏办公软件事件五级80分钟8:00:00秦鹏打印机软事件五级80分钟8:00:00秦鹏安装杀毒软件五级80分钟8:00:00秦鹏杀毒软件冲突五级80分钟8:00:00秦鹏邮件系统事件五级80分钟8:00:00秦鹏安装其他软件五级80分钟8:00:00秦鹏OA、COA事件五级80分钟8:00:00秦鹏安装网络打印机五级80分钟8:00:00秦鹏邮件客户端事件五级80分钟8:00:00秦鹏人为操作、指导用户五级80分钟8:00:00秦鹏打印机、复印机夹纸五级80分钟8:00:00秦鹏其他五级80分钟8:00:00秦鹏操作系统事件运行慢五级80分钟8:00:00秦鹏IE事件五级80分钟8:00:00秦鹏频繁死机五级80分钟8:00:00秦鹏系统补丁五级80分钟8:00:00秦鹏鼠标事件五级80分钟8:00:00秦鹏蓝屏/黑屏五级80分钟8:00:00秦鹏备份数据五级80分钟8:00:00秦鹏虚拟内存不足五级80分钟8:00:00秦鹏恢复操作系统五级80分钟8:00:00秦鹏更新操作系统五级80分钟8:00:00秦鹏USB无法识别五级80分钟8:00:00秦鹏指定的路径不存在五级80分钟8:00:00秦鹏系统无法正常启动五级80分钟8:00:00秦鹏桌面图标消失或无法打开五级80分钟8:00:00秦鹏安装操作系统及相关软件五级80分钟8:00:00秦鹏其他五级80分钟8:00:00秦鹏 网络事件线路事件五级80分钟8:00:00秦鹏交换接口五级80分钟8:00:00秦鹏更换网段五级80分钟8:00:00秦鹏客户端事件五级80分钟8:00:00秦鹏IP地址冲突五级80分钟8:00:00秦鹏入网验证事件五级80分钟8:00:00秦鹏其他五级80分钟8:00:00秦鹏病毒事件木马类五级80分钟8:00:00秦鹏蠕虫类五级80分钟8:00:00秦鹏恶意软件五级80分钟8:00:00秦鹏多种类别五级80分钟8:00:00秦鹏IE进程病毒五级80分钟8:00:00秦鹏系统注册表病毒五级80分钟8:00:00秦鹏其他五级80分钟8:00:00秦鹏新业务需求　　五级80分钟8:00:00周南无分类　　五级80分钟8:00:00周南IT运维帮助台系统平台与内部业务系统（OA、邮件、短信平台等）、监控工具（Netgate、英飞系统等）的无缝整合