这是《运维不容错过的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 的一些核心设计理念，希望对大家有些帮助。
