SRE(1차정리)
SLI / SLO / SLA
서비스를 수치로 정의하는 개념이다.
SLI는 현재 서비스 상태를 측정한 수치고,
SLO는 팀 내부에서 유지해야 하는 목표값이다.
SLA는 그 목표를 고객과 계약으로 맺은 것으로, 위반하면 패널티가 생긴다.
쉽게 기억하는 방법은 이렇다.
SLI → 지금 가용성이 99.7%다 (측정값)
SLO → 99.9% 이상 유지해야 한다 (내부 목표)
SLA → 99.5% 보장, 위반 시 환불 (고객 계약)
SLA는 항상 SLO보다 낮게 설정한다.
그 차이가 버퍼가 되어서 SLO를 약간 못 지켜도 고객 클레임이 발생하지 않는다.
Error Budget
SLO를 기반으로 실패해도 되는 허용 범위를 수치로 정한 것이다.
Error Budget = 100% - SLO
SLO 99.9% → 한 달 43.2분까지 다운돼도 괜찮다
버짓을 최대한 아끼는 게 목표가 아니다.
버짓은 새 기능을 배포하기 위한 연료다.
버짓이 남아있을 때 적극적으로 배포하고,
소진되면 배포를 중단하고 안정성 개선을 먼저 한다.
버짓 소진이 꼭 개발팀 배포 때문만은 아니다.
인프라 문제나 외부 의존성 장애도 버짓을 소진시킨다.
Toil
자동화할 수 있는데 사람이 손으로 반복하고 있는 작업이다.
귀찮은 일이랑은 다르다.
반복적이고, 자동화 가능하고, 서비스가 커질수록 같이 늘어나는 작업이 Toil이다.
Google SRE 기준으로 Toil은 업무 시간의 50%를 넘으면 안 된다.
넘기는 순간 개선하는 팀이 아니라 그냥 반복 작업하는 팀이 된다.
자동화도 비용이 들기 때문에 무조건 하는 게 아니라
절감 효과가 자동화 비용보다 클 때 한다.
Observability
모니터링이랑 다른 개념이다.
모니터링은 미리 정해둔 지표를 보는 것이고,
Observability는 어떤 질문이든 데이터로 답할 수 있는 능력이다.
세 기둥으로 구성된다.
| 기둥 | 역할 |
|---|---|
| Metrics | 얼마나 이상한지 수치로 감지 |
| Logs | 무슨 일이 있었는지 원인 파악 |
| Traces | 어느 구간에서 문제가 생겼는지 위치 특정 |
세 개가 같이 있어야 장애를 빠르게 해결할 수 있다.
Metrics만 있으면 "이상하다"는 건 알지만 왜, 어디서인지는 모른다.
Alerting 설계
알림이 많다고 좋은 게 아니다.
알림이 너무 많으면 Alert Fatigue가 생긴다.
팀이 알림에 무감각해져서 진짜 장애 알림도 무시하게 된다.
좋은 알림은 사용자가 실제로 영향을 받는 증상 기준으로 설계한다.
❌ "DB 슬로우 쿼리 10개 발생" → 내부 수치, 사용자 영향 불명확
✅ "결제 성공률 95% 아래로 하락" → 사용자가 결제를 못 하고 있음
그리고 알림마다 Runbook을 연결해두면
처음 보는 알림도 절차대로 대응할 수 있다.
Incident Management
장애가 발생했을 때 표준화된 절차로 대응하는 것이다.
감지 → 대응 → 완화 → 해결 → 사후분석
완화는 일단 불을 끄는 것이고, 해결은 불이 왜 났는지 찾는 것이다.
급할 때는 완화 먼저, 그 다음 근본 원인을 해결한다.
장애가 끝난 후에는 반드시 Postmortem을 작성한다.
핵심은 사람을 비난하지 않는 것이다.
누가 실수했는지가 아니라 왜 그 실수가 장애로 이어질 수 있었는지를 본다.
근본 원인은 5 Whys로 찾는다.
"왜?"를 5번 반복해서 표면적 원인이 아닌 진짜 원인을 찾는 것이다.
마지막 원인이 팀이 실제로 개선할 수 있는 것이어야 한다.
