장애 진단 순서

장애 범위 분리

처음부터 “네트워크 탓” 또는 “코드 탓”으로 단정하지 않고, 낮은 계층의 연결성부터 애플리케이션 응답까지 같은 순서로 증거를 쌓는다.

네트워크 문제와 애플리케이션 문제의 증거

네트워크 경로
연결성 자체가 흔들림 ping, mtr, traceroute에서 유실, 지연, 경로 단절이 보인다.
영향 범위가 넓음 여러 서비스, 여러 포트, 여러 클라이언트가 동시에 실패한다.
포트 연결이 성립하지 않음 nc -z, ss, 보안그룹, 방화벽 규칙을 확인한다.
application runtime
TCP는 되지만 응답이 이상함 curl은 연결되지만 4xx, 5xx, HTTP read timeout, 잘못된 body가 나온다.
영향 범위가 좁음 특정 URL, 특정 tenant, 특정 입력에서만 실패한다.
런타임 단서가 남음 앱 로그, 프록시 로그, CPU/메모리, DB 연결 풀 상태를 확인한다.
증거는 왼쪽에서 오른쪽으로 좁혀 간다 boundary map
1 Client 같은 증상이 여러 위치에서 재현되는지 본다.
2 DNS 이름 해석이 다른 IP를 가리키는지 확인한다.
3 Route 경로 유실, 지연, 방화벽 DROP을 분리한다.
4 TCP handshake와 포트 리스너까지 확인한다.
5 HTTP 상태 코드, 헤더, body가 정상인지 본다.
6 Runtime 로그, upstream, DB, 리소스 지표로 확정한다.
1 L1/L2 NIC, 링크, ARP, 게이트웨이를 확인한다.
2 L3 IP, 게이트웨이, 라우팅, 경로 추적을 본다.
3 L4 TCP handshake, 포트, 방화벽을 확인한다.
4 L7 HTTP 상태, 헤더, body, 프록시 응답을 본다.
5 Logs / Metrics 앱 로그와 리소스 지표로 원인을 확정한다.
refused 연결은 갔지만 리스너가 없음 대상 호스트가 RST를 보냈다면 서비스 미실행 또는 포트 불일치 가능성이 크다.
timeout 응답이 돌아오지 않음 방화벽 DROP, 라우팅 문제, 과부하 등 여러 가능성이 있어 패킷과 로그를 함께 본다.
5xx 애플리케이션 또는 프록시 계층 신호 네트워크 연결 뒤의 서버, upstream, DB, 런타임 상태를 확인한다.

장애 범위 분리 핵심: 트러블슈팅은 도구를 많이 치는 일이 아니라 가설을 줄이는 일이다. 아래 계층의 연결성 증거를 먼저 확보한 뒤, 응답과 로그로 애플리케이션 원인을 추적한다.