30장 세 가지 장애를 한 단계씩 좁혀 보기

이 장의 사건은 모두 가상이다. 정답을 맞히는 퀴즈보다 조사 순서를 익히는 연습으로 읽어 보자. 실제 현장에서는 여러 원인이 동시에 있을 수 있고 도구가 보여 주는 정보도 불완전하다. 그러므로 아래 결론을 다른 장애에 그대로 붙이는 대신 어떤 관찰이 후보를 줄였는지 살핀다.

사례 하나 특정 노트북에서만 사이트가 안 열린다

같은 사무실의 휴대전화와 다른 노트북에서는 자료실이 열린다. 문제의 노트북도 다른 사이트는 정상이다. 이 관찰은 사무실 전체 회선 단절 가능성을 낮춘다. 그러나 자료실의 모든 서버가 정상이라는 보장은 아니다. 장치마다 DNS 응답이나 주소 체계, 프록시, 로그인 상태가 다를 수 있다.

먼저 발생 시각과 정확한 오류를 기록한다. 인증서 경고인지 이름 조회 실패인지 연결 시간 초과인지가 다르다. 이 사례에서는 이름 조회가 실패하고 있었다고 하자. 운영체제와 브라우저가 사용하는 리졸버를 확인했더니 해당 노트북에만 오래된 VPN 설정이 남아 있다. 회사 도메인을 더 이상 접근할 수 없는 내부 리졸버로 보내고 있었다.

확인된 관리 절차에 따라 VPN 설정을 바로잡고 동일한 이름 조회와 실제 페이지 열기를 다시 시험한다. 두 결과가 모두 정상으로 돌아오면 가설을 뒷받침한다. 복구 기록에는 “DNS 문제” 한 줄 대신 어떤 정책이 어느 이름의 조회를 어디로 보냈는지 적는다. 다른 사이트가 됐다는 비교 관찰이 조사 범위를 크게 줄였다.

사례 둘 작은 페이지는 되는데 업로드가 실패한다

사용자는 로그인과 목록 조회는 되지만 큰 파일을 올리면 오류가 난다고 말한다. 모든 네트워크가 끊어진 것은 아니다. 파일 크기에 따라 경계가 있는지, 특정 형식만 실패하는지, 어느 시점에 어떤 응답이 오는지 확인한다. 애플리케이션 로그와 프록시 로그를 같은 요청 식별자로 연결하면 요청이 내부까지 왔는지도 알 수 있다.

이 사례에서는 일정 크기를 넘는 요청에 프록시가 413 응답을 반환했고 응용 서버에는 요청 기록이 없었다고 하자. 그러면 앞단의 본문 크기 제한이 주요 원인 후보가 된다. 제품 문서와 현재 설정을 확인해 서비스가 실제로 허용할 크기를 정하고, 디스크와 동시 업로드, 시간 제한의 영향도 계산한다. 제한을 무한대로 지우는 것이 해결책은 아니다.

수정 후에는 허용 크기 안의 파일이 성공하고 한도를 넘는 파일은 이해할 수 있는 오류로 거절되는지 모두 시험한다. 업로드 도중 중단했을 때 임시 파일이 남는지도 확인한다. 성공 경로 하나만 고치면 디스크 고갈이라는 다음 장애를 만들 수 있다. 크기 제한의 존재가 문제가 아니라 서비스의 약속과 제한이 서로 맞지 않았던 것이 문제다.

사례 셋 배포 뒤에 502가 간헐적으로 나온다

새 버전을 배포한 뒤 모든 요청이 아니라 일부 요청만 실패한다. 이때 브라우저 캐시부터 지우기보다 요청을 처리한 대상 서버를 나누어 본다. 실패가 특정 인스턴스에 몰린다면 공통 회선보다 그 대상의 실행 상태와 설정이 유력하다. 배포 버전, 준비 상태, 포트, 응용 로그를 비교한다.

가상의 조사에서는 두 서버 중 한 서버의 실행 포트만 새 설정으로 바뀌었고 프록시의 대상 포트는 이전 값이었다. 프로세스는 살아 있었지만 프록시는 잘못된 포트로 연결을 시도했다. 설정을 일치시키고 배포 검사를 보완한다. 단순 프로세스 상태 검사 대신 실제 입구에서 대상까지 연결되는지를 시험할 필요가 드러난다.

복구 후에는 실패한 사용자의 작업이 중복되거나 일부만 저장되지 않았는지 확인한다. 502 응답은 중간 입구가 정상적인 응답을 받지 못했다는 단서이지 업무가 전혀 실행되지 않았다는 증명은 아니다. 상태를 바꾸는 요청은 데이터 기록과 요청 식별자를 확인해야 한다. 네트워크 오류와 업무 결과의 모호함을 함께 다루어야 사건이 끝난다.

세 사건에서 공통으로 남는 습관

먼저 영향 범위를 나누었다. 한 장치인지, 큰 요청인지, 특정 서버인지 확인했다. 그다음 성공하는 비교 조건을 찾았다. 마지막으로 가설을 바꾸는 작은 관찰을 골랐다. 모든 설정을 동시에 바꾸지 않았기 때문에 어떤 조치가 결과를 바꾸었는지 설명할 수 있었다. 이것이 체계적인 진단의 핵심이다.

조사 중에는 사실과 추측을 구분해 적는다. “11시 5분, 서버 B 대상 요청에서만 실패”는 관찰이고 “서버 B의 포트 설정이 원인일 수 있음”은 가설이다. 둘을 섞으면 아직 검증하지 않은 설명이 팀의 사실로 굳어진다. 장애 때는 말이 빠르게 전달되므로 문장 앞에 관찰, 가설, 조치, 결과를 붙이는 간단한 방식도 도움이 된다.

끝내 원인을 확정하지 못한 채 서비스가 회복될 수도 있다. 그때는 모르는 부분을 남기는 것이 정직하다. 확보한 자료와 부족했던 관찰을 기록하고 다음번에 필요한 지표를 추가한다. 억지로 그럴듯한 원인을 붙이는 것보다 다음 사건에서 더 빨리 알아낼 준비를 하는 편이 낫다. 운영의 실력은 모든 질문에 즉시 답하는 능력과 같지 않다.