SLO 운영의 기본 흐름은 사용자 결과를 고정된 분모로 측정하고, 예산 소진 속도를 관찰한 뒤, 원인이 확정되지 않아도 되돌릴 수 있는 완화를 적용하고, 사용자 오류와 데이터 상태가 실제로 회복됐는지 별도로 검증하는 것입니다.
Process 생존과 서비스 사용 가능성
로그인 200 뒤 잘못된 token으로 다음 요청이 실패하면 사용자 여정은 실패입니다. 잘못된 비밀번호의 401은 정상 보안 거절일 수 있지만 용량 부족으로 유효 사용자를 막은 429/503은 가용성 실패일 수 있습니다. 장애 때 숫자를 좋게 만들려고 분모·제외 기준을 바꾸지 않습니다.
먼저 SLI가 무엇을 측정하는지 정하고, 그 측정 기준에 대한 목표를 SLO로 둡니다. 대상 요청·측정 위치·좋은 결과·시간 경계·기간을 정한 뒤, 예를 들어 “유효 요청 중 99.9%가 올바른 결과를 300ms 안에 반환”처럼 정의할 수 있습니다. 느린 실패를 지연 분모에서 빼지 말고, dependency 장애는 사용자 책임 범위에 맞춰 포함하며, 저트래픽에서는 절대 실패·영향 사용자·합성 probe도 함께 봅니다.
SLI를 정할 때 한 요청의 trace를 입구 수락 → 인증 → 핵심 처리 → 의존성 → 사용자 응답으로 나눠 어느 경계에서 bad가 되는지 먼저 표시합니다. 프로세스가 살아 있고 health endpoint가 200이어도 핵심 여정의 결과가 틀리거나 timeout이면 사용자 SLI는 나빠질 수 있습니다. 반대로 의도된 401/404를 bad로 넣을지는 제품 계약에 따라 고정하고 장애 중에 유리하게 바꾸지 않습니다.
오류 예산과 Burn Rate 산정
30일 동안 유효 요청이 100만 건이고 성공 목표가 99.9%라면 허용 오류율은 1−0.999=0.001이고, 요청 기반 허용 실패 수는 1,000,000×0.001=1,000건입니다. 실제 오류율이 0.01이면 0.01÷0.001=10이므로 burn rate는 10입니다. 트래픽과 오류율이 같은 조건으로 유지된다는 근사에서는 30일 예산을 30÷10≈3일에 쓰지만, 실제 요청량 변화와 남은 budget을 함께 봐야 합니다.
| 항목 | 계산·의미 |
|---|---|
| 허용 오류율 | 1−SLO |
| burn rate | 관측 오류율 / 허용 오류율 |
| 요청 기반 budget | 대상 요청 수×허용 오류율 |
| 좋은 이벤트 비율 | 동일 정의의 good count / eligible count |
instance별 percentile의 평균 대신 같은 good/bad 경계의 건수를 합칩니다. 오류 budget은 처벌 지표보다 배포·안정화 우선순위를 조정하는 도구입니다.
관측 창의 분자·분모가 같은 요청 모집단인지 확인하는 작은 표를 먼저 만듭니다. 예를 들어 retry를 요청 수로 셀지 시도 수로 셀지 바꾸면 burn rate가 인위적으로 달라지므로 logical request ID와 attempt ID를 분리합니다. traffic이 거의 없을 때는 비율만으로 큰 결론을 내리지 않고 절대 실패 수·영향 사용자·합성 흐름을 함께 사용합니다.
다중 창 AND 조건과 속도별 경보
30일 SLO의 예시로는 빠른 소진을 (1시간 burn>14.4 AND 5분 burn>14.4)로, 느린 지속을 (6시간 burn>6 AND 30분 burn>6)으로 둘 수 있습니다. 각 조건은 긴 창에서 의미 있는 예산 소비가 있었고 짧은 창에서도 지금 계속되는지를 함께 확인하는 방식입니다. 두 pair 중 하나가 충족되면 대응 정책을 실행하되, 이 수치는 모든 서비스에 권장되는 threshold가 아니라 해당 30일 SLO를 설명하기 위한 예시입니다.
긴 창은 의미 있는 소비를, 짧은 창은 현재도 지속되는지를 확인합니다. 빠른 pair와 느린 pair는 OR로 묶어 급격한 장애와 지속 저하를 다르게 포착합니다. 표본 부족·traffic 급변·수집 누락을 처리하고 실제 경보 뒤 수행할 조치·owner를 연결합니다.
그림을 글로 읽기
- 사용자 SLI·고정 분모·오류 budget
- 짧은/긴 창 burn·영향 범위
- 제한된 완화·성공/원복 조건
- 사용자 오류·queue·하위 부하 회복
- 원인·증폭 조건·대사·회귀 조치
- 사용자 SLI·고정 분모·오류 budget → 짧은/긴 창 burn·영향 범위: 소진 관측
- 짧은/긴 창 burn·영향 범위 → 제한된 완화·성공/원복 조건: 대응 정책
- 제한된 완화·성공/원복 조건 → 사용자 오류·queue·하위 부하 회복: 실제 효과
- 사용자 오류·queue·하위 부하 회복 → 원인·증폭 조건·대사·회귀 조치: 잔여 문제 추적
원인 확정 전 안전한 완화
배포 시각·endpoint·지역·앱 version의 영향 집단을 확인하고 핵심 증거를 보존하되 수집 때문에 피해 감소를 지연하지 않습니다. 데이터 호환이 있으면 rollback/flag off, DB 포화면 비핵심 유입·retry·fan-out 제한으로 회복 공간을 만들 수 있습니다. 여러 설정을 무작정 동시에 바꾸지 않고 가설·기대 지표·관찰 기한·되돌릴 조건을 남깁니다.
옛 코드가 새 schema를 읽지 못한다고 해서 곧바로 rollback하면, 이미 새 형식으로 쓰인 데이터와 충돌할 수 있습니다. 따라서 신규 쓰기를 제한하거나 기능을 축소하고, 호환 patch·보정·전진 복구 중 실제 데이터와 사용자 실패를 덜 만드는 경로를 비교합니다. 코드 전환을 되돌리는 것과 데이터 자체를 rollback하는 것은 다른 작업이므로, 원장·queue·사용자 실패를 각각 확인해야 합니다.
완화는 가설, 변경할 한 가지, 즉시 볼 지표, 유지 시간, 악화 시 원복 조건으로 선언합니다. 예를 들어 retry를 줄인 뒤 서버 오류율은 내려가도 성공률이 함께 내려갈 수 있으므로 queue depth·dependency load·사용자 good event를 동시에 봅니다. timeout을 줄이는 완화는 서버 작업을 취소하지 않을 수 있어, 늦은 작업과 외부 효과가 남는지 별도 확인합니다.
촉발 변경과 증폭 조건의 분리
잘못된 상태 전이가 촉발했고 client retry·log sink·공유 pool이 확대했을 수 있습니다. 변경 조정 담당과 영향/타임라인 기록을 나누어 상충 조치를 줄입니다. 오류 회복만으로 손상 데이터 대사가 끝났다고 하지 않습니다.
사후 항목은 “주의한다”가 아니라 구체 결함·담당자·수정 산출물·배포 version·완료 assertion·재현 시험으로 만듭니다. 같은 실패를 격리 환경에 다시 넣어 제약·경보·복구가 작동하는지 확인하고 잔여 한계를 남깁니다. 이 노트의 숫자는 설명 예시이며 실제 운영 SLO 측정이나 장애 대응을 수행한 결과는 아닙니다.
타임라인 표에 배포·첫 bad event·retry 증가·pool 고갈·완화·사용자 회복을 같은 기준 시각으로 배치하면 촉발과 증폭을 나누기 쉽습니다. 회복 후에는 동일한 입력을 격리 환경에서 재현하고, 원장·queue·알림·대사 결과가 정상인지 확인해야 합니다. 실제 장애를 수행한 증거가 없는 상태에서는 숫자 예시나 절차를 운영 완료로 표현하지 않습니다.