이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 장애 징후와 알림 조건은 어떻게 다르게 정의해야 하는가?
- Spring 백엔드에서 어떤 신호를 page 알림으로 올리고 어떤 신호는 ticket으로 남겨야 하는가?
- 알림을 만들 때 runbook과 첫 확인 지표를 어떻게 연결해야 하는가?
개요
장애 징후는 서비스가 나빠질 가능성을 보여 주는 신호다.
알림은 그 신호가 사람의 행동을 필요로 할 때 발생해야 한다.
모든 징후가 알림이 되면 noise가 된다.
반대로 사용자 영향이 큰 징후를 알림으로 만들지 않으면 장애 감지가 늦어진다.
목표는 “많이 울리는 시스템”이 아니라 “필요할 때 정확히 깨우는 시스템”이다.
징후 분류
장애 징후는 크게 증상, 원인 후보, 예고 신호로 나눌 수 있다.
증상: 5xx rate 증가, p95 latency 증가, 주문 성공률 감소
원인 후보: DB connection pool 포화, 외부 API timeout 증가
예고 신호: queue size 증가, error budget burn 증가Page 알림은 보통 증상이나 빠른 budget burn처럼 사용자 영향과 가까운 신호에 둔다.
원인 후보는 dashboard나 ticket 알림으로 두고 증상 알림과 연결한다.
알림으로 바꾸는 기준
알림 조건에는 threshold, duration, scope, severity, owner, runbook이 필요하다.
signal: POST /api/orders 5xx rate
threshold: > 2%
duration: 10m
scope: production, order-api
severity: page
owner: order-team
runbook: /runbook/order-api-5xxThreshold만 있고 duration이 없으면 순간 spike마다 알림이 울린다.
Owner가 없으면 알림이 떠도 누구도 책임지고 보지 않는다.
Page와 Ticket
Page는 즉시 깨워야 하는 알림이다.
Ticket은 근무 시간 안에 처리해도 되는 문제다.
page:
- 주문 생성 5xx rate > 2% for 10m
- error budget burn rate 14x for 5m
- readiness DOWN으로 production capacity 50% 감소
ticket:
- disk usage 75% and growing
- deprecated endpoint traffic remains
- non-critical batch retry 증가모든 알림을 page로 보내면 결국 중요한 page도 무시된다.
Runbook 연결
알림은 첫 행동으로 이어져야 한다.
Runbook에는 최소한 다음이 있어야 한다.
- 첫 확인 dashboard
- 관련 log query
- 관련 trace 검색 기준
- 최근 배포 확인 방법
- 임시 완화 조치
- escalation 대상
- 고객 영향 확인 기준
Runbook이 없는 알림은 실제 장애 중 담당자 기억에 의존하게 만든다.
운영 체크리스트
- 장애 징후가 증상, 원인 후보, 예고 신호로 분류되어 있는가?
- page 알림은 사용자 영향 또는 빠른 SLO burn과 연결되어 있는가?
- threshold와 duration이 함께 정의되어 있는가?
- severity와 owner가 명확한가?
- runbook과 첫 확인 dashboard가 연결되어 있는가?
- 배포나 점검 중 suppression 기준이 있는가?
- 알림 발생 후 실제 조치 결과를 회고에 남기는가?
장애 신호
- 알림은 울렸지만 담당자가 첫 확인 지표를 모른다.
- 같은 장애에서 증상 알림과 원인 후보 알림이 수십 개 동시에 울린다.
- 사용자 영향이 있는데 ticket 알림으로만 남아 대응이 늦다.
- threshold만 있고 duration이 없어 1분 spike마다 울린다.
- runbook 링크가 없거나 오래되어 현재 시스템과 맞지 않는다.
- 알림이 복구 후 자동 resolve되지 않아 상태가 혼란스럽다.
안전한 완화 조치
새 알림을 만들 때 먼저 어떤 행동을 유도할지 적는다.
행동이 없다면 dashboard나 ticket으로 충분할 수 있다.
Noise가 많은 알림은 최근 발생 사례를 보고 threshold, duration, severity를 조정한다.
중복 알림은 증상 알림을 중심으로 묶고 원인 후보는 context로 낮춘다.
장애 중에는 알림을 임의로 끄기보다 suppression 기간과 이유를 남긴다.
인프라 담당자와 공유할 자료
새 알림 제안: OrderCreateHighErrorRate
signal: POST /api/orders 5xx rate
threshold: > 2%
duration: 10m
severity: page
owner: order-team
runbook: /runbook/order-api-5xx
first dashboard: order-api overview
expected action: 최근 배포 확인, APM transaction 확인, payment/db dependency 확인알림 제안에는 “왜 울려야 하는가”와 “울리면 무엇을 할 것인가”가 같이 있어야 한다.
실전 팁
- 알림은 증상 중심으로 만들고 원인 후보는 context로 둔다.
- Threshold에는 지속 시간을 함께 둔다.
- Page와 ticket을 명확히 나눈다.
- Runbook 없는 page는 만들지 않는다.
- 알림 회고에서 noise와 missed alert를 모두 본다.
위험 신호!
- “혹시 모르니” 모든 징후를 page로 만든다.
- 알림 메시지에 service와 현재값이 없다.
- Runbook이 없는데 page로 보낸다.
- 점검 중 알림을 끄고 다시 켜는 절차가 없다.
- 알림이 실제 사용자 영향과 연결되지 않는다.
확인 질문
확인 질문
- 장애 징후와 알림의 차이는 무엇인가?
- 장애 징후는 상태가 나빠질 가능성을 보여 주는 신호이고, 알림은 사람이 지금 행동해야 할 조건이다.
- Page 알림으로 올리기 적합한 신호는 무엇인가?
- 사용자 영향이 있거나 빠르게 error budget을 소진하는 증상 기반 신호가 적합하다.
- Runbook 없는 알림이 위험한 이유는 무엇인가?
- 알림을 받은 사람이 첫 확인과 완화 조치를 기억에 의존해야 해 대응 시간이 길어지기 때문이다.