estudy 한국어/English

Incident Severity 산정 방식

1,572 단어·4 분·원문(.md)

저번 시간에는 장애 대응시 우선순위 판단 기준 (어떤 장애가 가장 심각하고 어떻게 대응해야하는지)를 알아보았고 오늘은 그 산정방식을 알아보자.

즉 객관적으로 수치화하고 등급을 매기는 방식 Incident Severity 장애 등급 산정 방식이다.

Severity 산정의 필요성과 2가지 핵심축 #

장애 등급 SEV, Severity를 명확하게 산정하지 않으면 사소한 버그에 전사 엔지니어가 새벽에 깨어나거나 리소스 낭비를 하기 쉽다.

반대로 결제가 안되는데 다음날 출근해서 고치는 비즈니스 망함 대참사도 발생할 수 있다.

글로벌 it기업 구글 넷플릭스의 sre 표준에서는 severity는 보통 영향도 impact와 ㄱ니급도 urgency라는 두 가지 축을 곱하여 산정한다.

비즈니스 영향도 Impact #

장애가 비즈니스 (매출, 유저경험, 데이터무결성)에 얼마나 타격을 주는지를 평가한다.

  • High (치명적): 핵심 결제 불가, 대규모 데이터 유실, 전면 접속 불가 (회사의 돈이 실시간으로 타들어감)
  • Medium (중간): 주요 기능 지연, 특정 지역/일부 유저(예:10%미만)에게만 에러가 발생하고 수익과 직결되지 않는 기능 마비.
  • Low (낮음): 내부 어드민 툴 버그, 사소한 UI/UX 깨짐, 우회 가능한 단순 에러

긴급도 Urgency #

당장 지금 고쳐야하는가 아니면 시간을 두고 고쳐도 되는가를 평가해야한다. 우회책 workaround의 존재 여부가 중요하다

  • High (즉각대응): 우회책이 전혀 없으며, 방치할 경우 피해가 기하급수적으로 커짐 (예: 보안 뚫림, db 100% 용량 임박)
  • Medium (빠른 대응): 고객이 불편하지만 우회할 방법이 있거나 (앱 대신 웹으로 결제 같은) 피해가 확산되지 않음
  • Low (일반 대응): 고객이 거의 눈치채지 못하거나 다음 정기 배포 일정에 맞춰서 수정해도 되는거

Matrix #

위의 두가지 축을 결합하면 누구나 감정이 아닌 기준에 따라 기계적으로 등급을 판정할 수 있는 메트릭스가 완성된다.

조직마다 숫자가 낮을수록 심각한 SEV-1 시스템을 쓰거나 반대로 Priority 1(P1) 시스템을 쓴다 여기서는 SEV-1가 최고 심각한 기준

영향도 (Impact) \ 긴급도 (Urgency)High (즉각 대응 필요)Medium (우회 가능/확산 안됨)Low (천천히 수정 가능)
High (핵심 비즈니스 타격)SEV-1 (Critical)SEV-2 (Major)SEV-3 (Minor)
Medium (일부 기능 타격)SEV-2 (Major)SEV-3 (Minor)SEV-4 (Low)
Low (내부/사소한 타격)SEV-3 (Minor)SEV-4 (Low)SEV-5 (Info)

자동화 알람 룰 및 명령어 예시 #

현대적인 인프라 환경에서는 사람이 직접 sev를 판단하기도 하지만 APM이나 알람툴에 수치를 걸어두고

기계가 1차적으로 severity를 산정하여 알람을 쏘도록 자동화한다.

Datadog 알람 monitor 설정 코드로 보는 severity 자동 산정 terraform 예시 #

결제 api 5xx 에러 비율에 따라 자동으로 sev 등급을 매기고 호출할 대상을 지정하는 인프라 코드다

resource "datadog_monitor" "payment_api_error_rate" {
  name               = "[Payment API] 5xx Error Rate is too high"
  type               = "query alert"
  query              = "avg(last_5m):avg:trace.http.request.errors{service:payment-api} / avg:trace.http.request.hits{service:payment-api} > 0.1"
  
  # 에러율 수치에 따라 Severity 등급을 기계적으로 분리
  monitor_thresholds {
    critical = 0.10  # 5분간 에러율 10% 초과 -> SEV-1
    warning  = 0.05  # 5분간 에러율 5% 초과 -> SEV-2
  }

  # 발생한 등급(Threshold)에 따라 슬랙 채널과 PagerDuty(전화) 대상을 분기 처리
  message = <<EOF
  {{#is_alert}}
    🚨 **[SEV-1] 결제 API 에러율 10% 돌파!** 비즈니스 영향도(Impact): High, 긴급도(Urgency): High
    즉시 대응 바랍니다! @pagerduty-payment-team-critical
  {{/is_alert}}
  
  {{#is_warning}}
    ⚠️ **[SEV-2] 결제 API 에러율 5% 돌파**
    비즈니스 영향도: Medium, 긴급도: High
    온콜(On-call) 담당자는 현상을 확인하세요. @slack-payment-backend-team
  {{/is_warning}}
  EOF
}

Slack을 통한 수동 incident 선언 명령어도 알아보자 pagerduty나 jibot을 연동해서

만약 시스템이 잡지 못하는 논리적 버그 예를들어 결제는 성공하는데 상품 지급이 안되었다거나 등같은 cs팀이나 엔지니어가 발견했을대, 슬랙봇을 통해 즉시 메트릭스 기준에 맞춰 장애를 선언하고 워룸을 여는 방식이다.

# 슬랙 채널에 명령어 입력
/incident declare

# 봇이 띄워주는 팝업에 입력 (예시)
- Title: 프로모션 쿠폰 적용 시 결제 금액 0원 처리되는 버그
- Impact: High (회사 매출 직접적 손실 발생 중)
- Urgency: High (지금 이 순간에도 악용 유저 증가 중, 우회책 없음)
- Severity: SEV-1 (위 매트릭스에 따라 자동 매핑)
- Component: Coupon Service, Payment Gateway
  1. #inc-20260316-coupon-bug 라는 전용 워룸(슬랙 채널) 자동 생성.
  2. PagerDuty를 통해 백엔드 리드와 결제/쿠폰 담당자 스마트폰으로 강제 전화(Call) 발신.
  3. 장애 대시보드 상태가 'Green'에서 'Red'로 즉시 변경됨.
SRE/question/q_42.md