장애를 완전히 막을 수 없다면 이상 징후를 일찍 잡아야 하지만, 개별 server metric과 바쁜 domain team의 설정에 기대던 alerting은 누락·조직 변화·tool 숙련도 차이로 계속 gray area를 남겼다. 우아한형제들 SRE가 server 중심 alert를 넘어 customer journey의 order·traffic 같은 service 지표를 중앙에서 보는 top-down anomaly detection으로 확장한 과정을 담았다.
핵심 포인트- app 접속·store 탐색·cart·payment 등 user journey에서 order count·recommendation count 같은 critical business indicator를 정의하고, 확률 model 대신 동일 요일·시간의 과거 중앙값 baseline을 택해 오탐 이유를 누구에게나 설명 가능하게 설계
- 장기 data·backfill·simulation을 다루는 VictoriaMetrics와 admin UI·RDB로 platform 구성, threshold 초과 횟수를 함께 세어 단일 spike를 걸러내고 promotion·시스템 작업 같은 planned event는 예외 등록
- 장애 판단 시 지표·예측·실값을 공용 channel 전송, Opsgenie on-call 호출, incident 공지·대응 channel까지 자동 생성해 담당자가 원인 탐색 전에 전파부터 하도록 전환
- 그 결과 alarm precision 11배, detection rate 70%, propagation time 74% 개선 — SRE 단독이 아니라 service team과 interview해 대표 지표를 함께 고른 공동 ownership의 산물
왜 읽나server metric 알림의 gray area에 지친 SRE·플랫폼 조직에게, 설명 가능한 중앙 anomaly detection을 어떤 지표·기술·조직 설득으로 세우는지 보여주는 레퍼런스.