KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 10 / 12

관측성과 장애 대응

사용자 SLO를 metric·log·trace·event와 연결하고 evidence-first incident response와 postmortem을 수행합니다.

난이도
중급
구성
핵심 단원 4개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    metric·log·trace가 답하는 질문을 나누고 동일한 service·revision·시각으로 연결합니다. 알림 개수보다 대응 행동과 재검증 결과를 남깁니다.

  2. 02

    오늘 맡은 일

    Incident 대응과 postmortem의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    GPU utilization은 정상인데 사용자 응답 p99가 두 배로 늘었습니다. 먼저 할 일은 무엇입니까?

낯선 용어 먼저 풀기

Trace context(요청 추적 문맥)
service 사이에서 trace와 span 관계를 이어 주는 식별 정보입니다.

이 과정의 운영 질문

경보 한 건에서 사용자 영향과 복구 증거까지 어떻게 연결합니까?

metric·log·trace가 답하는 질문을 나누고 동일한 service·revision·시각으로 연결합니다. 알림 개수보다 대응 행동과 재검증 결과를 남깁니다.

CORE UNIT 1 / 4

관측 signal과 공통 context

metric·log·trace·event가 답하는 질문을 구분합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

제공 기록 읽기 전용·운영 수집기 접근 없음. 예제 주소는 문서용이며 실제 요청하지 않습니다.

3처음 보는 값과 아직 실행하지 않은 시험은 어떻게 적습니까?

미확인으로 기록합니다. 교육용 예상 출력과 실제 측정값을 구분하고, 승인 없는 작업으로 빈칸을 채우지 않습니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 관측 signal과 공통 context의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 관측 signal과 공통 context의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 관측 signal과 공통 context의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
관측 signal과 공통 context 실습 환경과 안전 경계
하드웨어브라우저의 signal·incident 기록 fixture
소프트웨어Prometheus HTTP API v1·OpenTelemetry W3C trace context
필요 권한제공 기록 읽기 전용·운영 수집기 접근 없음
네트워크예제 주소는 문서용이며 실제 요청하지 않습니다

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Prometheus HTTP API v1 · W3C Trace Context version 00 header · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장gateway에서 확인을 시작합니다
  2. 2장context 전달의 실습 대상을 고정합니다
  3. 3장runtime의 출력과 의미를 구분합니다
  4. 4장누락 구간의 진행과 중단을 결정합니다
  5. 5장관측 signal과 공통 context의 복구를 재검증합니다
관측 signal과 공통 context의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · gateway에서 확인을 시작합니다

다음 연결: context 전달의 실습 대상을 고정합니다

  1. gateway에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. context 전달의 실습 대상을 고정합니다

    실습 상황:: 아래 두 예제 log를 읽고 같은 요청인지, 330ms를 어떤 증거로 더 나눌지 적습니다. 명령은 격리 환경에서 같은 필드를 조회하는 참고이며 브라우저에서는 출력 판독만 수행합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 시계 불일치·context 단절 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. runtime의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 trace ID 일치와 parent 관계가 성립하고 관측 범위 밖의 시간을 따로 남기는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 누락 구간의 진행과 중단을 결정합니다

    요청 연결 근거 두 개와 미관측 구간을 적고 queue span·clock 확인 순서를 설명하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 관측 signal과 공통 context의 복구를 재검증합니다

    context가 끊긴 경계를 찾으면 test 요청의 header 전달과 instrumentation 설정을 격리 환경에서 확인합니다. 수정 후 같은 요청을 다시 보내 span 관계와 개인정보 미포함을 함께 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

같은 요청의 기록을 묶어 지연 구간을 찾습니다

Trace context(요청 추적 문맥): service 사이에서 trace와 span 관계를 이어 주는 식별 정보입니다.

Metric은 일정 시간 동안의 값과 분포, log는 개별 사건, trace는 한 요청의 여러 작업을 보여 줍니다. CPU 수치가 낮다는 사실만으로 요청이 빨랐다고 말할 수 없는 이유는 세 자료의 관찰 단위가 다르기 때문입니다.

요청을 받은 service가 trace context를 다음 service로 전달하면 span 사이의 부모·자식 관계를 복원할 수 있습니다. 전달이 끊기면 뒤쪽 작업이 별도 trace로 보여 전체 지연을 잘못 나눌 수 있습니다. service 이름과 배포 revision은 어느 코드가 그 기록을 만들었는지 구분합니다.

교육 예시에서 gateway는 420ms 뒤 응답했고 runtime span은 90ms입니다. 나머지 330ms를 곧바로 network 지연으로 단정할 수는 없습니다. queue 대기·직렬화·누락된 span과 시계 차이를 먼저 확인해야 합니다.

아래 두 예제 log를 읽고 같은 요청인지, 330ms를 어떤 증거로 더 나눌지 적습니다. 명령은 격리 환경에서 같은 필드를 조회하는 참고이며 브라우저에서는 출력 판독만 수행합니다.

gateway 요청 420ms 안의 runtime span 90ms를 같은 trace ID로 잇고, 남은 330ms는 미관측으로 표시한 시간 축과 필드 표입니다.
그림 읽는 법 같은 요청의 기록을 묶어 지연 구간을 찾습니다. 위 시간 축은 gateway span 420ms 안에서 관측된 runtime span 90ms의 자리이고, 점선 두 구간을 합한 330ms에는 span이 없습니다. 점선 구간의 위치는 이 기록만으로 정해지지 않으므로 그림은 관측된 구간의 크기만 보여 줄 뿐 실제 실행 순서를 단정하지 않습니다. 아래 표는 필드·gateway.json·runtime.json·판정 네 열이며 번호 1부터 4까지 위에서 아래로 읽습니다. trace ID가 같고 runtime의 parent span ID가 gateway의 span ID와 같으면 두 기록은 한 요청으로 묶입니다. duration_ms 420에서 90을 뺀 330ms는 미관측이며 network 지연으로 단정하지 않고 queue 대기·직렬화·누락된 span·시계 차이를 먼저 확인합니다. 파란 상자의 확인 순서를 위에서 아래로 따르고, 시계 불일치나 context 단절이 보이면 변경을 보류합니다. 자료: OpenTelemetry Signals · OpenTelemetry Context Propagation를 바탕으로 저자 구성.
왜 이런가
요청을 받은 service가 trace context를 다음 service로 전달하면 span 사이의 부모·자식 관계를 복원할 수 있습니다. 전달이 끊기면 뒤쪽 작업이 별도 trace로 보여 전체 지연을 잘못 나눌 수 있습니다. service 이름과 배포 revision은 어느 코드가 그 기록을 만들었는지 구분합니다.
언제 문제가 되는가
시계 불일치·context 단절 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
인증 token·사용자 입력 원문을 baggage나 log에 복사하지 않습니다. 외부에서 들어온 trace context도 신뢰 경계에서 검증합니다.
직접 확인하는 방법
service.name·revision·환경을 먼저 대조합니다. gateway와 runtime의 trace ID, span ID, parent span ID를 구분합니다.
이 절을 정리하면요청 연결 근거 두 개와 미관측 구간을 적고 queue span·clock 확인 순서를 설명하면 성공입니다.

CHAPTER 1 / 5

gateway에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. service.name·revision·환경을 먼저 대조합니다. 2. gateway와 runtime의 trace ID, span ID, parent span ID를 구분합니다. 3. 시작·종료 시각의 timezone과 clock skew를 확인합니다. 4. 수집되지 않은 span은 지연 0이 아니라 미확인으로 기록합니다.

CHAPTER 2 / 5

context 전달의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
jq -c '{service,revision,trace_id,span_id,parent_span_id,duration_ms}' gateway.json runtime.json

CHAPTER 3 / 5

runtime의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
{"service":"gateway","revision":"r7","trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","span_id":"00f067aa0ba902b7","parent_span_id":null,"duration_ms":420}
{"service":"runtime","revision":"r7","trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","span_id":"b7ad6b7169203331","parent_span_id":"00f067aa0ba902b7","duration_ms":90}

CHAPTER 4 / 5

누락 구간의 진행과 중단을 결정합니다

CHAPTER 5 / 5

관측 signal과 공통 context의 복구를 재검증합니다

CONCRETE CASES

아래 두 예제 log를 읽고 같은 요청인지, 330ms를 어떤 증거로 더 나눌지 적습니다. 명령은 격리 환경에서 같은 필드를 조회하는 참고이며 브라우저에서는 출력 판독만 수행합니다.

교육 예시에서 gateway는 420ms 뒤 응답했고 runtime span은 90ms입니다. 나머지 330ms를 곧바로 network 지연으로 단정할 수는 없습니다. queue 대기·직렬화·누락된 span과 시계 차이를 먼저 확인해야 합니다.

잘못된 대응과 확인할 경계

인증 token·사용자 입력 원문을 baggage나 log에 복사하지 않습니다. 외부에서 들어온 trace context도 신뢰 경계에서 검증합니다.

context가 끊긴 경계를 찾으면 test 요청의 header 전달과 instrumentation 설정을 격리 환경에서 확인합니다. 수정 후 같은 요청을 다시 보내 span 관계와 개인정보 미포함을 함께 확인합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 아래 두 예제 log를 읽고 같은 요청인지, 330ms를 어떤 증거로 더 나눌지 적습니다. 명령은 격리 환경에서 같은 필드를 조회하는 참고이며 브라우저에서는 출력 판독만 수행합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 시계 불일치·context 단절 조건이 보이면 다음 변경으로 넘어가지 마십시오.

{"service":"gateway","revision":"r7","trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","span_id":"00f067aa0ba902b7","parent_span_id":null,"duration_ms":420}
{"service":"runtime","revision":"r7","trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","span_id":"b7ad6b7169203331","parent_span_id":"00f067aa0ba902b7","duration_ms":90}

값 자체를 외우는 것이 아니라 trace ID 일치와 parent 관계가 성립하고 관측 범위 밖의 시간을 따로 남기는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

인증 token·사용자 입력 원문을 baggage나 log에 복사하지 않습니다. 외부에서 들어온 trace context도 신뢰 경계에서 검증합니다.

KEY TERMS

이번 단원 핵심 용어

Trace context(요청 추적 문맥)
service 사이에서 trace와 span 관계를 이어 주는 식별 정보입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

관측 signal과 공통 context의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 2 / 4

Metric과 dashboard

SLI·SLO에서 필요한 metric과 dashboard를 역설계합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

제공 기록 읽기 전용·운영 수집기 접근 없음. 예제 주소는 문서용이며 실제 요청하지 않습니다.

3앞 단원 「관측 signal과 공통 context」에서 어떤 증거를 남겼습니까?

요청 연결 근거 두 개와 미관측 구간을 적고 queue span·clock 확인 순서를 설명하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Metric과 dashboard의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Metric과 dashboard의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Metric과 dashboard의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Metric과 dashboard 실습 환경과 안전 경계
하드웨어브라우저의 signal·incident 기록 fixture
소프트웨어Prometheus HTTP API v1·OpenTelemetry W3C trace context
필요 권한제공 기록 읽기 전용·운영 수집기 접근 없음
네트워크예제 주소는 문서용이며 실제 요청하지 않습니다

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Prometheus HTTP API v1 · W3C Trace Context version 00 header · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장counter에서 확인을 시작합니다
  2. 2장같은 구간의 실습 대상을 고정합니다
  3. 3장비율 계산의 출력과 의미를 구분합니다
  4. 4장판정의 진행과 중단을 결정합니다
  5. 5장Metric과 dashboard의 복구를 재검증합니다
Metric과 dashboard의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · counter에서 확인을 시작합니다

다음 연결: 같은 구간의 실습 대상을 고정합니다

  1. counter에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 같은 구간의 실습 대상을 고정합니다

    실습 상황:: 아래는 교육용 http_requests_total을 조회하는 예입니다. 결과 0.02와 5분 구간을 읽고 요청이 0건일 때 표시를 어떻게 바꿀지 적습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 분모 0·수집 누락·label 폭증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 비율 계산의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 value의 0.02는 2%이고 query의 5분 구간을 벗어나 일반화할 수 없다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 판정의 진행과 중단을 결정합니다

    type·단위·구간·분모를 명시한 panel 정의와 No data 표시, 유한한 label 목록을 제시하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Metric과 dashboard의 복구를 재검증합니다

    시계열이 폭증하면 수집 변경 revision과 label별 series 수를 보존합니다. 제한 없는 label을 제거한 canary에서 수집량과 query 결과를 다시 비교하고 보존 정책에 따라 기존 자료를 처리합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

오류율은 같은 관찰 구간의 분자와 분모로 만듭니다

Counter(누적 계수): 재시작 등을 제외하면 증가하며 일정 구간 증가량으로 사건 발생률을 계산하는 값입니다.

누적 counter와 현재값 gauge는 서로 다른 질문에 답합니다. 요청 counter 10,000은 측정 시작 이후 누적 횟수이지 초당 요청 수가 아닙니다. 시간당 변화를 알려면 관찰 구간과 증가량을 함께 사용해야 합니다.

Prometheus의 rate는 counter의 시간당 증가율을 추정하며 재시작에 따른 reset을 다룹니다. instance별 rate를 계산한 뒤 합산해야 reset을 잘못 해석할 위험을 줄입니다. histogram의 bucket은 지연 분포를 집계하므로 평균만으로 숨겨진 느린 요청을 볼 수 있습니다.

예제에서 5분간 요청은 1,000건, 실패는 20건입니다. 오류율은 2%이지만 traffic이 0이면 비율은 판정할 수 없습니다. dashboard가 No data를 초록색 0으로 칠하면 수집기 장애를 서비스 정상으로 오해합니다.

아래는 교육용 http_requests_total을 조회하는 예입니다. 결과 0.02와 5분 구간을 읽고 요청이 0건일 때 표시를 어떻게 바꿀지 적습니다.

5분 구간의 실패 20건과 전체 1,000건으로 오류율 2%를 만들고, 분모 0·수집 누락·label 폭증에서는 판정을 보류하는 표입니다.
그림 읽는 법 오류율은 같은 관찰 구간의 분자와 분모로 만듭니다. 위 띠를 왼쪽에서 오른쪽으로 읽으면 분자 20건, 분모 1,000건, 결과 0.02가 어떻게 이어지는지 보입니다. 아래 표는 관찰되는 증거·판정·다음 행동 세 열이며 번호 1부터 4까지 위에서 아래로 읽습니다. 1행은 traffic이 0보다 크고 up이 1일 때만 2%로 판정할 수 있다는 뜻이고, 2행부터 4행은 분모 0·수집 누락·label 폭증에서 판정을 보류하는 조건입니다. No data를 초록색 0으로 칠하면 수집기 장애를 정상으로 오해하므로 색 대신 글자로 상태를 적습니다. 마지막 상자는 같은 구간·같은 service·같은 환경이라는 계산 전제와 histogram bucket을 바꿀 때의 영향을 정리합니다. 도표의 식별자와 수치는 저자 구성 교육용 예시이며 실제 장비에서 측정한 값이 아닙니다. 자료: Prometheus Query functions · Prometheus Metric types를 바탕으로 저자 구성.
왜 이런가
Prometheus의 rate는 counter의 시간당 증가율을 추정하며 재시작에 따른 reset을 다룹니다. instance별 rate를 계산한 뒤 합산해야 reset을 잘못 해석할 위험을 줄입니다. histogram의 bucket은 지연 분포를 집계하므로 평균만으로 숨겨진 느린 요청을 볼 수 있습니다.
언제 문제가 되는가
분모 0·수집 누락·label 폭증 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
request ID·사용자 이메일·원문 URL을 metric label로 쓰지 않습니다. histogram bucket을 바꾸면 quantile 비교 조건도 달라집니다.
직접 확인하는 방법
지표 type과 단위를 확인합니다. rate 구간·scrape 간격·reset 여부를 기록합니다.
이 절을 정리하면type·단위·구간·분모를 명시한 panel 정의와 No data 표시, 유한한 label 목록을 제시하면 성공입니다.

CHAPTER 1 / 5

counter에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 지표 type과 단위를 확인합니다. 2. rate 구간·scrape 간격·reset 여부를 기록합니다. 3. 분자와 분모의 service·환경·시간 구간을 맞춥니다. 4. No data·up·수집 지연을 서비스 오류율 옆에 표시합니다.

CHAPTER 2 / 5

같은 구간의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
curl -fsSG http://127.0.0.1:9090/api/v1/query --data-urlencode 'query=sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))'

CHAPTER 3 / 5

비율 계산의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1788228000,"0.02"]}]}}

CHAPTER 4 / 5

판정의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Metric과 dashboard의 복구를 재검증합니다

CONCRETE CASES

아래는 교육용 http_requests_total을 조회하는 예입니다. 결과 0.02와 5분 구간을 읽고 요청이 0건일 때 표시를 어떻게 바꿀지 적습니다.

예제에서 5분간 요청은 1,000건, 실패는 20건입니다. 오류율은 2%이지만 traffic이 0이면 비율은 판정할 수 없습니다. dashboard가 No data를 초록색 0으로 칠하면 수집기 장애를 서비스 정상으로 오해합니다.

잘못된 대응과 확인할 경계

request ID·사용자 이메일·원문 URL을 metric label로 쓰지 않습니다. histogram bucket을 바꾸면 quantile 비교 조건도 달라집니다.

시계열이 폭증하면 수집 변경 revision과 label별 series 수를 보존합니다. 제한 없는 label을 제거한 canary에서 수집량과 query 결과를 다시 비교하고 보존 정책에 따라 기존 자료를 처리합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 아래는 교육용 http_requests_total을 조회하는 예입니다. 결과 0.02와 5분 구간을 읽고 요청이 0건일 때 표시를 어떻게 바꿀지 적습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 분모 0·수집 누락·label 폭증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1788228000,"0.02"]}]}}

값 자체를 외우는 것이 아니라 value의 0.02는 2%이고 query의 5분 구간을 벗어나 일반화할 수 없다는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

request ID·사용자 이메일·원문 URL을 metric label로 쓰지 않습니다. histogram bucket을 바꾸면 quantile 비교 조건도 달라집니다.

KEY TERMS

이번 단원 핵심 용어

Counter(누적 계수)
재시작 등을 제외하면 증가하며 일정 구간 증가량으로 사건 발생률을 계산하는 값입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Metric과 dashboard의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 4

Alert와 Runbook

증상 alert를 action 가능한 조건·owner·Runbook과 연결합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

제공 기록 읽기 전용·운영 수집기 접근 없음. 예제 주소는 문서용이며 실제 요청하지 않습니다.

3앞 단원 「Metric과 dashboard」에서 어떤 증거를 남겼습니까?

type·단위·구간·분모를 명시한 panel 정의와 No data 표시, 유한한 label 목록을 제시하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Alert와 Runbook의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Alert와 Runbook의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Alert와 Runbook의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Alert와 Runbook 실습 환경과 안전 경계
하드웨어브라우저의 signal·incident 기록 fixture
소프트웨어Prometheus HTTP API v1·OpenTelemetry W3C trace context
필요 권한제공 기록 읽기 전용·운영 수집기 접근 없음
네트워크예제 주소는 문서용이며 실제 요청하지 않습니다

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Prometheus HTTP API v1 · W3C Trace Context version 00 header · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장사용자 영향에서 확인을 시작합니다
  2. 2장지속 확인의 실습 대상을 고정합니다
  3. 3장경보 전달의 출력과 의미를 구분합니다
  4. 4장runbook의 진행과 중단을 결정합니다
  5. 5장Alert와 Runbook의 복구를 재검증합니다
Alert와 Runbook의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 사용자 영향에서 확인을 시작합니다

다음 연결: 지속 확인의 실습 대상을 고정합니다

  1. 사용자 영향에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 지속 확인의 실습 대상을 고정합니다

    실습 상황:: 예제 rule의 문법 검사 성공이 알림 전달까지 보장하는지 판단하고 별도 시험 두 개를 설계합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, owner·복구 기준·수집 신호 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 경보 전달의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 첫 결과는 문법, 둘째 결과는 준비한 시계열 시험의 성공이며 수신자의 실제 수신 증거는 별도라는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. runbook의 진행과 중단을 결정합니다

    정상·지속 장애·회복·수집 중단 입력에 대한 기대 상태와 담당자 수신·복구 확인 절차를 작성하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Alert와 Runbook의 복구를 재검증합니다

    오탐이 나면 해당 구간의 시계열과 rule revision을 보존합니다. 수정 rule을 과거 구간과 인위적인 실패 구간에 모두 시험한 뒤 canary로 적용합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

지속된 사용자 영향이 담당자의 행동으로 이어집니다

Runbook(대응 절차서): 증상에서 확인·중단·완화·재검증으로 이어지는 담당자의 행동 절차입니다.

경보는 값이 달라졌다는 통지가 아니라 사람이 지금 취할 행동이 있다는 계약입니다. GPU 사용률이 높아도 사용자 목표를 지키고 있으면 즉시 호출할 이유가 없을 수 있습니다. 반대로 요청 실패가 지속되면 자원 수치가 낮아도 대응해야 합니다.

경보 rule은 조건과 지속 시간을 평가하고 Alertmanager는 묶기·라우팅·억제 등을 담당합니다. runbook은 영향 확인, 안전한 조회, 중단 기준, 완화와 복구 판정 순서를 연결합니다. 담당자와 검증된 행동이 없는 경보는 소음으로 남습니다.

fixture에서는 5분 오류율 2% 초과가 10분 지속될 때 호출합니다. 이는 학습용 기준이지 모든 서비스의 적정 임계값이 아닙니다. 실제 기준은 SLO와 요청량, 대응 시간 및 누락 비용으로 정합니다.

예제 rule의 문법 검사 성공이 알림 전달까지 보장하는지 판단하고 별도 시험 두 개를 설계합니다.

경보 rule 이 inactive·pending·firing·resolved 를 지나는 상태 띠와, 정상·지속 장애·회복·수집 중단 네 입력에서 기대 상태와 담당자 행동을 정리한 표입니다.
그림 읽는 법 위쪽 띠를 왼쪽에서 오른쪽으로 읽으면 경보 rule 하나가 지나는 상태입니다. err_rate5m 이 2% 이하이면 inactive, 2%를 넘기 시작하면 pending 에서 for: 10m 을 세고, 10분을 채우면 firing 으로 Alertmanager 에 넘어가며, 조건이 풀리면 resolved 에서 복구를 판정합니다. 아래 표는 같은 rule 에 네 가지 입력을 넣었을 때의 기대 상태이며, 왼쪽부터 입력 상황·5분 창에서 관측되는 값·경보 rule 의 기대 상태·담당자가 하는 일과 판정 순서로 한 줄씩 읽습니다. 통과 기준은 상태 이름이 아니라 넷째 칸입니다. 지속 장애 줄은 담당자 수신 증거가 있어야 통과이고, 수집 중단 줄에서는 조용함을 정상으로 읽지 않습니다. 초록 상자는 promtool 의 두 검사가 각각 어디까지만 보증하는지 구분하고, 호박색 상자는 임계값만 올리지 않는다는 기준과 owner·복구 기준·수집 신호가 없을 때 멈추는 조건을 정리합니다. 색을 구별하지 않아도 각 상자의 제목만으로 읽을 수 있습니다. 2%와 10분을 비롯한 표 안의 값과 상태 문자열은 교육용 fixture 이며 실제 장비에서 측정한 결과가 아닙니다. 시간 비율이나 Alertmanager 내부 구조를 그린 그림이 아니라 상태와 판정만 표현합니다. 자료: Prometheus Alerting practices · Prometheus Recording and Alerting Rules · Prometheus Unit testing for rules를 바탕으로 저자 구성.
왜 이런가
경보 rule은 조건과 지속 시간을 평가하고 Alertmanager는 묶기·라우팅·억제 등을 담당합니다. runbook은 영향 확인, 안전한 조회, 중단 기준, 완화와 복구 판정 순서를 연결합니다. 담당자와 검증된 행동이 없는 경보는 소음으로 남습니다.
언제 문제가 되는가
owner·복구 기준·수집 신호 없음 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
반복 경보를 줄이려고 임계값만 올리지 않습니다. 관련 경보의 묶기와 root cause 억제를 검토하고 사용자 영향 경보는 보존합니다.
직접 확인하는 방법
사용자 영향과 rule의 분모를 연결합니다. pending·firing·resolved 상태와 지속 시간을 구분합니다.
이 절을 정리하면정상·지속 장애·회복·수집 중단 입력에 대한 기대 상태와 담당자 수신·복구 확인 절차를 작성하면 성공입니다.

CHAPTER 1 / 5

사용자 영향에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 사용자 영향과 rule의 분모를 연결합니다. 2. pending·firing·resolved 상태와 지속 시간을 구분합니다. 3. 라우팅 대상과 근무 외 escalation을 확인합니다. 4. 검증할 runbook 행동과 정상 복귀 관찰 시간을 정합니다.

CHAPTER 2 / 5

지속 확인의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
promtool check rules service-alerts.yml
promtool test rules service-alerts.test.yml

CHAPTER 3 / 5

경보 전달의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
Checking service-alerts.yml
  SUCCESS: 1 rules found

SUCCESS

CHAPTER 4 / 5

runbook의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Alert와 Runbook의 복구를 재검증합니다

CONCRETE CASES

예제 rule의 문법 검사 성공이 알림 전달까지 보장하는지 판단하고 별도 시험 두 개를 설계합니다.

fixture에서는 5분 오류율 2% 초과가 10분 지속될 때 호출합니다. 이는 학습용 기준이지 모든 서비스의 적정 임계값이 아닙니다. 실제 기준은 SLO와 요청량, 대응 시간 및 누락 비용으로 정합니다.

잘못된 대응과 확인할 경계

반복 경보를 줄이려고 임계값만 올리지 않습니다. 관련 경보의 묶기와 root cause 억제를 검토하고 사용자 영향 경보는 보존합니다.

오탐이 나면 해당 구간의 시계열과 rule revision을 보존합니다. 수정 rule을 과거 구간과 인위적인 실패 구간에 모두 시험한 뒤 canary로 적용합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 예제 rule의 문법 검사 성공이 알림 전달까지 보장하는지 판단하고 별도 시험 두 개를 설계합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, owner·복구 기준·수집 신호 없음 조건이 보이면 다음 변경으로 넘어가지 마십시오.

Checking service-alerts.yml
  SUCCESS: 1 rules found

SUCCESS

값 자체를 외우는 것이 아니라 첫 결과는 문법, 둘째 결과는 준비한 시계열 시험의 성공이며 수신자의 실제 수신 증거는 별도라는 점을 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

반복 경보를 줄이려고 임계값만 올리지 않습니다. 관련 경보의 묶기와 root cause 억제를 검토하고 사용자 영향 경보는 보존합니다.

KEY TERMS

이번 단원 핵심 용어

Runbook(대응 절차서)
증상에서 확인·중단·완화·재검증으로 이어지는 담당자의 행동 절차입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Alert와 Runbook의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 4 / 4

Incident 대응과 postmortem

timeline·역할·복구·동일 조건 재검증·재발 방지를 기록합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

제공 기록 읽기 전용·운영 수집기 접근 없음. 예제 주소는 문서용이며 실제 요청하지 않습니다.

3앞 단원 「Alert와 Runbook」에서 어떤 증거를 남겼습니까?

정상·지속 장애·회복·수집 중단 입력에 대한 기대 상태와 담당자 수신·복구 확인 절차를 작성하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Incident 대응과 postmortem의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Incident 대응과 postmortem의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Incident 대응과 postmortem의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Incident 대응과 postmortem 실습 환경과 안전 경계
하드웨어브라우저의 signal·incident 기록 fixture
소프트웨어Prometheus HTTP API v1·OpenTelemetry W3C trace context
필요 권한제공 기록 읽기 전용·운영 수집기 접근 없음
네트워크예제 주소는 문서용이며 실제 요청하지 않습니다

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Prometheus HTTP API v1 · W3C Trace Context version 00 header · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장영향 발견에서 확인을 시작합니다
  2. 2장대응 선언의 실습 대상을 고정합니다
  3. 3장완화 실행의 출력과 의미를 구분합니다
  4. 4장재검증의 진행과 중단을 결정합니다
  5. 5장Incident 대응과 postmortem의 복구를 재검증합니다
Incident 대응과 postmortem의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · 영향 발견에서 확인을 시작합니다

다음 연결: 대응 선언의 실습 대상을 고정합니다

  1. 영향 발견에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 대응 선언의 실습 대상을 고정합니다

    실습 상황:: timeline fixture를 읽고 회복 시각, 잠정 가설, 아직 모르는 항목을 분리해 교대 문서를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 증거 없는 종결·동시 변경 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 완화 실행의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 관측·결정·조치가 구분되고 같은 요청량에서 회복을 확인했는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 재검증의 진행과 중단을 결정합니다

    영향 구간, 완화 근거, 반증 가능한 원인 가설, 미확인 사항과 재발 검사 담당자를 포함하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Incident 대응과 postmortem의 복구를 재검증합니다

    회복 후 재악화하면 incident를 다시 활성화하고 마지막 정상 revision과 dependency 상태를 대조합니다. 인계받은 담당자가 같은 조회로 현재 상태를 재현하기 전에는 소유권 이전을 끝내지 않습니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

사실과 결정을 시간축에 남겨 복구를 검증합니다

Postmortem(장애 사후 분석): 영향·시간축·원인 조건과 재발 방지 조치를 증거로 정리하는 문서입니다.

장애 대응에서는 서비스 완화와 원인 규명을 나눕니다. 원인을 확정할 때까지 기다리면 피해가 커질 수 있지만, 증거 없이 여러 변경을 동시에 적용하면 어떤 행동이 효과가 있었는지 알 수 없습니다. 지휘·실행·소통 역할을 나누어 충돌을 줄입니다.

timeline은 관측 사실, 가설, 결정, 실행 결과를 같은 시간 기준으로 남깁니다. rollback 직후 오류율이 줄어도 원인이 완전히 밝혀졌다고 단정하지 않습니다. 이후 postmortem에서 촉발 조건과 탐지·완화의 빈틈을 연결합니다.

교육 사고는 10:00 배포, 10:04 오류율 상승, 10:06 incident 선언, 10:09 rollback, 10:12 회복 확인 순서입니다. 시간상 가까운 배포는 우선 가설이지만, dependency 장애나 traffic 변화도 대조해야 합니다.

timeline fixture를 읽고 회복 시각, 잠정 가설, 아직 모르는 항목을 분리해 교대 문서를 작성합니다.

10시 00분 배포부터 10시 12분 회복 확인까지 다섯 줄의 timeline 을 관측·결정·조치로 나누고, 그때의 역할과 아직 확정하지 않은 것을 함께 적은 표입니다.
그림 읽는 법 표를 위에서 아래로 시각 순서대로 읽습니다. 첫째 칸은 시각과 기록 종류(change·observation·decision·action), 둘째 칸은 timeline 에 남는 줄이며 jq -r '.events[] | [.time,.kind,.detail] | @tsv' 의 출력 형식과 같습니다. 셋째 칸은 그때 누가 무엇을 했는지이고, 넷째 칸은 그 시점에 아직 확정하지 않은 것입니다. 10:06 의 선언은 원인 확정이 아니고 10:09 의 rollback 은 완화일 뿐이며, 회복은 10:12 에 request volume unchanged 가 함께 관측될 때 비로소 인정된다는 점을 넷째 칸과 대조하십시오. 아래 왼쪽 상자는 postmortem 이 영향 구간·완화 근거·반증 가능한 가설·재발 방지 action 의 owner 와 기한을 어떻게 연결하는지 정리하고, 오른쪽 상자는 증거 없는 종결과 동시 변경처럼 incident 를 닫지 않는 조건을 적었습니다. 색을 구별하지 않아도 각 상자의 제목만으로 읽을 수 있습니다. 시각과 값은 교육용 timeline fixture 이며 실제 장비에서 측정한 결과가 아닙니다. 모든 대응 절차와 시간 비율을 그린 그림이 아니라 기록의 종류와 판정만 표현합니다. 자료: Google SRE Workbook: Incident Response · Google SRE: Postmortem Culture를 바탕으로 저자 구성.
왜 이런가
timeline은 관측 사실, 가설, 결정, 실행 결과를 같은 시간 기준으로 남깁니다. rollback 직후 오류율이 줄어도 원인이 완전히 밝혀졌다고 단정하지 않습니다. 이후 postmortem에서 촉발 조건과 탐지·완화의 빈틈을 연결합니다.
언제 문제가 되는가
증거 없는 종결·동시 변경 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
특정 사람을 원인으로 적지 않습니다. 당시 접근 가능한 정보와 시스템이 허용한 실패 조건을 설명하며 개인정보와 credential은 지웁니다.
직접 확인하는 방법
사용자 영향·시작 시각·범위를 먼저 기록합니다. incident commander·실행자·소통 담당자를 지정합니다.
이 절을 정리하면영향 구간, 완화 근거, 반증 가능한 원인 가설, 미확인 사항과 재발 검사 담당자를 포함하면 성공입니다.

CHAPTER 1 / 5

영향 발견에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 사용자 영향·시작 시각·범위를 먼저 기록합니다. 2. incident commander·실행자·소통 담당자를 지정합니다. 3. 변경별 가설·예상 효과·실제 효과를 남깁니다. 4. 재발 방지 action에 owner·기한·실패 재현 검사를 연결합니다.

CHAPTER 2 / 5

대응 선언의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
jq -r '.events[] | [.time,.kind,.detail] | @tsv' incident.json

CHAPTER 3 / 5

완화 실행의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
10:04	observation	5xx 8%
10:06	decision	incident declared
10:09	action	rollback r8 to r7
10:12	observation	5xx 0.1%, request volume unchanged

CHAPTER 4 / 5

재검증의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Incident 대응과 postmortem의 복구를 재검증합니다

CONCRETE CASES

timeline fixture를 읽고 회복 시각, 잠정 가설, 아직 모르는 항목을 분리해 교대 문서를 작성합니다.

교육 사고는 10:00 배포, 10:04 오류율 상승, 10:06 incident 선언, 10:09 rollback, 10:12 회복 확인 순서입니다. 시간상 가까운 배포는 우선 가설이지만, dependency 장애나 traffic 변화도 대조해야 합니다.

잘못된 대응과 확인할 경계

특정 사람을 원인으로 적지 않습니다. 당시 접근 가능한 정보와 시스템이 허용한 실패 조건을 설명하며 개인정보와 credential은 지웁니다.

회복 후 재악화하면 incident를 다시 활성화하고 마지막 정상 revision과 dependency 상태를 대조합니다. 인계받은 담당자가 같은 조회로 현재 상태를 재현하기 전에는 소유권 이전을 끝내지 않습니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: timeline fixture를 읽고 회복 시각, 잠정 가설, 아직 모르는 항목을 분리해 교대 문서를 작성합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, 증거 없는 종결·동시 변경 조건이 보이면 다음 변경으로 넘어가지 마십시오.

10:04	observation	5xx 8%
10:06	decision	incident declared
10:09	action	rollback r8 to r7
10:12	observation	5xx 0.1%, request volume unchanged

값 자체를 외우는 것이 아니라 관측·결정·조치가 구분되고 같은 요청량에서 회복을 확인했는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

특정 사람을 원인으로 적지 않습니다. 당시 접근 가능한 정보와 시스템이 허용한 실패 조건을 설명하며 개인정보와 credential은 지웁니다.

KEY TERMS

이번 단원 핵심 용어

Postmortem(장애 사후 분석)
영향·시간축·원인 조건과 재발 방지 조치를 증거로 정리하는 문서입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Incident 대응과 postmortem의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

GPU utilization은 정상인데 사용자 응답 p99가 두 배로 늘었습니다. 먼저 할 일은 무엇입니까?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

trace ID를 metric label로 넣으면 어떤 문제가 생깁니까?

답 선택
적용 문제 2

요청 1,000건 중 실패 20건입니다. 같은 구간의 오류율은?

답 선택
종합 문제 3

복구 후 postmortem의 조치로 가장 적절한 것은?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.