Skip to content
Published on

SLO와 Error Budget 실행 매뉴얼

🇰🇷KO🇺🇸EN🇯🇵JA
Authors
  • Name
    Twitter
SLO와 Error Budget 실행 매뉴얼

문제 정의

SLO/Error Budget과 OpenTelemetry 도입이 실패하는 이유는 데이터 수집만 하고, 운영 의사결정(출시 중단·우선순위 변경)으로 연결하지 못하기 때문이다.

아키텍처/원리

  • SLO는 대시보드 숫자가 아니라 출시 정책이다.
  • OTel은 trace/metric/log를 동일한 속성(서비스, 버전, 리전)으로 연결해야 가치가 생긴다.
  • burn-rate 경보는 다중 윈도우로 설계한다.

구현 예시 1

slo:
  availability: 99.9
  window_days: 30
  alerts:
    - burn_rate: 14
      window: 5m
    - burn_rate: 2
      window: 1h

구현 예시 2

def error_budget_remaining(target=0.999, actual=0.997):
    return max(0.0, (1-target) - (1-actual))

구현 예시 3

SELECT service, sum(errors)::float/sum(total) AS err
FROM slo_hourly
WHERE ts >= now()-interval '30 days'
GROUP BY service;

구현 예시 4

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  prometheus: {}
service:
  pipelines:
    traces: { receivers: [otlp], exporters: [prometheus] }

운영 팁

  • 출시 승인 조건에 “에러버짓 잔량”을 명시한다.
  • 로그 샘플링과 trace 샘플링을 트래픽 클래스별로 분리한다.
  • Incident 회고에 SLI 왜곡 여부를 포함한다.

트러블슈팅

  1. 경보 폭주: 정적 임계치 대신 burn-rate 기반으로 재설계.
  2. trace 단절: context propagation 미적용 구간 식별.
  3. 지표 해석 불일치: SLI 정의를 제품/플랫폼 공동 문서로 고정.

체크리스트

  • SLO-릴리스 정책 연결
  • OTel 속성 표준화
  • 다중 윈도우 경보
  • 에러버짓 리뷰 주기
  • 회고 템플릿 정착

결론

관측성의 목표는 더 많은 그래프가 아니라, 장애를 더 빨리 멈추고 제품 결정을 더 정확히 내리는 것이다.

참고 자료

Discuss on Twitter • View on GitHub