运维事件优先级（运维事件优先级分析）

本篇文章给大家谈谈运维事件优先级，以及运维事件优先级分析对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享运维事件优先级的知识，其中也会对运维事件优先级分析进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、IT运维中事件管理中的服务请求有没有响应时间和解决时间？是和事件要求是一样的么？
• 2、IT运维管理当前面临了哪些问题？
• 3、数据自动化运维应该注意哪些事项
• 4、有效运维的 on-call 机制
• 5、如何做好it运维

IT运维中事件管理中的服务请求有没有响应时间和解决时间？是和事件要求是一样的么？

在ITIL的事件管理（Incident Management）流程中，有关于SLA服务级别的具体要求。
其中，响应时间（Accept Time）和 解决时间（Resolve Time）是非常重要的两个时间，响应时间代表的是对事件开始启动受理及响应的时间，解决时间是最终问题被处理完成的时间。两者的时间差就是解决时长。
而解决时长对应的就是SLA的服务级别中优先级的具体要求。优先级=紧急度*影响度。
这和事件要求及事件来源都不是一个概念。
例如当影响度为高、紧急度也为高的一个case，优先级就是最高级，对于解决时长要求是10分钟。
影响度为中、紧急度为低的一个case，优先级为低，对应解决时长要求是4小时。
这里可以做成一个矩阵表。具体可以百度搜一下 事件流程优先级矩阵。
希望可以帮到你。

IT运维管理当前面临了哪些问题？

现在的企业几乎都是互联网办公，网络一旦出现问题，会对公司业务造成重大损失。而很多公司主业也不是IT，对网络问题不大懂，对于公司的网络问题往往都是请一个运维工程师处理。这些工程师有相应的专业能力，但管理人员的“不懂行”却让运维工作存在很多问题，主要有这五点：
1、缺乏有效的知识积累和共享，造成操作维护效率低下，类似的故障和问题仍然在不断发生，不断解决着，同时一旦某些掌握关键信息和技能的人发生意外状况(如生病，离职等)，整个日常维护可能面临严峻的考验。
2、工程师的维护职责不是很清楚，每个人都大概知道自己该做什么，但是某个具体事情到底该谁负责，却没有明细定位。
3、IT网络运维人员大多没有养成记录习惯，每个月汇总报告时，对自己的工作量、所维护系统的整体情况还是一头雾水。而且纸质的故障处理报告信息要素不全，统计和查询都是头痛的问题。
4、运维人员几乎很少能准时下班，处理突发技术故障的事情也时有发生。运维人员往往像“救火队员”一样去处理故障。 在“救火式”的IT管理维护模式下，很难有效地进行服务管理，无法保证IT服务的有效性和一致性，IT管理往往处于无序状态。
5、对于运维工程师的工作绩效缺乏客观考核依据。他们到底做了哪些事情?哪些事情还没有做?工作完成的时效性怎么样?解决问题的质量怎么样?这些问题，只能凭印象得出一个个模糊的答案。
如何解决以上问题?
如何解决以上提到的问题是目前许多企业用户需要解决的问题，但首要关注的问题应是如何建立专业化分工的IT运维体系。
1、细化用户角色，力求提高运维效率
运维人力分工管理包含人员、岗位、角色等信息，如果这些信息没有统一规划，就无法进行统一配置。网络管理中的角色是根据ITIL标准进行划分的，是把IT运维各种事情(包括人员、资源、突发事故)分成不同级别和不同运维操作，以便有效的配置运维人力资源。因此，对于企业而言，IT运维的专业化分工本质上是对IT运维人力资源配置的优化。例如，明确运维事件分级处理流程，明确运维人员的职责、权限、义务和绩效考核标准。事实上许多实践也证明，明确每种运维事件的专业化分工处理流程，可以大大减少IT运维操作的随意性和混乱性，并能大大提高运维中的人力资源效率。
2、设立IT运维服务台，规范IT流程
在网管软件中，一般提供自助服务和运维服务台，自助服务台的作用是，给用户报故障，评价IT人员解决问题是否负责等。运维服务台是为了确定运维等级和引入优先处理原则。运维服务台主要承担：运行值班、故障监控、接受请求、工单派发及问题解决过程中的监测等工作内容。服务台就像是传统产业生产车间的调度分配员，它会不断的根据事件的等级进行匹配分工和调度。例如发生任何一个突发运维事件时，服务台会先检查并进行分类流转处理。运维人员可分为一线普通维护、二线技术专家和三线厂商专家。一线人员作为第一级问题处理人员，主要解决常规的运维问题;在一线人员不能解决的情况下，二线技术专家将迅速介入问题解决过程;三线技术专家来自产品供应商，由二线技术专家申请三线厂商专家的介入，使问题解决时间能够大大缩短。
3、FAQ和知识库，最大限度节省人力成本
提供FAQ和知识库两种方式，知识库是指对网络运维中的典型故障事件和常见问题解答的自助式处理流程。当出现故障时，用户先在自助式知识库寻找解决方法。如果问题没有得到解决，则用户利用服务台申请维护，用户申请将会移交给相应的负责人，负责人第一时间建立服务档案并一直实时监控，直到问题得到圆满的解决。因此，自助式知识库能帮助运维人员节省大量的时间，从而节省人力成本支出。
最后，专业的事情要用专门的人员来做，还要配合专业的方法。运维工程师是以技术为主的群体，他们往往关注于IT问题本身，主要通过提升自身技术实力来解决问题，不太关注技术之外的事情。这种情况下不可避免的会出现一些问题，这就需要管理人员来解决了。

数据自动化运维应该注意哪些事项

一、基础数据概况

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、VPN等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。

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

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

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系统文档的一个存放和查阅的地方。

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

总结

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

有效运维的 on-call 机制

[编者按]本文作者为陈伯龙运维事件优先级，云告警平台 OneAlert 创始人运维事件优先级，著《云计算与 OpenStack 》，在IT运营管理、云计算方面从业10多年。

互联网技术运维事件优先级的发展，离不开运维支撑工作，没有零bug的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理：

如何有效处理紧急事件驱动的工作，成为（特别是运维主管）运维工作的关键。我接触了大量的各类型公司运维，从初创、中小、大型公司，总结和分享一些大多公司通用的on-call机制，帮助有序的处理紧急事件：

基本上都是围绕人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣也可以参考下，特别是其中的ITIL V3的运营管理。

大多公司都用了zabbix和nagios、open-falcon等监控工具，对硬件、网络、应用进行监控。可能会存在监控分散问题：

告警集中化，就是所有的生产监控发现的告警事件集中到一起，这样我们盯着一个平台就够了，同样也容易分析问题，是不是相同和类似原因。

如果监控工具单一，集中化不是最必要的，如何有序处理才是最核心的。特别运维团队是3-5人到数十／百人，就很有必要梳理下支撑流程和响应机制了。

如果管理比较细一些，还会进行业务拆分，形成一个矩阵，例如一线、二线根据不同专业，如负责网络和负责不同应用的团队。
另外还要考虑告警严重的程度级别，进行差异化处理，要求严格的同学一般会建立响应级别[1-3]或[1-5]：

那么问题来了，规划和设计挺好，如何落地呢？目前看zabbix、nagios、open-falcon等监控工具更多是聚焦如何发现问题，支撑流程属于处理问题的范畴，或者是说管理范畴，这一点目前市面上合适工具较少：

接触过一个互联网金融公司，设计了非常规范化的流程和P0-P5级别应急处理方案，涉及了网络、云平台、近50个应用研发团队。

分派升级

排班管理

再好的流程和设计，当时没有及时收到通知和处理，那么就会很郁闷了，最后一公里问题解决方式：

还支持几点：不同级别、不同时间段的设置，例如晚上严重的电话通知，白天工作时间就不用了。
这里面还存在一个问题，当告警规模大了后，特别是告警风暴的话，很容易撑爆邮箱或者是手机短信了，所以接下来就聊下告警风暴规避的问题。

这个问题比较大，基本上有些监控工具做了一部分，目前看也是一个业界难题，简单来说：

我们目前做了一些尝试分享下：

机器学习告警合并

如果告警量很大，告警后续处理和跟踪往往会依赖于外部团队（部门外或公司外）。但是监控告警粒度太细了，可能很多告警都是一个事情。如上面的告警风暴中，由于应用程序故障，引发引发了大量的异常，之后又产生连锁反应，其实就是一个事情，只需要处理一个事情就行。
一般来说一线人员会采用邮件或者电话方式，直接通知对应负责人，但是这个就很难追踪和事后分析，所以一套事件管理机制。
ITIL规范的事件Incident流程很有参考价值，感兴趣同学参考下。事件工单需要：

事件单

影响范围和紧急程度的交叉矩阵影响到优先级

On-Call机制建立后，通过告警和事件数据分析、建立起以数据指标驱动的团队文化，有机会和大家分享。

OneA lert 是 OneAPM 旗下产品，是国内第一个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想阅读更多技术文章，请访问 OneAPM 官方技术博客 。

本文转自 OneAPM 官方博客

如何做好it运维

1、深层次的IT资源监控 当IT资源出现故障的时候,运维事件优先级我们的第一反应就是快速的定位故障的根本原因以及故障影响哪些业务部门、哪些业务。以前是否出现过类似的问题,是否有成型的解决方案等等。要想能快速的定位故障的根本原因,首先运维事件优先级我们就要做到对IT资源深层次的监控。特别是对于一些应用的监控,通过指标来量化资源的健康程度。当资源出现故障时,能快速定位到问题关键性能指标。
2、建立对业务影响范围的判断机制
当资源出现故障的时候,我们需要快速的运维事件优先级了解运维事件优先级他会对哪些业务部门,哪些业务造成影响。所以我们必须有一种合理规范的机制来判断。并且当同时出现几个故障时,系统能判断服务所影响业务的重要性,以此来判断恢复故障的优先级。另外我们还得有KPI报表,统计服务的可用性。
3、自动关联同类故障
当资源出现故障时,如果能自动关联同类故障,那么将大大的提高我们处理故障的效率,提升IT服务的水平。通过知识提交、审核、发布、查询等功能自动沉淀IT部门日常运维中的工作经验,帮助各级支持人员提高技能水平,简化IT服务任务,同时降低对具体个人的依赖。并且知识库要和FAQ紧密的结合在一起,真正的提升运维的效率。
4、拓展IT服务途径,提升服务质量
建立运维人员与用户之间的联系点,统一受理用户的咨询、服务请求、故障报修、投诉等情况。并且当用户能通过FAQ查询以前出现过得同类故障。这样用户可以自己解决问题,从而降低运维人员的工作量,提升运维效率,提高用户的满意度。 关于运维事件优先级和运维事件优先级分析的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维事件优先级的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维事件优先级分析、运维事件优先级的信息别忘了在本站进行查找喔。