摘要：平均解决事件解决时间是衡量业务准备的最佳标准。平均每小时折合损失。说明整个团队的响应及时率是不错的。小结致力减少告警数量及时响应如果不能及时响应，能够升级处理，最终提升解决时间，个核心关键指标是运维支撑工作非常关键的指标。
很难说，生活在这个数据大爆炸的时代对运维同学是福还是祸。灵活的监控系统、开放 API 和易用的数据可视化资源可以将任何想要的数据图表化地显示出来，但是，过多的数据容易产生干扰，反而不利于具体信息提取和操作。
关于监控哪些指标，以及为什么要从系统化的角度出发，我们进行过深入的思考。本文中，我们想与大家分享一些具体的指标和准则，进一步帮助团队衡量并提高运维性能。以下整理了4个关键性运维指标：
告警事件数量如果团队中的事件数量呈现上升趋势，那么很有可能是哪里出了问题：要么是基础设施有故障，要么是监控工具配置错误需要调整。
随着公司的发展，组织结构会调整，同时业务产品也会不断升级，配套监控也会同步上线，告警事件数量会急剧增加。「我们浪费了大量时间来关闭冗余报警。」－－相信很多同学都会有类似的体会。告警事件数量是可控的：
告警数量可统计，如这周告警数量是多少，与新发布的产品系统有没有关系，发生哪些问题？
告警数量是可操作的，意味着每一个告警都是有意义并且是需要处理和操作的，如果仅仅是瞅一眼的数据，请不要通过告警方式。例如100＋机器时，每台机器的「CPU 使用率高」告警是没有啥用的，你知道机器 CPU 使用率高后，你能做什么操作呢？你可能直接忽略掉，当数量大到你把需要处理的告警也忽略掉时，告警就失去了意义。类似指标完全可以通过周报／日报进行数据的性能分析，而不是告警。
平均解决事件（ MTTR ）解决时间是衡量业务准备的最佳标准。当事件发生时，你的团队需要多长时间才能解决？
宕机不仅会影响你的收入，还会伤害客户用户体验和忠诚度，所以确保团队对所有事件可以快速响应极为关键。
全球500强企业平均每周出现严重故障时间长达1.6小时。
平均每小时折合损失$96,000。
当然，跟踪解决时间固然重要，但对其进行规范往往很难，企业可以根据环境的复杂性、团队和基础设施的责任制、行业及其他因素，进一步观测 MTTR 的差异。但是，规范化的操作手册、自动化的基础设施管理、可靠的告警升级策略都有助于减少事件，和提升 MTTR。
优秀的团队减少事件数量，并及时解决（ MTTR ），所以平均解决事件需要和上面告警数量一样，需要记录和统计分析，目前大多监控工具往往不具备类似能力，如果没有精力或者资源自行开发的话，我们就建议使用第三方平台OneAlert 。
有关如何减少事件数量，避免告警疲劳的事情，后续将会有独立文章进行发布。
平均响应时间（ MTTA ）如果说平均解决时间是结果，那么平均响应时间就是重要的过程指标，这一点往往被大多团队忽略掉。可以理解为告警越快发现，越快有人响应，就能够越快的解决（更好的MTTR）。
提升 MTTA 的核心是找对人、找到人。上图中如果02:01能够及时通知到位就可以节省至少4个小时时间。
说起来简单，实际上找对人有些工作（只1人运维的请忽略），一般是从职责责任制、协调机制、工作进程透明、工作量和时间可衡量等几点进行，后面针对「有序分派」再补充一篇。
除了以上机制，还有一点，就是需要记录谁什么时候确认响应告警，并做了哪些处理，能够持续跟踪，以及统计分析。
响应时间非常重要，因为它能帮助你了解哪些团队和个人处于随叫随到的状态。快速响应时间是一个战备文化的代表，你会发现具备快响应观念和工具的团队往往可以更快地修复事件。
如果使用像 OneAlert 的事件管理系统，[升级超时]有助于推进响应目标。例如，如果你希望所有事件都应该在5分钟内回复，可以将超时设置为5分钟，从而确保下一个接收人会收到提醒。再根据团队的整体表现，来决定是否需要调整目标，然后再跟踪升级事件的数量。
升级对于大多数使用事件管理工具的组织而言，告警升级是一种异常现象，该迹象表明首次应该响应的时候，无法及时应对事件，或许相关工具和人员技能失效。升级策略是事件管理的必须，各个团队应努力推动升级，实现升级事件数量的下降。
优秀的运维团队需要建立起有效的一线、二线、甚至三线响应机制，告警及时通知到一线，如果一线没有及时处理，可以自动升级至二线运维，保障每一个重要事件能够得到及时响应和处理。
有些情况下，升级是标准作业实践的一部分。例如，你可能有一个 NOC，一线支持团队或者自动修复工具，可根据内容来升级或分诊输入事件。这种情况下，一线更多像一个路由转发器，可以通过人工＋工具自动化方式实现。
示例分析
这是某个团队一个月的告警数据剖析：
告警数量在11-18前相对稳健，平均在3-5个告警。第3周告警突飞猛进，原因是新的业务上线，引发突增。经过周回顾，优化监控策略，在第4周经过初步优化，告警数量有所降低，运维团队工作初见成效，还需要继续优化。
告警响应时间 MTTA ，基本上都能够比较好的响应，基本在5分钟内响应。说明整个团队的响应及时率是不错的。同时也看到在第3、4周六的时候，明显的响应时间延迟较大，说明一个问题，周末的支撑工作有提升空间。
恢复时间 MTTR ，基本保持在20分钟左右，说明恢复比较及时，但是也有可能存在事件无需关注，自动恢复。后者需要针对事件的类型、根源进一步分析，后续文章再剖析。
升级，目前该团队基本上是5分钟升级，所以会看到在大部分问题能在5分钟内响应完成。
小结致力减少告警数量、及时响应 MTTA 、如果不能及时响应，能够升级处理，最终提升解决时间 MTTR，4个核心关键指标是运维支撑工作非常关键的指标。
运维是结合管理流程、工具、人员三方面的综合化工作，OneAlert 期望构建一个告警平台，能够帮助运维同学更有效率的完成支撑工作。
OneAlert 是北京蓝海讯通科技股份有限公司旗下产品，中国首个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有IT事件，提升IT可靠性。想了解更多信息，请访问 OneAlert 官网 。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/7946.html
摘要：为了掌握你的告警事件响应时间，在你已经开始处理告警时，强烈建议及时响应认领，例如通过移动端微信页面移动等方式及时认领。这一点国外做的很棒，在短信电话移动都可以很容易确认认领在微信端可以认领和关闭。 这是《运维不容错过的4个关键指标》的姐妹篇，上篇文章介绍了优秀运维团队需要关注的4个关键指标，我们分享了平均恢复时间 MTTR、平均响应时间 MTTA 等概念。这篇是介绍一些实践方法，更好的...
摘要：总故障时间是关于告警事件数量与各告警事件时长的函数。一个月的告警数据显示平均响应时间为分钟平均解决时间为分钟。确定团队领导人此人将在解决故障期间带领团队工作。找到并解决问题事件解决时间大部分花在确定告警问题的过程中。 前不久，我们讨论了运维不容错过的 4个关键指标，其中平均解决时间（MTTR）被认为是衡量业务的最佳标准，随后也分析了「告警等级」对MTTR的重要性。 正确看待 MTTR ...
摘要：告警当一个问题通过告警系统将消息以短信电话邮件等方式告知给用户时，我们称之为一条告警。图统一告警系统结构图告警收敛对于告警平台每天会产生数以万计的告警，这些告警对于运维或开发人员都需要去分析甄别优先级并处理故障。 一、背景一套监控系统检测和告警是密不可分的，检测用来发现异常，告警用来将问题信息发送给相应的人。v...
摘要：阻塞，非阻塞首先，阻塞这个词来自操作系统的线程进程的状态模型网络爬虫基本原理一后端掘金网络爬虫是捜索引擎抓取系统的重要组成部分。每门主要编程语言现未来已到后端掘金使用和在相同环境各加载多张小图片，性能相差一倍。 2016 年度小结（服务器端方向）| 掘金技术征文 - 后端 - 掘金今年年初我花了三个月的业余时间用 Laravel 开发了一个项目，在此之前，除了去年换工作准备面试时，我并...
摘要：阻塞，非阻塞首先，阻塞这个词来自操作系统的线程进程的状态模型网络爬虫基本原理一后端掘金网络爬虫是捜索引擎抓取系统的重要组成部分。每门主要编程语言现未来已到后端掘金使用和在相同环境各加载多张小图片，性能相差一倍。 2016 年度小结（服务器端方向）| 掘金技术征文 - 后端 - 掘金今年年初我花了三个月的业余时间用 Laravel 开发了一个项目，在此之前，除了去年换工作准备面试时，我并...
阅读 2966·2021-08-03 14:05
阅读 2013·2019-08-29 15:35
阅读 544·2019-08-29 13:30
阅读 3057·2019-08-29 13:20
阅读 2394·2019-08-23 18:15
阅读 1695·2019-08-23 14:57
阅读 2084·2019-08-23 13:57
阅读 1175·2019-08-23 12:10
