On call. Alarm is killing me

온콜, 알림만 보다가 죽겠어요

☸️ “온콜 알림만 보다가 죽겠어요” — 당근 SRE 팀의 알림 시스템 재탄생기

“우리는 왜 온콜에 지쳤는가, 그리고 어떻게 다시 시스템을 설계했는가.”

이 글은 단순히 알림 시스템 개선 사례가 아니라, 관제 피로도(alert fatigue) 를 기술적으로, 그리고 조직적으로 어떻게 해결했는지에 대한 기록입니다.

📘 1. 배경 — 알림의 바다에서 살아남기

당근 SRE 팀은 다섯 개 리전의 Kubernetes 클러스터(EKS)를 운영하고 있습니다.

한국 리전만 하더라도 350개 이상의 네임스페이스(namespace) 를 모니터링해야 했습니다.

모든 트래픽이 클러스터 하나에 집중되는 구조이므로, 단 하나의 지표 변화도 전체 서비스의 가용성에 영향을 미칠 수 있었습니다.

🔍 기존 모니터링 환경

  • Prometheus + Grafana 조합으로 지표 수집 및 대시보드 구성

  • Grafana Alerting 을 통해 Slack으로 알림 발송

  • 일부 서비스는 Datadog 및 Sentry 를 병행 사용

그러나 이 구조는 규모의 문제(scale issue) 를 견디지 못했습니다.

🚨 2. 장애의 실상 — “무슨 알림이 중요한지 모르겠다”

알림 시스템의 가장 큰 목적은 문제의 조기 탐지와 빠른 대응입니다.

하지만 실제 운영에서는 다음과 같은 3가지 근본적 문제가 드러났습니다.

① 네임스페이스 혼합 문제

하나의 Grafana 알림이 여러 네임스페이스의 지표를 묶어서 발송했습니다.

즉,

하나의 알림에 여러 네임스페이스가 섞여서 오고 있는 상태

“어느 네임스페이스에서 실제 문제가 발생했는지 알 수 없는”

상태였습니다.

이로 인해 SRE 엔지니어는 매번 이전 알림과 비교(diff) 하며, 새롭게 발생한 서비스만을 수동으로 찾아야 했습니다.

② 가독성 문제

Slack 메시지에는 수많은 레이블(label)이 들어가 있었고,

파드(pod) 이름, 노드(node), 앱(app) 구분이 한눈에 안 들어왔습니다.

즉, “한 줄 요약이 불가능한 알림” 이 되어버렸습니다.

③ 프로젝트 정보 누락

알림에는 배포 이력(deploy history) 과 담당자(owner) 가 없었습니다.

결과적으로, 알림이 오면 다음 단계를 반복했습니다:

  1. 최근 배포와 관련이 있는가?

  2. ArgoCD / 내부 배포 시스템 중 어떤 경로로 배포되었는지 확인

  3. Slack / Notion에서 담당자 수동 검색

    1. Argocd 배포이력 찾기

    2. 배포한 사람의 GitHub ID 찾기

    3. GitHb ID로 누구인지 찾기

  4. 담당자에게 수동으로 노티(notification)

이 모든 과정은 사람이 링크를 따라가며 수행해야 하는 비효율적 루틴이었습니다.

🧩 3. 문제의 근본 원인 — 시스템보다 사람이 빠르다

이런 상황에서 SRE 팀은 깨달았습니다.

“현재의 알림 시스템은 엔지니어보다 느리다.”

기존 시스템은 ‘지표 중심(alert-centric)’이었지만,

현실의 문제는 ‘프로젝트 중심(project-centric)’으로 발생합니다.

즉, 알림은 “무슨 일이 일어났는가” 를 알려주지만,

엔지니어는 “누가, 어디서, 왜 일어났는가” 를 알아야 대응할 수 있습니다.

🛠️ 4. 프로젝트 탄생 — Alert Delivery v1

이런 배경에서 2022년 Alert Delivery v1 이 시작되었습니다.

목표는 명확했습니다:

목표
설명

①

네임스페이스 단위로 알림 쪼개기

②

개별적인 알림 제어(알림 끄기, 리마인더, 임계치 조절 등)

③

메시지 가독성 향상

④

알림에 담당자 정보를 포함하고 필요 시 담당자를 멘션하여 빠른 대응 유도

⑤

전체 알림 상황을 한 번에 볼 수 있는 UI

📊 동작 방식

  • Alert Delivery는 매트릭 추세(metric trend) 와 수치(value) 를 모두 분석합니다.

  • 예: 응답률이 5%p 이상 떨어지면 Medium → High 승급

  • 반대로 회복되면 High → Medium 또는 Low로 강등

🔁 자동 멘션 조건

  • 동일 알림 3회 연속 발생 시

  • 세 번째 시점의 Severity가 Medium 이상일 때만 멘션

💡 결과:

  • 무의미한 Mentions 70% 감소

  • On-call 피로도 현저히 완화

🧵 10. 기능 ② — Slack Threading

기존에는 같은 알림에 대해 다음 네 메시지가 따로 도착했습니다:

  1. Firing Alert

  2. Repeat Alert

  3. Resolved (OK)

  4. Recovered notification

이제는 하나의 Slack Thread로 묶였습니다.

모든 알림 업데이트는 원본 메시지 아래에 달리고,

OK 시에는 본문에 바로 “✅ Resolved” 표시가 추가됩니다.

✨ 효과

  • 알림 채널의 “읽지 않아도 되는 노이즈” 대폭 감소

  • 진행 중(Firing) 알림만 채널 상단에 남음

  • On-call이 “현재 무엇이 문제인지” 즉시 파악 가능

🌐 11. 기능 ③ — Grafana Alert 전면 통합

기존에는 Alert Delivery가 Kubernetes 네임스페이스 기반 알림만 수신했습니다.

노드/디스크/네트워크 등 인프라 레벨 알림은 여전히 Grafana → Slack 직행 구조였습니다.

이제 모든 Grafana Alert에

labels:
  alert_delivery: enabled

을 추가하면 Alert Delivery가 대신 수신하고 전송합니다.

🧱 기술 구조

  • Grafana Unified Alerting System으로 업그레이드

  • Webhook receiver 단일화

  • Alert Delivery의 메시지 파서가 Label 기반으로 구분 처리

💡 결과:

운영팀은 하나의 시스템(Delivery) 에서 모든 알림을 통합 관리할 수 있게 됨.

🔎 12. 기능 ④ — 배포 이력 자동 삽입 (Alert Insight Bot)

별도의 Slack Bot 을 만들어,

알림 스레드에 해당 네임스페이스의 최근 배포 이력을 자동으로 추가했습니다.

🚀 [배포 이력]
2024-09-15 14:23 by dev.kim
Commit: feat(cache): Redis failover fix

이제 온콜은 “누가 언제 무엇을 배포했는지” 즉시 확인 가능했습니다.

ArgoCD나 내부 배포 시스템을 따로 검색할 필요가 없어졌습니다.

📉 13. 성과 분석 — “알림만 보다 죽던 시대의 종말”

📊 알림 메시지 감소량

  • 하루 평균 Slack 메시지 수: 약 40% 감소

  • 스레드 도입 후 실질적 확인 대상: 약 70% 감소

📈 Mentions 감소량

  • 하루 평균 멘션 횟수: 70회 → 10회 미만

  • 멘션이 아예 없는 “평화로운 날”도 등장

이 수치는 단순한 개선이 아니라 엔지니어의 집중력을 회복시킨 구조적 변화였습니다.

💬 14. 현장 피드백 — “이제는 알림이 아니라 인사이트다”

온콜 로그(On-call Log)에는 다음과 같은 기록이 남았습니다.

“알림 개수가 줄어들어 대응이 명확해졌습니다.”

“배포 이력 자동 표시가 정말 유용했습니다.”

“Slack 쓰레드로 묶이니까 알림이 산처럼 쌓이지 않아요.”

SRE 팀 내부의 인지 부하(cognitive load) 가 크게 줄었고,

팀원 간의 협업 효율성도 향상되었습니다.

📘 15. 시스템 아키텍처 — Alert Flow 재구성

Grafana Alerting
   ↓ (Webhook)
Alert Delivery
   ↓ (Metadata Enrichment)
Slack Notification
   ↓
Threaded Message + Deployment Info

  • Webhook Receiver: 모든 Grafana 알림 수집

  • Metadata Resolver: 프로젝트, 담당자, 배포 이력 연동

  • Severity Analyzer: 매트릭 추세 기반 레벨링

  • Slack Dispatcher: 메시지 생성 및 쓰레드 업데이트

각 모듈은 비동기 이벤트 큐(예: RabbitMQ)로 연결되어 있으며,

하나의 장애가 전체 플로우를 막지 않도록 idempotent 설계를 채택했습니다.

(주석: idempotent = 같은 요청을 여러 번 보내도 결과가 변하지 않는 설계 원리)

💡 16. 기술적 인사이트 — “좋은 알림은 기술이 아니라 철학이다”

Alert Delivery의 핵심 철학은 다음 세 가지로 요약됩니다.

  1. 불필요한 알림은 알림이 아니다.

    → 신뢰를 잃은 알림은 결국 무시된다.

  2. 맥락 없는 알림은 잡음(noise)이다.

    → 배포 이력, 담당자 정보, 대시보드 링크 등 맥락이 핵심이다.

  3. 알림은 협업의 시작이다.

    → 알림은 종착점이 아니라, “대응의 출발점”이다.

🧭 17. 교훈 — 기술보다 조직의 성숙이 중요하다

Alert Delivery V2의 성공은 단순히 시스템 개선이 아니라,

조직 문화의 변화를 동반했습니다.

  • 온콜이 “벌칙”이 아니라 “학습”의 기회로 인식되기 시작

  • 신규 입사자도 온콜을 통해 빠르게 실무 역량 확보

  • 알림 로그가 팀의 지식 자산으로 누적

🚧 18. 향후 과제 — 우리는 여전히 발전 중이다

Alert Delivery V2가 많은 문제를 해결했지만,

SRE 팀은 여전히 세 가지 과제를 남겨두었습니다.

  1. 알림 개인화 (Personalization)

    • 서비스별 Slack 채널 분리

    • 개발자가 스스로 알림을 구독/해제할 수 있는 인터페이스 구축

  2. 장애 판단 자동화 (Incident Classification)

    • 단일 알림 → 종합 장애 여부 판단

    • 다중 지표 상관관계 분석 기반 장애 감지 모델 연구

  3. 장애 대응 프로세스 자동화

    • 장애 판단 시 자동 Zoom 호출 및 워룸 생성

    • 관련자 자동 Mentions 및 상태 공유

느낀점

현재 회사에서 보고 있는 알림이 불편하다고 생각하진 않았는데, 당근의 바뀐 알림 시스템을 보니, 가독성이 좋아진것 같습니다. 아쉬운점이 기술적인 내용이 없었고, 크게 와닿진 않았습니다.

PreviousDangeun TechNextCS Note for Interview

Last updated