SLI · SLO · SLA · MTTR — 신뢰성의 언어
30일 타임라인에 장애 2건을 흘려 SLI가 실측으로 내려가고, 오류 예산이 타들어가 배포 동결 결정이 내려지는 것까지 실행한다.
1 / 8네 단어를 한 무대에 세웁니다. SLI = 실측 지표(성공 시간 비율), SLO = 내부 목표(99.9%), SLA = 고객 계약(99.5%, 어기면 배상). SLO 99.9%는 한 달에 43분까지 죽어도 된다는 뜻 — 그 43분이 오류 예산입니다.
SLI(실측) 100.000% · SLO 목표 99.9% · SLA 계약 99.5%
오류 예산 사용 0% · 누적 중단 0분
SLO 99.9% 준수SLA 99.5% 안전
단계 목록 · 키보드 ←/→ 이동, Space 재생
SLI는 재는 것, SLO는 노리는 것, SLA는 약속한 것 — 그리고 오류 예산(100%−SLO)은 '이만큼은 죽어도 된다'를 숫자로 만들어 배포 속도와 안정성의 환율을 정한다.
왜 헷갈리는가
넷이 전부 '가용성 몇 프로'로 뭉뚱그려진다. 회의에서 "SLA 99.9%"라고 말하는 것의 절반은 사실 내부 목표(SLO)고, 위반 시 배상이 걸린 계약(SLA)은 따로 있으며, 그 목표가 지켜지는지 재는 지표(SLI)는 정의조차 안 된 경우가 많다.
애니메이션이 보여주는 것
SLO 99.9%는 한 달 43.2분의 오류 예산이다. 장애 1(18분)과 장애 2(17분)로 예산의 81%가 타면 — SRE의 유명한 거래가 발동한다: 기능 배포를 늦추고 안정화에 우선순위를 준다. 예산이 남으면 반대로 과감히 실험한다. 오류 예산은 개발팀과 운영팀의 해묵은 싸움(빨리 내보내자 vs 안정적으로)을 숫자 하나로 중재하는 장치다.
월말 SLI 99.919%: SLO(99.9%)는 아슬아슬하게 지켰고 SLA(99.5%)에는 여유가 크다. SLA를 SLO보다 느슨하게 두는 것이 정석이다 — 내부 경보가 먼저 울려야 고객 배상까지 가지 않는다.
실무 감각
숫자와 지표를 다루는 요령.
- 나인의 산수: 99.9% = 월 43분, 99.99% = 월 4.3분, 99.999% = 월 26초. 나인 하나에 비용은 대략 10배 — '몇 나인이 필요한가'는 기술이 아니라 사업 질문이다.
- 좋은 SLI는 사용자 경험에 붙는다: '성공 응답 비율', '300ms 안에 응답한 비율' — 서버 CPU 같은 내부 지표는 SLI가 아니다.
- MTTR을 줄이는 것이 MTBF(장애 간격)를 늘리는 것보다 대개 싸다 — 장애는 나게 되어 있고, 감지(모니터링)·진단(관측성)·복구(자동 롤백)의 각 구간을 줄인다.
- 100% 가용성을 목표로 삼지 않는다: 무한히 비싸고, 사용자의 네트워크가 그보다 나쁘다. 남는 예산은 카오스 엔지니어링·재해 훈련에 '지출'한다.
기억할 것
- SLI=측정, SLO=내부 목표, SLA=배상 걸린 계약 — SLA는 SLO보다 느슨하게.
- 오류 예산 = 100%−SLO. 소진 속도가 배포 속도를 조절하는 다이얼이다.
- 나인 하나 올리는 비용은 ~10배 — 필요한 나인은 사업이 정한다.
- MTBF보다 MTTR — 안 죽는 시스템보다 빨리 일어나는 시스템이 현실적이다.