같은 12시간인데 가용성이 98.9% 와 85.0% 로 갈렸다

목표

같은 12시간 자료를 네 가지 SLI 정의로 직접 재서 숫자가 얼마나 벌어지는지 보고, 하나를 골라 목표와 함께 선언한 뒤 그 정의로 배포를 허용할지 막을지 판단합니다.

왜 중요한가

SLO 를 몇 퍼센트로 걸 것인가는 무엇을 셀 것인가가 정해진 뒤의 문제다. 좋은 사건과 유효한 사건을 어떻게 정하느냐에 따라 같은 자료에서 98.9% 도 나오고 85.0% 도 나온다. 분모에 헬스체크를 넣으면 사용자가 겪은 장애가 희석되고, 느린 성공을 성공으로 세면 사용자가 떠난 시간이 기록에 남지 않는다. 사건의 단위를 요청에서 시간으로 바꾸면 새벽의 장애와 낮의 장애를 같은 무게로 세게 된다. 이 선택들은 나중에 배포를 막느냐 마느냐로 돌아오므로, 정의를 바꿀 때마다 지난 기간을 다시 재 보고 그 숫자로 살 수 있는지 확인하는 습관이 필요하다.

단계

1. /root/obs-sli-events/01-events.txt 에 세 줄을 적으세요. metric= 뒤에는 사건을 세는 데 쓸 카운터 지표 이름, failure_label= 뒤에는 그 지표에서 실패 여부를 가르는 라벨 이름, valid_12h= 뒤에는 최근 12시간 동안의 유효한 사건 수를 정수로 적습니다(job 은 shop-api 입니다). 값은 직접 쿼리를 던져서 얻으세요.
2. /root/obs-sli-events/a-request.promql 에 '최근 12시간 동안 5xx 가 아닌 요청의 비율' 을 내는 PromQL 을 한 줄 이상으로 쓰고, 그 결과를 /root/obs-sli-events/a-request.txt 에 소수 넷째 자리까지 숫자 하나로 적으세요. 주석(#)은 남겨도 됩니다.
3. 같은 12시간을 '2xx 응답만 좋은 사건' 으로 다시 재세요. 쿼리는 /root/obs-sli-events/b-strict.promql, 값은 /root/obs-sli-events/b-strict.txt 에 소수 넷째 자리까지 적습니다. 분모는 앞 단계와 같아야 합니다.
4. '100밀리초 안에 끝난 요청' 을 좋은 사건으로 보는 정의로 12시간을 재세요. 쿼리는 /root/obs-sli-events/c-latency.promql, 값은 /root/obs-sli-events/c-latency.txt 에 소수 넷째 자리까지 적습니다. 그리고 /root/obs-sli-events/04-note.txt 에 '이 정의로는 상태 코드와 지연을 한 쿼리로 함께 볼 수 없다' 는 사실과 그 이유를 한 줄로 적으세요 — reason= 로 시작하고 40자 이상이어야 합니다.
5. 1분 창을 사건으로 삼는 정의로 같은 12시간을 재세요. 어떤 1분 안에서 5xx 비율이 1% 미만이면 그 1분을 좋은 사건으로 봅니다. 쿼리는 /root/obs-sli-events/d-window.promql, 값은 /root/obs-sli-events/d-window.txt 에 소수 넷째 자리까지 적습니다. 그리고 /root/obs-sli-events/05-badminutes.txt 에 12시간(720분) 중 나쁜 분이 몇 분인지 정수로 적으세요.
6. /root/obs-sli-events/budget.tsv 를 만드세요. 머리글 없이 네 줄이고, 각 줄은 탭으로 나눈 세 칸 <id> <가용성> <30일 허용 다운타임 분> 입니다. id 는 순서대로 a, b, c, d 이고, 가용성은 앞 단계에서 적은 값, 세 번째 칸은 그 가용성이라면 30일(43200분) 동안 나빠도 되는 시간이 몇 분인지를 소수 첫째 자리까지 적습니다.
7. /root/obs-sli-events/choice.txt 에 네 줄을 적으세요. sli= 뒤에 고른 id(a·b·c·d 중 하나), query= 뒤에 그 정의의 쿼리 파일 이름(예: d-window.promql), target= 뒤에 걸 목표를 0 과 1 사이 소수로, reason= 뒤에 왜 그 정의인지 60자 이상으로 적습니다. 채점기는 query= 가 가리키는 파일을 실제로 던져 sli= 와 맞는지 확인합니다.
8. /root/obs-sli-events/decision.txt 에 두 줄을 적으세요. 각 줄은 target=<목표> consumed=<소진비율> release=<allow|hold> 이고 목표는 첫 줄이 0.99, 둘째 줄이 0.95 입니다. 소진비율은 (1 − 측정된 가용성) ÷ (1 − 목표) 로 소수 셋째 자리까지, 판단은 소진비율이 1 이상이면 hold, 미만이면 allow 입니다. 측정된 가용성은 7단계에서 고른 정의의 값을 씁니다.

참고

• 작업 디렉터리는 /root/obs-sli-events 입니다. 없으면 먼저 만드세요.
• 쿼리는 promq "<PromQL>" 로 바로 던져 볼 수 있고, 원본 JSON 은 promq -r 입니다. 스크립트에서는 curl -sG --data-urlencode "query=..." http://127.0.0.1:9090/api/v1/query 를 씁니다.
• 파드의 Prometheus 에는 12시간치가 미리 들어 있습니다. 그 안에 20분짜리 오류 급증이 한 번 들어 있습니다.
• 흔한 실수: 카운터를 increase 없이 그대로 나누는 것. 카운터는 누적값이라 비율이 전체 기간 평균으로 뭉개집니다.
• 흔한 실수: 지연 히스토그램에 상태 코드 라벨이 있다고 가정하는 것. 이 실습의 4단계가 바로 그 벽입니다.
• [Implementing SLOs (SRE Workbook)](https://sre.google/workbook/implementing-slos/) · [Service Level Objectives (SRE Book 4장)](https://sre.google/sre-book/service-level-objectives/) · [Querying basics](https://prometheus.io/docs/prometheus/latest/querying/basics/) · [Query functions](https://prometheus.io/docs/prometheus/latest/querying/functions/) · [Histograms and summaries](https://prometheus.io/docs/practices/histograms/)

단계 8개

1. 무엇을 하나로 셀 것인지부터 정한다
2. 요청 기준 — 5xx 만 실패로 센다
3. 400 대도 실패로 세면 얼마나 달라지나
4. 느린 성공은 성공인가
5. 요청을 세지 말고 분을 세어 본다
6. 네 정의를 30일 허용 다운타임으로 환산한다
7. 고른 정의를 기계가 읽을 수 있게 선언한다
8. 같은 자료, 다른 목표 — 배포를 허용할 것인가