상태 페이지는 조사 중, 원인 식별, 모니터링, 해결 같은 단계로 사고 대응 진행을 요약한다. resolved는 모든 사용자의 지연 데이터가 복구됐거나 원인 분석이 끝났다는 뜻이 아닐 수 있다. 따라서 영향 구성요소, 시작·갱신·종료 시각과 사후 보고서 링크를 확인한다.
incident 단계와 component 상태는 서로 다른 축
Statuspage incident는 운영팀이 하나의 사고에 대해 investigating, identified, monitoring, resolved로 진행상황을 알리는 기록이다. component는 API, 웹앱, 출금처럼 서비스 조각별로 operational, degraded, partial outage 등의 상태를 가진다.
incident가 monitoring이어도 특정 component는 degraded일 수 있고, top-level이 초록색이어도 내가 쓰는 외부 의존 서비스가 별도 사고를 겪을 수 있다. 단계와 구성요소를 한 문장으로 합치지 않는다.
상태 페이지는 장애를 직접 측정하는 센서가 아니라 운영팀이 외부에 공개하는 사고 커뮤니케이션 기록이다.
JOBCOIN 해설
Monitoring은 복구 선언이 아니라 관찰 단계
identified는 원인을 찾고 fix 작업 중이라는 뜻이고 monitoring은 fix가 성공했다고 보고 증상이 가라앉는지 지켜보는 단계다. monitoring 시각을 전체 복구 완료시각으로 쓰면 관찰 구간을 누락한다.
resolved는 Statuspage 정의상 원인 제거와 정상 성능 복귀를 뜻한다. 그러나 누적된 요청·출금 queue 처리, 누락 데이터 백필과 postmortem 발행은 별도일 수 있다. 운영사가 명시하지 않은 사용자별 후속 상태를 추정하지 않는다.
10시 조사부터 11시 30분 해결까지 읽는 예시
교육용 가정에서 10:00 investigating, 10:20 identified, 10:45 monitoring, 11:30 resolved로 갱신됐다면 최초 게시부터 해결까지 90분이다. 식별까지 20분, 수정 적용 후 관찰 구간은 monitoring 시작부터 resolved까지 45분이다. 실제 장애 시작은 첫 게시보다 빨랐을 수 있어 ‘장애 지속 90분’과 ‘공개 incident 90분’을 구분한다.
Atlassian 정의에서 investigating은 증상을 봤지만 원인을 모르는 단계, identified는 원인을 찾아 수정 중인 단계, monitoring은 수정이 성공했다고 보고 증상 해소를 기다리는 단계다. resolved는 원인이 제거되고 시스템이 정상 성능으로 돌아온 상태지만 데이터 백로그 처리나 모든 사용자 후속 영향까지 자동 증명하지 않는다.
| 단계 | 운영팀이 말하는 상태 | 아직 확정할 수 없는 것 |
|---|---|---|
| Investigating | 증상을 인지하고 원인 조사 | 근본 원인·복구시각 |
| Identified | 원인을 찾고 수정 중 | 수정 성공·전체 복구 |
| Monitoring | 수정 후 증상 해소 관찰 | 재발 없음·백로그 완료 |
| Resolved | 게시된 사고의 원인 제거·정상화 | RCA 완료·모든 개별 사용자 보상 |
전체 초록색과 내 기능의 정상화는 다를 수 있다
Statuspage의 top-level status는 페이지 구성요소 상태를 조합해 계산한다. API는 operational인데 withdrawal component가 degraded라면 ‘전체 서비스 중단’도 ‘모두 정상’도 정확하지 않다. incident에 연결된 affected components와 지역·네트워크 범위를 먼저 읽는다.
Statuspage 자체는 웹사이트나 서버를 직접 모니터링하지 않는 커뮤니케이션 도구다. 운영자가 수동으로 갱신하거나 외부 모니터·API와 연동한다. 그래서 상태 페이지에 공지가 없다는 사실만으로 장애가 없었다고 단정할 수 없다.
- incident 제목보다 affected components를 먼저 기록한다
- 각 업데이트의 원문 시각과 timezone을 UTC로 맞춘다
- investigating과 identified를 원인 확정 여부로 구분한다
- monitoring 시작을 전체 복구시각으로 쓰지 않는다
- resolved 뒤 postmortem·백로그 공지를 별도로 확인한다
체인 상태와 서비스 상태를 분리한다
블록 탐색기, RPC 제공자, 거래소 입출금은 같은 블록체인을 사용해도 서로 다른 서비스다. RPC 제공자의 incident가 resolved여도 거래소가 중단했던 입출금을 별도 검증 후 재개할 수 있다. 체인이 블록을 계속 만들었다면 인프라 장애와 합의 중단을 같은 사건으로 쓰지 않는다.
‘일부 사용자’라는 공지에는 분모가 없다. 지역, API method, 요청 비율이 공개되지 않았다면 전체 영향률을 추정하지 않는다. 자신의 요청 성공 여부나 소셜 제보는 보조 신호일 뿐 공식 영향 범위를 대체하지 않는다.
사고 타임라인을 재구성하는 기록표
incident id, created_at, update id, status, message, affected component와 각 timestamp를 행으로 저장한다. 이후 문구가 수정될 수 있으므로 최초 캡처와 현재 페이지를 구분한다. planned maintenance는 unexpected incident와 별도 유형으로 둔다.
MTTR을 계산할 때 시작점을 실제 감지시각, 첫 공개시각, 영향 시작 추정시각 중 무엇으로 썼는지 적는다. 위 가정의 90분은 첫 공개→resolved일 뿐 내부 감지→복구 시간이 아니다.
resolved 뒤 공개되는 postmortem은 사과, 원인 이해와 재발 방지 계획을 담는 별도 문서다. 게시되지 않았다고 원인이 없다는 뜻은 아니고, 게시 전에는 근본 원인을 추측하지 않는다.
자주 묻는 질문
Monitoring이면 서비스를 다시 써도 된다는 뜻인가요?
fix 후 관찰 중이라는 뜻이다. 운영사가 기능 재개를 명시했는지와 해당 component 상태를 확인하고, monitoring 자체를 전면 복구 선언으로 바꾸지 않는다.
Resolved면 근본 원인 보고도 끝난 건가요?
아니다. incident 종료 뒤 postmortem이 별도로 작성될 수 있다. 공개되지 않은 원인과 재발 방지책을 추측하지 않는다.
상태 페이지가 초록색이면 장애가 없나요?
Statuspage는 커뮤니케이션 도구이며 직접 모니터가 아니다. 공지 지연·범위 제한이 있을 수 있어 실제 endpoint와 독립 신호를 함께 확인한다.
