运维事件响应和解决时间（运维响应机制）

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

本文目录一览：

• 1、IT运维中事件管理中的服务请求有没有响应时间和解决时间？是和事件要求是一样的么？
• 2、MTTR 已死，CIRT 长存
• 3、如何做好运维工作

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

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

MTTR 已死，CIRT 长存

IT 运维圈子的玩法正在发生变化，这意味着过去的规则越来越不合理。机构需要适当环境中的准确的、可理解的、且可操作的指标，以衡量运维绩效并推动关键业务转型。

越多的客户使用现代工具，他们管理的事件类型的变化越多，将所有这些不同事件粉碎到一个桶中以计算平均解决时间来表示运维绩效的意义就越少，这就是 IT 一直以来在做的事情。

历史 表明，在分析信号以防止错误和误解时，背景信息是关键。例如，在 20 世纪 80 年代，瑞典建立了一个分析水听器信号的系统，以提醒他们在瑞典当地水域出现的俄罗斯潜艇。瑞典人使用了他们认为代表一类俄罗斯潜艇的声学特征 —— 但实际上是鲱鱼在遇到潜在捕食者时释放的 气泡声 。这种对指标的误解加剧了各国之间的紧张关系，几乎导致了战争。

平均解决时间(Mean Time To Resolve)（MTTR）是运维经理用于获得实现目标洞察力的主要运维绩效指标。这是一项基于 系统可靠性工程(systems reliability engineering)的古老措施。MTTR 已被许多行业采用，包括制造、设施维护以及最近的 IT 运维，它代表了解决在特定时间段内创建的事件所需的平均时间。

MTTR 的计算方法是将所有事件（从事件创建时间到解决时间）所需的时间除以事件总数。

正如它所说的，MTTR 是 所有 事件的平均值。MTTR 将高紧急事件和低紧急事件混为一谈。它还会重复计算每个单独的、未分组的事件，并得出有效的解决时间。它包括了在相同上下文中手动解决和自动解决的事件。它将在创建了几天（或几个月）甚至完全被忽略的事件混合在一起。最后，MTTR 包括每个小的瞬态突发事件（在 120 秒内自动关闭的事件），这些突发事件要么是非问题噪音，要么已由机器快速解决。

MTTR 将所有事件（无论何种类型）抛入一个桶中，将它们全部混合在一起，并计算整个集合中的“平均”解决时间。这种过于简单化的方法导致运维执行方式的的噪音、错误和误导性指示。

关键事件响应时间(Critical Incident Response Time)（CIRT）是评估运维绩效的一种更准确的新方法。PagerDuty 创立了 CIRT 的概念，但该方法可供所有人免费使用。

应用这些假设对响应时间有什么影响？简而言之，效果非常非常大！

由于 MTTR 计算的响应时间长得多、人为地偏差，因此它是运维绩效较差的一个指标。另一方面，CIRT 是一项有意的措施，专注于对业务最重要的事件。

与 CIRT 一起使用的另一个关键措施是确认和解决事故的百分比。这很重要，因为它验证 CIRT（或 MTTA / MTTR）是否值得利用。例如，如果 MTTR 结果很低，比如 10 分钟，那听起来不错，但如果只有 42％ 的事件得到解决，那么 MTTR 是可疑的。

总之，CIRT 和确认、解决事件的百分比形成了一组有价值的指标，可以让你更好地了解运营的执行情况。衡量绩效是提高绩效的第一步，因此这些新措施对于实现机构的可持续、可衡量的改进周期至关重要。

via: https://opensource.com/article/19/7/measure-operational-performance

作者： Julie Gunderson 选题： lujun9972 译者： wxy 校对： wxy

如何做好运维工作

一、运维方法
技术层面：
随着信息技术运维事件响应和解决时间的发展以及企业业务的不断扩张运维事件响应和解决时间，运维人员所面临的系统架构越发的复杂，关联度越发紧密。对运维人员的要求也会越来越高，打造个个都是高手，对业务系统运维事件响应和解决时间了如指掌。
1、需要运维人员快速转变观念，学会通过主动运维的方式应对复杂多变的 IT 问题，保证业务系统的稳定。
2、更多的站在客户的层面思考问题，解决问题。
3、使用集成的运维平台，在业务系统没有感知的情况下实现运维事件响应和解决时间了业务的变更、升级。
运维文档层面：
一个好的系统或者项目，必定有很多的文档进行支撑。
1、系统建设前期，一定要做好系统的需求文档、设计文档、实施文档。在系统建设中要依据前期的文档进行实施和设计，并生成系统相关的问题总结文档和更新实施文档。
2、系统建设完成后，要基于系统的业务能力和使用对象编写操作手册和运维手册等。
3、业务在交付一定要文档同行。否则系统上线后问题层出不穷，导致运维人员手忙脚乱，不知道从何下手处理，往往会让运维人员绕很多的弯路，错失良机。
4、文档归类保存：文档也分好多种，比如配置文档、实施文档、设计文档、系统规范性文档、项目管理文档等等。做到一式两份，运维部门一份，档案室一份。
5、要求运维人员一定要具备相应的文档编写能力和整理能力。同时一定要严格按照之前的文档进行实施，有问题要学会及时沟通，并把修正后的问题更新到文档中。
6、建立知识库：把运维过程中出现的问题及解决办法和思路，另外最重要的是运维事件的总结，记录在案。
运维流程层面：
1、建立运维流程。要求运维人员一定要基于一个既定的规则来干活。
2、通过流程确定事件责任。业务人员专注点与运维人员的专注点不同，责任也不同。
3、使用ITIL 了（即 IT 基础架构库(Information Technology Infrastructure Library，ITIL，信息技术基础架构库)。ITIL 为企业的 IT 服务管理实践提供了一个客观、严谨、可量化的标准和规范。
二、运维人员技术
正所谓工欲善其事，必先利其器。很多的企业都在强化以用户服务为中心，专业技术为驱动的理念，可见拥有过硬的技术是多么的重要。
1、运维人员必须掌握的技能：
运维对技术的要求是很高的，首先运维人员要对自己所负责的系统有较深的理解，全程参与系统的设计、实施与运维。一定要具备相关领域的技术积累，有较丰富的设计或者排错经验
同时运维人员具备以下软实力：如沟通能力、合作心态和文档编写能力。
2、运维人员一定要对现在的主流技术有一定的涉猎（云计算、边缘计算、大数据、AIOps、人工智能、深度学习等等），要与时俱进。
3、经常参与线上或者线下的相关讨论和交流学习。了解目前流行的 IT 技术，并学习它，思考如何将其用于企业的业务中，为企业创造价值，提升运维效率。所以具备主流技术的捕捉能力，也是运维人员的必修课之一。
三、运维现场监控层面
监控的目的就是防患于未然。通过监控，运维人员能够及时了解到企业网络的运行状态。
一旦出现安全隐患，可以及时预警或者是以其他方式通知运维人员，让运维监控人员有时间处理和解决，避免影响业务系统的正常使用，将一切问题的根源扼杀在摇篮当中。现在的监控工具可以在监控指标触发时，自动修复一些故障，但是它最多帮运维事件响应和解决时间你做些简单的自动化任务，更高阶的自动化任务需要运维人员具备较深的脚本和系统知识。 关于运维事件响应和解决时间和运维响应机制的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维事件响应和解决时间的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维响应机制、运维事件响应和解决时间的信息别忘了在本站进行查找喔。