> For the complete documentation index, see [llms.txt](https://wonjoon.gitbook.io/joons-til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wonjoon.gitbook.io/joons-til/techtalk-review/dangeun-tech/on-call.-alarm-is-killing-me.md).

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

## 느낀점

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