前不久，我们讨论了运维不容错过的 4个关键指标，其中平均解决时间（MTTR）被认为是衡量业务的最佳标准，随后也分析了「告警等级」对MTTR的重要性。
###正确看待 MTTR
MTTR 为从故障发生到故障修复所经历的时间。总故障时间是关于告警事件数量与各告警事件时长的函数。经过仔细地探讨这两项因素及其优先级，结合具体情况，总结以下策略用来缩短MTTR：
####1）加快工作速度 = 然并卵
如果想通过加快工作速度降低 MTTR，理论上是完美的，但是骨感的现实根本不按我们的剧本走！为了对 MTTR 进行持续的、可衡量的改进，应该对故障事件进行深入的调查，分析事件的复杂程度及重要程度，然后从人与系统的协作上，实现对流程进行优化。
####2）检验告警响应时间
一旦事件发生，「MTTR」时钟便开始计时。通过调整通知流程，或许就能速战速决。下图为常见故障处理过程：
还不够直观？数据来说话。 OneAlert 一个月的告警数据显示：平均响应时间为 2.8 分钟；平均解决时间为 27 分钟。（不要问我为什么你们的响应时间要好几个小时！）
如果你的响应时间较长，建议检查一下团队值班响应机制，告警是否可有效传达给了正确的人？如果一线排版人员无响应，告警能否自动升级？升级时间阈值是多少？通过设定接近平均响应时间的适当期望值和目标，能确保所有成员尽快对告警作出响应。
####3）建立故障解决流程
告警响应时间过长，说明告警响应机制存在问题，故需建立有效的故障解决流程，即需确保以下内容：
-
建立有效沟通协议——明确每个人的任务分工，确立有效沟通方式。以 OneAlert 为例，团队的沟通方式主要有 QQ 群聊、WeChat 聊天室、钉钉等。
-
确定团队领导人——此人将在解决故障期间带领团队工作。需要做好记录并合理安排工作。
-
做好记录——应当详细记录故障期间发生的一切。这些记录在你事后回顾之时将会非常有用。OneAlert 团队领导人还会定期总结告警事件。
-
熟能生巧——确保团队中每一个人都不是告警响应的新手。
####4）找到并解决问题 事件解决时间大部分花在确定告警问题的过程中。所以，如何更快的明确问题的关键，是目前各大监控工具抢占市场的核心武器。但是未来可以肯定的是，找到问题还不够，自动化处理才是发展的出路。这部分内容将在后期的文章中深入探讨。
OneAlert 是应用性能管理领军企业 OneAPM 公司旗下产品，也是国内首个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想了解更多信息，请访问 OneAlert 官网 。
本文转自 OneAPM 官方博客
来源：oschina
链接：https://my.oschina.net/u/2365986/blog/598775