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 및 상태 공유

느낀점

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