OA
OpenAkashic
SLO Error Budget Policy Failure Modes: Multi-Window Burn-Rate Alerts, Low-Traffic Services, Maintenance Windows, and Budget Reset Semantics
/////

SLO Error Budget Policy Failure Modes: Multi-Window Burn-Rate Alerts, Low-Traffic Services, Maintenance Windows, and Budget Reset Semantics

SLO error budget policy는 “목표치”보다 “운영 계약”에 가깝다. 실패 모드는 대개 수식 자체보다 다음 네 지점에서 발생한다: 1) multi-window / multi-burn-rate alert가 너무 민감하거나 너무 둔감하게 설계됨, 2) low-traffic 서비스에서 비율 기반 SLI가 통계적으로 불안정함, 3) maintenance window와 planned downtime을 error budget에서 어떻게 처리할지 합의하지 않음

/////

Summary#

SLO error budget policy는 “목표치”보다 “운영 계약”에 가깝다. 실패 모드는 대개 수식 자체보다 다음 네 지점에서 발생한다:
1) multi-window / multi-burn-rate alert가 너무 민감하거나 너무 둔감하게 설계됨,
2) low-traffic 서비스에서 비율 기반 SLI가 통계적으로 불안정함,
3) maintenance window와 planned downtime을 error budget에서 어떻게 처리할지 합의하지 않음,
4) rolling window, calendar window, reset 시점의 의미를 조직이 다르게 이해함.

핵심 원칙은 “error budget을 소모하는 사용자 영향”과 “알림을 울릴 만큼 신뢰할 수 있는 관측량”을 분리해서 설계하는 것이다. burn-rate alert는 빠른 대형 장애와 느린 장기 누수를 동시에 잡기 위해 multi-window로 구성하되, 저트래픽 서비스에서는 최소 이벤트 수, absolute error count, synthetic probe, latency/availability 보조 신호를 함께 고려해야 한다. maintenance window와 budget reset semantics는 도구 설정이 아니라 SLO 계약서에 명시해야 한다.

Key Points#

  • Multi-window multi-burn-rate alert의 목적
  • Google SRE Workbook의 burn-rate alerting 패턴은 짧은 창과 긴 창을 함께 사용해 “빠르게 타는 장애”와 “느리지만 지속적인 예산 소모”를 구분하려는 접근이다.
  • 예: 짧은 window는 빠른 탐지에 유리하지만 noise가 많고, 긴 window는 안정적이지만 탐지가 늦다.
  • 두 window가 모두 threshold를 넘을 때 paging하는 방식은 transient spike로 인한 false positive를 줄인다.

  • 실패 모드:

    • 짧은 window만 사용해 일시적 spike마다 page 발생.
    • 긴 window만 사용해 실제 장애 탐지가 늦음.
    • burn-rate threshold를 서비스 중요도, SLO period, on-call 정책과 무관하게 복사함.
    • warning ticket과 paging alert의 burn-rate를 구분하지 않음.

  • Burn rate는 “현재 오류율 / 허용 오류율”이다

  • 예를 들어 99.9% availability SLO는 허용 오류율이 0.1%다.
  • 실제 오류율이 1%이면 burn rate는 10x다.
  • 의미: 현재 속도로 오류가 계속되면 error budget을 정상보다 10배 빠르게 소모한다.

  • 실패 모드:

    • burn rate를 단순 error rate로 오해함.
    • SLO target이 바뀌었는데 alert threshold는 그대로 둠.
    • denominator, 즉 전체 요청 수 또는 전체 valid event 수가 바뀌었는데 budget burn 해석을 유지함.

  • Low-traffic 서비스는 비율 기반 SLO가 흔들린다

  • 요청 수가 적으면 한두 건의 실패가 매우 큰 error rate로 보인다.
  • 반대로 요청이 거의 없으면 장애가 발생해도 관측 이벤트가 부족해 alert가 늦거나 발생하지 않을 수 있다.
  • 실패 모드:
    • errors / total 비율만 보고 page를 발생시킴.
    • denominator가 작은데 burn rate가 높다는 이유만으로 critical incident로 취급함.
    • 야간·주말처럼 traffic pattern이 낮은 시간대의 burn rate를 평시와 동일하게 해석함.

  • 완화책:

    • 최소 요청 수 조건을 alert expression에 포함한다.
    • 비율 조건과 absolute error count 조건을 함께 둔다.
    • user traffic이 적은 control-plane, internal API, batch service에는 synthetic check나 heartbeat SLI를 보조로 사용한다.
    • “low traffic에서는 SLO가 무의미하다”가 아니라 “비율 SLO만으로는 page 근거가 약하다”고 문서화한다.

  • Denominator drift는 SLO 의미를 바꾼다

  • SLI가 bad events / total valid events라면 denominator 정의가 바뀌는 순간 과거와 현재의 error budget burn이 달라진다.
  • 예:
    • health check 요청을 포함했다가 제외함.
    • retry 요청을 별도 request로 계산함.
    • bot traffic, internal traffic, cached response를 포함하거나 제외함.
    • maintenance 중 발생한 5xx를 denominator에서 제거함.
  • 실패 모드:
    • metric label 변경, gateway migration, sampling 변경 후에도 같은 SLO라고 주장함.
    • denominator 감소로 error rate가 상승했는데 실제 사용자 영향 증가로 오해함.
    • denominator 증가로 error rate가 희석되어 장애를 놓침.

  • 정책:

    • SLI numerator와 denominator 정의를 SLO 문서에 고정한다.
    • major instrumentation change 시 “SLO continuity break” 여부를 기록한다.
    • reset 또는 backfill 여부를 임의로 결정하지 말고 governance 절차로 처리한다.

  • Maintenance window는 error budget 정책의 핵심 예외 규칙이다

  • planned maintenance를 budget에서 제외할지 포함할지는 기술 문제가 아니라 운영 계약이다.
  • 제외하면 팀은 계획 작업을 더 쉽게 수행할 수 있지만, 사용자는 여전히 downtime을 경험할 수 있다.
  • 포함하면 사용자 관점에는 정직하지만, 필요한 유지보수 작업이 error budget을 과도하게 소모할 수 있다.
  • 실패 모드:
    • maintenance를 알림 silence만 하고 SLO 계산에는 포함하는지 여부를 정하지 않음.
    • alert silence를 budget exclusion으로 착각함.
    • scheduled maintenance 동안 발생한 실제 unexpected incident까지 모두 제외함.
    • window 시작·종료 시각, timezone, partial outage 처리 기준이 없음.

  • 권장 계약:

    • “planned maintenance는 SLO에서 제외/포함한다”를 명시한다.
    • 제외한다면 승인 조건, 사전 공지, 최대 duration, affected services, audit trail을 둔다.
    • monitoring silence, incident declaration, SLO correction은 서로 다른 행위로 분리한다.

  • Rolling window와 calendar window는 다른 운영 의미를 가진다

  • Rolling window:
    • 최근 N일 또는 N시간을 계속 움직이며 평가한다.
    • 최근 사용자 경험을 더 잘 반영한다.
    • 나쁜 이벤트가 window 밖으로 밀려날 때 budget이 점진적으로 회복된다.
  • Calendar window:
    • 월, 분기 등 고정 기간으로 평가한다.
    • 조직의 리포팅, 목표 관리, 계약 기간과 맞추기 쉽다.
    • 기간 초에는 budget이 “새로 생긴 것처럼” 보이고, 기간 말에는 회복이 늦다.

  • 실패 모드:

    • “이번 달 reset”을 “사용자 영향이 사라짐”으로 오해함.
    • calendar reset 직후 대형 장애가 발생해도 남은 기간 동안 행동 기준이 불명확함.
    • rolling window에서 budget이 회복되는 것을 실제 reliability 개선으로 착각함.
    • 툴은 rolling으로 계산하는데 경영 보고는 calendar로 해석함.

  • Budget reset semantics는 반드시 문서화해야 한다

  • reset은 보통 계산 기간이 바뀌는 것이지, 장애 기록을 삭제하는 것이 아니다.
  • reset 정책에서 정해야 할 것:
    • SLO period: 7일, 28일, 30일, calendar month, quarter 등.
    • budget reset 시점: UTC 기준인지 local timezone 기준인지.
    • reset 후 이전 incident가 decision-making에 남는지.
    • maintenance correction, data correction, metric outage correction을 허용하는지.
    • correction을 누가 승인하고 어디에 감사 기록을 남기는지.

  • 실패 모드:

    • error budget이 reset되었으므로 freeze도 자동 해제된다고 가정함.
    • 월말 장애가 다음 달 정책 결정에 영향을 주지 않음.
    • SLO tooling의 reset semantics와 release governance의 reset semantics가 다름.

  • Alert policy와 release policy를 분리하되 연결해야 한다

  • Burn-rate alert는 “지금 대응해야 하는가”를 결정한다.
  • Error budget policy는 “릴리즈를 계속할 수 있는가”, “reliability work로 전환해야 하는가”를 결정한다.
  • 실패 모드:
    • page가 없었으므로 error budget도 안전하다고 판단함.
    • error budget이 남아 있으므로 사용자 영향이 큰 장애도 낮은 우선순위로 취급함.
    • SLO breach와 incident severity를 1:1로 매핑함.

  • 좋은 정책:

    • paging burn-rate, ticket burn-rate, release freeze threshold를 각각 둔다.
    • SLO breach는 incident review의 입력이지 유일한 판단 기준이 아님을 명시한다.

  • 실무용 최소 정책 템플릿

  • SLO target: 예) 99.9% successful requests over 28 days.
  • SLI numerator: failed valid user requests.
  • SLI denominator: all valid user requests, excluding explicit non-user probes if documented.
  • Alerting:
    • fast burn paging alert.
    • slow burn ticket alert.
    • low-traffic guard: minimum event count or supplemental absolute error threshold.
  • Maintenance:
    • planned maintenance included/excluded 여부.
    • exclusion approval workflow.
    • alert silence와 SLO correction의 차이.
  • Reset:
    • rolling 또는 calendar.
    • timezone.
    • correction/backfill policy.
  • Governance:
    • SLI definition changes require review.
    • instrumentation changes may create SLO continuity break.
    • release freeze policy references budget state but is not identical to alert state.

Cautions#

  • 공개 문서들은 multi-window burn-rate alerting의 원리와 SLO tooling의 window 옵션을 설명하지만, “정답 threshold”는 서비스별 risk tolerance, traffic volume, on-call 운영 방식에 따라 달라진다.
  • Low-traffic 서비스의 alerting 실패 모드는 일반적으로 알려진 통계적 문제지만, 각 도구가 제공하는 정확한 low-traffic 보정 기능은 제품별·버전별로 확인해야 한다.
  • Maintenance window를 error budget에서 제외하는 것이 항상 올바른 것은 아니다. 사용자 관점 SLO라면 planned downtime도 사용자 영향에 포함될 수 있다.
  • Calendar reset은 조직 관리에는 편하지만, 사용자 경험 관점에서는 임의적 경계다. Rolling window와 calendar report를 동시에 쓰는 경우 해석 충돌이 생길 수 있다.
  • Datadog, Grafana, Prometheus 생태계의 SLO 기능은 계속 변경된다. 실제 capsule 확정 전에는 현재 사용하는 제품 버전의 공식 문서를 다시 확인해야 한다.
  • 본 초안은 공개 자료 기반의 운영 정책 정리이며, 특정 조직의 SLA 법적 계약이나 고객 보상 조건을 대체하지 않는다.

Sources#

  • https://sre.google/workbook/alerting-on-slos/
  • https://sre.google/sre-book/service-level-objectives/
  • https://prometheus.io/docs/practices/alerting/
  • https://grafana.com/docs/grafana-cloud/alerting-and-irm/slo/
  • https://docs.datadoghq.com/service_management/service_level_objectives/

Sagwan Revalidation 2026-07-27T09:10:35Z#

  • verdict: ok
  • note: SLO burn-rate와 저트래픽·점검창·reset 주의점은 여전히 유효함

Sagwan Revalidation 2026-07-29T13:54:04Z#

  • verdict: ok
  • note: SLO burn-rate·저트래픽·정비창 원칙은 최신 관행과도 부합함

Sagwan Revalidation 2026-07-31T23:02:23Z#

  • verdict: ok
  • note: SLO burn-rate와 저트래픽·점검창 주장은 현재 practice와 부합함

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1