현장 노트 문제가 생겼을 때 펼치는 순서

이 노트는 급한 상황에서 책 전체를 다시 읽지 않아도 조사 순서를 잡도록 만든 참고 자료다. 운영체제의 설정을 바꾸거나 다른 사람의 시스템을 검사하는 지침이 아니다. 자신의 장치와 허가받은 환경에서 먼저 상태를 읽고, 변경이 필요하면 담당 절차를 따른다. 복구가 급할수록 확인 대상과 영향 범위를 짧게라도 기록하자.

첫 문장에 넣을 다섯 가지

무엇이 안 되는지, 언제 시작했는지, 누구에게 영향을 주는지, 마지막으로 정상이었던 때는 언제인지, 최근 무엇을 바꾸었는지 적는다. “인터넷 오류”보다 “오늘 10시 이후 사무실 노트북 두 대에서 자료실 검색만 시간 초과”가 좋은 출발점이다. 사용자의 표현을 무시하지 않되 기술적으로 확인한 사실과 아직 확인하지 않은 추측을 구분한다.

민감한 자료를 포함하지 않는 범위에서 정확한 오류 문구와 시각을 보존한다. 스크린샷에는 계정 이름, 내부 주소, 개인 문서, 토큰이 보일 수 있다. 공유하기 전에 가리고 원본은 허가된 위치에 보관한다. 비밀번호 입력 화면을 촬영하거나 인증 헤더 전체를 붙여 넣는 방식으로 진단 자료를 모으지 않는다.

장치의 현재 연결부터

유선 또는 무선 연결이 실제로 활성화되어 있는지 본다. 여러 인터페이스와 VPN이 있으면 어느 경로가 사용되는지 확인한다. 주소, 접두사, 게이트웨이, DNS 설정을 함께 읽는다. 주소만 있다고 인터넷 연결이 정상인 것은 아니다. 반대로 특정 서비스만 실패한다면 모든 로컬 설정을 지우는 작업은 너무 넓은 조치일 수 있다.

Windows에서 ipconfig /all과 route print는 현재 설정과 경로를 읽는 데 사용할 수 있다. 리눅스에서는 ip address와 ip route가 대응하는 관찰을 돕는다. 출력에는 장치와 내부 네트워크 정보가 있으므로 외부 게시판에 전체를 올리지 않는다. 이 단계의 목적은 명령을 많이 실행하는 것이 아니라 실제 연결 환경을 한 장으로 정리하는 것이다.

Read-only observation examples

Windows:
  ipconfig /all
  route print

Linux:
  ip address
  ip route

Record, without publishing private details:
  active interface
  address and prefix
  default route
  resolver configuration
  VPN or proxy status

이름과 연결을 분리한다

도메인 이름이 어떤 주소로 해석되는지 확인한다. A와 AAAA가 모두 있다면 두 주소 체계를 구분한다. 사내 이름에는 내부 DNS가 필요할 수 있으므로 임의의 공개 리졸버로 바꾸기 전에 정책을 확인한다. 브라우저와 운영체제의 DNS 경로가 다를 수 있다는 점도 기억한다.

HTTPS 서비스의 주소를 IP로 바꾸어 접속하는 시험은 이름 검증과 가상 호스트 처리가 달라질 수 있다. IP 접속이 실패했다고 DNS 문제라고 결론내리지 말자. 진단 도구의 이름과 주소 분리 기능을 쓸 때도 정확한 의미를 알아야 한다. 입문 단계에서는 원래 이름을 유지한 요청의 오류 종류와 DNS 결과를 따로 기록하는 것만으로도 충분히 도움이 된다.

응답이 오면 그 의미를 읽는다

HTTP 상태 코드가 왔다면 어떤 서버 또는 중간 장비가 응답한 것이다. 401과 403, 404, 429, 502, 503, 504는 서로 다른 단서다. 401은 인증과 관련된 응답이고 403은 요청을 거부했다는 의미로 사용된다. 429는 요청 속도 제한과 관련된다. 실제 원인을 확인하려면 응답과 서버 기록, 서비스의 구현을 함께 살펴야 한다.

502나 504가 보이면 입구와 내부 대상 사이의 연결, 응답, 시간 제한을 확인한다. 그러나 그 코드만으로 업무가 전혀 실행되지 않았다고 판단하지 않는다. 주문이나 결제 같은 상태 변경은 요청 식별자로 실제 결과를 조회한다. 실패 화면 뒤의 데이터 상태를 확인해야 사용자의 재시도가 중복 결과를 만들지 않는다.

비교할 대상을 하나 고른다

같은 장치에서 다른 네트워크, 같은 네트워크에서 다른 장치, 같은 서비스의 다른 기능처럼 비교 조건을 고른다. 한 번에 하나의 차이만 두는 것이 이상적이다. 다만 업무용 장치를 임의의 네트워크로 옮기거나 보안 정책을 우회하지 않는다. 허용된 범위에서 비교할 수 없다면 그 제한도 조사 기록에 남긴다.

비교 결과를 원인으로 착각하지 않는다. 다른 브라우저에서 성공했다고 첫 브라우저의 프로그램 파일이 망가졌다는 뜻은 아니다. 캐시와 쿠키, 확장 기능, DNS, 프록시, 기존 연결의 차이가 있을 수 있다. 조건 차이를 구체적으로 적으면 재설치 같은 큰 조치보다 좁은 실험을 고를 수 있다.

변경을 해야 할 때

변경 전 값을 보존하고 대상과 범위를 확인한다. 예상 결과와 실패 시 되돌릴 방법, 검증 방법을 적는다. 원격 연결을 끊을 수 있는 네트워크와 방화벽 변경은 별도의 복구 경로가 필요하다. 다른 팀의 설정을 허가 없이 수정하지 않는다. 진단할 권한과 변경할 권한이 항상 같은 것은 아니다.

변경 후에는 원래 실패했던 행동과 정상이어야 하는 다른 행동을 함께 시험한다. DNS를 고친 뒤 웹은 되지만 메일이 안 될 수도 있고 업로드 제한을 늘린 뒤 디스크가 빠르게 찰 수도 있다. 직접 목표와 주변 영향을 구분해 확인한다. 사용자에게는 무엇이 복구되었고 무엇이 아직 조사 중인지 정확하게 알린다.

다음 담당자에게 넘길 기록

아래 틀은 그대로 복사해 사용할 수 있는 간단한 진단 기록이다. 비밀과 개인 정보는 적지 않고 관련 자료의 안전한 위치만 연결한다. 추측을 확정 원인 칸에 넣지 않는다. 담당자가 바뀌어도 이미 한 검사를 처음부터 반복하지 않도록 만드는 것이 목적이다.

Incident note

Observed at:
Affected function:
Affected scope:
Last known good state:
Recent approved changes:

Confirmed observations:
1.
2.

Current hypotheses:
1.

Checks already completed:
1. Question / method / result / time

Changes made:
1. Target / old value reference / new value / owner

Recovery verification:
Rollback path:
Remaining uncertainty:
Next owner and next check:

기록이 길어질수록 중요한 정보가 묻힐 수 있다. 맨 위에는 현재 영향과 다음 행동을 짧게 두고 자세한 자료는 아래에 연결한다. 같은 실패가 계속된다는 사실만 반복해서 알리기보다 가설이 달라졌거나 복구됐거나 도움이 필요한 순간을 명확히 전달한다. 기술적인 문제를 해결하는 동안 사람들의 판단도 함께 관리해야 한다.