종합 트리아지: 결제 API 장애

목표

세 가지 결함이 겹친 장애를 계층별로 좁혀 원인을 특정하고, 고치고, 정해진 형식의 사후 보고서를 남깁니다. 이 코스에서 배운 모든 도구를 한 번에 씁니다.

왜 중요한가

실제 장애는 원인이 하나가 아닌 경우가 많습니다. 하나를 고치고 "안 낫네" 하고 방향을 바꾸면 이미 고친 것까지 의심하게 됩니다. 그래서 각 층을 끝까지 확인하고 발견한 것을 전부 적어 두는 편이 결국 빠릅니다. 그리고 고친 뒤에는 실패를 재현했던 그 명령으로 성공을 확인해야 조치가 끝납니다.

단계

1. bash /opt/fixtures/nt-triage/start-incident.sh 로 장애 상황을 재현하고, /opt/fixtures/nt-triage/incident.md 를 읽으세요. /root/triage 디렉터리를 만드세요.
2. 자기 인터페이스 IP 로 3회 ping 한 결과를 /root/triage/l3.txt 로 저장하세요. 손실이 0% 여야 합니다.
3. 자기 인터페이스 IP 의 9101 과 9102 포트를 각각 두드려 보고, 결과를 /root/triage/l4.txt 에 두 줄로 적으세요.
9101=<open|refused|timeout> / 9102=<open|refused|timeout>
4. pay-api.labhub.local 의 이름 해석 결과를 확인하고, /root/triage/name.txt 에 두 줄로 적으세요.
RESOLVED=<getent 가 돌려준 IP> / SOURCE=<그 값이 적혀 있는 파일의 절대 경로>
5. 9101 서비스의 리슨 주소를 확인해 /root/triage/bind.txt 에 한 줄로 적으세요. BIND=<리슨 주소:포트> 형식입니다. (예: BIND=127.0.0.1:9101)
6. 접근 가능한 쪽(9102)으로 /ok 를 요청해 상태 코드를 /root/triage/http.txt 에 code=<코드> 한 줄로 적으세요.
7. 두 가지를 고치세요.

• /etc/hosts 의 pay-api.labhub.local 항목을 이 서버의 실제 인터페이스 IP 로 바로잡으세요.
• 9101 서비스를 0.0.0.0 에서 듣도록 다시 띄우세요. (기존 프로세스는 종료)

그리고 curl -s http://pay-api.labhub.local:9101/ok 가 성공하는 것을 확인해 그 출력을 /root/triage/fixed.txt 로 저장하세요.
8. /root/triage/report.txt 를 다음 6줄로 만드세요.
SYMPTOM=remote-timeout / LAYER1=name / LAYER2=bind / CAUSE_NAME=<원래 hosts 에 적혀 있던 잘못된 IP> / CAUSE_BIND=127.0.0.1 / FIXED=yes

참고

• 서비스를 다시 띄울 때는 pkill -f 'server.py 9101' 로 먼저 정리하고, nohup python3 /opt/fixtures/nt-http/server.py 9101 0.0.0.0 & 로 올립니다.
• 이름 해석 결과는 getent hosts, 실제 리슨 주소는 ss -ltnp 로 확인합니다.
• 흔한 실수 1: 3번에서 루프백으로 시험해 두 포트가 모두 open 으로 보이는 경우. 반드시 인터페이스 IP 로 하세요.
• 흔한 실수 2: 7번에서 hosts 만 고치고 바인딩을 그대로 두면 여전히 실패합니다. 원인은 두 개입니다.

단계 8개

1. 장애 상황 재현
2. L3 도달성 확인
3. 포트별 결과 판정
4. 이름 해석 문제 특정
5. 바인딩 문제 특정
6. 애플리케이션 계층 확인
7. 고치고 검증
8. 사후 보고서