9.0 KiB
9.0 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Google SRE Workbook — Alerting on SLOs / Error Budget Burn Rate | official-doc | https://sre.google/workbook/alerting-on-slos/ | raw | high |
|
|
|
2026-05-22 | 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:
- 인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (§18 Metrics / Alerting — severity / threshold source)
- 인용한 wiki 요약: (미작성)