SLO와 에러 버짓

학습 목표

SLI · SLO · SLA 차이를 설명하고 각각 누가 정의·측정하는지 구분할 수 있다.

Error budget(허용 실패량)이 99.9% 같은 목표에서 어떻게 계산되는지 설명할 수 있다.

Burn rate로 budget을 얼마나 빠르게 태우는지 측정·알람할 수 있다.

Prometheus PromQL로 availability SLI·budget remaining·burn rate를 표현할 수 있다.

Error budget 정책(배포 freeze, incident 우선)을 팀과 합의할 수 있다.

문제 상황

• SLA 99.9% 계약 — 장애 후 “이번 달 몇 % 남았지?” 아무도 모름
  • 가용성 감은 있는데 숫자·정책이 없다
• 알람이 CPU 80%·pod restart — 사용자 체감과 불일치
  • 5xx rate는 오는데 on-call은 인프라만 본다
• 배포 직후 장애 — “이번 주 배포 멈출까?” 감으로 결정
  • error budget 소진 시 freeze 규칙이 없다
• Grafana SLO 패널은 만들었지만 SLI 정의가 팀마다 다름
  • 5xx만? latency? 특정 route 제외?
• burn rate 2.4x 알람 — 무슨 윈도·얼마나 지속해야 page?

Part 4 시작 — 11편까지 신호·연계는 갖췄다. 이제 “얼마나 망가져도 되는가”를 숫자로.

1. SLI · SLO · SLA

용어	정의	예
SLI	Service Level Indicator — 측정 지표	good requests / total
SLO	Service Level Objective — 내부 목표	99.9% / 30일 rolling
SLA	Service Level Agreement — 계약·보상	99.5% 미만 시 크레딧

SLI  = 실제 측정 (Prometheus·로그 집계)
SLO  = SLI ≥ target (팀·제품 목표)
SLA  = SLO보다 보통 **느슨** — 법무·고객 facing

• SLO < SLA 여유 — SLA breach 전에 내부에서 대응
• SLI는 사용자 관점 — server CPU 아님 (앞서 RED)
• Architecture 가용성 품질 속성 — SLO가 운영 숫자로 구현

2. SLI 고르기

SLI 유형	good event	total / window
Availability	2xx·3xx (또는 non-5xx)	HTTP requests
Latency	duration < threshold	requests with latency
Freshness	data age < N min	pipeline runs

# Availability SLI (5xx 제외) — 30d rolling ratio
sum(increase(http_requests_total{job="api", status!~"5.."}[30d]))
/
sum(increase(http_requests_total{job="api"}[30d]))

원칙
단순	on-call이 한 문장으로 설명
사용자 proxy	gateway edge 측정 preferred
동일	SLO 대시보드 = alert = postmortem 같은 SLI
제외 명시	health check·/metrics scrape 제외 여부 문서화

Latency SLI 예:

# requests faster than 500ms / all requests (histogram)
sum(rate(http_request_duration_seconds_bucket{job="api", le="0.5"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="api"}[5m]))

• 앞서 RED·histogram — SLI 원료
• SLI 여러 개 가능 — availability 하나로 시작 권장

3. Error budget

SLO 99.9% (30일) → 허용 실패율 0.1% = error budget 0.001.

기간	total requests (가정)	budget (실패 허용)
30d	10M	10,000 failed
30d	100M	100,000 failed

Error budget remaining =
  1 - (bad_events / budget_total)
  budget_total = (1 - SLO_target) × total_events_in_window

# Error budget remaining (0~1) — target 99.9%
(
  1 -
  (
    sum(increase(http_requests_total{job="api", status=~"5.."}[30d]))
    /
    sum(increase(http_requests_total{job="api"}[30d]))
  )
)
/
(1 - 0.999)

• 1.0 — budget 100% 남음
• 0.0 — budget 소진 — SLO 위반 임박/발생
• 앞서 Grafana SLO 패널 — 이제 의미 정의

Budget으로 하는 일

budget 상태	정책 (예)
> 50%	정상 배포·실험
25~50%	risky change 리뷰 강화
< 25%	배포 freeze (hotfix만)
0%	incident 우선 — feature freeze

• Platform canary/blue-green — budget 낮을 때 traffic shift 보수 (앞서 배포 전략)
• budget은 blameless postmortem 우선순위 근거

4. Burn rate

Burn rate — budget 대비 현재 실패율 속도.

burn_rate = (short_window_error_rate) / (1 - SLO_target)

• target 99.9% → budget 0.001
• 1h error rate 0.002 → burn rate 2.0 — budget 2배속 소진
• > 1 — 허용보다 빠르게 태움

# 1h burn rate (앞서 Grafana 7편과 동일)
(
  sum(rate(http_requests_total{job="api", status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total{job="api"}[1h]))
)
/
(1 - 0.999)

Multi-window alert (Google SRE)

심각도	window	burn threshold	의미
page	1h	14.4x	budget 2%를 1h에 — 빠른 장애
page	6h	6x	지속적 bad
ticket	3d	1x	느린 leak

• 짧은 window — acute outage
• 긴 window — slow burn
• for: 5m — flapping 방지 (앞서 Grafana alert)

전체 PromQL: code/slo-promql.promql
Alert rule 예: code/slo-burn-alert.yaml

5. Grafana · Prometheus 운영

패널	쿼리	용도
SLI 30d	availability ratio	현재 SLO 충족?
Budget remaining	§3 formula	릴리스 게이트
Burn 1h / 6h	§4 formula	page vs ticket
RED overlay	rate·errors·latency	장애 맥락

• recording rule — job:sli_availability:ratio5m pre-aggregate (cardinality·성능)
• annotation — deploy marker (Platform CI/CD)
• SLO breach → 11편 trace/log drill-down

6. 안티패턴

안티패턴
SLI = CPU	사용자 무관
SLO 100%	budget 0 — 배포 불가
SLA = SLO	여유 없음 — breach 즉시 계약 위반
alert 없이 dashboard만	budget 소진 후 발견
SLI 정의 비공개	팀마다 다른 99.9%
burn 단일 window	slow leak 놓침

7. 실무 체크리스트

항목	권장
SLI	1~2개 — availability + (optional) latency
SLO	30d rolling, 문서 + dashboard
SLA	SLO보다 낮게 — legal review
budget policy	50/25/0% gate — 팀 합의
alert	multi-window burn + for
review	분기 SLO retrospective

산출물
SLI spec	good/bad 정의, 제외 route
Error budget policy	freeze·escalation
Grafana board	SLI + budget + burn
Runbook	burn alert 시 첫 3 step (13편)

8. 정리

• SLI 측정 · SLO 목표 · SLA 계약 — 층이 다름
• Error budget — SLO에서 역산한 허용 실패량
• Burn rate — budget 소진 속도 — multi-window alert
• budget 정책으로 배포·우선순위 합의
• 다음 — 온콜·인시던트 runbook·postmortem

다음에 다룰 것

• 온콜과 인시던트
• runbook, postmortem, severity

---

해당 내용은 Site Reliability Engineering (Google), Implementing Service Level Objectives (Google), Observability Engineering (Charity Majors, Liz Fong-Jones, George Miranda) 의 내용을 기반으로 합니다.