如何让运维指标变得更有价值?

原创
2015/12/15 11:05
阅读数 35

这是《运维不容错过的4个关键指标》的姐妹篇,上篇文章介绍了优秀运维团队需要关注的4个关键指标,我们分享了平均恢复时间 MTTR、平均响应时间 MTTA 等概念。这篇是介绍一些实践方法,更好的使用工具进行优化以上指标。

##以 MTTA 为指导原则

MTTA 是衡量响应一个告警事件的关键性指标。为了掌握你的告警事件响应时间,在你已经开始处理告警时,强烈建议及时响应(认领),例如通过移动端、微信、页面、移动 APP 等方式及时认领。特别是如果有多人运维、并且设置了升级处理的策略,该实践会非常有用,你可以知道现在是谁在处理,处理进展怎样,你就不用担心告警没通知到位或者是没有处理了。

大多数优秀的运维团队,往往会将 MTTA 作为最关键的指标之一,因为这是可控和可操作的。有故障时,我们很难控制最终的恢复时间,毕竟涉及问题较多;但是至少可以保证响应及时率。优秀的运维告警平台很容易就能够能够跟踪整个团队的 MTTA ,包括现状、历史趋势,团队是否可以达到响应标准。

可能有同学会质疑,因为大家经常是第一时间就开始处理告警,往往忽略掉响应(认领),平时如果多个人协作同学坐一起,会吼一句「放着我来!」就能搞定,需要这么复杂么。

没有数据记录,就没有优化基础。比如如果人员不集中的话,或者是事情多了,就容易沟通不畅或遗漏,使用工具能够避免该问题。

很多告警工具需要同学们在 PC 上登录到告警系统去认领一下(甚至拨 VPN 访问内网),确实很麻烦。这一点国外 PagerDuty 做的很棒,在短信、电话、移动 APP 都可以很容易确认/认领; OneAlert 在微信端可以认领和关闭。移动化和快捷是实践 MTTA 的重要保障。

##解决问题需要记录

我们强烈建议及时更新记录告警的解决时间,当解决告警或者是告警自动恢复后,及时在告警系统上记录/更新告警的状态为关闭或者是恢复。例如使用 PagerDuty 、 VictorOps 、或者国内 OneAlert 时,可以人工记录告警关闭。并且如果使用 API 或者其他工具集成方式,会自动化同步监控工具的告警状态。

##谨慎使用超时时间

不少监控工具都具备自动升级规则,一般会支持告警自动关闭,即如果长时间没有关闭/恢复告警,告警系统会自动关闭掉,该参数会影响到最终的 MTTR 。

如果你没有形成解决故障后,及时更新告警平台上告警状态的习惯,那么超时自动关闭时间能够避免该问题。PagerDuty 的服务和 OneAlert 的应用都支持超时自动关闭时间设置,一般是30分钟-4小时。如果使用超时自动关闭,那么可能会在数据统计周报中影响到最终 MTTR,统计数据会比实际更长,这一点不是很利于团队执行效率优化,需要谨慎使用。

##抖动告警(flapping alert) 抖动告警(flapping alert)是指告警触发后,即刻恢复,之后又触发并恢复,反复多次。抖动告警的原因大多是监控指标在阈值范围附近频繁抖动。抖动告警会引发 MTTA 和 MTTR 数据异常,通常表现为大量的告警数量,但是很小的 MTTA 和 MTTR 值,甚至没有 MTTA。因为告警还没有来得及响应(认领)就已经被自动关闭了。

还有一点,非常重要的是抖动告警往往会引发告警疲劳,即大量无需处理的告警出现,会增加运维人员负担,往往会忽略掉重要告警。所以非常有必要通过周报分析的方式识别出哪些抖动告警,大部分情况下可以通过优化阈值方式优化。如可参考 Nagios flapping 设置。

##小结 上一篇《运维不容错过的4个关键指标》和这篇文章,分享了国外PagerDuty、VictorOps和国内 OneAlert 的一些核心设计理念,希望对大家有些帮助。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部