IT系统的介绍

从IT系统实施到系统上线，经历了漫长辛苦的过程。好不容易实施结束，以为可以休息一段时间了，谁知日常运维工作却越来越多，让他疲于奔命。一直以来，公司把IT专项资金投入在着重解决从无到有的基础设施和系统的构建，然而却忽视了系统建设完成以后的运行维护。随之而来的是，信息化的运维压力和挑战逐渐凸现出来，已经成为影响信息系统应用效果的主要瓶颈。当系统进入运维期后，IT部门就像救火队一样，不知道什么时候、什么地方会出现“火”情。虽然作为CIO，一些具体的事情不需要陈贤本人去做，比如系统参数的调整，订单的排程等，但是IT 管理、系统运行维护、项目管理等工作他还是要一一过问。传统被动的、孤立的、分散的“救火队”式IT运维管理模式，让IT部门疲惫不堪。而且，随着公司业务模式的复杂化和多样化，更带来IT运营环境的复杂性和不确定性。在IT运维系统时，IT部门普遍面临多种问题。主要有以下几个方面:(1)运维人员被动救火，工作效率低下在IT运维过程中, IT员工工作太被动，只有当事件已经发生并已造成业务影响时才能发现和着手处理。这种被动“救火”不但使IT服务人员终日忙碌，也使IT服务本身质量很难提高，导致IT和业务部门的满意度都不高等。(2)流程规范不足,没有形成闭环跟踪在运维流程方面，IT部门一直处于原始的状态。例如在事件处理流程上，存在以下几种典型的问题：①没有明确的事件升级标准，例如满足怎样的条件后，事件必须从一线转到二线支持工程师，再转到三线研发工程师处理。②没有事件的有限级定义标准，没有建立优先级和解决时限的关联关系，从而不能保证事件解决的实效性和 IT 资源的有效利用。③事件产生后没有明确而唯一的责任人，从而缺乏有效对事件监控和跟踪机制。④没有统一的 IT 服务管理对事件受理的界面，没有事件完整记录、没有及时反馈。这些都使事件/服务请求处理过程中没有形成严格的闭环管理;没有建立明确的重大或紧急事件处理流程，从而不能保证在相应事件发生后有效及时地处理。对事件处理过程的记录比较分散，随意性很大，没有控制。更没有严格规范的流程政策和控制手段，使之存在太多的漏洞。整体运行维护情况无法一目了然，不能够清楚地知道各位员工的工作情况和工作状态，从而缺少对流程有效的监控和跟踪。(3)缺乏运维技术工具企业缺乏诸如事件监控和诊断工具等技术工具，事件不能在技术工具的支持下得到主动、快速处理。事件和工作任务在分派过程中没有相应的技术工具记录所有历史信息，不便于跟踪和分析;配置管理信息没有相关工具支持，以便为配置元素建立复杂的关系、状态等属性和提供相应查询功能。总的来说，目前诸多企业在IT系统运维方面并没有高度重视，前期规划仅为解决短期IT建设问题。但随着企业规模的不断扩大，IT系统涉及的设备种类越来越多，对全系统的运营和维护管理提出了近乎苛刻的要求，而相对的则是IT运维的原始和落后的手段。建立运维制度，关键在于规范我们可以看出，在企业信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。作为CIO，应首先是一位管理专家，其次才是技术专家。由此，建立完善的IT运维制度是最主要的工作内容，是企业信息化有效执行和监督的立足点。IT部门本身管理不好，就不可能为业务部门提供满意的IT服务，业务部门对IT部门的满意度就会低，满意度低又会影响IT投资及新项目的开展，使IT部门陷入困境。所以建立高效规范的IT运维机制，是CIO走向战略管理的第一步。

IT解决方案主要是针对于目前企业所面临的一些现实中存在的问题，或者说是其预见未来可能会发生的一些问题，所提出的一种切实可行且能降低成本、提高效率的有效问题解决方案，帮助客户作出更明智的决定，取得更有效的管理成果。

解决方案必需有明确的对象，或者施行的范围和领域（这些要素可能包括但不限于：不同的行业，领域，阶层，类别等等）。

在某些领域，解决方案不止是针对问题本身，也必须考量到需要服务的对象，例如面向的客户的具体情况和需求。

扩展资料

从传统的观点来说，解决方案只包含方案的生成阶段，具体的执行阶段是另外划分的。

但是从统一的流程来看，解决方案直接为执行层面服务，它们不是简单的线性关系和单一接口。

所以，从某种程度来说，解决方案和执行是相互交互影响的，执行的效果应该及时反馈，并且对原方案做出修正性的参考和建议。

这种交互是多重性的，重复性的。一个可以不断自我完善的解决方案，才能真正改善状况，使得它以更高的效率执行。

相反，就一些复杂的现实情况来说，问题涉及到更多的要素，问题之间也有复杂的联系。

如果期望以一个完美的解决方案，一次性解决所有问题。提出方案就可以高枕无忧，旁观执行层的实际进展。这在实际看来是不太现实的，也可能产生不适应的效果。

在市场经济领域，尤其是面向客户的案例中，能够提供执行参考，甚至能够亲自参与到具体执行中的解决方案，是更容易被客户认可和青睐的。

简而言之，与拿到一个完整的建议书或者计划书相比，客户更希望获得解决问题的全套服务。

IEC术语 国际标准IEC60364区分了三类不同的接地系统，使用两个字母代号表示TN,TT和IT。 第一个字母表示供电设备（发电机或变压器）与地的连接： T 将一点直接与地相接（拉丁文：terra） I 没有与地相接的点（隔离：isolation），除非是通过一个高阻抗。 第二个字母表示提供给用电设备的与地连接： T 将一点直接与地相接。 N 在安装位置直接与接地的中性点相接。

数字化时代，银行业务的快速发展，计算机的系统数量和部署规模均呈快速增长态势，且加上应用系统的微服务化，系统间的关联更为复杂，也相应提升了对运维系统的要求与难度。虽然银行内建立了较为全面的监控体系，但是面对千百万的告警风暴时，故障定位解决问题十分困难，特别不利于系统安全、持续、稳定运行。

数字化转型中，以用户为中心是驱动金融行业的核心基础。所以，对于像银行、证券公司这样拥有海量运维数据的金融行业来说，智能运维势在必行。采用先进的运维手段（智能运维）则是企业不断前行的源源动力。

说一个我们正在服务的客户案例吧，客户是一家商业银行。

这家商业银行通过擎创科技提供的夏洛克AIOps解决方案，建设了一套智能运维数据分析系统，集中收集和分析十多个系统的运维数据，包括应用系统日志、告警、性能指标、交易指标和网络性能指标等，并通过机器学习算法实现指标异常检测、关联分析和告警收敛，以此加快问题定位效率，保障系统运行。为了有效提高对异常情况的监测和未来趋势预测，提前发现系统隐患，该商业银行通过擎创夏洛克AI实验室，训练并生成了基于业务场景的多类算法，实现系统的单指标异常检测，极大降低系统故障发生的概率。

与此同时，该商业银行还用了擎创夏洛克指标解析中心和告警辨析中心，通过此实现多维指标关联分析，帮助快速发现和定位系统问题，提升排障效率；实现告警收敛，降低告警风暴，加快定位时间。目前告警压缩率达到了80%以上，运维人员的告警处理效率明显提高。实现了IT系统运维的智能化，为业务健康运转提高强力保障。

其实，擎创科技此前便服务过众多银行类客户，如中国银联、交通银行、浦发银行和宁波银行等，帮助其构建了智能化的运维平台，提升了客户运维效率，且目前很多项目都进入到二期、三期建设阶段。

在IT系统的需求分析阶段，保证项目以业务需求为目标; 在系统交付时，进行充分的功能测试和性能测试; 在运行阶段，保持对系统的监控，这是进行IT系统质量管理的关键。 IT系统作为银行业务的有力支撑，越来越受到重视，各家银行纷纷通过改善IT系统来节约实施和维护成本，提高客户的满意度和增加收入。但是，随着IT系统的建设越来越多，结构越来越复杂，如何保证IT系统的质量，使其真正能够满足日益发展的业务需要，逐渐成为各家银行重点考虑解决的问题。具有雄厚资金实力和IT投资预算的大型商业银行，已经开始着手IT系统和软件产品的质量控制和管理建设，制订出从业务需求到开发、测试、部署以及产品和系统上线以后的实时监控等一揽子规划，并且开始着手购买各种软件和工具进行实施。但是对于大多数银行，每年的IT预算有限，如何保证IT系统的质量面临不小困难。笔者结合目前国际上流行的质量控制和管理趋势，根据自身在银行方面质量管理和控制项目支持的经验，提出一个分阶段分步骤进行建设的建议，以供广大银行的决策者及相关人员参考。

测试工具的选择

银行作为一个特殊的行业，对于IT系统的功能性要求和性能性要求都比较高。对于银行IT系统，功能上不能有丝毫的马虎，客户交易必须正确记录，决不允许错记、漏记，如果发生错误，对于客户是经济损失，对于银行来说则是信用的损失。性能上为了提高客户的满意度，在各种渠道上都需要保证在一定的时间内完成交易，如果客户存取一笔款项需要花费很多时间，那么客户对于银行的抱怨是无法想象的，很有可能使这位客户转而投入其他银行的怀抱。从技术上说，对于功能和性能方面的质量都必须通过测试来进行验证，这是保证IT系统在功能和性能方面能够满足业务需求的基础。在功能和性能方面的投资可以优先考虑两个方面: 测试管理工具和性能测试工具。

软件测试目前作为软件工程中的一个重要的环节受到各个企业的重视，并且大家也普遍承认，这是一个需要进行有效管理的过程，因为其中涉及到测试需求的选择、测试案例的设计、测试执行的管理以及缺陷跟踪的流程等多个方面和环节，如果还停留在依靠手工处理、电话或者邮件通知、人工收集数据、使用Office软件来进行统计的阶段，那么工作量相对来说是很大的，而且不能及时反映整个测试阶段的进程和情况，因此在准备进行测试时，选择一个业界承认的优秀的测试管理工具是很有必要的。

选择一个好的测试管理的意义在于:

● 能快速学习测试管理工具中附加的先进经验和最佳实践;

● 能有效地进行测试资产的集中管理和控制;

● 能理顺并完善适合本企业内部的测试管理流程，并且映射到测试管理工具中;

● 能促进各个团队进行有效沟通和分工协助;

● 能方便地进行各种数据统计和图表处理，有利于了解项目测试的情况。

在选择测试管理工具时，决策者和相关人员可以根据以上要求来考量测试管理工具是否适合和满足本企业的要求，同时要考量测试管理工具的平台性，即不仅仅只是一个工具，而同时要具有开放性、可扩展性等平台特性，这样才能很好地融入到企业IT建设架构中，真正地成为企业IT建设的基础。

功能和性能测试方面的投资当然是以性能测试为主。原因一方面在于，IT系统的性能问题不易发现，在测试期间只有少量用户使用，往往不会暴露出存在的性能瓶颈，只有上线了以后，千百个分行支行网点的用户使用、并发量大的情况下才会出现，而使用性能测试工具可以模拟这种大批量的用户并发使用。另一方面，性能测试要衡量的指标有很多，依靠工具更加易于进行统计和分析，帮助测试人员发现和定位性能问题。

选择性能测试工具要考量的指标一般有:

● 是否易于创建测试脚本。如通过录制就可以完成，不需要或者需要很少的手工编制;

● 是否能够精确地模拟现实中系统上线后的运行情况;

● 是否能够在压力加载的同时，收集被测系统的资源消耗情况，并且这些数据是真实准确的;

● 是否提供了强大的分析模块和报告生成能力;

● 是否能够和测试管理工具很好地集成。

性能测试工具的价格往往很昂贵，在购买时可以考虑先购买部分功能和模块，然后再分阶段逐步完善。

在自动化功能测试方面，尤其要注意不要盲目地购买，然后仓促地、大范围地在系统功能测试中使用。因为自动化功能测试工具的优点在于通过可重用的脚本和模块，简化脚本创建和维护的工作，同时通过重放，在回归测试中将测试人员从重复性的单调 *** 作中解放出来，使他们更加专注于缺陷修复和功能变更后的模块测试。由于自动化功能测试工具目前大多是通过录制生成脚本，如果以单独一次测试来和人工相比，往往不具有明显的优势。使用自动化功能测试工具能够提高投资回报率的关键在于，通过自动化功能测试工具测试生命力相对持久的系统。例如银行核心业务系统、信贷系统等，通过不断积累和完善该系统的功能测试脚本，可简化该系统变化相对不大的模块的功能测试。

在选择功能测试工具时，需要考虑的最主要指标是工具的简单易用性，因为就实际经验来说，自动化功能测试工具往往由业务人员直接使用，如果 *** 作简单，脚本可维护性好，结果报告清晰明了，那么就会达到事半功倍的效果。

总体上，第一阶段可以考虑优先购买和实施测试管理工具和自动化性能测试工具，同时可以考虑选择一到两个相对修改不会很大的系统来使用自动化功能测试工具录制功能脚本，进行自动化功能测试前期的积累。

逐步建立质量管理体系

如果前一阶段我们的目的是选择测试管理工具和测试工具，同时选择固定的人员，组建相对独立的测试队伍，实现知识共享和经验积累，那么第二阶段我们的目标就是基于本企业内部的情况，制定出适合本企业的质量管理体系，全面控制和管理测试工作，加强功能和性能测试方面的自动化程度，将测试工作和测试团队纳入到整个企业的质量管理工作中，同时可以考虑在本阶段将设计、开发和测试集成起来协同工作。

这一阶段我们应该充分发挥测试管理工具的开放性和集成性，一方面通过它实现与设计、开发、部署等过程良好集成，例如将设计需求快速转变为测试需求，通过测试管理工具管理 单元测试 等; 另一方面可以通过工具提供的功能或者二次开发，建立关键性能指标，从测试管理工具中提取数据，展现测试项目和测试工作的全面视图，例如缺陷的趋势图（每天新增加的缺陷和处理完毕的缺陷）、测试案例计划和执行分析图、测试项目总体进度图等，这样就能通过完善系统质量的衡量指标，逐步建立起质量的评估体系来。

在功能和性能测试方面，由于经过第一个阶段自动化功能测试的积累，已经具有很强的脚本编制和功能组件划分能力，因此可以逐步建立起自动化功能测试的框架，这样做的好处在于: 首先，可以大大简化后期脚本的维护和自动化功能测试的运行; 其次，可以利用框架，快速构建新的系统的自动化功能测试; 再次，可以充分利用业务人员对于业务的熟悉，让他们加入到自动化功能测试过程中来，便于他们使用自动化功能测试工具; 最后，具有一个良好的框架，将来可以快速建立基于业务流程和数据驱动的测试方法，推动回归测试和冒烟测试。

性能测试在这个阶段可以继续深入，一方面通过工具进行针对应用开发代码的性能诊断，协助开发人员发现和定位代码方法级别的性能瓶颈，另一方面要收集各种测试的结果数据，建立起性能和硬件配置的估算模型，充分保证在硬件投资上的最合理支出，提高投资回报率。

该阶段还需要加强的是设计、开发和部署时通过建模工具、配置工具、变更管理工具、运维监控工具、帮助开发人、测试人员和运维人员协同工作，高效率地完成应用系统的整个生命周期中关键环节的管理。由于中小型银行系统主要以外包为主，这里就不做细致的阐述了。

该阶段要注意的是，由于开发以外包为主，所以更需要加大测试方面的投入。因为完善的设计理念、先进的开发技术和方法论、良好的团队合作和项目管理，并不能绝对保证开发出具有优秀功能和性能的应用系统，更何况系统的参数配置对运行的性能影响同样巨大，因此功能和性能是否能够满足业务的需要，最终还是要通过测试来检验。这就好像一个人，虽然具有良好的家庭背景、教育环境、生长氛围，并不一定会成为一个优秀的人才一样，是否有能力能够胜任工作，还是需要通过考试等测评方法来衡量他的综合素质才可以下结论。

促使IT系统和业务目标的统一

银行业IT系统的根本目标是提高生产效率，为银行业务的实现提供强有力的支持。因为银行IT系统本身并不会为银行带来经济收入，收入是依靠其支撑的业务运营来实现的，因此IT系统从设计的那天起，就决定了其要为业务运行服务，要帮助达成业务目标。

但是实际应用开发过程中，由于开发人员过于理想化、开发管理不善等各种问题和各种变化，往往导致最终完成的系统与业务目标具有一定的偏离，这种偏离有时候是很大的，甚至可以称作鸿沟，而IT系统质量管理发展阶段的最终目标就是建立机制，消除这种鸿沟，使IT系统真正能够满足业务目标的需求。

要消除这种鸿沟，可以从以下几个方面考虑:

● 需求和项目管理。这里的需求指的是业务需求，通过项目全生命周期的有效管理，保证应用开发项目的设计、开发和测试都以业务需求为目标，使项目最大化地满足业务需求，实现业务价值。

● 质量保证。通过测试保证应用系统在功能上满足业务需求。

● 性能验证。通过测试验证应用系统在性能上是否满足业务需求。

● 服务水平管理。应用系统上线后，通过实时监控等手段保证应用系统能够满足服务水平协议，使最终用户能够通过应用系统实现业务 *** 作，提高最终用户的满意度。

● 变更生命周期管理。在应用系统整个生命周期中，能够使需求变更被控制在管理范围内，并且能够按照需求的这种变更快速地组织开发、测试和上线后的监控，使这种变更还是依照业务需求进行。

可以看出，需求和项目管理、变更生命周期管理两方面都需要银行内部各部门之间的协助，只有建立起全面的内部质量管理体系和制度才能很好地实现，而质量保证和性能验证就是前阶段的功能测试和性能测试。只有通过测试，才能从功能上和性能上保证应用系统满足业务需求。

这里面要强调一下服务水平管理，虽然目前银行运维部门大多已经具有一系列的工具和手段，可以监控Unix服务器、数据库、网络等底层应用基础架构运行的状况，但是银行是以业务为主导的，最终这些软硬件的运行是要保证业务功能的实现，因此银行监控观念和侧重点应该有一定的转变，即最关键的应该是监控业务功能是否能够正确实现，业务流程是否能够正常流转。举例来说，网上银行系统被不小心修改了登录页面，导致页面出错，这时候传统的监控工具看到的情况是Unix *** 作系统正常、数据库正常、网络正常，但是客户却不能使用网银系统，如果使用了基于业务流程的监控工具，就可以监控到这种错误，并且报警，同时可以帮助运维人员定位到是应用级别出现了错误，从而帮助快速解决这个问题。

选择这类监控工具一方面是要考虑能够有效地模拟真实的用户 *** 作，另一方面是能够将业务流程和底层应用基础架构映射，将业务流程的失效定位到应用基础架构问题。

至此本文介绍了银行IT系统质量管理建设各阶段要考虑的方面，如果我们把银行应用系统比做一个人，那么各阶段的建设可以形象地总结如下:

● 测试先行。就像人定期的健康体检一样，以检查是否有潜在的疾病。

● 全面的质量管理体系。从饮食习惯、作息起居、日常锻炼等方面来提高人的机体的整体免疫力。

● IT管控，消除IT与业务需求的鸿沟。真正明白人生存的价值和意义，不仅仅要有一个健康的体魄，更要从精神、心态等方面来全面调节生理和心理，使自己具有一个乐观、积极的人生。

（作者单位:美科利公司技术顾问）

一、IT营运管理方法论现今的企业为了强化自己在这个新世纪的竞争力，导入了ERP系统、供应链系统、CRM系统、决策支持系统、知识管理系统等等，这些系统最后都要进到企业的IT营运体系中。当我们透视解决方案生命周期时，可以看到，所有的解决方案最后都要进到企业的IT营运体系中，为企业员工所使用。如果IT的整个营运管理做得不好，那这些花大钱建置起来的系统再好功能再强也没有用，因为使用者根本无法顺利地使用它们。某大型电子公司，共运行了四十多个应用系统，当他的信息主管被问到，哪一个系统最重要时，他回答：「IT的营运与管理最重要！唯有好的IT营运管理，才能让公司上上下下好好的用每一个系统。」这个见解实在是一针见血。既然IT营运管理非常重要，那么如何提供好的IT 服务，对IT 主管或CIO 而言当然是非常重要的课题。答案是采用更新的技术或添购功能更强的设备吗？在1999 及2000年Gartner Group 广泛访问企业CIO 有关服务或应用程序无法使用(downtime) 的原因。结果大家最常认定会出问题的技术或产品(包括硬件、软件、网络、电力失常及天灾等)，其实只占了20%，那么占大宗的是什么呢？我想你已经猜到了，作业程序(Process) 失误就占了40%，另外作业人员(People) 疏失也占了40%。作业流程失误包括变更管理(Change Management) 没有做好、超载、没有测试等等程序上的错误或不完整。作业人员疏失包括忘了做某些事情、训练不足、备份错误或安全疏忽等等。Gartner Group 这份访查结果正是80/20 法则的再次印证。我们常想要把系统的可用度提高，当然就是要花大钱购买标榜可提高可用度的硬件或软件。孰不知这个部分事实上只占了系统停机原因的20%。如何做好IT 服务管理，首要工作当然是加强流程和作业人员管理，因为那才是造成系统无法使用的主要原因－ 两个原因加起来共占80%！我们常听人家说大型主机(Mainframe) 的 系统比较稳定可靠，所以经过了这么多年还是有许多企业愿意花大钱继续一年年采用。其实真的是它的系统软硬件更好吗？恐怕并不尽然。我们知道，大型主机系统 有着一套完整清楚的系统运作规范可遵循，人员在训练时花在运作程序方面的心力绝对不亚于系统软硬件，甚至是更多。有了严谨的程序，加上完整的人员训练，自 然就可以把那80%的系统停机风险降到最低。那么是否有方法论，可以用来建构企业内IT 服务管理而且是主要IT 厂商都支持的呢？

二、什么是ITILITIL（Information Technology Infrastructure Library）是信息系统运营与服务管理标准，用于定义IT部门管理工作中需要的各个工作程序(Process)，以及各个工作程序之间的相互关系。在跨国公司IT经理中素有"IT界MBA"之称。80年代中期，英国政府部门发现提供给其的IT服务质量不佳，于是要求当时的政府计算机和电信局（CCTA），启动一个项目对此进行调查，并开发一套有效的和可进行财务计量的IT资源使用方法以供本国的政府部门和私有部门使用。同时，这种方法还应该是独立于厂商的并且可适用于不同规模、不同技术和业务需求的组织。这个项目的最终成果是一套公开出版的IT服务管理指南，即ITIL（Information Technology Infrastructure Library）。虽然ITIL当初只是为英国政府开发的，但是在90年代初期，它很快就在欧洲其它国家和地区流行起来。到90年代中期，ITIL成为了事实上的欧洲IT服务管理标准。90年代后期，ITIL又被引入到美国、南非和澳大利亚等国家和地区。2001年英国标准协会（BSI）在国际IT服务管理论坛（itSMF）年会上正式发布了以ITIL为基础的IT服务管理英国国家标BS15000。2002年BS15000被提交给国际标准化组织（ISO），申请成为IT服务管理国际标准。国际标准组织已接受这个申请，并为此设立了一个专门工作组。该标准有望在2006年前后生效，可以说，ITIL已是事实上的国际IT服务管理标准。ITIL的目的是帮助企业降低IT运营管理成本，并且提高IT服务水平，提高业务部分的满意度。

三、ITIL的核心思想ITIL它并不是一套理论模式，它所根据的是最佳的实际经验。其中的许多经验不但广为人知，而且有无数的IT机构都是采用它来提升IT服务的效率及加强IT部门间的横向沟通。这套方法论历经了十数年的考验，证明它是最被IT业界广为接受的一套经营IT经验指南，等于是IT管理的业界标准。ITIL将IT的工作分为两大类：分别为《服务支持》（《Service Support》）和《服务提供》（《Service Delivery》Service Support针对的是一般系统的运作部分，目的是让使用者可以顺利存取到IT服务。其中包括Service Desk、事件处理与追踪、问题处理与追踪、系统变更、系统配置设定的记录与维护，以及版本的发行与控管。第二大类Service Delivery则是针对IT部门对客户提供信息服务时应有的工作程序。其中包括服务层级的约定与管理、IT服务的财务管理、系统可用度管理、系统容量的测量与未来规划、灾难情况的业务持续运作规划与系统复原。《服务支持》（《Service Support》包括如下流程：

1 事件管理（Incident Management）: 识别偶发的事件。

2 问题管理（Problem Management）：对服务台识别的偶发事件的潜在原因加以诊断，安排改正IT基础设施的错误并进行问题预防指导。

3 变动管理（Change Management）：变动管理过程确保使用标准方法和规程有效且迅速处理所有变动。变动管理旨在提高组织的日常运作水平。

4 配置管理（Configuration Management）：识别、控制、维护和检验现有的包括基础设施和服务在内的IT资产。

5 发布管理（Release Management）：通过控制软件、硬件的发行和版本确保信息系统资产的安全，并消除不同版本引起的潜在问题。 《服务提供》（《Service Delivery》）包括如下流程：

1 服务水平管理（Service Level Management）：服务水平管理的目标是通过协调IT用户和提供者双方的观点，实现特定的、一致的、可测量的服务水平，以为客户节省成本、提高用户生产率。

2 可用度管理（Availability Management）：可用性管理的目标是优化IT基础设施的性能，它的服务和支持的组织。可用性管理导致成本节省的、持续的服务可用性水平，这种服务可用性确保业务满足其目标。

3 能力管理（Capacity Management）：使组织在危机出现时管理资源并提前预测需要的额外的能力。它描述了计划、实施和运行该过程必需的规程。

4 持续性管理（Continuity Management）：在尽量少的中断客户业务情况下，提供IT服务，并在IT系统出现问题时，以可控的方式恢复。

5 财务管理（Financial Management）：确定IT服务的成本核算，设定预算，监督预算执行情况，根据提供的服务收取费用。 针对ITIL管理流程的具体实现，ITIL标准又将实现工具分为三类：Process Management Tools—过程管理工具Analysis Tools—分析工具Execution Tools—执行工具 四、XX银行IT管理规划建议全面实施ITIL模式对任何IT企业都至关重要，但在实施时通常需要循序渐进，并且要从最急迫需要解决问题处入手。最重要的是要采用统一的符合ITIL标准的信息架构。另外，在实施前，切记先记录下现有环境数据，以便随着时间的流逝来衡量成效。我们建议xx银行将规划分为：短期目标，中期目标，长期目标三个阶段实施，从而构建符合ITIL标准的IT服务和管理平台。短期目标：达到目的1）立符合ITIL标准的统一的信息架构（altiris notification server）

2） 保证统一的配置管理数据库（Configuration Management Database）

3）实现变更管理、配置管理、问题管理变更管理（Change Management）为何要做变更管理呢？这里举两个因为变更管理没做好而蒙受重大损失的例子来说明。2001 6 ，NASDAQ当机长达半天，原因是 *** 作人员做了一个未经测试的变更动作，结果导致整个系统停机。同样也是在2001年6月，NYSE在半夜做了一个软件变更的变更动作，导致部份系统当机，无法完成股票买卖交易。这两件事都上了报纸及新闻头条，包括华尔街日报、CNN 及CNBC等等。这反映出了变更管理真的很重要，一旦没有做好它，企业的关键任务(Mission Critical)系统就会受到影响。以银行业为例，只要是IT部门当机一小时，其导致的结果可能是全体员工要花上数倍或甚至是数十倍的时间来补救，而且因为分行里客户大排长龙，负面报导上了晚间新闻及报纸，企业形象受损的损失更是无法估计。这也可以说明为何企业CIO 把变更管理视为第一要务。为进行变化管理，IT组织中应该有变更管理员（Change Manager）及CAB（Change Advisory Board）的编制。变更管理员是全程负责监督RFC从提出到结案整个过程的人。CAB代表是变更咨询委员会。配置管理：在公司内，通常会做所谓的资产管理(Asset Management)，也就是把每项公司资产是何年何月何日购入、哪一个会计科目、负责人是谁等信息记载在数据库中，这是一般传统的资产管理方式。但是实际经验显示，如果用这种方式来管理IT相关资产，包括硬件、软件、网络等等，结果会因为记录的信息太过简化而衍生出许多问题。IT资产的管理所必须记录的信息要比一般资产多得多。目前有经验的IT部门都有一套方式来记录IT资产。但是IT资产的管理难道就只是详尽记录它的型号版本等等这些规格信息而已吗？其实这是不够的，还要包含该项资产所有的配置设定，以及它与其它IT资产之间的相互影响关系。这些配置都会输入到所谓的「配置管理数据库」(CMDBConfiguration Management Database)中。准确而完整的CMDB是相当重要的。因此要有一个机制来提供这个信息，这个机制就是配置管理(Configuration Management)。配置管理可存取并提供IT资产正确信息和这些资产间的关系，还能提供对系统的影响及趋势分析，降低未经授权软件的使用情形，以及控制所使用的IT资产。问题管理问题管理的目标就是要找出事件或问题发生的真正原因，并找出对策或步骤来解决问题。我们常说要对症下药。没有针对原因来解决问题，可能可以让服务暂时还可以使用，但如果错误原因没有被消除的话，将来还是会发生问题，事件还会再重复发生─ 进而再度影响IT服务的提供。这 也就是为什么要有问题管理的原因。唯有找到原因，才能解决问题，避免同样的问题一而再，再而三的发生。问题管理分成两个部分，一个是被动的部分─等事件通 报变成问题，再来分析问题，找出问题发生原因，加以诊断，再提出解决方法及步骤。一个是主动的部分，分析趋势，事前先找出可能潜在的问题，主动提出解决方 法及步骤，预防问题将来发生。

4） 对应altiris工具

配置管理Configuration Management 过程管理工具/分析工具/执行工具

Altiris Architecture- altiris notification server 建立统一的信息管理架构

Altiris Inventory solution 资产管理

Altiris web reports 报表分析功能

Asset Control solution 固定资产管理，建立最完整统一的资产信息及相关联信息

变化管理Change Management 分析工具

Altiris Inventory solution 资产管理

Asset Control solution 固定资产管理

Altiris web report 报表分析功能

Application Metering Solution 应用软件管理

执行工具

Altiris software delivery 软件部署与升级管理

Altiris client management suite 客户端 *** 作系统部署、升级；软件的部署与升级；微软补丁自动安全管理；远程控制等。

问题管理Problem management及事件管理 Incident management 分析工具

Altiris Inventory solution IT 资产管理

Asset Control solution 固定资产管理

Altiris web report 报表分析功能

Application Management Solution 应用管理

执行工具

Altiris Deployment Solution 系统部署、升级和管理

Application Management Solution 应用管理

Carbon Copy Solution 远程控制

中期目标：达到目的：实现事件管理、持续性管理（Continuity Management）、可用度管理在现今全球化经济社会下，可用度及IT服务持续性管理可说是最举足轻重的两个重要程序。营运服务能否持续每天24 小时，一周7天地正常运作，变得愈来愈重要。可用度能左右顾客满意度，并且能快速的影响企业整体声誉及业务是否成功。IT服务持续性管理程序是要确保正常可用的解决方案发生问题后，依然能够持续提供另一个等级的IT服务给客户。从这个观点来看，可用度管理及IT服务持续性管理的关系非常密切。这两个管理程序都是试图减小IT服务的可用度危机。可用度管理的焦点主要是集中在处理日常可能出现会影响到可用度的危机，如果无对应的反制措施或反制措施没有办法完全涵盖或应付时，这些危机就由应变计划及IT服务持续管理程序来处理。IT服务持续管理程序分做3 个步骤。第一步是取得Service Level Agreement，然后分析及找出每层的危机，将IT服务分成下列层级：服务、应用软件、中介软件、 *** 作系统、硬件、网络、环境、外在影响因素。第二步是提出这些紧急状况的解决方法；这包括两个部分：第一个部分是Failover，第二个部分是Recovery。Failover 包括有几种选择：Cold Standby、Warm Standby 及Hot Standby。第三步则是制作应变计划。对应altiris方案：

服务水平管理（Service Level Management） 过程管理工具/分析工具/执行工具

Altiris helpdesk Solution 建立统一的service desk

持续性管理（Continuity Management） 分析工具

Altiris Site Monitor Solution 网络站点监控模块

Altiris Monitor Solution 服务器监控模块

Application Metering Solution 应用监控模块

执行工具

Altiris Recovery Solution 恢复模块

长期目标：达到目的：IT财务管理分析（Financial Management）

IT财务管理分析Financial Management） 过程管理工具/分析工具/执行工具

Altiris Contract Management Solution 合同管理

Altiris TCO Management Solution IT 总体拥有成本分析

以上就是关于CIO如何规范IT系统运维管理全部的内容，包括:CIO如何规范IT系统运维管理、什么是IT解决方案、IT系统的介绍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！