서비스 목표(SLO)는 장애 전에 정한다 — 기준 문장과 에러 버짓

장애가 났어요. 사용자들이 느리다고 하는데, 대시보드를 보니 평균 응답 시간이 평소랑 비슷해요.

무엇을 봐야 할지 그 자리에서 논의가 시작돼요. 백분위를 봐야 하나, 엔드포인트별로 나눠야 하나, 어느 구간을 기준으로 잡아야 하나.

30분이 지났는데 아직 "장애가 맞는지"조차 합의가 안 됐어요. 그동안 사용자는 계속 겪고 있고요.

이 책의 마지막 편이 이 얘기인 데는 이유가 있어요. 앞에서 본 모든 장치가 "무엇을 지켜야 하는가"를 안 정해 두면 방향 없이 도는 장치가 되거든요.

무엇이 정상이고 무엇이 장애인지는 평소에 정해 두는 거예요. 장애 중에 정하면 판단이 늦고, 사람마다 다르고, 대개 상황에 맞춰 관대해집니다.

왜 그런가

지표를 미리 안 정해 두면 세 가지가 무너져요.

판단이 늦어요. 무엇을 볼지부터 정해야 하니 대응이 시작조차 안 돼요. 앞 편들에서 본 장애 대응 시간의 큰 부분이 여기서 낭비됩니다.

기준이 흔들려요. 장애 중에 기준을 정하면 지금 상태에 맞춰 정하게 돼요. "이 정도면 괜찮은 것 같다"는 판단이 되고, 나중에 보면 명백한 장애였던 경우가 생겨요.

합의가 안 돼요. 개발자는 서버 지표를 보고 괜찮다 하고, 사업 쪽은 주문이 줄었다 하고, 지원 쪽은 문의가 폭증한다고 해요. 어느 것이 판단 기준인지 정해져 있지 않으면 논쟁이 됩니다.

그리고 더 근본적인 문제가 있어요. 무엇을 지켜야 하는지 모르면 무엇을 개선해야 할지도 몰라요. 응답 시간을 200ms 로 줄이는 게 가치 있는 일인지, 지금 500ms 로도 충분한지 판단할 근거가 없어요. 그러면 개선 작업이 감으로 정해집니다.

지표를 미리 정한다는 건 결국 약속을 명시하는 것이에요. 이 서비스는 어느 수준까지 동작하기로 되어 있는가. 그게 있어야 위반 여부를 말할 수 있어요.

코드로 보면

평소에 문장으로 적어 둔다:

· 나쁜 예 — 무엇을 재는지 모호하다
✕ '응답이 빨라야 한다'
✕ '가용성이 높아야 한다'

· 좋은 예 — 대상·측정 위치·기준·기간이 다 있다
✓ 대상: 주문 생성 API
✓ 측정: 로드 밸런서에서 본 응답 시간
✓ 기준: 30일 동안 99% 의 요청이 800ms 이하
✓ 성공 정의: 5xx 가 아니고 타임아웃도 아닌 응답

· 사용자 관점 지표를 하나는 둔다
✓ '주문 성공률' 은 서버가 멀쩡해도 떨어질 수 있다
✕ 서버 지표만 보면 조용한 실패를 놓친다

· 여유분을 계산한다
✓ 99% 기준이면 30일에 허용되는 실패는 1%
✓ 이번 달에 얼마나 썼는지가 배포 속도의 근거가 된다

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

좋은 지표에는 요소가 몇 개 있어요.

무엇을 재는지가 분명해야 해요. "응답 시간"이 아니라 "주문 생성 API 의 응답 시간"이요. 서비스 전체를 뭉뚱그리면 특정 기능의 장애가 평균에 묻혀요.

어디서 재는지도 정해야 해요. 앞 편에서 본 대로 서버에서 잰 것과 사용자가 겪은 것은 달라요. 사용자에 가까운 쪽이 진실에 가깝습니다.

성공을 무엇으로 보는지가 필요해요. 5xx 만 실패로 볼 건지, 타임아웃도 포함할 건지, 내용이 빈 200 은 어떻게 볼 건지요.

기준과 기간이 있어야 해요. "99% 가 800ms 이하"만으로는 부족하고 "30일 동안"이 붙어야 해요. 기간이 없으면 언제 위반인지 정할 수 없어요.

그리고 사용자 관점 지표를 최소 하나 두세요. 서버가 전부 정상인데 사용자는 아무것도 못 하는 상황이 실제로 있어요. 주문 성공률, 로그인 성공률 같은 게 그걸 잡아요. 앞 편의 조용한 실패가 여기서 드러납니다.

여유분 개념도 유용해요. 99% 기준이면 1% 는 실패해도 되는 몫이에요. 이번 달에 그걸 얼마나 썼는지가 지금 배포를 더 해도 되는지의 근거가 돼요. 여유가 많으면 과감하게, 다 썼으면 안정화에 집중하는 식이죠. 감이 아니라 숫자로 정하는 방법이에요.

기준을 정할 때 100% 를 목표로 하지 마세요. 비용이 무한대로 가고, 달성 못 할 목표는 기준 역할을 못 해요. 사용자가 실제로 불편을 느끼는 지점을 찾아 그보다 조금 엄격하게 잡는 게 현실적입니다.

처방

1. 핵심 기능마다 지표를 문장으로 적어 두세요. 대상·측정 위치·성공 정의·기준·기간을 다 넣으세요.
2. 사용자 관점 지표를 최소 하나 두세요. 서버 지표만으로는 조용한 실패를 못 잡습니다.
3. 어디서 재는지 명시하세요. 서버에서 잰 것과 사용자가 겪은 것은 다릅니다.
4. 기간을 붙이세요. 기간이 없으면 언제 위반인지 정할 수 없습니다.
5. 100% 를 목표로 하지 마세요. 달성 못 할 목표는 기준 역할을 못 합니다.
6. 여유분을 계산하고 배포 속도의 근거로 쓰세요. 감이 아니라 숫자로 정하는 방법입니다.
7. 장애 판단 기준을 이 지표로 통일하세요. 그래야 논쟁이 아니라 확인이 됩니다.
8. 정기적으로 기준을 재검토하세요. 서비스가 변하면 적정 기준도 변합니다.
9. 지표를 대시보드 첫 화면에 올리고 알림에 거세요. 문서에만 있으면 장애 때 아무도 안 봅니다.
10. 지표 개수를 적게 유지하세요. 서른 개를 정해 두면 아무도 기억하지 못합니다.

지금 확인해 보세요

지표가 살아 있는가:

· 핵심 기능마다 문장이 있는가
✓ 대상 · 측정 위치 · 성공 정의 · 기준 · 기간

· 사용자 관점 지표가 하나는 있는가
✕ 서버 지표만이면 조용한 실패를 못 잡는다

· 대시보드 첫 화면에 있는가 · 알림에 걸려 있는가
✕ 문서에만 있으면 장애 때 아무도 안 본다

· 기준을 실제로 지키고 있는가
✕ 계속 못 지키면 무시되기 시작하고 다른 기준도 같이 무시된다

· 사용자 반응(문의·이탈)과 대조되는가
✕ 기준 안인데 사용자가 불편하면 기준이 느슨한 것이다

· 이 지표를 잴 데이터가 실제로 있는가
✓ 라벨 설계 · 샘플링 정책 · 로그 구조가 다 여기 걸려 있다

핵심 한 줄무엇이 장애인지는 장애 나기 전에 정하는 것이다.