이 문서는 "서비스가 충분히 건강한가"를 숫자로 판단하는 기준인 SLI/SLO/에러 버짓을 설명한다.
| 말 | 뜻 | 예 |
|---|---|---|
| SLI | 서비스 품질을 재는 실제 지표 | 5xx가 아닌 요청 비율, p95 응답시간 |
| SLO | SLI의 목표치 | 가용성 99.9%, p95 < 1500ms |
| 에러 버짓 | 1 − SLO. 허용되는 실패량 | 99.9% → 0.1%(월 약 43분) |
핵심: SLO는 100%가 목표가 아니다. 에러 버짓이 남아 있으면 변경·배포를 진행하고, 빠르게 소진되면 멈추고 안정화한다.
아래는 업계 표준 기반 제안값이며, 서비스별로 확정해야 한다.
| 서비스 | 가용성 SLO(제안) | 지연 SLO(제안) | 비고 |
|---|---|---|---|
| do4i | 99.9% | p95 < 1500ms | 사용자 대면 API |
| passv | 99.9% | p95 < 1500ms | 컷오버 후 적용 |
| palcar | 99.9% | p95 < 1500ms | |
| papersens | 99.9% | 별도 기준 | LLM 호출 특성상 1500ms는 과도할 수 있음 |
| wiki | 보수적 | 없음 | 단일 인스턴스 내부 도구 |
측정원: ingress 5xx 비율을 비가용으로 근사(
platform-slo-rules.yaml). 가용성 = 1 − 5xx비율.
에러 버짓을 "얼마나 빠르게 태우고 있는가"로 본다. 멀티윈도 방식:
| 알림 | 윈도 | 임계(99.9% 기준) | 의미 |
|---|---|---|---|
| Fast burn | 1h & 5m | 번레이트 > 14.4 (5xx비율 > 1.44%) | 버짓을 매우 빠르게 소진 → 즉시 대응(critical) |
| Slow burn | 6h & 30m | 번레이트 > 6 (5xx비율 > 0.6%) | 지속 소진 → 원인 조사(warning) |
두 윈도를 AND로 묶어 일시적 스파이크의 오탐을 줄인다.
규칙 구현과 임계 조정은 gitops k8s/infra/monitoring/manifests/platform-slo-rules.yaml에서 한다.
온보딩 트랙 3부. 관측과 SRE
이전: wiki 관측과 조치 · 다음: 알림에서 인시던트, 에스컬레이션까지 · 전체 경로: 시작하기: 신입 온보딩