이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Alert Rule은 어떤 조건을 만족해야 행동 가능한 알림이 되는가?
- Alert Noise가 늘어나면 운영 대응에 어떤 피해가 생기는가?
- Severity, 지속 시간, runbook, suppression을 어떻게 설계해야 하는가?
개요
Alert는 사람의 주의를 강제로 가져오는 운영 장치다.
따라서 알림은 “무언가 이상하다”가 아니라 “지금 어떤 행동이 필요하다”를 말해야 한다.
Alert noise가 많아지면 담당자는 알림을 무시하기 시작한다.
그 결과 진짜 장애가 늦게 감지된다.
좋은 alert rule은 사용자 영향, 지속 시간, severity, runbook, 담당자를 가진다.
좋은 Alert의 조건
좋은 alert는 증상 기반이다.
원인 후보보다 사용자 영향에 가까운 신호가 우선이다.
예를 들어 “CPU 80%”보다 “주문 API 5xx 비율 2% 초과”가 더 행동 가능하다.
CPU 알림도 필요할 수 있지만, page 등급인지 ticket 등급인지 구분해야 한다.
즉시 깨워야 하는 알림은 사용자가 지금 영향을 받고 있거나 곧 받을 가능성이 높아야 한다.
Rule 예시
groups:
- name: order-api-alerts
rules:
- alert: OrderApiHigh5xxRate
expr: |
sum(rate(http_server_requests_seconds_count{service="order-api",status=~"5.."}[5m]))
/
sum(rate(http_server_requests_seconds_count{service="order-api"}[5m]))
> 0.02
for: 10m
labels:
severity: page
service: order-api
annotations:
summary: "order-api 5xx rate is above 2% for 10m"
runbook: "https://wiki.example.com/runbook/order-api-5xx"for: 10m은 짧은 spike를 줄인다.
severity는 대응 채널과 시간을 결정한다.
runbook은 첫 확인 지표와 완화 절차로 연결되어야 한다.
Noise 원인
Noise는 여러 이유로 생긴다.
임계치가 너무 낮을 수 있다.
지속 시간이 없어 순간 spike마다 울릴 수 있다.
원인 알림과 증상 알림이 동시에 울릴 수 있다.
서비스별 routing이 없어 관련 없는 사람이 계속 깨질 수 있다.
배포나 점검 중 알림 억제 기준이 없을 수도 있다.
Severity 기준
Severity는 내부 기술 지표만으로 정하지 않는다.
사용자 영향, 영향 범위, 우회 가능성, 업무 시간 여부, 자동 복구 가능성을 함께 본다.
page: 즉시 대응 필요, 사용자 영향 큼
ticket: 근무 시간 내 확인 가능
info: 기록 목적, 사람을 깨우지 않음모든 알림을 page로 보내면 page의 의미가 사라진다.
운영 체크리스트
- alert가 사용자 영향 또는 SLO burn과 연결되어 있는가?
- rule에 threshold와 지속 시간이 모두 있는가?
- severity가 page/ticket/info로 구분되어 있는가?
- runbook 링크와 첫 확인 dashboard가 있는가?
- 배포/점검 중 suppression 기준이 있는가?
- 같은 장애에서 중복 알림이 과도하게 울리지 않는가?
- 알림마다 owner와 routing이 정해져 있는가?
장애 신호
- 알림은 많이 울리지만 실제 장애는 아니다.
- 담당자가 알림을 mute한 뒤 진짜 장애를 놓친다.
- 같은 원인으로 10개 이상의 알림이 동시에 울린다.
- 알림 메시지에 metric 이름이나 service가 없다.
- runbook 링크가 없거나 오래되어 첫 조치가 늦어진다.
- 배포 중 예상 가능한 알림이 매번 page로 간다.
안전한 완화 조치
Noise가 많다고 알림을 무작정 삭제하지 않는다.
최근 발생 이력과 실제 사용자 영향을 확인해 severity와 threshold를 조정한다.
중복 알림은 symptom alert를 page로 두고 cause alert는 ticket으로 낮출 수 있다.
배포 중 예측 가능한 알림은 suppression이나 maintenance window를 둔다.
단, suppression은 시작과 종료 시간이 명확해야 한다.
인프라 담당자와 공유할 자료
문제: order-api page alert noise 증가
alert: OrderApiHighLatency
현재 조건: p95 > 300ms for 1m
최근 7일: 42회 발생, 사용자 영향 확인 1회
제안: p95 > 800ms for 10m 또는 SLO burn 기반으로 변경
runbook: 누락
필요 조치: dashboard/runbook 추가 후 severity 재분류Alert rule 변경 논의에는 발생 빈도, 실제 영향, 제안 threshold, runbook 상태를 포함한다.
실전 팁
- Page alert는 행동 가능한 증상 중심으로 둔다.
- 순간값보다 지속 시간을 둔다.
- Alert message에는 service, metric, threshold, 현재값을 넣는다.
- Runbook 없는 page alert는 빚이다.
- 알림 회고는 장애 회고만큼 중요하다.
위험 신호!
- 모든 warning을 page로 보낸다.
- 알림이 울려도 무엇을 해야 할지 모른다.
- 배포 때마다 같은 알림이 울린다.
- 알림을 줄이려고 중요한 symptom alert까지 꺼 버린다.
- Owner 없는 alert가 남아 있다.
확인 질문
확인 질문
- 행동 가능한 알림의 조건은 무엇인가?
- 사용자 영향과 연결되고, 현재값/기준/지속 시간/severity/runbook/담당자가 있어야 한다.
- Alert noise가 위험한 이유는 무엇인가?
- 담당자가 알림을 무시하거나 mute하게 되어 실제 장애 감지가 늦어질 수 있기 때문이다.
- 원인 알림과 증상 알림 중 page에 더 적합한 것은 무엇인가?
- 일반적으로 사용자 영향에 가까운 증상 알림이 page에 더 적합하고, 원인 후보 알림은 보조 신호로 둔다.