July 30, 2021 at 9:16 am
Personally I'm not a fan of using MTTI and MTTR for anything other than incident management and designing the procedures that allows the company to keep functioning as effectively as possible during the incident.
If you use them as a performance metric, the MTTI and MTTR often end up in conflict with each other. Since it's often faster to guess and test that an identified defect is responsible for the incident than to rectify the defect and see if that resolves the incident. Even if the latter is more likely to lead to a shorter MTTR (provided defects are continuously rectified as an ongoing process during the lifecycle of the system).
Both of these metrics also actively penalize rolling out any kind of update to the software or infrastructure. In order for these metrics to be of any relevance I think they need to be multiplied by incident frequency, incident related costs and production value (a number describing how much the problem that the system solves is worth to the company). With those factors added you would have the tools required to describe the value of the system operating as intended as opposed to periodically failing by design in a predictable manner.
July 30, 2021 at 10:57 am
In my last position there was usually a gulf between project managers (Get it running!) and DBAs (Get it fixed!).
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
July 30, 2021 at 12:56 pm
As far as I know, there is no tracking of MTTR. I could be wrong, however. I work in a large IT shop, so perhaps upper management does track this, without passing what they've learned down.
On the other hand, although I've known about MTTR and other similar metrics, I've never worked anywhere that actually tracked it.
Rod
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply