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.