감시가 30분마다 장애라고 알렸는데, HTTP 404 는 주소 이사였습니다

배포는 낮에 조용히 나갔고, 첫 알림은 다섯 시간 뒤에 왔습니다. '아직 내려가 있습니다 / 화면 — HTTP 404'. 그 뒤로 30분마다 같은 알림이 반복됐습니다. 저는 서버로 갔습니다.

서비스는 처음부터 정상이었습니다. 기계에 직접 들어가 확인한 값은 넷이었습니다. 감시가 보던 루트 경로만 404 였고, 실제 화면 주소는 200, API 헬스는 200, 밖에서 들어오는 공개 주소도 200 이었습니다. 장애는 없었고 감시가 옛 주소를 보고 있었습니다.

알림은 멈췄다고 말했고, 틀린 것은 감시였습니다

상시 켜 둔 기계 한 대에서 사내 문서 검색 플랫폼이 돌고 있습니다. 감시 스크립트가 대상 8개(문서 엔진·API·화면·수집·색인·백업·외부 세션·디스크)를 주기로 찍어 메신저로 알립니다. 판정 규칙은 단순합니다. 2회 연속 실패면 '멈춤', 멈춘 것으로 판정된 동안에는 30분마다 다시 알리고, 살아나면 복구 알림을 보냅니다.

그날 낮에 이 플랫폼을 바깥에 열면서 운영 빌드의 화면을 하위 경로 아래로 옮기는 배포가 나갔습니다. 감시 스크립트의 화면 확인 주소는 루트에 그대로 남아 있었습니다. 루트는 더 이상 화면을 내주지 않으니 404 를 돌려줬고, 판정 규칙은 2xx·3xx 가 아닌 모든 응답을 멈춤으로 접습니다.

문구 안에 404 라는 숫자는 있었습니다. 그런데 앞에 '아직 내려가 있습니다'가 붙어 있어서 저는 그 숫자를 읽지 않고 문장을 읽었습니다. **서버가 안 떠 있다는 뜻으로 받아들이고 서버 로그와 프로세스 목록을 뒤지는 데 30분을 썼습니다.** 정작 볼 곳은 감시 스크립트가 들고 있던 대상 주소 한 줄이었습니다.

고치는 데 20분, 엉뚱한 곳을 보는 데 30분

1차 수정은 확인 주소 한 줄이었습니다. 20분이 들었습니다. 이 감시 스크립트는 설정을 60초마다 다시 읽는 구조라, 재시작 없이 다음 회차에 화면 항목이 정상으로 돌아왔고 상태 파일도 따라서 되돌아갔습니다. 고치는 비용보다 어디를 고쳐야 하는지 찾는 비용이 비쌌습니다.

다만 원인은 남겼습니다. 판정 규칙이 그대로라서 경로를 바꾸는 배포가 또 나가면 같은 오탐이 다시 납니다. 그런데 404 를 멈춤에서 빼면 라우팅이 실제로 깨진 사고를 놓칩니다. 그래서 '404 와 연결거부를 가르는 판정'은 어떻게 할지 정하지 못했다고 적어 두고 넘겼습니다.

등급을 만들 것인가, 문구를 나눌 것인가

그 항목은 같은 날 다시 올라왔고, 선택지는 둘이었습니다.

둘째 줄(판정은 두고 문구만 나눈다)을 골랐습니다. 첫째 줄이 정확하다는 것은 분명한데, 이 감시에서 가장 손대기 싫은 부분이 상태머신이고 그걸 등급마다 다시 세우는 비용과 회귀 위험이 얻는 것보다 컸습니다. **제가 그 30분을 잃은 이유는 심각도를 잘못 알았기 때문이 아니라 어디를 봐야 하는지를 몰랐기 때문입니다.** 그건 문구가 정하는 일입니다.

판정은 그대로 두고 문구만 세 갈래로 갈랐습니다

응답을 세 갈래로 보고 서로 다른 문장을 내게 했습니다.

응답 없음(상태코드 000 이나 빈 값) → '무응답 — 서버가 안 떴거나 포트가 닫혔다'

404 → 'HTTP 404 — 주소가 바뀌었을 수 있다(이 감시의 대상 주소를 본다)'

그 밖의 4xx → '서버는 떠 있다. 인증·권한을 본다'

판정은 셋 다 멈춤으로 그대로 뒀습니다. 상태머신도, 대상 목록 구조도 건드리지 않았습니다. 15분이 들었습니다.

문구를 고친 뒤에 '갈렸겠지'로 끝내지 않고 세 갈래를 실제로 돌려 봤습니다. 없는 경로로 404 하나, 닫아 둔 포트로 응답 없음 하나, 정상 주소로 200 하나. 서로 다른 문구가 나오는 것까지 확인했고, 배포 뒤 감시 대상 8개는 전부 정상입니다. **제가 검증한 것은 여기까지입니다.** 다음 오탐에서 서버를 뒤지는 시간이 줄 것으로 보지만, 그건 아직 잰 값이 아니라 예상입니다. 다음에 같은 알림이 왔을 때 몇 분이 걸리는지를 재야 알 수 있습니다.

거짓 실패는 거짓 통과보다 비쌉니다

거짓 통과는 사고 한 번을 놓칩니다. 거짓 실패는 성격이 다릅니다. 같은 알림이 반복되면 사람이 그 알림 채널을 꺼 버리고, 그 뒤에 오는 진짜 알림을 사람이 열지 않습니다. 사고 한 번이 아니라 그다음 사고 전부를 놓치는 쪽입니다.

이번 오탐의 반복은 하루치에서 끝났습니다. 그날 안에 주소를 고쳤기 때문입니다. 같은 30분 재알림 규칙이 사람 손으로 갱신하는 항목에 붙으면 이야기가 달라집니다. 같은 날 이 감시에 하루 한 번 예고를 보내는 항목을 하나 더 붙였는데, **거기에는 30분 재알림 규칙을 일부러 쓰지 않았습니다.** 갱신이 사람 손이라 이틀만 밀리면 96번이 울리고, 그쯤이면 사람이 알림을 끕니다. 판단의 축은 이번 오탐과 같습니다.

감시가 거짓으로 통과를 말한 쪽도 같은 자리에서 났습니다. 배포 관문이 통과한 대상이 새 프로세스가 아니라 옛 프로세스였던 적이 있습니다.

아직 안 고친 것

남은 것도 그대로 적어 둡니다. 등급 판정은 여전히 없습니다. 문구는 '주소가 바뀌었을 수 있다'라고 가능성만 말하고, 라우팅이 실제로 깨진 404 인지 감시 주소가 낡은 404 인지는 사람이 가립니다. 이 처방은 판정을 개선하지 않았습니다.

더 근본인 쪽도 남았습니다. 주소를 바꾸는 배포는 감시 대상 주소도 같이 바꿔야 하는데, 그 연결이 코드에 없습니다. 지금은 사람 기억에 걸려 있고, 기억은 배포한 날 저녁이면 없습니다. 이번에도 다섯 시간 뒤 알림을 보고서야 알았습니다. 문구 분기는 그때의 손실을 줄이는 완화책이고, 연결을 만드는 일은 아직 처방이 없습니다.

살아있냐만 묻는 감시가 무엇을 놓치는지는 전에 한 번 겪었습니다. 응답은 200 이었는데 안에서 일이 17시간 30분 멈춰 있었습니다.

알림 문구를 점검할 때 보는 것

판정에 쓴 정보가 문구에 남아 있는지 — 404 인지 응답 없음인지를 알고 있었는데 한 덩어리로 접었다면 그게 손실입니다

문구가 받는 사람의 첫 행동을 지정하는지 — '내려가 있습니다'는 서버를 보게 하고, '주소가 바뀌었을 수 있다'는 감시 설정을 보게 합니다

같은 알림이 며칠 반복될 수 있는 항목인지 — 갱신이 사람 손인 항목에 재알림 규칙을 걸면 알림 자체가 꺼집니다

문구를 고쳤으면 문구도 돌려 봤는지 — 분기마다 한 번씩 실제로 내보내 서로 다른 문장이 나오는 것을 봅니다

분기가 몇 갈래인지 — 세 갈래까지가 한눈에 들어왔고, 그 이상은 읽히지 않을 것으로 봅니다

이 처방은 받는 사람이 곧 고치는 사람인 소규모 운영에서 값이 가장 큽니다. 수신자가 여럿이고 교대로 받는 조직이라면 어디를 볼지가 사람마다 다르고, 그 일은 문구가 아니라 런북과 심각도 라우팅이 합니다. 그래도 판정에 쓴 정보를 문구에서 버리지 않는다는 부분은 조직 크기와 무관하게 남습니다.