Oncall Bot과 프론트엔드 모니터링

문제

NFC 확인처럼 외부 서비스로 넘어가는 과정에서 생기는 조용한 이탈은 며칠 뒤에야 고객 지원을 통해 발견되었습니다. 알림은 임계값 기반이라 소음이 많았고, 사람들은 이미 무시하는 데 익숙해져 있었습니다.

접근 방식

• 고정 임계값 대신 상대적 기준선. 알림 서비스가 ClickHouse에 SQL을 실행해 각 지표를 지난주 같은 시간대와 비교합니다. 전환율 20% 하락은 도쿄의 새벽 3시와 베를린의 정오에 전혀 다른 의미이고, 전 세계 트래픽의 오르내림이 더는 오탐을 만들지 않습니다.
• 맥락과 함께 도착하는 알림. 알림이 울리면 사내 채팅 플랫폼에 인시던트 카드를 올립니다. 이어서 백그라운드 워커가 ClickHouse에서 최근 프론트엔드 오류 스택 트레이스를, 설정 서비스에서 현재 활성화된 설정 버전을, 그리고 Kubernetes 배포 로그를 모아 구조화된 프롬프트로 엔터프라이즈 LLM API에 보냅니다.
• 스레드 안의 요약. 봇은 유력한 근본 원인을 답글로 남깁니다. 예를 들어 일본에서 3단계 전환율 32% 하락, NFC 브리지 래퍼의 null 포인터 오류, 15분 전에 배포된 설정 변경, 백엔드에서 벤더 게이트웨이 타임아웃 같은 내용입니다.

결과

감지 시간은 몇 시간에서 며칠이던 것이 5분 미만으로 줄었고, 완화 시간은 65%, 오탐 알림은 80% 줄었습니다. 알림의 신호 대 잡음비(실제 인시던트로 이어진 알림의 비율)와 프론트엔드 모듈의 평균 고장 간격도 추적했습니다.

왜 이렇게 했나

일반적인 알림은 무언가 고장 났다는 사실만 알려 줍니다. 데이터를 자동으로 모으고 요약하면, 지표와 그것을 사람이 이해하기까지의 간극이 메워집니다. 대응 시간의 대부분이 바로 거기서 쓰이고 있었습니다.