业务应用:IT运维管理的核心 把业务指标分解到it运维中

在ITIL的事件管理（Incident Management）流程中，有关于SLA服务级别的具体要求。

其中，响应时间（Accept Time）和 解决时间（Resolve Time）是非常重要的两个时间，响应时间代表的是对事件开始启动受理及响应的时间，解决时间是最终问题被处理完成的时间。两者的时间差就是解决时长。

而解决时长对应的就是SLA的服务级别中优先级的具体要求。优先级=紧急度影响度。

这和事件要求及事件来源都不是一个概念。

例如当影响度为高、紧急度也为高的一个case，优先级就是最高级，对于解决时长要求是10分钟。

影响度为中、紧急度为低的一个case，优先级为低，对应解决时长要求是4小时。

这里可以做成一个矩阵表。具体可以百度搜一下 事件流程优先级矩阵。

希望可以帮到你。

一、基础数据概况

CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，与未来的IT运维管理标准化和流程化紧密关联，并且支持流程的运转。运维管理平台创建初期或初版中的CMDB更多是偏向IT资产管理，我们在这里定义的IT资产管理，暂时抛除公司个人使用的普通PC机。

日志主要存储CMDB中涉及到服务器或是其它设备的日志信息。

DB主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库。由于数据库的重要性，所以在基础数据中单独一个模块管理数据库，包括生产数据库、测试数据库、开发数据库。数据库的日志放在日志模块进行统一管理，监控和备份。

知识库主要存储日常运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。

二、基础数据三要素

基础数据要求完整、准确、实时，这三个特性缺一不可。

1完整性

完整性，要求在数据采集整理阶段，要一一梳理，不能有遗漏。任何一个设备的疏漏都将会导致未来出现问题。例如最近的勒索病毒在防范上需要给服务器升级打补丁，这个时候就是根据服务器清单一一对照，升级。如果有遗漏落下的服务器未及时打补丁而导致病毒入侵，后果将很严重。那么，如何做到完整性呢？大致可以分为以下几步：

首先数据采集阶段多人（推荐三人以上）同时对IT资产进行采集，那么在数据采集完成后，将会有三份或以上的IT资产清单。

接下来就是相互确认阶段。相互check对比两方的清单和自己梳理的清单，找到不一样的地方，大家在一起开会进行讨论。经过这个阶段，会产生一份相对完整且三方（或以上）认可的IT资产清单。

最后就是三方（或以上）一同针对认可的IT资产清单进行最终check，确保最后的清单，是经过多方讨论确认，并最终又check过的IT资产清单。此时这份IT资产清单，相对比较完整。另外在梳理、讨论和check的过程中，针对新增、变更、删除的IT资产一定要及时更新我们的IT资产清单。

2准确性

准确性要求IT资产清单或是CMDB中存储的数据不能与实际情况有任何差异。要做到基础数据的准确性除了在数据采集阶段要下功夫外，要在运维管理的每一个阶段定期对基础数据进行审计，确保基础数据中的数据无误。一般月度一小审，半年一大审，具体情况根据企业的IT规模而定。

3实时性

基础数据的实时性可以确保数据的准确性。即基础数据的每一次变动，包括增加、删除、修改，不论大小，只要有变动（在运维流程完结阶段，执行运维 *** 作成功后，就要及时更新基础数据。忽略基础数据的实时性，必将导致准确性大打折扣，在以后的月审、年审中必将导致额外的工作量。一般在审计的过程中，当数据的错误率达到一定程度后，需要重新梳理全部数据，以确保最终的准确和完整。

CMDB

CMDB总的来说分为：产品线、资产管理、供应商管理三个部分。

总的思路是：通过产品线管理IT资产，通过IT资产信息管理硬件或服务提供者，供应商管理。

1产品线

产品线是指整个公司所有IT系统、产品按照属性进行归类划分。这有一个前提，就是梳理整个公司的IT项目和IT服务。这里项目也可以理解为每一套IT系统，例如OA、CRM、订单系统、支付系统等等。

IT服务主要是指：应用服务（Tomcat、WebLogic、数据库服务等），基础IT服务如Nginx、Varnish、Redis等。通过项目和服务两个维度来管理IT资产，尤其是虚拟机。因为一般系统和服务都是部署在虚拟机上，虚拟机的宿主机则是一台台物理主机。

产品线的划分一般除了根据业务分类划分几个大的产品线外，还需要划分一些基础产品线，如：信息安全产品线，主要管理信息安全、网络安全等系统和设备等;基础服务产品线，如Nginx反向代理大部分系统，Varnish缓存Web静态资源等。

在这里单独说一下产品线和项目包括的服务必须制定运维优先级等级。运维等级的制定不能简单定义为多少级，而应该是为每一套系统进行运维优先级打分，分值不能一样。这样保证在大面积故障的时候，可以根据优先级解决问题。

2资产管理

资产管理主要有以下几个方面。

首先是比较大的机房管理。有的企业可能会有多个机房，每个机房的基础信息，如带宽、位置、值班电话等都需要加以整理存储用来管理机房信息。机房中的机架、机柜、交换机、路由器等硬件信息，机房的空调、UPS电源、环境监测系统等都属于机房管理的范畴。

安全设备管理。安全设备管理这里主要包含防火墙、IPS、WAF、***等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。

服务器管理。这里假定企业实现了虚拟化，大部分系统和服务都部署在虚拟机，而虚拟机是部署在物理机上。服务器管理分物理机和虚拟机分开管理，同时又密切关联。虚拟机在哪一台或几台物理机需记录清楚。

根据产品线中定义的运维优先度等级，在资产管理中的每一个节点标注上相应的等级分值，以便出现大规模故障，有选择、有重点、有顺序地逐一解决问题。

3供应商管理

供应商管理主要是管理由第三方企业提供的IT系统或设备的服务信息。记录供应商的具体信息、值班电话、硬件备件库等信息。

以上几个模块单独管理，但是又密切相连。如产品线包含哪些项目，包含哪些服务，这些项目和服务部署在哪些虚拟机上，虚拟机又在哪一些物理机上，物理机分布在哪些机房和在机房中的具体位置，物理机在机房中的网络位置和网络架构如何，经过哪些安全设备等等。

反过来需要知道某一些机房有哪一些物理机，物理机位置，安全设备，以及安全设备与物理机的网络架构等，物理机上又有哪些虚拟机上部署了哪一些项目和服务等。系统和服务属于哪些供应商提供，供应商又提供了哪些系统、设备或服务器等。都要多维度进行管理。要求做到某一环节的故障，一查就知道所有受影响的系统和服务。CMDB中的信息相互交织，多维度查询和管理，构建出一张完整的总体架构图，通过总体架构图除了展现出各个部分的基础信息外，还描述了所有的依赖关系，做到坏一点而知全面。

日志

通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻击会在系统安全日志中有一定的体现。

1系统日志

系统日志主要指的是 *** 作系统的日志，主要在/var/log下的各种日志信息。包含系统 *** 作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的 *** 作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能append。

2应用日志

应用日志主要记录应用服务的健康运行情况以及业务 *** 作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务 *** 作日志得出结论。业务 *** 作日志可以为业务审计提供主要依据。有一些系统喜欢把业务 *** 作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。

3数据库日志

数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。

4设备日志

设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。

在CMDB中梳理的IT基础设施的基础上，对日志进行分类收集、管理、分析和监控，配着监控管理模块的系统，就已经可以达到多方位监控IT系统，保障IT系统的安全稳定。

DB

由于数据和数据库的重要性，在基础数据中，数据库作为单独的模块存在，根据环境划分为：生产数据库、测试数据库、开发数据库。严格区分三种环境的数据库，避免测试数据到生产环境，生产数据到测试环境等。另外数据库中数据也为业务监控提供数据依据。通过查询数据库中的数据，依据业务逻辑进行判断是否有错误或是遗漏的数据。

知识库

知识库在整个运维管理中是一个辅助功能，主要为运维提供事件管理、问题管理。很多朋友可能会疑惑为什么把事件库和问题库放在知识库这里，这些不是应该在CMDB中吗？这里稍微解释一下，其实本人也并不太清楚这种办法是否可行。在CMDB模块中更多是偏向IT资产管理，为以后的运维 *** 作提供运维范围和运维目标。而事件（主要指运维过程中遇到的所有的运维事件）和问题（需要进行变更发布才能解决的事件升级）更多是在IT资产之上，是解决IT资产的过程中遇到的事件和问题。如果把CMDB作为IT运维的基础管理对象和范围目标的话，事件和问题应该单独出来。也许在后面的运维管理中，逐渐强化CMDB的功能，会把事件库和问题库回归到CMDB模块中。

知识库中还包含经典案例库，主要是解决一些常遇故障、经典问题的解决方法的整理和归档。

解决方案库只要是一些常用的或是探索中的解决方案，例如：Nginx+Tomcat+Redis部署方案，FastDFS分布式文件服务器方案等。

文档库主要用来存储运维管理过程中执行的运维标准和规范以及运维的流程规范，常用的一些规范举例：

文档库也包括一些企业或是部门的规章制度，与供应商的合同条文等。主要是涉及到IT系统文档的一个存放和查阅的地方。

运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。

总结

基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。

由于信息技术的渗透性和先导性,信息技术已成为国内外企业战略决策的制定和调整、生产经营过程中的计划、组织、管理和控制不可或缺的重要工具以及公司核心技术的主要载体,信息技术促进了生产经营过程的集成化和科学化,从而成为各公司降低成本、维持技术领先地位的战略举措。

近年来,国内外各企事业单位都十分重视信息化建设,把加快信息化建设作为提高生产经营管理水平、促进业务流程优化、加强内部控制、提高决策质量和效率的重要手段。结合中国石油发展战略和业务需求,中国石油出台了统一的“十一五”信息技术总体规划,F5(企业信息系统管理)项目便是“十一五”信息技术总体规划中的一项,目标是建立集成的监控管理平台和统一、完善的运维管理体系,提高中国石油信息技术基础设施的可靠性和性能,从而保证中国石油各业务系统的高可用性,彻底改善IT服务的管理水平,提高客户满意度,降低IT服务支持成本。

被动的传统IT运维管理

市场研究机构Gartner调查发现,在导致IT基础设施出现故障的原因中,源自技术或产品方面的因素其实只占了 20%,而因为运维管理方面的原因则占到80%,可见IT系统运维及管理是相当重要的。企业每年对IT部门投资都不少,但是得到的效益却没有体现,问题仍然时常发生,感觉好像所有的投入都打了水漂。

企业的IT运维部门是一个吃力不讨好的部门,因为IT运维就是在后台默默地保证信息系统的正常运行,只有在问题发生的时候才想到还有IT部门的存在。这种现象是由于IT运维管理还处于传统模式,即无相应的运维监控软件或者是仅仅单独使用某项监控软件而没有联合使用。这种传统的IT运维管理是被动的管理,是孤岛式的管理,是与业务应用没有联动的管理。

1被动管理

传统的IT运维管理是救火式的管理。通常是用户先于IT人员发现问题,然后再找到IT部门要求解决问题。这是由于传统的IT管理采用人工方式管理基础设施,网络管理是从各种IT基础设备出发的,仅仅是保障各类IT设备如服务器、数据库、存储设备、交换机等等基础设施的正常运行。

不采用任何管理软件,仅仅靠运维人员定期轮询,或者执行某项命令来检查设备,在系统规模较小时,只要参与运维的技术人员足够负责,人工运维方式是可以满足日常运维需要的。但是,当应用系统达到一定的规模后,这种运维方式的弊端就暴露出来了。轮询一遍要花费几个小时,这样,轮询周期越长也就代表越需要更久才能发现故障。这种被动式管理IT导致有了问题不能及时发现。

2 无关业务、孤岛管理

有些企业虽然采用某一种或几种监控软件来监控IT基础设施,但这些监控软件都各自独立运作,没有进行对业务的整合监控。如果用户投诉业务应用不畅通,很难定位故障源,到底是网络、应用程序、数据库还是其他后台系统出了问题,或者是各部门踢皮球,都说自己所负责的设备正常

好一些的IT主管会把各个部门集合到一起开会,讨论问题根源。传统的IT运维管理方式是各类设备的管理各自为政,丝毫没有关联性。处理故障不便于追根溯源。每个人的精力有限,在专业应用系统赖以生存的各基础设施支撑单元上很难做到专、精、准的多面手角色,加之由于管理范围的界定和监控手段的限制,运维人员很难直接判定问题是出在基础网络、系统服务器、数据库还是应用系统自身,故障难以定位将直接导致业务恢复时间的推迟,影响业务系统的正常运行,大大降低服务质量。

将IT运维与业务相关联

IT运维是在后台默默地保证各项业务应用系统的正常运行。IT运维工作是无形的,怎样把这种无形的运维变为有形、甚至量化,这就要把IT的运维与业务相关联。传统的IT运维管理中,基础设施的运维工作不能和业务相结合,仅仅是在设备管理的层面上。这就导致IT管理的成绩没有体现。想想看,如有业务应用不正常,那网络或者服务器之类的任何一种基础设备的正常运行又有什么用呢业务应用是“1”,设备是“0”,没有了正常通畅的业务应用,那其他的都是空谈。只有在业务应用畅通的前提下,基础设施管理才有意义,才能体现IT运维管理的价值。

因此我们需要帮助企业IT:部门了解用户使用感受,关联真实用户感受和系统性能,指导问题事件定位和原因诊断 。

企业信息化发展过程首先是基础架构建设阶段,这个阶段主要是采购一些硬件和应用软件。随着采购的不断扩大,企业的IT组件不断完备,IT系统初具规模,这就产生了IT运维和管理的要求,即网络和系统监控(NSM)阶段,监控网络连通性和系统可用性,此阶段主要还是对IT设备的监控。随着企业业务日趋复杂,IT系统进一步扩大,这时就产生了对IT服务流程进行管理的需求,上升到第三阶段,即IT服务管理(ITSM)的阶段。以上三个阶段都是IT间接产生业务价值的阶段,对业务的顺畅起辅助监控的作用。

企业业务系统对IT系统依赖的不断增强,企业开始关心IT服务对业务带来的影响,强调从业务目标角度出发来管理IT,也就是到达第四个阶段――IT与业务融合的阶段,即BSM(Business Service Management,业务服务管理)阶段。企业可以根据业务目标对IT服务进行调整,以确保IT能够支持业务目标,从而直接产生业务价值(如图2所示)。

如今各类重要的IT应用系统相继在中国石油发挥着举足轻重的作用,所以IT应用系统的可用性尤其重要,例如ERP、OA、邮件、门户等各类重要的系统如果出现中断,都会给企业造成大量的经济损失,所以除了需要对各类应用系统部署冗余的设备以备保证其高可用性,同时也需要对应用系统进行监控和管理,并且进行关联管理。业务系统的可用性是由底层的各类基础设施的状态所决定的,因此建立一个有效的业务模型,将与某个业务相关的底层IT基础设施关联起来,该业务模型能够有效地定位故障根源。这样ERP的管理员只需要关心ERP业务的可用性,而没有必要去关注每台主机的性能参数和启动的进程,不但大大节约了运维时间,而且也提高了运维效率,使故障持续时间大大缩短了。

基于BSM的IT运维

当前中国石油IT运维管理的需求就是从业务出发,建立基于BSM解决方案的新型IT运维。

新型的IT运维管理系统要做得到的就是基于BSM架构的业务管理。

首先,要实时掌控最终用户对IT服务的使用体验,根据制定好的SLA(Service Level Agreement,服务等级协议)来管理业务服务的质量,这样就可以根据业务影响和SLA来对IT服务进行管理。

其次,通过端对端的应用交易时间测量,实现业务要求端对端的可见性;从最终用户的角度,来测量业务服务的响应性能,主动帮助运维人员在第一时间发现问题,以便在问题对用户造成不利影响之前,及时得到隔离、诊断和修复,把它们对业务的干扰降到最低。

第三,提供业务服务、应用及底层IT系统构架部件之间的映射关系。这种解决方案通常会基于一种称为CMDB(Configuration Management Database,配置管理数据库)来实现。通过服务依存关系映射技术,来展现业务服务、应用和底层IT系统构架部件之间的动态关系,这样就增进了对各种IT元素的掌控和理解。

第四, 借助业务服务与IT基础设施的依存关系,对告警事件进行管理。当IT系统的组件产生告警时,结合收集上来的底层的IT系统告警事件,对它们进行过滤、关联、聚合,根据对业务服务影响的严重性,来进行排序处理。

传统意义上的CMDB是服务流程中的一部分,是ITIL中最重要、最核心的概念之一,在以业务为核心的IT运维中,CMDB也是业务建模的主要工具。CMDB通过自动发现工具收集和一定范围的IT基础架构基础信息,包括配置项和关系,建立IT基础架构模型;并通过端到端的业务服务拓扑图来可视化展示业务系统所有部件和关联关系。

把这四方面的功能整合起来,从最终用户的角度来衡量业务影响和风险;自动发现业务服务、应用和底层IT系统构件,并建立依存关系;理解用户感受,监控用户业务响应时间 ,在用户受影响之前发现问题,以求满足下列功能:

1 通过基于角色的业务视图,提供业务流和服务的可见性;

2 从最终用户的角度来衡量业务影响和风险;

3 设置和检测业务过程的SLA,了解应用性能对业务的影响;

4 24×7小时端到端监控,从浏览器到后台实时监控所有交易;

5 理解用户感受,监控用户业务响应时间 ,在用户受影响之前发现问题;

6 主动发现和按优先级管理关键业务问题;

7 通过自动把业务和底层运营信息建立关联来缩短平均问题修复时间;

8 自动发现业务服务、应用和底层IT系统构件,并建立依存关系;

9 通过联合的CMDB,来为IT环境提供一个“统一的真实数据”视图,这样就可以为用户提供一个主动的、以业务为中心的BSM解决方案,帮助用户极大地改善业务服务的性能和可用性,降低服务突然中断带来的风险。

提升IT部门的作用

以前,IT运维部门救火队式的混乱状况导致无法判断IT运维总体表现的好坏。而IT部门又是公认的成本中心,这就导致了在很多企业中IT部门总是承受着很多批评,IT人员的工作热情也不高。

而现在,IT运维部门实现了主动发现问题、提前处理故障;IT运维管理与实际的业务应用挂钩,IT运维部门的工作由无形化为有形;促进IT部门从成本中心向利润中心转变,这一切既有利于IT人员发挥其工作热情,也有利于IT部门在整个企业地位的提升。

中石油的IT运维管理就是要基于BSM模式来建设,F5项目就是要实现基于业务来管理IT,也就是要提高信息技术基础设施的可靠性和性能,降低支持成本,对基础设施的规划进行最佳的决策和采用更好的系统支持策略。同时,获取与业务运行相一致的信息技术服务与实践,整合网络、系统、数据库和应用系统管理等关键业务,从而服务于数据大集中趋势下数据中心运维模式的建立和各专业应用日常运维的需要。

以上就是关于IT运维中事件管理中的服务请求有没有响应时间和解决时间是和事件要求是一样的么全部的内容，包括:IT运维中事件管理中的服务请求有没有响应时间和解决时间是和事件要求是一样的么、数据自动化运维应该注意哪些事项、业务应用:IT运维管理的核心 把业务指标分解到it运维中等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！