사용자가 불만을 제기하기 전에 어떻게 문제를 탐지하나요?

Question

Accepted Answer

목표는 **page 전에** 문제를 잡는 것입니다 — 흡수할 여유가 남아 있을 때 성능 저하를 찾아내는 것이죠. 이는 **선행 지표(leading indicators)**를 지켜보고, **error budget이 있는 SLO**를 정의하며, 시스템이 실패하기를 기다리는 대신 능동적으로 탐침하는 것을 뜻합니다.

## SLO와 error budget

**SLO**는 reliability를 숫자로 만듭니다(예: 요청의 99.9% 성공). 남은 0.1%가 당신의 **error budget**입니다. **burn rate**를 추적하면 budget을 너무 빨리 쓰고 있을 때 alert할 수 있습니다 — 실제로 SLO를 위반하고 사용자가 알아차리기 훨씬 전에요.

```text
SLO 99.9% → 월 0.1% error budget (~43분 downtime)
burn rate 급상승 → 2일이면 소진 → 지금 alert, 아직 고칠 수 있을 때
```

## 수동 metric만이 아니라 능동 탐침

```text
SYNTHETIC MONITORING  스크립트 검사가 핵심 경로를 일정에 따라 타격
                      (login, checkout) → 실제 traffic 0인 새벽 3시에도 실패 감지
HEALTH CHECKS         /healthz endpoint + dependency 검사 → load balancer가
                      사용자가 닿기 전에 불량 instance를 제거
RUM (real-user mon.)  실제 브라우저/기기에서 latency/errors 측정 →
                      일부 사용자/지역만 보는 문제를 포착
```

Synthetic monitoring이 강력한 이유는 사용자를 기다리지 않기 때문입니다 — 시스템을 지속적으로 작동시키므로, 깨진 checkout이 아침 러시가 불평할 때가 아니라 새벽 3시에 발견됩니다.

## 선행 지표와 추세

가장 이른 징후는 사용자 대면 오류가 아니라 리소스에 있습니다. 정적 선이 아니라 **추세**에 alert를 거세요.

```text
LEADING INDICATORS   saturation (CPU/mem 상승), queue depth 증가,
                     connection-pool이 한계에 근접, latency가 슬금슬금 상승
ANOMALY DETECTION    정상 baseline / 계절성에서의 이탈을 표시
TREND ALERTS         "이 속도면 disk가 4시간 내 가득 참" → 차기 전에 조치
```

천천히 오르는 p99나 부풀어 오르는 queue는 경고 사격입니다: 그 슬금슬금 상승에 조치함으로써, 그것이 향하던 outage를 예방합니다.

## 왜 중요한가

반응적 모니터링은 사용자가 곧 당신의 alert 시스템이라는 뜻입니다 — 그들이 불평할 무렵이면 인시던트는 이미 진행 중이고 error budget은 소진되었습니다. 능동적 탐지(SLO burn rate, synthetics, health checks, RUM, 선행 지표, trend/anomaly alert)는 선행 시간을 벌어줍니다: saturate되는 queue나 슬금슬금 오르는 latency를, 그것이 새벽 2시 page와 성난 고객이 되기 전에 고칩니다. 그 선행 시간이 조용한 수정과 outage를 가르는 차이입니다.