MTTR

장애가 끝난 자리에는 오래도록 숫자가 남지 않았습니다. 남는 것은 인상뿐이었습니다. 누군가는 "요새 자주 터지는 것 같은데" 라고 말하고, 개발팀은 "그래도 지난번보다는 빨리 복구했습니다" 라고 답했습니다. 양쪽 다 근거가 없으니 대화는 매번 같은 자리에서 끝났고, 다음 분기에 무엇을 고쳐야 할지도 정해지지 않았습니다.

분기 리뷰 장면이 특히 그랬습니다. 대표가 "지난달 그 건은 왜 그렇게 오래 걸렸어요" 하고 물으면 답은 대개 "원인 찾는 데 시간이 좀 걸렸습니다" 였습니다. 좀이 30분인지 여섯 시간인지는 아무도 몰랐습니다.

MTTR은 그 자리를 숫자로 바꾸려고 들여온 값입니다. 원래는 공장 설비를 다루던 말이었습니다. 멈춘 기계를 다시 돌리기까지 평균 몇 분이 걸리는지를 재서 정비 인력을 어디에 둘지 정하던 지표가, 서비스가 멈추면 매출이 멈추는 소프트웨어 운영으로 그대로 넘어왔습니다. 여기서 재는 대상은 인시던트, 즉 사용자가 하려던 일을 못 하게 만든 사고입니다. 로그에 찍힌 오류 전부가 아니라 영향이 확인된 것만 셉니다.

사고 한 건마다 복구까지 걸린 시간을 재고, 정한 기간 안에 일어난 사고 전부의 시간을 더한 뒤 건수로 나눕니다.

계산은 세 단계입니다.

1. 사고마다 시작 시각과 끝 시각을 정합니다. 시작은 사용자 영향이 시작된 시각이고, 끝은 서비스가 정상 동작을 회복한 시각입니다.
2. 건별 소요 시간을 구합니다. 한 달에 세 건이 있었고 각각 20분·40분·180분이 걸렸다면 합은 240분입니다.
3. 건수로 나눕니다. 240분을 3으로 나눠 이달 MTTR은 80분입니다.

걸리는 곳은 1번의 시작 시각입니다. 발생한 시각부터 셀지, 알림이 울려 팀이 알아챈 시각부터 셀지를 팀이 먼저 정해야 합니다. 알아챈 시각부터 세면 탐지가 늦은 팀일수록 숫자가 좋아지는 뒤집힌 결과가 나옵니다. 새벽 두 시에 시작된 장애를 아홉 시에 발견하고 아홉 시 반에 고쳤다면, 발생 기준으로는 7시간 30분이고 탐지 기준으로는 30분입니다. 사용자가 겪은 시간은 7시간 30분입니다.

집계 단위도 미리 정해 둡니다. 보통 월이나 분기로 끊는데, 건수가 적으면 평균이 크게 흔들립니다. 20분·25분·30분 세 건이면 평균 25분이지만 여기에 8시간짜리 한 건이 끼면 평균은 141분으로 뜁니다. 그래서 평균만 보지 않고 중앙값과 가장 오래 걸린 건을 같이 적습니다. 평균은 큰 사고 한 건에 끌려가고 중앙값은 보통의 사고가 어땠는지를 보여 줍니다.

이 값에는 모든 팀에 통하는 합격선이 없습니다. 결제가 몇 분만 멈춰도 돈이 새는 서비스와 하루 한 번 도는 정산 배치는 같은 기준으로 잴 수 없습니다. 기준은 SLA, 즉 고객과 계약서에 적어 약속한 서비스 수준에서 거꾸로 내려옵니다. 월 99.9퍼센트 가동을 약속했다면 한 달에 멈춰도 되는 시간이 43분뿐이라, 사고 한 건을 한 시간씩 끌면 약속이 그 달에 깨집니다.

굳이 눈대중을 대자면 운영이 자리 잡은 팀은 대개 한 시간 안쪽에서 끝내고, 복구가 하루를 넘어가면 절차 어딘가가 비어 있다고 봅니다. DORA 지표도 개발 조직의 성과를 재는 네 값 가운데 하나로 복구 시간을 넣어 두고, 상위 그룹의 기준을 한 시간 미만으로 잡습니다.

정작 읽을 것은 절대값이 아니라 추세입니다. 네 시간이던 값이 두 분기에 걸쳐 40분이 됐다면 당번 체계와 복구 절차가 자리를 잡았다는 뜻입니다. 줄이는 방법은 원인을 빨리 찾는 쪽이 아니라 원인을 나중에 찾는 쪽에 있습니다. 롤백으로 직전 버전에 되돌려 서비스를 먼저 살리고 원인은 그다음에 캡니다. 원인을 밝힌 뒤에 고치려 들면 그 시간이 전부 사용자가 기다리는 시간이 됩니다.

온콜 당번표가 비어 있는 시간대가 있는지도 같이 봅니다. 금요일 밤에 시작된 사고가 월요일 아침에 발견되는 팀은 고치는 실력과 무관하게 이 값이 나쁩니다.

"이번 분기 MTTR이 2시간 40분에서 55분으로 줄었습니다."

사고가 줄었다는 말이 아니라 한 건을 끄는 데 걸리는 시간이 짧아졌다는 말입니다.

"그 건은 탐지가 늦어서 MTTR이 통째로 밀렸어요."

고치는 데 걸린 시간은 짧았고 알아채는 데 시간을 다 썼다는 뜻입니다.

"MTTR을 30분으로 목표 잡으면 원인 분석을 건너뛰게 됩니다."

숫자를 목표로 걸었을 때 생길 부작용을 미리 막는 말입니다.

페이지덱에서는 태오가 매달 운영 리뷰에 이 숫자를 들고 들어옵니다. 지난달 사고가 다섯 건이었고 평균은 90분인데, 태오는 그 옆에 중앙값 22분과 가장 오래 걸린 건 6시간을 나란히 적어 둡니다. 평균을 끌어올린 것은 그 6시간짜리 한 건이고, 그 건은 고치는 데 25분이 걸렸으며 나머지 다섯 시간 반은 아무도 모르고 지나간 시간이었습니다.

규원이 여기서 묻는 것은 "왜 90분이냐" 가 아니라 "그 다섯 시간 반 동안 왜 아무 알림도 울리지 않았냐" 입니다. 그래서 다음 분기 과제는 복구를 빠르게 만드는 일이 아니라 알림 규칙을 손보는 일이 됐습니다.

값이 낮으면 서비스가 안정적이라고 읽는 경우가 가장 많습니다. 복구가 빠르면 사용자가 겪는 불편도 짧으니 자연스러운 연결입니다. 하지만 이 값은 사고가 얼마나 자주 나는지에 대해서는 한마디도 하지 않습니다. 하루에 세 번 터지는 서비스라도 매번 10분 만에 끄면 MTTR은 10분이고, 석 달에 한 번 터지지만 그때마다 반나절이 걸리는 서비스보다 숫자가 좋습니다. 이 값만 보고 운영을 평가하면 팀은 불을 빨리 끄는 데만 능숙해지고, 불이 왜 나는지를 다루는 일은 매번 다음 분기로 밀립니다.

목표 숫자로 거는 것도 자주 나오는 실수입니다. 재는 값을 목표로 바꾸면 사람은 그 값을 만들기 쉬운 쪽으로 움직입니다. 30분이라는 목표를 받은 팀은 포스트모템을 건너뛰고 서둘러 종료 선언을 하거나, 애초에 작은 건을 사고로 세지 않는 쪽을 고릅니다. 등급 기준을 조금만 올려 잡아도 짧은 건들이 목록에서 빠지면서 평균이 내려갑니다. 반년 뒤에는 숫자만 30분에 맞춰진 채 사용자가 겪는 장애 시간은 그대로 남습니다.