SLO burn rate 알람, fast burn 하나만 두지 마세요

며칠 전에 팀 신입한테 SLO 세팅을 맡겼는데, 결과물이 좀 아쉬웠다. Availability SLO 99.9% 걸어놓고 burn rate 알람을 하나만 만들어놨더라. 1시간 윈도우에 14.4x 넘으면 알람. 이거 흔한 실수라서 짧게 정리해둔다.

왜 하나면 부족한가

burn rate 알람 하나만 두면 두 가지 중 하나 문제가 무조건 생긴다.

윈도우를 짧게 잡으면 (예: 5분/1시간) — 트래픽 스파이크 한 번에 알람을 뜬다. 새벽에 CDN이 잠깐 흔들려서 5분간 에러율 튀었다? 알람 온다. 근데 실제로는 15분 후에 자동 복구됐다. 오탐이다. 이런 게 반복되면 팀이 알람을 무시하기 시작한다.

윈도우를 길게 잡으면 (예: 6시간/3일) — 진짜 큰 장애가 났는데 알람이 늦게 온다. 30분간 API가 완전히 죽어 있었는데도 6시간 윈도우 평균으로는 아직 threshold를 안 넘어서 조용하다. 감지가 30분 이상 늦어진다.

그래서 최근 SRE 워크북 스타일은 여러 윈도우를 조합하는 게 표준이다. Multi-window multi-burn-rate. 이름은 거창한데 개념은 간단하다.

3단 구성이 일반적이다

Google SRE Workbook의 표준 예시 그대로 쓰는 팀이 많다. 30일 예산 기준으로:

• Fast burn — 1시간 윈도우 + 5분 짧은 윈도우, 14.4x. 2% 예산을 1시간 안에 태우면 페이지.
• Medium burn — 6시간 윈도우 + 30분 짧은 윈도우, 6x. 5% 예산을 6시간 안에 태우면 페이지.
• Slow burn — 3일 윈도우 + 6시간 짧은 윈도우, 1x. 10% 예산을 3일 안에 태우면 티켓.

각 알람은 긴 윈도우와 짧은 윈도우가 동시에 threshold를 넘어야 발화한다. 이게 핵심이다. 긴 윈도우로 "진짜 지속되는 이슈"를 확인하고, 짧은 윈도우로 "지금도 계속되고 있는가"를 확인한다. 이미 복구된 이슈로 알람 안 뜨게 하는 장치다.

Prometheus 룰로 쓰면 이렇게 된다

- alert: SLOFastBurn
  expr: |
    (
      job:slo_errors_ratio:rate1h{job="api"} > (14.4 * 0.001)
      and
      job:slo_errors_ratio:rate5m{job="api"} > (14.4 * 0.001)
    )
  for: 2m
  labels:
    severity: page

- alert: SLOMediumBurn
  expr: |
    (
      job:slo_errors_ratio:rate6h{job="api"} > (6 * 0.001)
      and
      job:slo_errors_ratio:rate30m{job="api"} > (6 * 0.001)
    )
  for: 15m
  labels:
    severity: page

0.001이 99.9% SLO의 허용 에러율(1 - 0.999). Fast burn은 severity: page로 즉시 호출, slow burn은 티켓만 자르게 하는 게 보통이다. 새벽에 slow burn으로 사람 깨우면 팀에서 미움받는다.

대시보드는 별도로 만들어라

알람이랑 별개로 burn rate 그래프는 대시보드에 꼭 있어야 한다. 알람이 안 떠도 burn rate가 slow하게 올라가는 상황(예: 0.5x가 며칠째 유지)이 있는데, 이게 결국 예산 잠식으로 이어진다. 알람은 threshold 도달 여부만 알려주지만, 대시보드로는 추세를 본다.

우리 팀은 요즘 burn rate를 SLO 대시보드 최상단에 크게 박아두고, 주간 정기 리뷰에서 한 번씩 훑는다. 이게 postmortem이나 capacity 결정보다 훨씬 앞선 신호가 된다.

혹시 fast burn 하나로만 쓰고 있는 분들, 한 번 3단 구성으로 바꿔보시길. 알람 노이즈랑 감지 지연이 동시에 잡힌다.