![作为运营团队,您使用什么工具来衡量您的 MTTR?](https://linux22.com/image/776848/%E4%BD%9C%E4%B8%BA%E8%BF%90%E8%90%A5%E5%9B%A2%E9%98%9F%EF%BC%8C%E6%82%A8%E4%BD%BF%E7%94%A8%E4%BB%80%E4%B9%88%E5%B7%A5%E5%85%B7%E6%9D%A5%E8%A1%A1%E9%87%8F%E6%82%A8%E7%9A%84%20MTTR%EF%BC%9F.png)
你测量过它吗?
我的问题是,当出现中断警报时,首先创建 JIRA 票证会感觉很浪费时间,所以我立即开始解决它。此外,一些中断首先通过变通方法解决,然后重新审视以正确解决它们。
答案1
“我的问题是,当收到中断警报时,感觉先创建 JIRA 票很浪费时间”
这当然很容易解决,大多数警报系统可以同时发出多个警报,其中一个警报可以自动创建 Jira 票证。
关闭该 Jira 票证的一部分可以是记录(以适合您的任何方式/系统)您同意的修复时间的管理任务。
(已经暗示了,但让我明确说明:您的票务系统跟踪的票务解决时间与修复时间不同。)
当故障单解决时间很重要,并且本身就是一个性能指标时,您可能希望在中断解决后立即关闭自动生成的故障单。
当您开始根本原因分析 (RCA) 调查时,请使用相关但新的问题调查故障单 #XYZ(它具有不同的性能标准,并且报告方式与中断故障单不同)。
根据 RCA 的结果,您可以开始着手实施永久性修复/缓解措施,并根据需要执行的操作再次以不同的方式进行跟踪。