Files
llm-wiki/raw/official-docs/metric-google-sre-slo-burn-rate.md

111 lines
9.0 KiB
Markdown

---
title: Google SRE Workbook — Alerting on SLOs / Error Budget Burn Rate
source_type: official-doc
url: https://sre.google/workbook/alerting-on-slos/
archive_url:
status: raw
confidence: high
tags: [ca-metrics-alerting, slo, burn-rate, alert-severity, sre, official-doc]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-metrics-alerting-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---
# Google SRE Workbook — Alerting on SLOs / Error Budget Burn Rate
> Layer: `raw/official-docs/` — Google SRE Workbook Chapter 5 verbatim. ca-tmpl 의 "alert threshold 는 임의 수치가 아니라 SLO/error budget 또는 documented operational default 에 연결" + "burn-rate 기반 alert 는 추후 도입" 결정의 1차 spec 근거.
## Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-metrics-alerting-contract]] | alert threshold 가 SLO/error budget 또는 documented default 에 연결되어야 한다는 결정 + burn-rate 기반 alert 의 추후 도입 시 multi-window 권장 사양 근거 |
| [[raw/project-notes/ca-skeleton-operational-contract]] | §18. Control Plane Contract (Metrics / Alerting) 의 alert severity / threshold source 대안 비교 (Group G-A 대안 3 — SLO burn-rate alert vs threshold + 잠정 SLO) |
## 컨텍스트
ca-tmpl 이 결정한 "**alert threshold 는 임의 수치가 아니라 SLO/error budget 또는 documented operational default 에 연결**" 및 "**burn-rate 기반 alert 는 추후 도입 (현재는 단순 threshold)**" 의 spec 출처. 미래 도입 시 reference.
## 출처 / Source
- 원본 URL: https://sre.google/workbook/alerting-on-slos/
- 아카이브 URL: (미수집)
- 저자 / 조직: Google SRE Team (Site Reliability Workbook, 공개 e-book)
- 발행일: 2018 (e-book 발행)
- 마지막 확인일: 2026-05-27
## 핵심 인용 / Key quotes (verbatim)
> [§Alerting goals] "your goal is to be notified for a significant event: an event that consumes a large fraction of the error budget."
> [§Alerting goals] "turn your SLOs into actionable alerts on significant events"
> [§Burn rate examples] "2% budget consumption in one hour and 5% budget consumption in six hours as reasonable starting numbers for paging"
> [§Multi-window] "enhance the multi-burn-rate alerts in iteration 5 to notify us only when we're still actively burning through the budget—thereby reducing the number of false positives. To do this, we need to add another parameter: a shorter window"
> [§Multi-window — short/long ratio] "a good guideline is to make the short window 1/12 the duration of the long window"
> [§SLO-based vs threshold] "alerting based on multiple burn rates is a powerful way to implement SLO-based alerting"
> [§Definitions] "The error budget gives the number of allowed bad events, and the error rate is the ratio of bad events to total events."
## Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SRE-BURN-C1 | alert 의 목표는 error budget 의 큰 비율을 소진하는 significant event 에 대해 notify 받는 것 — SLO 를 actionable alert 으로 변환 | [§Alerting goals] "your goal is to be notified for a significant event: an event that consumes a large fraction of the error budget." + "turn your SLOs into actionable alerts on significant events" | `official-vendor-doc` | SLO 가 수립된 서비스의 alert 설계 | SLO 미수립 서비스에 적용 가능하다는 뜻은 아님 — error budget 정의 필요 |
| SRE-BURN-C2 | paging 의 reasonable 시작값: **2% budget consumption in 1 hour** + **5% budget consumption in 6 hours** | [§Burn rate examples] "2% budget consumption in one hour and 5% budget consumption in six hours as reasonable starting numbers for paging" | `official-vendor-doc` | 30일 rolling budget 기준 page severity | 1h/14.4x, 6h/6x 같은 정확한 burn rate 환산값이 모든 SLO 에서 동일 의미라는 뜻 아님 — 환산은 SLO 값에 의존 |
| SRE-BURN-C3 | multi-window multi-burn-rate alert 는 false positive 감소를 위해 short window 추가 (still actively burning 인 경우에만 notify) | [§Multi-window] "enhance the multi-burn-rate alerts in iteration 5 to notify us only when we're still actively burning through the budget—thereby reducing the number of false positives. To do this, we need to add another parameter: a shorter window" | `official-vendor-doc` | multi-window alert 구현 | short window 가 없으면 false positive 가 반드시 많아진다는 강한 결론 아님 — "reducing" 표현 |
| SRE-BURN-C4 | short window 는 long window 의 **1/12** 길이로 설정하는 것이 좋은 가이드라인 (예: 1h long → 5m short, 6h long → 30m short) | [§Multi-window — short/long ratio] "a good guideline is to make the short window 1/12 the duration of the long window" | `official-vendor-doc` | multi-window 파라미터 선택 | 1/12 가 모든 traffic 패턴에서 최적이라는 뜻 아님 — "guideline" 표현 |
| SRE-BURN-C5 | multiple burn rate 기반 alert 가 SLO-based alerting 을 구현하는 강력한 방법 | [§SLO-based vs threshold] "alerting based on multiple burn rates is a powerful way to implement SLO-based alerting" | `official-vendor-doc` | SLO-based alerting 채택 시 | threshold alert 가 항상 inferior 라는 강한 결론 아님 — SLO 미수립 단계에서는 threshold 가 가능한 fallback |
| SRE-BURN-C6 | error budget 정의: 허용된 bad events 의 수. error rate = bad events / total events 비율 | [§Definitions] "The error budget gives the number of allowed bad events, and the error rate is the ratio of bad events to total events." | `official-vendor-doc` | SLO/SLI 정의 일반 | "bad event" 의 정의 (5xx? timeout? business logic 실패?) 는 본 인용에 없음 — SLI 별도 정의 필요 |
## Usage Boundaries / 적용 경계
- **이 자료가 직접 증명하는 것**:
- `SRE-BURN-C1` ~ `C6`: SLO-based alerting 의 목표, 2%/1h + 5%/6h paging 시작값, multi-window 1/12 ratio, error budget 정의
- **이 자료가 증명하지 않는 것**:
- "burn rate = 14.4x for 1h" 의 정확한 표 (SRE Workbook 다른 절의 표 — 본 발췌에는 reasonable 시작값으로 2%/1h + 5%/6h 만 직접 인용)
- 정확한 P1/P2/P3 severity 매핑 (조직별 정책)
- PromQL 으로 multi-window burn-rate 를 표현하는 정확한 query syntax (별도 vendor 문서)
- SLO 가 99.9% vs 99.99% 일 때 동일 error rate 의 severity 차이 (정량 매핑은 SLO 값 의존)
- threshold alert (예: `error_rate > 1% for 10m`) 가 SRE Workbook 에 의해 명시적으로 부정된다는 결론 — 본 인용은 SLO-based 를 "powerful" 하다고 표현, threshold 부정은 별도
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
- ca-tmpl 의 잠정 SLO (p99 = 1s) 가 multi-window alert 으로 환산될 때의 정확한 burn rate
- ca-tmpl 의 P1 "(>5% 5분 또는 >10% 1분)" threshold 가 SLO 99.9% 기준 burn rate 으로 환산 시 의미 (별도 계산)
- Prometheus / Grafana 의 multi-window alert 구현 (recording rule 필요 여부)
## 메모 / Notes (내 프로젝트 해석)
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- **burn rate 정의**: error budget 을 정상 속도 (`1x`) 보다 몇 배 빠르게 소진하는지. `14.4x for 1h` = "이대로면 4.2일 안에 30일 budget 다 씀" (Workbook 다른 절의 환산표 기반).
- **multi-window 표 (SRE Workbook 권장, 본 발췌로는 reasonable 시작값만 직접 지지)**:
| severity | long window | short window | burn rate (해석) |
|---|---|---|---|
| page | 1h | 5m | 14.4x |
| page | 6h | 30m | 6x |
| ticket | 3d | 6h | 1x |
- **P1/P2/P3 매핑 (ca-tmpl 과 비교)**:
- ca-tmpl P1 "(>5% 5분 또는 >10% 1분)" 은 threshold alert.
- SRE 등가 표현: SLO 99.9% (월 0.1% 예산) 에서 5% 5분 = burn rate 약 50x → P1 page 정당 (정확한 환산은 별도 검증 필요).
- **장점**: 같은 SLO 에서 traffic 변화 무관하게 일관된 severity. false page 감소. SLA 보고와 정렬.
- **단점**: SLO 미수립 시 적용 불가. multi-window PromQL 복잡. 신규 서비스 (traffic 적음) 는 burn rate 의미 약함.
- **ca-tmpl 과의 차이**:
- ca-tmpl 현재 = threshold alert (잠정 SLO p99=1s).
- ca-tmpl 명시: "burn-rate 기반 alert 는 추후 도입".
- SRE Workbook 은 burn-rate 를 권장 (`SRE-BURN-C5`) 하나 ca-tmpl 은 SLO 미수립 단계 → threshold 가 합리적 선택.
## Related / 관련
- 같은 주제 다른 raw:
- [[raw/official-docs/metric-micrometer-naming-convention-official]] (metric naming, 별도 spec)
- [[raw/official-docs/metric-otel-metrics-data-model-spec]] (metric data model, 별도 spec)
- 인용하는 branch:
- [[raw/branch-notes/feature-metrics-alerting-contract]]
- 인용하는 project:
- [[raw/project-notes/ca-skeleton-operational-contract]] (§18 Metrics / Alerting — severity / threshold source)
- 인용한 wiki 요약: (미작성)