18강 / 20강
장애 진단 — '사이트가 안 열려요'
5분 안에 범인을 좁히는 절단법
토요일 오후 2시. 사장님에게 전화가 옵니다. "사이트가 안 열려요."
이 한 문장에는 정보가 거의 없습니다. 안 열리는 곳이 전 세계인지 그분 폰만인지, 느린 건지 안 되는 건지, 언제부터인지 아무것도 모르죠.
초보 운영자는 여기서 아무거나 재시작합니다. 운이 좋으면 고쳐지고, 나쁘면 상황이 더 나빠집니다. 우리는 다르게 합시다.
절단법 — 아래층부터 하나씩
지금까지 배운 17강이 사실 전부 이 순간을 위한 것이었습니다. 네트워크는 층으로 쌓여 있으니, 아래층부터 정상임을 확인해 나가면 문제가 있는 층에서 반드시 멈춥니다.
1전기가 통하나
ip addr — 랜카드에 주소가 있나2길이 있나
ip route · ping 8.8.8.8 — 밖으로 나가지나3이름이 풀리나
dig mallshop.kr — 주소가 맞게 나오나4문이 열렸나
nc -zv 도메인 443 — 방화벽·NAT5누가 듣고 있나
ss -tulpn — 서비스가 떠 있나6대답을 하나
curl -I — 상태 코드가 뭔가7왜 실패했나
tail error.log — 앱·DB증상별 빠른 판정표
사실 몇 가지 증상은 거의 항상 같은 범인을 가리킵니다. 외워 두면 1분이면 끝납니다.
| 증상 | 범인 | 확인 명령 |
|---|---|---|
| IP로는 되는데 이름으로만 안 됨 | DNS | dig · cat /etc/resolv.conf |
| 같은 층은 되는데 인터넷만 안 됨 | 게이트웨이 | ip route |
| 타임아웃 (대답 없음) | 방화벽 · NAT | ufw status · 공유기 |
| Connection refused (즉시 거절) | 서비스가 안 떠 있음 | ss -tulpn · systemctl status |
| 502 | 뒷단 앱이 죽음 | systemctl status mallshop |
| 504 | 뒷단이 너무 느림 | 앱 로그 · DB 느린 쿼리 |
| 작은 것만 되고 큰 파일만 안 됨 | MTU | ip addr · 터널 구간 |
| 어제까지 되던 게 오늘 인증서 오류 | 인증서 만료 | openssl s_client |
| 일부 손님만 안 됨 | DNS 캐시 · 체인 · 지역 회선 | 여러 곳에서 테스트 |
위젯에서 장애를 만든 뒤 이 순서로 돌려 보세요.
🖥️ 내 가상 서버
브라우저 안에서 실행 (계산용)
안에서와 밖에서 — 두 관점으로 자르기
같은 명령을 서버 안과 손님 노트북에서 각각 돌려 보면 문제 구간이 순식간에 좁혀집니다.
서버 안에서 ○ · 밖에서 ×
앱은 멀쩡. 범인은 방화벽 · NAT · DNS
즉 중간 구간
즉 중간 구간
서버 안에서도 ×
범인은 nginx · 앱 · DB
즉 서버 안쪽
즉 서버 안쪽
같은 명령을 손님 관점에서. 위 셀의 결과와 비교하세요.
💻 손님 노트북
브라우저 안에서 실행 (계산용)
장애가 끝난 뒤 — 사후 기록
불이 꺼지면 30분만 투자해 이 네 줄을 남기세요. 다음 사고를 막는 가장 싼 방법입니다.
- 언제부터 언제까지 — 실제 영향 시간
- 무엇이 원인이었나 — 사람이 아니라 구조를 적으세요
- 어떻게 알았나 — 손님 신고였다면 감시가 부족한 것입니다
- 다음에 막으려면 — 알림 추가? 점검 항목 추가? 자동화?
🤔 확인 문제
바깥에서는 타임아웃인데 서버 안에서
curl http://localhost 는 200이 나옵니다. 범인 후보는?해설 안에서 정상이라는 것은 nginx·앱·DB가 모두 멀쩡하다는 뜻입니다. 밖에서만 안 된다면 범인은 중간 구간 — 방화벽·NAT·DNS 중 하나예요.
🤔 확인 문제
장애 대응 중 가장 피해야 할 행동은?
해설 동시에 여러 개를 바꾸면 고쳐져도 무엇이 고쳤는지 모르고, 되돌리기도 어렵습니다. 한 번에 하나, 그리고 기록 — 이것이 장애 대응의 철칙이에요.