상태 페이지는 조사 중, 원인 식별, 모니터링, 해결 같은 단계로 사고 대응이 어디까지 왔는지 요약해 보여 줍니다. ‘해결(resolved)’ 표시가 모든 사용자의 밀린 데이터가 복구됐다거나 원인 분석이 끝났다는 뜻은 아닐 수 있습니다. 그래서 영향받은 구성요소, 시작·갱신·종료 시각, 사후 보고서 링크를 함께 확인합니다.
사고 단계와 구성요소 상태는 서로 다른 축입니다
Statuspage의 사고(incident) 기록은 운영팀이 사고 하나를 두고 조사 중(investigating), 원인 식별(identified), 모니터링(monitoring), 해결 순으로 진행 상황을 알리는 기록입니다. 구성요소(component)는 API, 웹앱, 출금처럼 서비스 조각마다 정상, 성능 저하, 부분 중단 같은 상태를 따로 표시합니다.
사고가 모니터링 단계여도 특정 구성요소는 성능 저하 상태일 수 있고, 맨 위 전체 표시가 초록색이어도 내가 쓰는 외부 의존 서비스는 따로 사고를 겪고 있을 수 있습니다. 단계와 구성요소를 한 문장으로 뭉뚱그리지 않습니다.
상태 페이지는 장애를 직접 재는 센서가 아니라, 운영팀이 바깥에 공개하는 사고 소통 기록입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 사고 단계와 구성요소 상태는 서로 다른 축입니다
Statuspage의 사고(incident) 기록은 운영팀이 사고 하나를 두고 조사 중(investigating), 원인 식별(identified), 모니터링(monitoring), 해결 순으로 진행 상황을 알리는 기록입니다.
- 모니터링은 복구 선언이 아니라 관찰 단계입니다
원인 식별은 원인을 찾아 고치는 중이라는 뜻이고, 모니터링은 수정이 통했다고 보고 증상이 가라앉는지 지켜보는 단계입니다.
- 10시 조사부터 11시 30분 해결까지 읽는 예시
교육용으로 10:00 조사 중, 10:20 원인 식별, 10:45 모니터링, 11:30 해결로 갱신됐다고 가정해 보겠습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
모니터링은 복구 선언이 아니라 관찰 단계입니다
원인 식별은 원인을 찾아 고치는 중이라는 뜻이고, 모니터링은 수정이 통했다고 보고 증상이 가라앉는지 지켜보는 단계입니다. 모니터링으로 바뀐 시각을 전체 복구 완료 시각으로 쓰면 관찰 구간이 통째로 빠집니다.
해결은 Statuspage 정의상 원인이 제거되고 정상 성능으로 돌아왔다는 뜻입니다. 그러나 쌓인 요청·출금 대기열 처리, 빠진 데이터 채워 넣기, 사후 보고서 발행은 별개일 수 있습니다. 운영사가 밝히지 않은 사용자별 후속 상태는 추정하지 않습니다.
10시 조사부터 11시 30분 해결까지 읽는 예시
교육용으로 10:00 조사 중, 10:20 원인 식별, 10:45 모니터링, 11:30 해결로 갱신됐다고 가정해 보겠습니다. 이 경우 최초 게시부터 해결까지 90분입니다. 식별까지는 20분, 수정 뒤 관찰 구간은 모니터링 시작부터 해결까지 45분입니다. 실제 장애는 첫 게시보다 먼저 시작됐을 수 있으므로 ‘장애 지속 90분’과 ‘공개된 사고 기록 90분’은 구분합니다.
Atlassian 정의에서 조사 중은 증상은 봤지만 원인을 모르는 단계, 원인 식별은 원인을 찾아 고치는 단계, 모니터링은 수정이 통했다고 보고 증상이 사라지기를 기다리는 단계입니다. 해결은 원인이 제거되고 시스템이 정상 성능으로 돌아온 상태지만, 밀린 데이터 처리나 모든 사용자의 후속 영향까지 저절로 증명하지는 않습니다.
| 단계 | 운영팀이 말하는 상태 | 아직 확정할 수 없는 것 |
|---|---|---|
| 조사 중 | 증상을 알아채고 원인 조사 | 근본 원인·복구 시각 |
| 원인 식별 | 원인을 찾고 수정 중 | 수정 성공·전체 복구 |
| 모니터링 | 수정 뒤 증상 해소 관찰 | 재발 없음·밀린 작업 완료 |
| 해결 | 게시된 사고의 원인 제거·정상화 | 근본 원인 분석 완료·모든 개별 사용자 보상 |
전체 초록색과 내 기능의 정상화는 다를 수 있습니다
Statuspage 맨 위의 전체 상태는 페이지 구성요소들의 상태를 조합해 계산합니다. API는 정상인데 출금 구성요소가 성능 저하라면 ‘전체 서비스 중단’도 ‘모두 정상’도 정확한 말이 아닙니다. 사고에 연결된 영향 구성요소와 지역·네트워크 범위부터 읽습니다.
Statuspage 자체는 웹사이트나 서버를 직접 감시하지 않는 소통 도구입니다. 운영자가 손으로 갱신하거나 외부 감시 도구·API와 연동해 씁니다. 그래서 상태 페이지에 공지가 없다는 사실만으로 장애가 없었다고 단정할 수 없습니다.
- 사고 제목보다 영향 구성요소를 먼저 기록합니다
- 각 업데이트의 원래 시각과 시간대를 UTC로 맞춥니다
- 조사 중과 원인 식별은 원인 확정 여부로 구분합니다
- 모니터링 시작을 전체 복구 시각으로 쓰지 않습니다
- 해결 뒤 사후 보고서와 밀린 작업 공지를 따로 확인합니다
체인 상태와 서비스 상태를 분리합니다
블록 탐색기, RPC 제공자, 거래소 입출금은 같은 블록체인을 써도 서로 다른 서비스입니다. RPC 제공자의 사고가 해결됐어도 거래소는 멈췄던 입출금을 따로 검증한 뒤 재개할 수 있습니다. 체인이 블록을 계속 만들고 있었다면 인프라 장애와 합의 중단을 같은 사건으로 쓰지 않습니다.
‘일부 사용자’라는 공지에는 분모가 없습니다. 지역, API 메서드, 요청 비율이 공개되지 않았다면 전체 영향률을 추정하지 않습니다. 내 요청이 성공했는지나 소셜 제보는 보조 신호일 뿐 공식 영향 범위를 대신하지 못합니다.
사고 타임라인을 재구성하는 기록표
사고 ID, created_at, 업데이트 ID, 상태, 메시지, 영향 구성요소와 각각의 타임스탬프를 행으로 저장합니다. 문구는 나중에 고쳐질 수 있으니 처음 캡처한 내용과 현재 페이지를 구분합니다. 예정된 점검은 예기치 못한 사고와 다른 유형으로 둡니다.
평균 복구 시간(MTTR)을 계산할 때는 시작점을 실제 감지 시각, 첫 공개 시각, 영향 시작 추정 시각 가운데 무엇으로 잡았는지 적습니다. 위 가정의 90분은 첫 공개부터 해결까지일 뿐, 내부 감지부터 복구까지 걸린 시간이 아닙니다.
해결 뒤 공개되는 사후 보고서(postmortem)는 사과, 원인 설명, 재발 방지 계획을 담는 별도 문서입니다. 아직 게시되지 않았다고 원인이 없다는 뜻은 아니며, 게시 전에는 근본 원인을 짐작하지 않습니다.
자주 묻는 질문
상태가 Monitoring이면 서비스를 다시 써도 된다는 뜻인가요?
수정 뒤 지켜보는 중이라는 뜻입니다. 운영사가 기능 재개를 밝혔는지와 해당 구성요소의 상태를 확인하고, 모니터링 단계 자체를 전면 복구 선언으로 받아들이지 않습니다.
상태가 Resolved면 근본 원인 보고도 끝난 건가요?
아닙니다. 사고가 종료된 뒤 사후 보고서가 따로 작성될 수 있습니다. 공개되지 않은 원인과 재발 방지책은 짐작하지 않습니다.
상태 페이지가 초록색이면 장애가 없나요?
Statuspage는 소통 도구이지 직접 감시하는 장치가 아닙니다. 공지가 늦거나 범위가 좁을 수 있으니 실제 엔드포인트와 독립적인 신호를 함께 확인합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
