MTTD, MTTR - 장애 대응 능력의 현재 지표

MTTD, MTTR: 장애 대응 능력의 현재 지표

모든 서비스들은 장애가 나기 마련이다.

놓친 버그와 같은 내부 요인이나, 인프라 등의 외부 요인 등 원인은 다양하다.

그런데, 장애가 발생했다고 하여 마냥 손놓고 있을 수는 없지 않나?

우리는 장애를 수동적으로 맞이하고 있는지 혹은 적극적으로 대응하고 있는지를 데이터로 알 수 있지 않을까?

우리 팀/ 우리 서비스의 장애 대응 능력은 어느 정도 수준일까?

우리는 장애 대응을 얼마나 잘 하고 있나?

를 알 수 있는 지표를 정리한다.

 

MTTD: 우리는 얼마나 빨리 장애를 인지하고 있나?

MTTD(Mean Time To Detect)는 장애를 인지하는데 걸리는 평균시간을 뜻한다.

왜 평균이냐면, 발생한 장애 한 건으로 장애 인지 능력을 평가할 수 없기 때문에 평균값으로 MTTD를 산출한다.

 

 

MTTR: 우리는 얼마나 빨리 장애를 복구하고 있나?

MTTR(Mean Time To Repair)는 장애 발생 인지 이후, 장애를 복구하는데 걸리는 평균시간을 뜻한다.

마찬가지로, 발생한 장애 한 건으로 장애 복구 능력을 평가할 수 없기 때문에 평균값으로 MTTR을 산출한다.

 

좋은 MTTD, 좋은 MTTR

MTTD가 작을 수록, 우리는 장애를 빨리 인지할 수 있는 능력을 갖췄다고 할 수 있다.

즉, 고객이 우리에게 문제를 리포트도 하기에 앞서 문제를 사전 인지할 수 있을 것이다.

좋은 MTTD의 방해 요소는 어떤 것이 있을까?

알람의 noise가 대표적이다. 양치기 소년을 생각해 보자.

장애 알람에 거짓 정보가 섞여 있으면, 장애인지를 하는데 필터링의 과정이 들어가야 한다.

그러면, 장애 인지의 품질 저하가 수반될 것이다.

그리고, 감지한 내용을 적절한 팀에 적시에 안내할 수 있어야 한다.

MTTR이 작을 수록, 우리는 장애를 빨리 복구할 수 있는 능력을 갖췄다고 할 수 있다.

반응형

 

좋은 MTTR의 방해 요소는 어떤 것이 있을까?

만약, 장애가 발생했는데 원인이 무엇인지 모른다면, 어떻게 해결할지 처방하는데도 오래 걸릴 것이다.

문제를 찾았는데, 그 절차가 명확하게 기술되어 있지 않다면 장애 복구를 하는데도 오래 걸릴 것이다.

즉, 누가/언제/무엇을/어떻게 할 것인가가 명확히 나뉘어 있고, 그 절차가 얼마나 능숙하게 훈련이 되어 있느냐가 영향을 준다.

 

참고

RTO, RPO - 장애복구의 목표 기준