Compute the Budget and Test the Alert

목표

"가용성 99.9%" 는 계약서에 적기는 쉬운데, 그게 한 달에 몇 분인지 아는 사람은 드뭅니다. 그리고 대부분의 알림은 SLO 와 아무 관계가 없습니다.

이 실습은 숫자를 직접 구하고, 그 숫자로 알림을 다시 쓰고, 그 알림이 진짜 울리는지 시험합니다.

시작

cp -r /opt/lab/slo/* .
python3 budget.py 99.9
promtool check rules rules.yml
promtool test rules test.yml

파일

파일	하는 일
budget.py	에러 예산·번 레이트 계산. 고치지 않습니다
rules.yml	알림 규칙. 여기를 고칩니다
test.yml	규칙의 단위 시험. 여기도 고칩니다

시계열 표기

test.yml 의 0+90x20 은 0에서 시작해 1분마다 90씩 20번 늘린다는 뜻입니다. 즉 분당 90건입니다.

단계

1. 에러 예산 → 01-budget.txt
2. 번 레이트 → 02-burn.md
3. 지금 알림의 문제 → 03-why-bad.md
4. 번 레이트로 다시 쓰기 → rules.yml
5. 울리는지 시험 → test.yml
6. 조용한지도 시험 → test.yml
7. 두 개의 창 → 07-window.md
8. 정리 → 08-notes.md

참고

4·5·6단계는 채점기가 promtool 을 직접 돌려 확인합니다.

99.9% 는 한 달에 몇 분인가

99.9, 99.95, 99.99 세 가지의 한 달 에러 예산을 구해 01-budget.txt 에 남기세요.

python3 budget.py 99.9 처럼 씁니다.

숫자를 외우는 게 목적이 아니라 자릿수 감각을 잡는 게 목적입니다. 99.9% 와 99.99% 는 표기가 한 자리 차이인데 허용 시간은 열 배 차이입니다.

계약서에 99.99% 를 적기 전에 그게 한 달에 몇 분인지 알아야 합니다.

지금 속도면 언제 다 쓰나

번 레이트 1, 6, 14.4 각각에 대해 예산이 언제 바닥나는지 구해 02-burn.md 에 적고, 14.4 라는 숫자가 어디서 오는지 설명하세요.

python3 budget.py 99.9 --burn 14.4.

번 레이트는 오류율이 허용치의 몇 배인가입니다. 1배면 딱 한 달에 예산을 다 씁니다(설계대로).

14.4 는 이렇게 나옵니다 — 1시간에 한 달 예산의 2%를 태우는 속도입니다. 0.02 × 30일 × 24시간 = 14.4. 이 정도면 지금 깨워야 한다는 뜻입니다.

지금 알림이 왜 쓸모없나

rules.yml 의 현재 규칙을 읽고, 왜 SLO 와 무관한지 03-why-bad.md 에 적으세요. 조용해야 하는데 울리는 경우와 울려야 하는데 조용한 경우를 각각 드세요.

지금 규칙은 "5분 오류율 1% 초과" 입니다. SLO(0.1% 허용)와 아무 관계가 없습니다.

생각해 볼 것 — 오류율 0.5%가 한 달 내내 지속되면? (예산 5배 초과인데 조용합니다) 반대로 새벽에 1.2%가 5분 튀면? (예산은 거의 안 줄었는데 사람을 깨웁니다)

알림 피로는 알림이 많아서가 아니라 쓸모없는 알림이 많아서 생깁니다.

번 레이트로 다시 쓴다

rules.yml 을 고쳐 번 레이트 기준 알림으로 바꾸세요. promtool check rules rules.yml 이 통과해야 합니다.

임계값은 14.4 × (1 - SLO) 입니다. SLO 가 99.9% 면 14.4 * 0.001.

expr: |
  (sum(rate(http_requests_total{status=~"5.."}[5m]))
   / sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)

알림 이름도 바꾸세요 — 이제 "오류율이 높다" 가 아니라 "예산을 빠르게 태우고 있다" 입니다. 이름이 대응 방법을 정합니다.

알림이 진짜 울리는지 시험한다

test.yml 을 고쳐 promtool test rules test.yml 이 통과하게 만드세요. 새 알림 이름과 주석에 맞춰야 합니다.

이게 이 실습에서 가장 값진 단계입니다. 알림 규칙에 단위 시험을 붙이는 사람은 드뭅니다. 그래서 정작 장애가 났을 때 안 울리는 알림이 흔합니다.

input_series 의 0+90x20 은 1분마다 90씩 20번 늘린다는 뜻입니다. 오류를 0+10x20 으로 두면 10% 오류율이라 어떤 기준으로도 울립니다.

채점기가 promtool test rules 를 직접 돌립니다.

울리면 안 될 때 조용한지도 시험한다

test.yml 에 알림이 울리면 안 되는 경우를 하나 더 넣으세요. 예산 안에서 도는 정상 상태입니다.

exp_alerts: [] 로 "아무 알림도 없어야 한다" 를 표현합니다.

오류율을 0.05% 쯤(예: 0+1x20 대 0+2000x20) 두면 SLO 안입니다.

울려야 할 때 우는지만 시험하면 절반입니다. 조용해야 할 때 조용한지도 시험해야 알림 피로를 막습니다.

빠른 창과 느린 창

왜 창(window)이 하나로는 부족한지 07-window.md 에 적고, 두 창을 쓰는 구성을 제안하세요.

짧은 창(5분)만 쓰면 잠깐 튀는 것에 깨어납니다. 긴 창(1시간)만 쓰면 빠르게 타는 것을 늦게 압니다.

그래서 보통 둘을 and 로 묶습니다 — 짧은 창과 긴 창이 둘 다 임계를 넘을 때만 울립니다. 그러면 순간적인 튐은 걸러지고 진짜 소진은 빨리 잡힙니다.

그리고 심각도를 나눕니다 — 빠른 소진(14.4배)은 즉시 호출, 느린 소진(6배 이하)은 티켓으로.

정리한다

08-notes.md 에 세 줄 이상. 번 레이트가 무엇인지, 알림 규칙을 시험해야 하는 이유, 예산이 바닥나면 팀이 무엇을 하기로 했는지.

본문에 번 레이트, 시험, 예산 이 들어가야 합니다. 마지막 항목이 어렵습니다 — 예산 소진에 대응이 정해져 있지 않으면 SLO 는 장식입니다.