LabHub
시작하기
배우기 러닝패스 코스

용량 계획과 변경 관리 — 언제 차는지 계산하고 멈출 시각을 먼저 적는다

목표가 아니라 실측이다 — RPO·RTO·3-2-1 과 사람을 탓하지 않는 사후 분석

LabHub 에서 이어서 보기

한 줄 요약

RPO 와 RTO 는 문서에 적는 목표이고, 복구 훈련은 그 목표를 실제로 몇 분에 지켰는지 재는 일이다. 실제 데이터 손실은 "마지막으로 성공한 백업" 부터 세고, 실제 복구 시간은 장애가 시작된 순간부터 서비스가 확인된 순간까지 센다. 훈련이 끝나면 사람을 탓하지 않는 사후 분석과, 담당과 기한이 있는 개선 조치가 남아야 한다.

왜 이게 필요했나

"백업은 매시간 돌고, RPO 는 1시간입니다" 라는 문장은 자주 거짓이다. 백업 작업이 두 번 연달아 실패했는데 아무도 몰랐다면 실제 손실은 세 시간이다. "복구는 30분이면 됩니다" 도 복원 명령이 도는 시간만 잰 것이고, 장애를 알아채는 데 15분, 복구를 결정하는 데 13분, 준비에 13분이 따로 든다. 목표와 실측의 차이는 훈련을 해야만 보인다.

어떻게 동작하나

두 목표. NIST SP 800-34 Rev. 1 은 비상 계획의 용어를 이렇게 정의한다. RTO(Recovery Time Objective)는 시스템이 멈춰 있어도 되는 최대 시간이고, RPO(Recovery Point Objective)는 장애 전 어느 시점까지의 데이터를 되살려야 하는가 — 곧 잃어도 되는 데이터의 최대 시간 폭이다.

목표 실측 방법
RPO 잃어도 되는 최대 시간 장애 시각 − 장애 전 마지막으로 성공한 백업 시각
RTO 멈춰 있어도 되는 최대 시간 서비스 확인 시각 − 장애 시작 시각

실측에서 흔히 틀리는 자리가 둘이다. RPO 를 "마지막 백업 시각" 으로 세면서 그 백업이 실패했는지 보지 않는 것, 그리고 RTO 를 "복원 시작부터 끝까지" 로 세는 것이다. 사용자에게 서비스는 장애가 시작된 순간부터 멈춰 있었다.

구간으로 쪼갠다. 복구 시간을 탐지 → 판단 → 준비 → 복원 → 확인 구간으로 나누면 어디를 줄여야 하는지 보인다. 복원 명령이 가장 길다면 백업 방식이나 대역폭을, 탐지가 길다면 경보를, 판단이 길다면 누가 무엇을 결정하는지의 절차를 고친다.

3-2-1 규칙. 미국 US-CERT 가 2012년 Data Backup Options 에서 권한 규칙이다 — 데이터 사본을 두고(원본 포함), 두 가지 서로 다른 매체에 담고, 그중 하나는 다른 장소에 둔다. 같은 디스크 배열 안의 스냅숏 세 개는 사본이 셋이어도 매체가 하나, 장소가 하나라 규칙을 어긴다. 배열이 통째로 죽거나 건물에 불이 나면 셋이 함께 사라진다.

복원본을 검증한다. 복원이 "끝났다" 는 것과 데이터가 "맞다" 는 것은 다른 사실이다. 백업할 때 파일마다 해시를 담은 목록(manifest)을 함께 남겨 두면, 복원한 뒤 목록과 대조해 빠진 파일과 내용이 다른 파일을 가를 수 있다. sha256sum -c 가 그 일을 한다.

사람을 탓하지 않는 사후 분석. SRE 책의 사후 분석 문화 장은 사후 분석이 비난 없는(blameless) 것이어야 한다고 말한다. 누가 잘못했는지를 찾기 시작하면 사람들은 사실을 숨기고, 같은 조건은 그대로 남는다. 근본 원인 절에는 "누가" 가 아니라 그 사람이 그렇게 할 수밖에 없게 만든 조건을 적는다 — 백업 실패가 경보로 이어지지 않았다, 백업 대상 볼륨의 여유를 아무도 보지 않았다. 개선 조치에는 담당과 기한을 붙인다. 담당이 없는 조치는 아무도 하지 않는다.

현장에서 만나는 모습

훈련에서 가장 자주 드러나는 사실은 백업이 조용히 실패하고 있었다는 것이다. 백업 대상 볼륨이 가득 차 증분이 실패했는데 알림이 메일로만 가고 그 메일함을 아무도 보지 않았다 — 이런 이야기는 흔하다. 그래서 백업 모니터링은 "작업이 실패하면 알린다" 에서 멈추지 말고 "마지막 성공이 N분보다 오래되면 알린다" 로 건다. 실패 알림은 작업이 아예 안 돌 때 오지 않는다.

두 번째는 복구 절차가 사람 머릿속에만 있다는 것이다. 훈련은 그 절차를 모르는 사람이 런북만 보고 해 보는 것이 좋다. 훈련 때 준비 구간이 긴 이유가 "복원 서버 접속 정보를 찾느라" 라면, 그 정보를 런북에 넣는 것이 개선 조치다. 세 번째는 훈련을 한 번 하고 끝내는 것이다. 데이터 크기와 구성은 계속 바뀌므로 반년 전에 45분이던 복원이 지금은 두 시간일 수 있다. 분기마다 같은 훈련을 되풀이하고 구간별 시간을 표로 쌓으면, 목표를 지킬 수 있는지가 추세로 보인다.

다음 실습에서 할 것

데이터 네 벌의 사본 목록에서 3-2-1 을 어기는 것을 찾는다. 백업 작업 기록과 장애 기록으로 실제 데이터 손실 시간과 복구 시간을 재고 목표와 비교한 뒤, 가장 긴 구간을 찾는다. 복원된 파일을 목록과 대조해 빠진 것과 달라진 것을 가르고, 마지막으로 사람을 탓하지 않는 사후 분석과 담당·기한이 있는 개선 조치를 쓴다.