목차
로그·메트릭·트레이스를 갖췄어도, 사람이 24시간 대시보드를 볼 수는 없다. 언제 부를지를 정하는 게 알림이고, 그 앞에 살았는지부터 아는 게 헬스체크다.
살았는지 죽었는지부터
가장 기본 신호는 “이 서버가 지금 살아 있나”다. 그래서 서버는 헬스체크 엔드포인트(/health)를 열어두고, 바깥에서 주기적으로 찔러 응답을 본다.
이 발상은 새 게 아니다 - 로드 밸런서가 죽은 서버를 골라내는 방식이 정확히 이 헬스체크다. 여기서 더할 관점은 하나 - 헬스체크도 관측의 한 신호라는 것이다. “무엇을 보고 살았다고 할지”를 어떻게 잡느냐가 다음 갈림이다.
살아있음과 준비됨은 다르다
헬스체크는 사실 두 가지 다른 질문이다.
- 살아있음(liveness) - 프로세스가 죽지 않고 돌고 있나. 실패하면 답은 재시작.
- 준비됨(readiness) - 지금 요청을 받아도 되나. 부팅 중이거나 DB 연결이 아직이면 살아는 있어도 준비는 안 됐다. 실패하면 답은 트래픽 빼기(재시작이 아니라).
둘을 안 나누면 사고가 난다 - 부팅 중인 서버에 트래픽을 보내 에러를 내거나, 잠깐 느린 서버를 죽었다고 재시작해 오히려 흔든다. 쿠버네티스가 이 둘을 나눠 설정하는 것도 그래서다.
알림: 사람을 언제 부르나
헬스체크가 “살았나”라면, 알림은 “사람을 깨울 만한가”다. 메트릭이 정한 선을 넘으면(에러율 급증, p99 폭등) 사람을 부른다.
기준은 하나로 요약된다 - 새벽 3시에 깨울 값어치가 있나. 값어치 없는 걸로 깨우면 다음의 알림 피로로 이어지고, 정작 중요한 걸 놓치게 된다. 그래서 “무엇에 알림을 걸까”가 신중해야 한다.
증상에 알리고 원인은 대시보드에서
여기가 알림 설계의 핵심이다. 사용자가 겪는 증상에 알리고, 원인 지표에는 알리지 않는다.
알림 ○ 사용자 증상: 에러율 급증 · 응답 p99 폭등 · 주문 실패
알림 ✕ 원인 후보: CPU 90% · 메모리 80% · 큐 길이 증가CPU가 90%여도 사용자가 멀쩡하면 급한 게 아니다 - 그건 대시보드에 두고 조사할 때 본다. 원인 지표마다 알림을 걸면 한 번 터질 때 수십 개가 동시에 울려(CPU·메모리·큐…) 정작 무엇이 문제인지 더 안 보인다. 증상 몇 개에만 알리면, 울렸을 때 “사용자가 실제로 아프다”가 확실해진다.
SLI·SLO·에러 예산
“증상”을 숫자로 정하는 틀이 이 셋이다.
- SLI(지표) - 사용자 경험을 재는 수. 예: 성공한 요청의 비율.
- SLO(목표) - 그 지표의 목표치. 예: “한 달 성공률 99.9%.”
- 에러 예산 -
100% - SLO. 99.9%가 목표면 0.1%까지는 실패해도 된다는 허용량이다.
에러 예산이 관점을 바꾼다. “장애 0”이 목표가 아니라 **“예산 안에서 실패는 정상”**이다. 예산이 남으면 과감히 배포하고, 예산을 다 쓰면 안정에 집중한다. 알림도 여기 건다 - 예산을 너무 빨리 태우는 속도에 알리면, 사소한 순간 오류엔 안 깨고 진짜 위험만 잡는다.
알림 피로: 너무 많으면 아무도 안 본다
알림의 가장 흔한 실패는 부족이 아니라 과잉이다. 안 급한 알림이 쌓이면 사람은 곧 무시하는 법을 배운다(늑대소년). 그러다 진짜가 그 사이에 묻힌다.
그래서 알림을 줄이는 게 실력이다.
- 사용자 영향이 없는 알림은 끄거나 대시보드로 내린다.
- 잠깐 튀고 마는 값은 잠시 지속될 때만 울리게 한다(순간 스파이크 무시).
- 울린 알림마다 “이게 정말 필요했나”를 되묻고 가지치기한다.
실무에서: 온콜과 런북
- 온콜(on-call) - 알림을 받을 담당자를 정해 돌린다. 알림은 대시보드가 아니라 사람에게 닿아야 뜻이 있다.
- 런북(runbook) - 알림마다 “이게 울리면 무엇을 확인하고 어떻게 대응하나”를 적어둔다. 다음 행동이 없는 알림은 소음이다.
- 회고 - 사고 뒤엔 “왜 늦게 알았나, 어떤 알림이 없었나”를 돌아봐 알림을 고친다.
정리
- 헬스체크는 “살았나”를 본다 - 살아있음(실패 시 재시작)과 준비됨(실패 시 트래픽 빼기)은 다르다.
- 알림은 증상에 걸고 원인은 대시보드에 둔다 - 원인마다 걸면 한 번에 수십 개가 울려 더 안 보인다.
- SLO와 에러 예산으로 “허용되는 실패”를 정하고, 예산을 빨리 태우는 위험에 알린다.
- 알림 피로를 막는 게 실력 - 줄이고, 각 알림에 **다음 행동(런북)**을 붙인다.
다음 글은 여기까지의 세 기둥을 하나로 잇는 실무, 관측가능성의 완성형으로 간다.