把错误预算算成数字

목표

실제 Prometheus에서 최근 오류 속도를 관찰하고, 별도 합성 30일 집계로 기능 배포 판단 프로그램을 만든다. 소진 속도와 기간 사용량, 동결과 자료 부족을 구별한다.

왜 중요한가

12시간 오류율을 허용 오류율로 나눈 값은 12시간 번 레이트다. 그 값 하나로 30일 예산을 이미 썼다고 결론 내릴 수 없다. 관측이 없을 때 0을 대신 넣는 것도 안전한 판단이 아니다. 실제 데이터의 단위와 범위를 확인한 뒤 명시적인 정책을 코드로 실행한다.

예상 75분이다. 기본 60분 세션이 끝나기 전에 ＋시간으로 연장한다(최대 180분). 세션 종료 시 /root/obs 파일은 사라지므로 필요한 코드를 따로 보관한다. Python 조건문·딕셔너리·JSON 입출력이 선수 지식이다.

단계

1. 5xx만 실패로 정한 합성 서비스의 성공 비율 SLI를 /root/obs/slo-01-sli.promql에 쓴다. 최근 1시간 rate를 합쳐 성공 요청/전체 요청을 구한다. 이 정의를 다른 서비스의 4xx에 일반화하지 않는다.
2. 시간 기반 99.9% SLO의 30일 허용 불가용 시간을 분으로 계산해 /root/obs/slo-02-budget.txt에 숫자만 쓴다. 요청 오류 건수로 환산하지 않는다.
3. 최근 12시간 오류율을 0.001로 나눈 번 레이트 쿼리를 /root/obs/slo-03-consumed.promql에 쓴다. 파일명은 기존 실습 호환을 위해 유지하지만 값은 월간 사용량이 아니다.
4. 최근 1시간 번 레이트 쿼리를 /root/obs/slo-04-burn1h.promql에 쓴다. 3단계와 창 길이가 다르며 둘 다 속도 지표다.
5. 1시간과 5분 번 레이트가 각각 14.4를 초과하는 조건을 and로 연결해 /root/obs/slo-05-multi.promql에 쓴다. 회복한 짧은 창을 무시하지 않는다.
6. /etc/prometheus/rules/slo.yml에 ErrorBudgetBurnFast라는 다중 창 알림 규칙을 작성한다. alert·expr·for·labels.severity·annotations.summary를 포함하고 promtool check rules로 검사한다. 알림 전달과 기능 배포 허용 정책은 별개다.
7. Prometheus를 reload한 뒤 규칙 API에 알림이 등록됐는지 확인한다. 등록됐다는 사실만으로 실제 발화나 운영 대응이 검증된 것은 아니다.
8. /opt/lab/slo_release/contract.md를 읽고 /root/obs/slo-gate.py를 완성한다. stdin의 합성 관측 JSON 한 개에서 기간 예산 사용 비율과 두 창의 번 레이트를 계산한다. 자료 불충분은 hold, 예산 사용 비율 1 이상은 freeze, 그 외에도 두 창 모두 14.4 초과면 freeze, 나머지는 allow다. 출력은 decision·reason·budget_used·burn_hour·burn_five_minutes 다섯 필드이며 종료 코드는 allow=0, freeze=2, hold=3이다. 자료 검사의 순서와 상세 reason은 실행 계약을 따른다.

참고

• 시작 파일: /opt/lab/slo_release/starter.py. 없다면 mkdir -p /root/obs 후 slo-gate.py로 복사한다.
• 입력 보기: python3 /opt/lab/slo_release/evaluate.py sample healthy
• 전체 검증: python3 /opt/lab/slo_release/evaluate.py check /root/obs/slo-gate.py
• 05·06단계 시계열 검사 안내: /opt/lab/slo_release/promql.md. 거짓 조건은 값 0인 원소가 아니라 빈 벡터를 반환해야 알림이 꺼진다.
• Prometheus의 약 12시간 합성 이력과 프로그램 입력의 30일 합성 집계는 서로 다른 자료다. 실제 운영 기록이 아니다.
• 자료가 없는 경우 숫자는 null이며 0이 아니다. 월간 비율 20%는 20이 아니라 0.2다.
• 프로그램은 외부 서비스에 접속하거나 실제 배포·롤백을 실행하지 않는다. allow는 이 합성 정책의 통과이지 운영 안전 보장이 아니다.

SLI 를 쿼리로 정의

성공 비율 SLI → /root/obs/slo-01-sli.promql

이 합성 서비스는 관측된 5xx만 실패로 셉니다. 성공 요청의 rate 합을 전체 rate 합으로 나누세요. 다른 서비스의 4xx를 무조건 성공으로 분류하지 않습니다.

30일 에러 버짓을 분으로

시간 기반 30일 예산(분) → /root/obs/slo-02-budget.txt

시간 기반 99.9% SLO입니다. 30일의 분 수에 허용 불가용 비율을 곱하고 소수 첫째 자리까지 적습니다. 요청 건수 예산과 혼동하지 마세요.

12시간 소진 속도 관찰

12시간 소진 속도 관찰 → /root/obs/slo-03-consumed.promql

12시간 오류율을 허용 오류 비율 0.001로 나눕니다. 1 초과는 그 창의 속도가 허용 속도보다 빠르다는 뜻이지 30일 예산을 이미 다 썼다는 뜻이 아닙니다.

1시간 소진 속도 관찰

1시간 소진 속도 관찰 → /root/obs/slo-04-burn1h.promql

같은 오류 정의로 창을 1h로 바꿉니다. 긴 창도 짧은 창도 번 레이트이며, 예산 사용량과 구분합니다.

다중 윈도 조건

다중 창 조건 → /root/obs/slo-05-multi.promql

1시간과 5분이 각각 14.4를 초과하는 조건을 and로 잇습니다. 거짓인 원소를 제거해야 합니다. bool 비교의 0도 알림을 켤 수 있습니다. /opt/lab/slo_release/promql.md의 시계열 검사로 회복·누락을 확인하세요.

알림 규칙 작성

ErrorBudgetBurnFast 다중 창 알림 규칙 → /etc/prometheus/rules/slo.yml

alert·expr·for·labels.severity·annotations.summary를 포함하세요. for: 0s는 추가 지속 대기 없이 두 창 조건을 평가합니다. 긴 for는 심각한 실패의 알림까지 늦출 수 있습니다.

규칙 등록 확인

ErrorBudgetBurnFast 규칙이 Prometheus에 등록됐는지 확인

설정 검사 후 reload하고 rules API에서 이름을 확인하세요. inactive여도 등록 확인은 통과하지만 실제 발화·알림 전달 시험을 대신하지 않습니다.

배포 판단을 코드로 검증

판단 프로그램 → /root/obs/slo-gate.py

실행 계약의 자료 검사부터 구현하세요. 월간 예산 초과와 최근 두 창의 장애, 미확인 자료를 서로 다른 이유와 종료 코드로 남깁니다.