MTBF

장애가 얼마나 자주 나는지는 오랫동안 느낌으로만 오갔습니다. 개발팀은 "요즘 꽤 안정적입니다" 라고 하고 영업은 "저번 주에도 고객사에서 연락 왔는데요" 라고 했습니다. 둘 다 거짓말이 아니었습니다. 한쪽은 큰 사고가 없었던 것을 기억했고 다른 쪽은 자기 고객이 겪은 두 번을 기억했을 뿐입니다.

복구가 빨라지면서 이 어긋남이 더 커졌습니다. 예전에는 한 번 멈추면 반나절이 갔으니 누구나 기억했는데, 되돌리는 절차가 자리 잡으면서 3분 만에 정상으로 돌아오는 일이 늘었습니다. 3분짜리 중단은 기억에 남지 않습니다. 그래서 한 달에 열두 번 멈춰도 개발팀 눈에는 조용한 달로 보이고, 하필 그 순간 저장을 누른 고객에게는 열두 번 다 사고입니다.

페이지덱에서도 같은 장면이 있었습니다. 월간 회고에서 태오가 "이번 달은 큰 장애 없이 넘어갔습니다" 라고 하자 지현이 "저는 문서 저장이 세 번 막혔어요" 라고 답했습니다. 두 사람이 같은 달을 다르게 기억한 이유는 한쪽이 사고의 크기를 세고 다른 쪽이 사고의 횟수를 셌기 때문입니다.

MTBF 는 그 횟수 쪽을 숫자로 고정한 값입니다. 얼마나 심했는지가 아니라 얼마나 자주였는지만 봅니다. 그래서 "요즘 안정적이다" 라는 말이 "장애 간격이 60시간에서 240시간으로 늘었다" 로 바뀝니다.

정상으로 돌아간 시간을 모두 더해 그 기간의 장애 건수로 나눕니다. 30일(720시간) 동안 장애가 3건 났고 멈춰 있던 시간이 합쳐서 6시간이었다면, 정상 가동 714시간을 3으로 나눠 238시간입니다. 열흘에 한 번꼴로 멈췄다는 뜻입니다.

계산은 네 단계입니다.

1. 기간을 정합니다. 한 달이 기본이고, 장애가 드문 서비스는 분기로 잡습니다. 기간이 짧으면 한 건 차이로 값이 크게 흔들립니다.
2. 무엇을 셀지 정합니다. 인시던트로 판정된 건만 셉니다. 서버 로그에 쌓이는 오류 가운데 사용자가 하려던 일을 못 하게 만든 것만 사고로 보는 개념입니다.
3. 정상 가동 시간을 구합니다. 전체 시간에서 멈춰 있던 시간을 뺍니다.
4. 그 값을 장애 건수로 나눕니다.

2번이 이 숫자의 성격을 거의 다 결정합니다. 심각도 등급을 어디까지 세느냐에 따라 같은 달의 값이 크게 달라집니다. 전체 사용자가 저장을 못 한 1등급만 세면 이번 달 장애는 1건이고 MTBF 는 714시간이 됩니다. 특정 브라우저에서 글자가 깨진 3등급까지 세면 9건이 되고 MTBF 는 79시간으로 떨어집니다.

그래서 세는 기준을 먼저 글로 적어 두고, 그 기준을 바꾼 달에는 앞뒤 값을 이어 붙이지 않습니다. 기준을 넓힌 달에 숫자가 반 토막 나는 것은 서비스가 나빠진 것이 아니라 자를 바꾼 것입니다.

절대 기준은 없습니다. 몇 시간이면 좋은 값인지는 서비스가 무엇을 하느냐에 달려 있습니다. 결제를 처리하는 시스템에서 240시간은 위험한 값이고, 사내에서만 쓰는 보고서 생성 도구에서는 넉넉한 값입니다. 그래서 비교 대상은 같은 기준으로 잰 자기 과거뿐입니다.

방향은 하나입니다. 이 값은 늘어나야 합니다. 60시간에서 240시간이 됐다면 장애 간격이 네 배로 벌어진 것이고, 그렇게 만드는 수단은 근본 원인 분석에서 나온 개선 항목이 실제로 처리되는 것뿐입니다. 디스크가 가득 차서 멈춘 사고에서 디스크를 비우는 일은 복구이고, 남은 용량이 줄면 알림이 울리도록 알림을 걸어 두는 일이 이 숫자를 늘립니다.

반드시 MTTR과 함께 봅니다. 장애를 복구하는 데 걸린 평균 시간이고, 이 값만 보면 팀은 불을 빨리 끄는 데만 능숙해집니다. 두 값을 합치면 가동률이 나옵니다. MTBF 가 720시간이고 MTTR 이 1시간이면 720을 721로 나눠 99.86퍼센트입니다. 간격을 두 배로 벌리는 것과 복구를 절반으로 줄이는 것이 가동률에는 같은 크기로 작용합니다.

표본이 적다는 점도 감안합니다. 한 달에 장애가 2건이면 한 건이 늘고 주는 것만으로 값이 절반이 되거나 두 배가 됩니다. 2건에서 3건으로 는 달은 357시간에서 238시간으로 떨어지는데, 이 낙폭은 서비스가 그만큼 나빠졌다는 뜻이 아니라 세는 대상이 적다는 뜻에 가깝습니다. 장애가 드문 서비스는 월 단위 값을 그래프에 찍지 말고 분기로 묶어 봅니다.

"지난 분기 MTBF 가 90시간이었는데 이번 분기는 260시간입니다."

같은 기준으로 셌을 때 장애 간격이 세 배 가까이 벌어졌다는 뜻입니다.

"MTBF 는 좋아졌는데 MTTR 이 그대로예요."

드물게 나지만 한 번 나면 여전히 오래 멈춘다는 말입니다.

"그건 3등급이라 MTBF 계산에서 빠집니다."

이번 달 사고 판정 기준에 들지 않아 건수에 세지 않는다는 뜻입니다.

페이지덱에서는 태오가 분기마다 이 값을 정리해 포스트모템 목록과 나란히 놓습니다. 지난 분기에 쓴 사고 기록이 다섯 건이고 그 안에서 나온 개선 항목이 열두 개인데, 그중 여덟 개를 처리한 분기에 값이 90시간에서 260시간이 됐습니다. 숫자 하나만 놓으면 왜 늘었는지 설명이 안 되지만 처리한 항목 목록과 같이 놓으면 설명이 됩니다.

지현은 이 값을 다른 용도로 씁니다. 다음 분기에 기능을 얼마나 밀어 넣을지 정할 때 참고합니다. 간격이 다시 100시간 아래로 내려온 분기에는 새 기능 대신 안정화에 쓸 시간을 먼저 떼어 둡니다.

평균이니까 다음 장애까지 그만큼 남았다고 읽는 경우가 있습니다. 240시간이라는 값을 보면 열흘은 괜찮겠다고 생각하기 쉽습니다. 하지만 장애는 고르게 흩어지지 않습니다. 배포한 날 두 건이 몰리고 그다음 3주가 조용한 달도 평균은 똑같이 240시간입니다. 이 값으로 다음 장애 시점을 예측하고 당번 인원을 줄이면 정작 몰리는 날에 사람이 없습니다.

값이 길어졌으니 서비스가 안정됐다고 읽는 것도 흔합니다. 숫자가 올랐으니 좋아 보입니다. 그런데 이 값은 사고로 세는 기준을 조이기만 해도 올라갑니다. 3등급을 계산에서 빼기로 한 분기에는 아무것도 고치지 않아도 값이 세 배가 됩니다. 목표로 걸어 두면 팀이 기준을 조이는 쪽으로 움직이고, 그러면 숫자는 오르는데 고객이 겪는 횟수는 그대로입니다. 볼 것은 값 자체가 아니라 같은 기준을 유지한 상태에서의 변화입니다.