総合トリアージ: 決済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 만 고치고 바인딩을 그대로 두면 여전히 실패합니다. 원인은 두 개입니다.

장애 상황 재현

bash /opt/fixtures/nt-triage/start-incident.sh 로 장애 상황을 재현하고, /opt/fixtures/nt-triage/incident.md 를 읽으세요. /root/triage 디렉터리를 만드세요.

픽스처의 시작 스크립트를 실행하면 상황이 만들어집니다. 신고서도 함께 읽으세요.

L3 도달성 확인

자기 인터페이스 IP 로 3회 ping 한 결과를 /root/triage/l3.txt 로 저장하세요. 손실이 0% 여야 합니다.

이름이 아니라 IP 로 확인해야 이름 문제와 섞이지 않습니다. 자기 인터페이스 주소를 쓰세요.

포트별 결과 판정

자기 인터페이스 IP 의 9101 과 9102 포트를 각각 두드려 보고, 결과를 /root/triage/l4.txt 에 두 줄로 적으세요. 9101=<open|refused|timeout> / 9102=<open|refused|timeout>

두 포트의 결과가 다릅니다. refused 와 timeout 과 open 을 정확히 구분해 적으세요.

이름 해석 문제 특정

pay-api.labhub.local 의 이름 해석 결과를 확인하고, /root/triage/name.txt 에 두 줄로 적으세요. RESOLVED=<getent 가 돌려준 IP> / SOURCE=<그 값이 적혀 있는 파일의 절대 경로>

getent 가 돌려주는 IP 와 이 서버의 실제 IP 를 비교하세요. 어디에 그 값이 적혀 있는지도 찾아야 합니다.

바인딩 문제 특정

9101 서비스의 리슨 주소를 확인해 /root/triage/bind.txt 에 한 줄로 적으세요. BIND=<리슨 주소:포트> 형식입니다. (예: BIND=127.0.0.1:9101)

ss 출력의 Local Address 열이 답입니다. 두 서비스 중 어느 쪽이 문제인지 가리세요.

애플리케이션 계층 확인

접근 가능한 쪽(9102)으로 /ok 를 요청해 상태 코드를 /root/triage/http.txt 에 code=<코드> 한 줄로 적으세요.

접근 가능한 쪽으로 먼저 확인해 서비스 자체는 정상임을 증명하세요.

고치고 검증

두 가지를 고치세요.

• /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 로 저장하세요.

두 가지를 모두 고쳐야 합니다. 고친 뒤에는 반드시 바깥 주소로 다시 확인하세요.

사후 보고서

/root/triage/report.txt 를 다음 6줄로 만드세요. SYMPTOM=remote-timeout / LAYER1=name / LAYER2=bind / CAUSE_NAME=<원래 hosts 에 적혀 있던 잘못된 IP> / CAUSE_BIND=127.0.0.1 / FIXED=yes

형식이 정해져 있습니다. 각 값은 앞 단계에서 실제로 확인한 것이어야 합니다.