이 글에서 얻는 것

  • “알람이 많으면 안전하다”가 아니라, 액션 가능한 알람을 소수로 유지하는 이유를 이해합니다.
  • 레이턴시/에러율/트래픽/포화(Golden Signals)를 기준으로 “무엇을 알람으로 만들지” 선택할 수 있습니다.
  • SLO/에러 버짓 기반 알람(번레이트)과 단순 임계치 알람을 구분해서 운영할 수 있습니다.
  • Runbook/온콜 라우팅/무음(silence) 같은 운영 루프까지 포함해 알람 체계를 설계할 수 있습니다.

0) 알람의 목표는 “깨우기”가 아니라 “복구”다

좋은 알람은 한 문장으로 정의됩니다.

지금 당장 사람이 개입하면 결과가 좋아진다.

반대로, 아래는 나쁜 알람입니다.

  • 너무 자주 울린다(노이즈)
  • 울려도 뭘 해야 할지 모른다(액션 불가)
  • 이미 늦었다(탐지 지연)

1) 알람 vs 대시보드: 역할이 다르다

  • 대시보드: “상황을 이해”하기 위한 화면(분석 도구)
  • 알람: “지금 바로” 대응이 필요한 신호(행동 트리거)

대시보드에 있는 모든 지표를 알람으로 만들면 온콜은 곧 마비됩니다.

2) 무엇을 알람으로 만들까: Golden Signals로 시작

서비스 관점에서 최소한 아래 4개 축을 봅니다.

  • Latency: p95/p99 레이턴시
  • Errors: 5xx(그리고 의미 있는 실패율)
  • Traffic: 요청 수/처리량(급증/급감)
  • Saturation: 자원 포화(CPU/메모리/스레드/커넥션 풀/큐)

메시징/배치가 있다면:

  • Kafka lag, DLQ 유입

도 흔한 알람 후보입니다.

3) 증상 알람(Symptom) vs 원인 알람(Cause)

알람은 크게 두 종류가 있습니다.

3-1) 증상 알람(서비스가 깨졌다)

  • 에러율 급증
  • p99 레이턴시 급증
  • SLO 위반(에러 버짓 번레이트)

이 알람이 1순위입니다. “사용자가 실제로 아픈가?”를 가장 먼저 알려주기 때문입니다.

3-2) 원인 알람(곧 깨질 것 같다)

  • DB 커넥션 풀 고갈
  • 메모리 누수(점진 상승)
  • 큐 backlog 증가

원인 알람은 유용하지만, 너무 많아지면 노이즈가 됩니다. “증상 알람이 울리기 전에 고칠 수 있는 것”만 선별하는 편이 좋습니다.

4) SLO 기반 알람: 번레이트(burn rate)로 노이즈를 줄이기

단순 임계치(p99 > 1s)는 쉽지만, 트래픽 변동/노이즈에 약합니다. SLO 기반 알람은 “에러 버짓을 얼마나 빨리 태우고 있는지”로 판단합니다.

감각적으로:

  • 짧은 창(예: 5~15분)에서 빠르게 타면 즉시 대응(페이지)
  • 긴 창(예: 1~6시간)에서 계속 타면 근본 원인 해결(티켓/개선)

구체 구현은 조직/도구마다 다르지만, “멀티 윈도우”로 단기/장기 번레이트를 함께 보는 방식이 흔합니다.

5) 임계치 알람을 쓸 때의 최소 원칙

  • 관찰 기간을 명시한다(스파이크 노이즈 방지): 1분이 아니라 5~10분 평균/최댓값 등
  • 절대값 + 변화율을 함께 본다(증분 알람)
  • 알람에 “상태”를 넣는다: 현재 값/기간/관련 대시보드 링크

6) 온콜 운영: 라우팅/에스컬레이션/무음

알람은 “어디로” 가는지가 절반입니다.

  • 심각도(severity): page vs ticket
  • 라우팅: 서비스/팀/시간대(온콜)
  • 조용 시간/무음(silence): 배포/점검 시 노이즈 차단
  • 에스컬레이션: 응답 없을 때 다음 담당자/채널로

알람이 울렸을 때 “누가/어디서/어떻게” 대응할지까지 포함돼야 운영이 됩니다.

7) Runbook: 알람이 ‘행동’으로 이어지게 만든다

좋은 Runbook의 구성(최소):

  • 이 알람의 의미(증상/원인)
  • 1차 확인(최근 배포, 대시보드 링크, 의존성 상태)
  • 10분 안에 할 수 있는 응급 조치(롤백, 스케일, 기능 플래그 off)
  • 근본 원인 분석 포인트(로그/트레이스/지표)

알람에는 Runbook 링크를 반드시 붙이는 편이 좋습니다.

8) 알람 테스트/위생(운영 루프)

  • 새 알람은 “일단 낮은 심각도”로 시작해 노이즈를 측정
  • 월 1회라도 “알람 리뷰”로 삭제/조정(알람 갯수는 항상 늘어나는 경향)
  • 장애 후에는 “왜 늦게 알았나/왜 노이즈였나”를 회고에 포함

연습(추천)

  • 서비스에서 page 알람 3개만 선정해보기(에러율, p99, 의존성 실패) + 각각 Runbook 10줄 작성
  • 배포 시간에만 자주 울리는 알람을 찾아, 관찰 기간/조건을 조정해 노이즈를 줄여보기
  • “증상 알람 → 원인 지표”로 이어지는 대시보드 링크를 구성해, 알람 하나로 원인 탐색이 가능하게 만들기