알림 모범 사례
알림 모범 사례 (Alerting best practices)
효과적인 알림 시스템을 설계하고 구성하는 데는 시간이 걸려요. 이 안내서는 실제 운영에 맞춰 확장되는 알림 시스템을 만드는 데 초점을 맞춰요. 여기 설명된 관행은 도구와 무관하게 적용되는 고수준 원칙이라서, Prometheus든 Grafana Alerting이든 다른 스택이든 같은 제약(복잡한 시스템, 불완전한 신호, 대기 중인 인간)이 적용돼요. 알림은 사고, 조직 변화, 보호 대상 시스템과 함께 진화하므로 완성되지 않아요.
출처: 문서
본문
증상 우선, 그래도 인프라 신호도 무시하지 마세요
알림은 주로 사용자가 보는 실패(사용자 대면 실패)를 감지해야 해요. 사용자는 pod가 재시작했다는 사실에는 관심이 없고, 애플리케이션이 느리거나 실패할 때 관심이 있어요. 증상 기반 알림은 사용자 영향에 직접 연결돼요. 지연 시간, 오류, 가용성 같은 사용자에게 영향을 주는 신뢰성 메트릭이 인프라 이벤트나 내부 오류보다 나은 페이지 신호예요.
그래도 인프라 신호도 중요해요. 조기 경고 지표로 작동하며 알림 성숙도가 낮을 때 유용해요. CPU나 메모리 사용량의 지속적 스파이크가 페이지를 유발할 가치는 없지만, 증상 기반 실패를 설명하거나 예상하는 데 도움을 줄 수 있어요. 인프라 알림은 시끄럽기 쉬워 페이지 신호처럼 취급하면 무시되는 경우가 많아요. 대시보드, 알림 목록, 전용 Slack 채널 같은 비페이지 대상의 낮은 심각도 채널에 더 적합해요. 핵심은 알림이 성숙해짐에 따라 균형을 잡는 것 — 인프라 알림을 증상 기반 알림의 대체가 아니라 진단·예방 지원으로 쓰세요.
신뢰도(confidence)에 따라 우선순위 에스컬레이션
알림 우선순위는 사용자 영향과 응답의 긴급성에 연결되는 경우가 많지만, 언제 에스컬레이션할지는 신뢰도가 결정해야 해요. 여기서 에스컬레이션이란 신뢰도가 높아짐에 따라 응답자에게 알리는 방식을 말해요 — 알림 우선순위 높이기, 알림 범위 넓히기, 추가 응답자 페이지, 개입이 명확히 필요할 때 사고 열기 등을 포함해요.
초기 신호는 종종 모호하고, 비일시적 실패에 대한 신뢰도는 낮아요. 너무 일찍 페이지하면 소음이 생기고, 너무 늦게 하면 아무도 행동하기 전에 사용자가 더 오래 영향을 받아요. 지연 시간의 작거나 갑작스러운 증가가 즉각 조치를 정당화하지 못할 수 있지만 진행 중인 실패를 나타낼 수는 있어요. 신호가 강해지거나 상관관계를 보이기 시작하면 신뢰도가 올라가요. 문제가 지속되거나 여러 신호로 보강될 때(예: 높은 지연 시간 + 상승하는 오류율, 또는 같은 이벤트가 지속적으로 발화) 에스컬레이션을 정당화해요. 일시적 소음의 가능성을 줄이고 실제 영향의 가능성을 높여요.
확장성과 실행 가능성을 위한 알림 범위
분산 시스템에서 모든 호스트·서비스·엔드포인트마다 별도의 알림 규칙을 만들지 마세요. 대신 다차원 알림 규칙으로 자동 확장되는 규칙을 정의해요. 이렇게 하면 규칙 중복이 줄고 시스템이 커져도 알림이 확장돼요. 단순하게 시작해 서비스나 엔드포인트 같은 단일 차원을 기본으로 해 관리 가능하게 유지하고, 실행 가능성이 개선될 때만 차원을 추가해요(예: region 같은 차원이 없으면 실패가 숨겨지거나 빠르게 행동할 정보가 부족할 때). region이나 instance 같은 추가 차원은 근본 원인 식별에 도움을 주지만, 항상 더 많다고 좋은 건 아니에요.
첫 응답자를 위한 알림 설계와 명확한 조치
알림은 규칙을 만든 사람이 아니라 첫 응답자를 위해 설계해야 해요. 대기 중인 누구든 시스템이나 알림 설정에 대한 깊은 지식 없이 무엇이 잘못됐고 다음에 무엇을 해야 하는지 이해할 수 있어야 해요. 응답자가 맥락을 파악하느라 시간을 쓰게 하는 모호한 알림은 피하세요. 모든 알림은 왜 존재하는지, 무엇이 트리거했는지, 어떻게 조사하는지를 명확히 설명해야 해요. 애노테이션으로 관련 대시보드와 런북에 연결하는 것은 더 빠른 해결에 필수예요.
알림은 영향이 낮아도 실제 문제를 나타내고 실행 가능해야 해요. 정보성 알림은 신뢰성을 개선하지 않고 소음만 더해요. 조치가 불가능하다면 알림이 아니라 대시보드를 고려해요. 시간이 지나면 알림은 기술 부채처럼 행동해요 — 만들기 쉽고, 유지하긴 비싸고, 제거하긴 어려워요. 자주 검토하고 조치로 이어지지 않는 알림은 제거하세요.
알림에는 소유자와 시스템 범위가 있어야 해요
소유권이 없는 알림은 무시되는 경우가 많아요. 모든 알림에는 소유자(알림을 유지하고 발화 시 응답할 책임이 있는 팀)가 있어야 해요. 알림은 또한 서비스나 인프라 컴포넌트 같은 시스템 범위를 정의해야 해요. 범위는 조직 맥락을 제공하고 알림을 소유권과 연결해요. 범위, 소유권, 우선순위를 정의한 뒤, 라우팅이 알림이 어디로 가고 어떻게 에스컬레이션할지 결정해요. 알림 라우팅은 알림만큼 중요해요.
알림은 우선순위, 소유권, 팀 워크플로에 따라 올바른 팀과 채널로 전달돼야 해요. 알림 정책(notification policies)으로 서비스나 범위의 맥락과 일치하는 라우팅 트리를 정의해요:
- 범위 내 기본 라우팅을 위한 부모 정책 정의
- 특정 사례나 우선순위가 높은 문제를 위한 중첩 정책 정의
알림 그룹화로 알림 과부하 방지
알림 그룹화가 없으면 응답자는 같은 근본 문제에 대한 여러 알림을 받을 수 있어요. 예를 들어 데이터베이스 실패는 지연 시간 증가, 높은 오류율, 내부 오류 등 여러 알림을 동시에 트리거할 수 있어요. 각 증상에 대해 따로 페이지하면 단일 근본 원인인데도 알림 스팸이 돼요. 알림 알림 그룹화는 관련 알림을 단일 알림으로 통합해, 같은 문제에 여러 페이지 대신 사고를 나타내는 알림 하나와 그와 관련된 모든 발화 알림을 받게 해요. 그룹화는 알림 정책이 정의한 서비스나 소유자 같은 운영 경계를 따라야 해요. 다운스트림·연쇄 실패는 많은 문제가 아닌 하나의 문제로 표면화되도록 함께 그룹화돼야 해요.
초당 보낼 수 있는 알림 수에도 한도가 있어요. 연락 지점(Contact Point) 설정에서 개별 이메일 대신 단일 이메일 알림을 설정해 이메일 지출을 줄일 수 있어요. 원하는 이메일 연락 지점으로 가서 선택 설정에서 Single email을 활성화하면 돼요.
플래핑 알림 완화
수명이 짧은 실패 스파이크는 빨리 자동 해제되는 알림을 자주 트리거해요. 일시적 실패에 대한 알림은 소음을 만들고 응답자가 무시하게 해요. 문제가 알림되기 전에 지속되도록 요구하세요. pending 기간을 설정해 발화 전에 조건이 참이어야 하는 시간을 정의해요. 높은 오류율에 즉시 알리는 대신 몇 분간 임계값 위에 유지되길 요구해요. 또한 쿼리 범위와 집계를 조정해 알림을 안정화해요. 원시 데이터를 쓰면 알림이 소음에 민감해져요. 대신 시간 창에 걸쳐 평가하고 데이터를 집계해 짧은 스파이크를 평활화해요:
# Reacts to transient spikes. Avoid this.
cpu_usage > 90
# Smooth fluctuations.
avg_over_time(cpu_usage[5m]) > 90
지연·오류 기반 알림에서는 평균보다 백분위가 더 유용한 경우가 많아요:
quantile_over_time(0.95, http_duration_seconds[5m]) > 3
마지막으로 복구 중 알림을 잠시 활성 상태로 유지하는 keep_firing_for나 복구 임계값을 사용해 빠른 해제-발화 알림을 피하세요. 두 옵션 모두 플래핑과 불필요한 알림을 줄여요.
증상 기반 알림을 SLO로 승격
증상 기반 알림이 자주 발화하면, 더 신중하게 측정·관리해야 할 신뢰성 우려를 나타내는 경우가 많아요. 이는 종종 그 알림이 **SLO(서비스 수준 목표)**로 진화할 수 있는 신호예요. 기존 알림은 즉시 반응하라는 압박을 만들지만, 오류 예산은 행동할 시간 버퍼를 도입해 긴급성 처리 방식을 바꿔요. 알림은 모든 사소한 이탈에 반응하는 대신 오류 예산 소진율(burn rate)로 정의할 수 있어요. SLO는 "좋음"이 무엇인지 공유된 정의를 제공해 서로 다른 팀을 공통 신뢰성 목표로 정렬하고, 여러 증상 알림을 단일 사용자 대면 목표로 통합해요. 예를 들어 여러 팀이 높은 지연 시간에 알림을 거는 대신, 팀 전체에서 단일 SLO로 전반적 API 성능을 포착할 수 있어요.
사고 포스트모템에 알림 통합
모든 사고는 알림을 개선할 기회예요. 사고 후 알림이 응답자를 빨리 행동하게 했는지, 불필요한 소음을 더했는지 평가하세요. 어떤 알림이 발화했고 사고 대응에 어떻게 영향을 줬는지 판단하고, 알림이 너무 늦게·너무 일찍·맥락 없이 트리거됐는지 검토한 뒤 실제로 일어난 일에 따라 임계값·우선순위·에스컬레이션을 조정하세요. 활성 사고 중에는 silences를 사용해 반복 알림을 줄이되, 무관한 알림을 무음화하지 않도록 범위를 신중히 정하세요. 포스트모템은 근본 원인과 교훈과 함께 알림을 평가해야 해요.
알림은 지속적으로 개선되어야 해요
알림은 반복적인 과정이에요. 검토·개선되지 않은 알림은 시스템과 트래픽 패턴이 변하면서 효과를 잃어요. 정기적으로 기존 알림을 검토하고, 조치로 이어지지 않는 알림은 제거하며, 유용한 신호 없이 너무 자주 발화하는 알림이나 임계값을 조정하세요. 거짓 긍정을 줄여 알림 피로에 대응하세요. 알림 설계에서 명확성과 단순성을 우선시해요. 더 단순한 알림은 압박 속에서 이해·유지·신뢰하기 쉬워요. 가치 낮은 알림을 많이 만드는 것보다 품질 높고 실행 가능한 알림을 적게 만드는 쪽이 좋아요. 조사에는 대시보드와 관측성 도구를 쓰고, 알림에는 쓰지 마세요.