작은 상태 페이지를 만들고 알림 기준을 줄인 회고

처음 만든 화면

서버가 살아 있는지 보여 주는 상태 페이지를 하나 붙였다. 처음에는 /health 응답만 초록색이면 충분하다고 생각했다. 그런데 막상 써 보니 초록색 화면보다 더 중요한 것은 "언제 나에게 알려 줄 것인가"였다.

처음 설정은 너무 예민했다. 한 번 요청이 실패하면 바로 알림을 보냈고, 새벽에 네트워크가 잠깐 흔들릴 때마다 메시지가 쌓였다. 실제 장애는 아닌데 확인하느라 피곤해졌다.

알림 조건을 바꾼 이유

내가 겪은 문제는 서버 다운보다 짧은 타임아웃이 많았다. 그래서 기준을 이렇게 바꿨다.

type CheckResult = {
  ok: boolean
  latencyMs: number
  checkedAt: string
}

function shouldNotify(results: CheckResult[]) {
  const recent = results.slice(-3)
  return recent.length === 3 && recent.every((result) => !result.ok)
}

한 번 실패는 기록만 남기고, 연속 실패일 때만 알림을 보내도록 했다. 대신 복구 알림은 따로 두었다. 장애가 끝났는지 모르면 계속 대시보드를 새로고침하게 되기 때문이다.

화면에는 적게 보여 주기

상태 페이지에 모든 로그를 보여 주면 멋있어 보이지만, 실제로는 읽기 어려웠다. 지금은 세 가지 정도만 노출한다.

• 현재 상태
• 마지막 성공 시각
• 최근 실패가 연속으로 몇 번 있었는지

운영자는 로그를 보면 되고, 방문자는 서비스가 정상인지 정도만 알면 된다.

배포하면서 남긴 명령어

문제가 생겼을 때 바로 확인하려고 서버에 아래 명령어를 메모해 두었다.

curl -i https://example.com/health
journalctl -u my-app.service -n 80 --no-pager

curl로 외부에서 보이는 응답을 먼저 보고, 그다음 서비스 로그를 확인하는 순서가 편했다.

회고

상태 페이지를 만든 뒤 가장 크게 바뀐 점은 장애를 더 빨리 아는 것이 아니라, 별일 아닌 신호를 덜 보게 된 것이다. 알림은 많을수록 안전한 게 아니라, 내가 실제로 행동할 수 있을 때만 오는 편이 낫다.