복구 시간

장애를 줄이라는 지시는 대개 배포를 줄이는 쪽으로 흘러갑니다. 배포하지 않으면 그날은 아무것도 깨지지 않으니 건수가 줄어드는 것은 사실입니다. 그러나 장애 건수가 0이 되는 조직은 없고, 배포를 줄인 팀에서는 한 번 나가는 변경의 덩치가 커져서 한 건의 장애가 더 오래갑니다.

페이지덱에서 그 일이 한 분기 동안 그대로 진행됐습니다. 규원이 장애 건수를 줄이라고 했고, 배포는 주 5회에서 주 1회로 내려갔습니다. 분기 장애 건수는 3건에서 2건으로 줄었습니다. 그런데 그 2건 중 하나가 4시간 동안 이어졌습니다. 같은 기간에 들어온 문의 수는 오히려 늘었습니다. 사용자가 겪은 것은 건수가 아니라 서비스가 멈춘 시간이었습니다.

복구 시간은 그래서 질문을 바꾼 지표입니다. 얼마나 자주 깨지는지가 아니라 깨졌을 때 얼마나 빨리 되돌리는지를 봅니다. 깨지지 않게 만드는 일과 빨리 되돌리는 일은 서로 다른 투자이고, 뒤쪽이 더 확실하게 통제되는 영역이기도 합니다.

장애가 시작된 시각과 정상으로 돌아온 시각의 차이를 재고, 기간 안의 건들을 모아 중앙값을 봅니다. 정해 둘 것은 다섯 가지입니다.

1. 시작 시각은 배포한 때가 아니라 사용자에게 영향이 시작된 때입니다. 아무도 알아채지 못한 35분이 그 앞에 있었다면 그 35분도 포함됩니다. 알아챈 시각으로 시작을 잡으면 감지가 늦은 문제가 숫자에서 사라집니다.
2. 종료 시각은 원인을 고친 때가 아니라 영향이 끝난 때입니다. 이전 버전으로 되돌리는 롤백으로 화면이 정상으로 돌아왔다면 그 시점까지만 셉니다. 원인 조사는 그 뒤에 이어져도 이 값에는 들어가지 않습니다.
3. 세는 대상은 사용자에게 영향이 있었던 인시던트입니다. 내부 도구가 잠깐 멈춘 일이나 경고만 울린 일은 빼고, 대신 무엇을 넣고 무엇을 뺄지를 미리 적어 둡니다.
4. 평균 대신 중앙값을 씁니다. 10분, 15분, 20분, 240분짜리 네 건이면 평균은 71분이고 중앙값은 17분 남짓입니다. 평균을 쓰면 특별한 한 건이 나머지 셋을 가려 버립니다.
5. 기록을 사람 손에 맡기지 않습니다. 알림이 울린 시각과 해소를 선언한 시각을 도구가 자동으로 남기게 해 둡니다. 나중에 적으면 시간이 짧아지는 쪽으로 기억됩니다.

분기에 장애가 네 건뿐이면 중앙값이 한 건에 크게 흔들립니다. 월 단위로 보기보다 분기나 반기로 묶어 흐름을 읽는 편이 현실적입니다.

바깥에서 가져온 기준보다 우리 값의 흐름이 먼저입니다. 지난 분기 30분이던 값이 이번 분기 18분이면 무언가 좋아진 것이고, 업계 평균과 비교해 나온 판정은 시스템 구조가 다른 조직끼리의 비교라 쓰기 어렵습니다. 참고 삼아 말하면 한 시간 안쪽이면 나쁘지 않고, 하루를 넘기는 건이 반복되면 손볼 곳이 분명히 있습니다.

이 값을 만드는 요소는 셋입니다.

1. 감지. 무슨 일이 벌어지는지 밖에서 알 수 있는 정도가 관측성이고, 이것이 낮으면 값의 절반이 모르는 시간으로 채워집니다.
2. 대응 시작. 정해진 시간에 연락을 받기로 한 당번이 온콜입니다. 당번이 없으면 새벽 장애가 아침까지 이어집니다.
3. 되돌리기. 한 번의 조작으로 이전 상태로 돌아갈 수 있는지가 마지막 구간을 정합니다.

줄이려면 세 번째부터 손대는 것이 빠릅니다. 되돌리기가 자동이면 원인을 몰라도 영향은 끝낼 수 있습니다. 배포를 작게 쪼개는 팀이 복구도 빠른 이유가 여기 있습니다. 배포 빈도가 높으면 한 번에 나가는 변경이 작아서 되돌릴 때 잃는 것도 적습니다.

혼자 보면 오해를 만드는 값이기도 합니다. 배포가 장애로 이어진 비율인 변경 실패율과 나란히 놓고 봐야 합니다. 복구가 15분으로 짧아도 배포 다섯 번 중 한 번이 장애라면 사용자는 그 15분을 자주 겪습니다.

"이번 분기 중앙값은 17분이에요. 240분짜리 한 건은 따로 다루겠습니다."

전체 흐름과 예외 한 건을 갈라 보자는 제안입니다.

"감지에 35분이 걸렸어요. 고치는 데는 5분이었고 문제는 알림이 안 울린 겁니다."

같은 값 안에서 어느 구간이 길었는지를 가른 말입니다.

"원인은 아직 모르는데 되돌려서 영향은 끝났어요. 복구 시간은 여기까지로 셉니다."

이 지표가 재는 것이 영향 해소라는 확인입니다.

태오가 분기 장애 네 건을 정리해 보니 240분짜리 한 건만 유난히 길었습니다. 그 건에는 저장 구조를 바꾸는 작업이 코드 배포와 함께 올라가 있었고, 구조가 이미 바뀌어 되돌릴 수가 없었습니다. 나머지 세 건은 모두 되돌리기로 20분 안에 끝났습니다.

그 뒤로 페이지덱은 저장 구조 변경과 코드 배포를 다른 날에 나눠 올립니다. 구조 변경은 되돌릴 수 있는 형태로 먼저 올리고, 그것이 자리를 잡은 다음에 코드를 올립니다. 다음 분기 최대값은 40분이었습니다. 중앙값보다 최대값이 먼저 줄어든 것이 이 변경의 효과였습니다.

장애를 빨리 고치는 능력으로 읽는 경우가 가장 많습니다. 복구라는 말이 수리를 떠올리게 하기 때문입니다. 그런데 이 값이 재는 것은 원인 제거가 아니라 영향 해소입니다. 실제 현장에서 대부분의 건은 원인을 모르는 채로 되돌려 끝납니다. 원인 규명을 복구의 조건으로 두면 사용자가 멈춘 화면을 보는 시간이 길어지고, 그 시간이 이 숫자로 돌아옵니다.

짧으면 안정적이라고 읽는 것도 흔합니다. 하나의 숫자가 좋아 보이면 그 영역이 건강한 것처럼 느껴집니다. 하지만 이 값은 장애가 났다는 전제 아래의 숫자입니다. 빈도를 같이 보지 않으면 하루에 세 번 깨지고 세 번 빨리 되돌리는 팀이 우수한 것으로 집계됩니다. 네 지표를 함께 두는 이유가 그것입니다.