해결되는 네트워크 장애 신고 쓰는 법

네트워크 관련 지원 요청은 대부분 누군가 실제 문제를 들여다보기 전에 세 번쯤 오갑니다. 언제부터인가요, 나만 그런가요, 뭘 해보셨나요. 첫 메시지에서 이걸 다 답하면 첫 답장이 해결책이 될 수 있습니다.

쓰기 전에

범위부터 파악하세요. 무엇을 쓸지만큼이나 누구에게 보낼지가 달라집니다.

• 한 사이트인가, 전부인가? 한 사이트만 느리거나 안 되고 나머지는 멀쩡하면 그 사이트 문제입니다. 통신사가 아니라 그쪽에 신고하세요.
• 한 기기인가, 전부인가? 휴대폰은 되는데 노트북만 안 되면, 네트워크는 대개 멀쩡하고 노트북이 문제입니다.
• 와이파이만인가, 유선도인가? 랜선으로 해결되면 건물 안의 무선 문제입니다.

연결이 느릴 때 점검하는 순서에 이 과정이 제대로 정리돼 있습니다. 거기서 5분 쓰면 신고가 처음부터 맞는 사람에게 가는 경우가 많습니다.

담아야 할 것

1. 기대한 것과 실제로 일어난 것. “페이지가 안 떠요”보다 “github.com이 30초쯤 뒤 ERR_CONNECTION_TIMED_OUT을 보여주고, 다른 사이트는 정상”이 훨씬 쓸모 있습니다. 오류 메시지는 그대로 옮기거나 스크린샷을 붙이세요.
2. 언제 시작됐고, 계속 그런지. 정확한 시각이 있으면 상대가 로그에서 해당 기록을 찾을 수 있습니다. “매일 저녁 8시쯤부터”는 혼잡을, “화요일 점검 이후”는 변경 작업을 가리킵니다.
3. 그 밖에 영향받는 것. 다른 기기, 건물의 다른 사람, 다른 네트워크 — 모바일 데이터로는 되나요?
4. 공인 IP 주소와 통신사. 상대가 시스템에서 내 회선을 찾는 데 필요할 수 있습니다. 네트워크 리포트가 브라우저, 연결 종류, 지연 시간과 함께 모아주고, 공개된 곳에 올릴 때는 주소를 가려줍니다.
5. 근거. 짧은 명령어 결과 두세 개가 설명 한 문단보다 낫습니다.
   • 공유기와 1.1.1.1로 보낸 ping. 로컬 장애인지 더 넓은 장애인지 가려줍니다.
   • 안 되는 이름의 DNS 조회. 이름 문제인지 연결 문제인지 가려줍니다.
   • 안 되는 목적지 그리고 되는 목적지 하나로 보낸 traceroute나 mtr, 두세 번씩. 한 번짜리 추적은 증명하는 게 거의 없습니다. 이유는 traceroute 결과 읽는 법에 있습니다.
6. 이미 해본 것. 공유기 재시작, 다른 DNS 서버, 랜선 연결. 같은 걸 다시 시키지 않게 해줍니다.

양식

문제:       <무엇이 안 되는지, 오류 메시지 그대로>
기대:       <원래 어떻게 됐어야 하는지>
시작:       <시작된 날짜와 시각>  상시 / 간헐: <어느 쪽>
영향 범위:  <이 기기만 / 모든 기기 / 이 네트워크의 모든 사람>
            <모바일 데이터에서는: 됨 / 안 됨>
네트워크:   <통신사>, 공인 IP <주소 또는 "리포트 첨부">
해본 것:    <공유기 재시작, 다른 DNS, 랜선, 다른 브라우저...>

근거:
  ping <공유기>      -> <손실 %, 평균 시간>
  ping 1.1.1.1       -> <손실 %, 평균 시간>
  DNS 조회 <이름>    -> <응답 또는 오류>
  안 되는 목적지 traceroute(3회)와 되는 목적지 1회: 첨부

공개된 곳에 올리기 전에

비공개 티켓이 아니라 게시판에 묻는 거라면, 내 네트워크를 특정하거나 접근 권한을 주는 건 전부 지우세요.

• 공인 IP 주소 (네트워크 리포트가 가려줍니다),
• 네트워크 구조를 드러내는 내부 호스트 이름과 주소,
• 비밀번호, 토큰, API 키처럼 보이는 모든 것. 붙여넣은 로그에 생각보다 자주 섞여 있습니다.

누구에게 보내나

• 특정 웹사이트나 서비스만 이상함 — 그 사이트의 고객지원이나 상태 페이지.
• 집 인터넷 — 통신사.
• 회사 인터넷 — 사내 IT팀. 나는 못 보는 로그를 볼 수 있습니다.
• 메일이 반송되거나 스팸함으로 감 — 메일을 보내는 서비스. 먼저 SPF·DKIM·DMARC 검사로 DNS 레코드부터 확인하세요.