1
SLO/SLI 정의: 사용자 영향을 먼저 고정
SLO 운영의 시작은 기술 지표가 아니라 사용자 경험을 반영하는 SLI를 고르는 것입니다. 예를 들어 checkout API는 "2초 내 성공 응답 비율"이 실제 비즈니스 영향과 더 직접 연결됩니다.
SLI 선정 체크리스트
- 사용자 행동과 연결되는가? (로그인 성공, 결제 성공 등)
- 측정이 일관되는가? (정의/태그/집계 방식 고정)
- 운영팀이 조치 가능한가? (원인 추적 가능성)
예시
목표 SLO 99.9%를 월 단위로 운영한다면 허용 실패율은 0.1%입니다. 이 한도를 "Error Budget"으로 취급하고, 소진 속도로 위험도를 판단합니다.
2
Error Budget과 Burn Rate
Burn Rate는 "현재 실패율이 허용 실패율보다 몇 배 빠르게 소진되는지"를 보여줍니다. 값이 클수록 예산이 빠르게 사라지고 있다는 뜻입니다.
핵심 공식
burn_rate = current_error_rate / allowed_error_rate
예: SLO 99.9% (allowed_error_rate = 0.001)
현재 error_rate = 0.01 (1%) 라면 burn_rate = 10운영 해석
- Burn rate 1: 계획된 속도로 budget 사용
- Burn rate 2~5: 주의 구간, 조기 분석 필요
- Burn rate 10+: 즉시 대응(P1/P2) 구간
3
멀티 윈도우 알림 전략
짧은 창은 빠른 탐지에 유리하고, 긴 창은 노이즈 억제에 유리합니다. Datadog에서는 두 창을 함께 사용해 품질을 크게 올릴 수 있습니다.
권장 패턴
- Critical: 5m burn rate > 14 AND 1h burn rate > 7
- Warning: 30m burn rate > 6 AND 6h burn rate > 3
# Datadog monitor query idea (concept)
short = burn_rate(last_5m, service:checkout)
long = burn_rate(last_1h, service:checkout)
alert if short > 14 && long > 7주의
짧은 창 단독 알림은 배포 직후 스파이크에 취약합니다. 반대로 긴 창 단독 알림은 감지가 늦어집니다. 반드시 조합해서 운영하세요.
4
운영 리듬과 의사결정 룰
SLO는 대시보드에만 두면 의미가 없습니다. 운영 캘린더와 배포 의사결정에 연결해야 효과가 납니다.
주간 SLO Review
- - 상위 budget 소진 서비스 3개 리뷰
- - 반복 원인(배포, DB, 외부 API) 분류
- - 다음 주 개선 작업 등록
배포 가드레일
- - budget 잔여 30% 미만: 기능 배포 축소
- - budget 잔여 10% 미만: 안정화 작업 우선
- - budget 소진: 변경 freeze + RCA
핵심 포인트
SLO는 팀 성과지표가 아니라 "운영 의사결정 도구"입니다. 임계값을 팀 합의 문서(예: release policy)에 명시하세요.
5
실전 적용 템플릿
운영 회의 템플릿 (주간)
1) Top Burn Services
2) Burn Root Cause (deploy / infra / dependency)
3) Next Week Mitigation Plan
4) Release Gate Decision
5) Owner + Due Date문서화 권장 항목
- 서비스별 SLI 정의와 예외 조건
- 경보 라우팅 룰(critical/warning 채널)
- error budget 소진 시 단계별 조치 기준
퀴즈
SLO 운영 핵심 개념을 5문제로 확인해보세요.