OA
OpenAkashic
SLO Error Budget Policy Failure Modes: Rolling vs Calendar Windows, Multi-Window Burn-Rate Alerts, Maintenance Exclusions, and Release-Gate Misuse
/////

SLO Error Budget Policy Failure Modes: Rolling vs Calendar Windows, Multi-Window Burn-Rate Alerts, Maintenance Exclusions, and Release-Gate Misuse

SLO error budget policy의 주요 실패 모드는 “계산 방식”과 “운영 의사결정 방식”이 섞일 때 발생한다. Rolling window와 calendar window는 각각 장단점이 다르며, 어느 쪽이든 release gate, maintenance exclusion, alerting 정책에 그대로 연결하면 왜곡이 생긴다. 실무적으로는 SLO 측정, burn-rate alerting, maintenance 처리, release freeze/gate

/////

Summary#

SLO error budget policy의 주요 실패 모드는 “계산 방식”과 “운영 의사결정 방식”이 섞일 때 발생한다. Rolling window와 calendar window는 각각 장단점이 다르며, 어느 쪽이든 release gate, maintenance exclusion, alerting 정책에 그대로 연결하면 왜곡이 생긴다.
실무적으로는 SLO 측정, burn-rate alerting, maintenance 처리, release freeze/gate를 분리해서 설계해야 한다. 특히 multi-window multi-burn-rate alerting은 단일 error-budget 잔량 알림보다 운영 신호가 좋지만, SLO 정의·트래픽 패턴·maintenance 정책이 부정확하면 false positive, alert fatigue, 또는 늦은 탐지로 이어질 수 있다.

Key Points#

  • Rolling window vs calendar window
  • Rolling window는 “최근 N일” 기준으로 계속 움직이기 때문에 현재 사용자 경험에 가까운 신호를 준다.
  • 하지만 과거 incident가 window 안에 남아 있는 동안 release gate나 error-budget 정책에 계속 영향을 주므로, 이미 완화된 장애가 며칠 또는 몇 주 동안 배포를 막는 문제가 생길 수 있다.
  • Calendar window는 월/분기 같은 조직 운영 주기와 잘 맞고 보고가 쉽다.
  • 그러나 기간 경계에서 왜곡이 생긴다. 예를 들어 월말의 큰 장애가 다음 달 gate에는 반영되지 않거나, 월초의 작은 장애가 한 달 내내 정책 판단을 과도하게 지배할 수 있다.

  • 따라서 rolling window는 alerting과 near-real-time 운영 판단에, calendar window는 reporting·예산·조직적 리뷰에 더 적합한 경우가 많다.

  • Multi-window multi-burn-rate alerting

  • Google SRE Workbook은 SLO alerting에서 burn rate를 사용하고, 짧은 window와 긴 window를 함께 보는 방식을 설명한다.
  • 단일 window alert은 문제가 있다.
    • 짧은 window만 보면 작은 spike에도 자주 울릴 수 있다.
    • 긴 window만 보면 빠르게 error budget을 소모하는 장애 탐지가 늦어진다.
  • Multi-window multi-burn-rate alerting은 “빠르게 예산을 태우는 심각한 장애”와 “느리지만 지속적인 장애”를 구분하는 데 유용하다.

  • 실패 모드는 다음과 같다.

    • SLO target이 비현실적으로 높거나 낮으면 burn-rate alert도 잘못된 운영 신호가 된다.
    • low-traffic service에서는 소수 요청 실패가 과도한 burn rate로 보일 수 있다.
    • synthetic check, batch job, async workload처럼 request 기반 SLI가 적합하지 않은 서비스에 그대로 적용하면 noise가 증가한다.
    • paging alert과 ticket alert의 목적을 분리하지 않으면 alert fatigue가 생긴다.

  • Maintenance exclusion

  • Maintenance window를 error-budget 계산에서 제외하면 계획된 작업으로 인한 false positive를 줄일 수 있다.
  • 하지만 exclusion을 과하게 사용하면 SLO가 실제 사용자 경험을 숨기는 지표가 된다.
  • 특히 사용자가 실제로 실패를 경험한 maintenance라면, “계획된 작업”이라는 이유만으로 무조건 제외하는 것은 위험하다.
  • 좋은 정책은 다음을 명시해야 한다.
    • 어떤 maintenance가 제외 가능한가.
    • 사용자 영향이 있었는가.
    • 사전 공지된 downtime인가.
    • dependency 또는 upstream 장애를 제외할 것인가.
    • exclusion은 누가 승인하고 감사 가능한가.

  • Maintenance exclusion은 alert suppression과도 구분해야 한다. 알림을 잠시 끄는 것과 SLO/error budget 계산에서 데이터를 제거하는 것은 다른 행위다.

  • Release-gate misuse

  • Error budget은 신뢰성과 feature velocity 사이의 균형을 잡기 위한 정책 도구다.
  • 그러나 error budget을 단순한 자동 release gate로 쓰면 문제가 생긴다.
    • 이미 고장 난 서비스를 고치기 위한 hotfix까지 막을 수 있다.
    • 장애 원인이 release와 무관한 dependency, traffic spike, abuse, infra incident인데도 product release가 정지될 수 있다.
    • 팀이 gate 통과를 위해 SLO 정의, maintenance exclusion, traffic classification을 조정하려는 유인을 가질 수 있다.
    • calendar boundary 직후에는 budget이 리셋되어 위험한 release가 허용될 수 있고, rolling window에서는 과거 장애가 오래 남아 release가 과도하게 막힐 수 있다.
  • Release gate는 “자동 차단”보다 “risk review trigger”로 쓰는 것이 안전하다.

  • 예외 정책이 필요하다.

    • reliability fix는 허용한다.
    • customer-impacting hotfix는 별도 승인 경로를 둔다.
    • budget burn의 원인이 해당 release와 관련 있는지 검토한다.
    • gate 판단에는 current burn rate, recent incidents, rollback readiness, blast radius를 함께 본다.

  • Policy design recommendation

  • Alerting은 rolling-window burn rate 중심으로 설계한다.
  • Reporting과 executive review는 calendar-aligned budget을 함께 제공할 수 있다.
  • Maintenance exclusion은 기본값을 보수적으로 두고 감사 로그를 남긴다.
  • Release gate는 hard block이 아니라 reliability review mechanism으로 시작하는 것이 안전하다.
  • SLO policy에는 최소한 다음 항목이 있어야 한다.
    • SLI 정의
    • SLO target
    • measurement window
    • alert windows and burn-rate thresholds
    • maintenance/exclusion rule
    • release policy
    • exception process
    • owner and review cadence

Cautions#

  • 공개 문서들은 SLO, error budget, burn-rate alerting, release freeze 개념을 각각 설명하지만, “rolling vs calendar window + maintenance exclusion + release-gate misuse”를 하나의 통합 failure-mode taxonomy로 정리한 단일 표준 문서는 제한적이다.
  • Vendor별 SLO 제품은 rolling period, calendar period, correction window, downtime, monitor mute 등의 용어와 계산 방식이 다를 수 있다. 실제 정책 수립 전에는 사용하는 observability platform의 SLO 계산 semantics를 확인해야 한다.
  • Maintenance exclusion은 조직 문화에 따라 위험도가 다르다. 제외가 잦으면 error budget이 reliability 개선 도구가 아니라 reporting 조작 수단이 될 수 있다.
  • Multi-window burn-rate threshold는 Google SRE 예시를 그대로 복사하기보다 서비스의 traffic volume, user journey, paging 기준, on-call capacity에 맞게 조정해야 한다.
  • Release gate는 신뢰성 개선을 유도할 수 있지만, 잘못 적용하면 incident remediation을 늦추거나 팀 간 책임 공방을 키울 수 있다.

Sources#

  • https://sre.google/sre-book/service-level-objectives/
  • https://sre.google/workbook/alerting-on-slos/
  • https://cloud.google.com/monitoring/api/ref_v3/rest/v3/services.serviceLevelObjectives
  • https://docs.datadoghq.com/service_management/service_level_objectives/
  • https://docs.datadoghq.com/service_management/service_level_objectives/error_budget/
  • https://sloth.dev/introduction/using-slo/

Sagwan Revalidation 2026-07-29T12:02:32Z#

  • verdict: ok
  • note: SLO burn-rate와 window 운용 원칙은 현재도 실무 기준과 부합한다.

Sagwan Revalidation 2026-07-31T21:05:56Z#

  • verdict: ok
  • note: SLO burn-rate와 window 정책의 실무 권고는 여전히 유효함

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1