SRE 실무 #3 경보 설계: 증상 기반 알림과 다중 창 번 레이트
경보의 목적은 하나입니다. 사람의 개입이 필요한 문제를, 개입이 필요한 시점에, 개입할 수 있는 사람에게 알리는 것. 그런데 대부분의 조직에서 경보 채널은 아무도 안 읽는 알림의 폭포가 되어 있습니다. 이번 편은 2편에서 다룬 번 레이트를 경보로 구현하는 법과, 경보 시스템을 신뢰할 수 있는 상태로 유지하는 운영을 다룹니다.
원인이 아니라 증상에 경보를 겁니다 #
전통적 경보는 원인 후보에 걸려 있습니다. CPU 80% 초과, 디스크 90%, 프로세스 재시작. 이 방식의 문제는 두 방향 모두에서 틀린다는 것입니다.
- 오탐: CPU가 90%여도 사용자 요청이 전부 정상 처리되고 있다면 새벽에 깨울 이유가 없습니다. 배치 작업이 돌고 있을 뿐일 수도 있습니다.
- 미탐: CPU, 메모리, 디스크가 전부 정상인데 업스트림 의존성 문제로 사용자 요청이 실패하고 있다면, 원인 기반 경보는 침묵합니다.
증상 기반 경보는 사용자가 겪는 것, 즉 SLI에 겁니다. 에러율이 임계값을 넘는가, 지연 시간 SLI가 무너지는가. 원인이 무엇이든 사용자 영향이 있으면 울리고, 사용자 영향이 없으면 울리지 않습니다. 1편에서 SLI를 사용자 여정 기반으로 설계한 이유가 여기서 회수됩니다. CPU 같은 원인 지표는 경보 대상이 아니라, 경보를 받은 뒤 열어 보는 진단 대시보드의 자리로 내려갑니다.
페이지와 티켓: 응답 시간의 계약 #
모든 알림이 같은 긴급도일 수 없습니다. 두 등급으로 가릅니다.
| 등급 | 의미 | 기준 |
|---|---|---|
| 페이지(page) | 지금 사람을 깨운다 | 방치하면 수 시간 안에 SLO가 유의미하게 훼손됨 |
| 티켓(ticket) | 업무 시간에 처리한다 | 문제는 실재하지만 며칠의 여유가 있음 |
판정 질문은 하나입니다. “이 알림을 새벽 3시에 받았을 때, 지금 일어나서 할 수 있고 해야 하는 일이 있는가?” 없다면 페이지가 아닙니다. 이 기준을 통과하지 못하는 페이지가 쌓이면, 정말 중요한 페이지가 왔을 때 반응이 무뎌집니다.
다중 창 번 레이트 경보: 빠른 소진과 느린 소진을 모두 잡기 #
SLI에 경보를 건다고 할 때 가장 단순한 구현은 “최근 5분 에러율이 X%를 넘으면 알림"입니다. 이 방식은 창이 짧아서 순간 스파이크에 오탐을 내고, 낮은 강도로 오래 지속되는 문제는 놓칩니다. 검증된 해법이 다중 창(multiwindow) 번 레이트 경보입니다.
구성 원리는 이렇습니다. 28일 창, SLO 99.9% 기준으로 널리 쓰이는 조합은 다음과 같습니다.
| 목적 | 번 레이트 | 측정 창 | 의미 | 대응 |
|---|---|---|---|---|
| 빠른 소진 감지 | 14.4배 | 1시간 | 1시간 만에 28일 버짓의 약 2% 소모 | 페이지 |
| 중간 소진 감지 | 6배 | 6시간 | 6시간에 버짓의 약 5% 소모 | 페이지 |
| 느린 소진 감지 | 1배 | 3일 | 이 속도면 창 안에 버짓 전량 소진 | 티켓 |
여기에 짧은 확인 창을 조합합니다. 예를 들어 “1시간 창에서 14.4배 그리고 최근 5분 창에서도 14.4배"처럼 두 창이 동시에 조건을 만족할 때만 울리게 하면, 문제가 이미 끝났는데 긴 창의 평균 때문에 뒤늦게 울리는 잔불 경보가 사라집니다.
이 구성의 장점은 경보의 강도가 사용자 영향의 크기에 비례한다는 것입니다. 버짓을 빠르게 태우는 큰 문제는 몇 분 안에 페이지가 오고, 천천히 갉아먹는 문제는 티켓으로 쌓여 업무 시간에 처리됩니다. 어느 쪽도 놓치지 않으면서 새벽 호출은 최소화됩니다.
경보 피로: 측정하지 않으면 줄지 않습니다 #
경보 시스템은 만들 때보다 유지할 때 무너집니다. 무뎌짐은 서서히 오기 때문에, 정기적으로 숫자를 봐야 합니다.
- 주간 경보 리뷰: 지난주 울린 페이지 전부를 놓고 셋으로 분류합니다. 조치가 필요했는가(정상), 조치가 필요 없었는가(오탐, 튜닝 대상), 알림 없이 다른 경로로 발견된 사용자 영향이 있었는가(미탐, 커버리지 보강 대상).
- 오탐 경보는 그 자리에서 처분합니다. 임계값을 조정하거나, 티켓으로 강등하거나, 삭제합니다. “일단 두자"가 쌓인 것이 알림 폭포의 정체입니다.
- 페이지 건수 자체를 지표로 삼습니다. 교대 근무당 페이지가 일정 수를 넘는 상태가 지속되면, 그것은 온콜 개인의 문제가 아니라 시스템의 신뢰성 부채 또는 경보 품질 문제입니다. 이 숫자는 다음 편(온콜)에서 부담 상한으로 다시 등장합니다.
하나 더, 모든 경보에는 런북 링크를 붙입니다. 새벽에 페이지를 받은 사람이 “이 경보가 무슨 뜻이고 첫 30분에 뭘 확인해야 하는가"를 문서 없이 알아내게 만드는 것은 설계 실패입니다. 진단의 첫 단계가 막막하다면 REST API가 느릴 때: 병목을 찾는 순서 같은 진단 순서 문서가 런북의 재료가 됩니다.
정리 #
- 경보는 원인(CPU)이 아니라 증상(SLI)에 겁니다. 원인 지표는 진단 대시보드로 내려보냅니다.
- 페이지의 기준은 “지금 일어나서 해야 할 일이 있는가"입니다. 아니면 티켓입니다.
- 다중 창 번 레이트 경보(14.4배/1시간, 6배/6시간 페이지 + 1배/3일 티켓)가 오탐과 미탐을 함께 줄이는 검증된 구성입니다.
- 주간 경보 리뷰로 오탐을 그 자리에서 처분하고, 교대당 페이지 건수를 지표로 관리합니다.
- 모든 경보에 런북을 붙입니다. 다음 편은 그 페이지를 받는 사람들, 온콜 운영입니다.