문제점 해결
문제 해결은 문제점을 해결하는 체계적인 접근 방법입니다. 문제점 해결의 목표는 예상대로 작동하지 않는 이유와 문제점 해결 방법을 판별하는 것입니다.
문제점 해결 프로세스의 첫 번째 단계는 문제점을 완전하게 설명하는 것입니다. 문제점 설명은 기술 지원 담당자가 문제점의 원인을 찾기 위한 출발점을 아는 데 유용합니다. 이 단계에는 다음과 같은 기본 질문을 묻는 과정이 포함됩니다.
- 문제점 증상은 어떻게 나타납니까?
- 어디에서 문제점이 발생합니까?
- 언제 문제점이 발생합니까?
- 문제점이 어떤 조건에서 발생합니까?
- 문제점을 재현할 수 있습니까?
이 질문에 대해 응답하면 일반적으로 문제점을 잘 설명할 수 있게 되며 문제점 해결을 시작할 수 있습니다.
문제점 증상은 어떻게 나타납니까?
이 질문은 직접적인 질문같지만 문제점을 보다 구체적으로 설명하는 여러 개의 보다 집중적인 질문으로 분류할 수 있습니다. 예를 들면, 다음과 같습니다.
- 누가(또는 무엇이) 문제점을 보고합니까?
- 오류 코드 및 메시지는 무엇입니까?
- 어떻게 시스템에서 장애가 발생했습니까? 예를 들어, 루프, 정지, 크래쉬, 성능 저하 또는 올바르지 않은 결과가 나타납니까?
어디에서 문제점이 발생합니까?
문제점이 발생하는 위치를 항상 쉽게 파악할 수 없지만, 문제점을 해결하는 데 가장 중요한 단계입니다. 보고된 컴포넌트와 실제 실패한 컴포넌트 간에는 많은 기술적 레이어가 존재할 수 있습니다. 네트워크, 디스크 및 드라이버는 문제를 조사할 때 고려할 수 있는 몇 가지 컴포넌트에 불과합니다.
다음 질문은 문제점 레이어를 분리하기 위해 문제점이 발생한 위치에 초점을 두는 데 도움이 됩니다.
- 문제점이 특정 플랫폼 또는 운영 체제에서만 발생됩니까? 아니면 여러 플랫폼 또는 운영 체제에서 공통적으로 발생됩니까?
- 현재 환경 및 구성이 지원됩니까?
한 레이어가 문제점을 보고하는 경우, 문제점이 반드시 그 레이어에서 생성될 필요는 없습니다. 문제점이 발생한 위치 식별 시 문제점이 발생한 환경을 이해하는 과정이 포함됩니다. 운영 체제 및 버전, 해당하는 모든 소프트웨어 및 버전, 하드웨어 정보를 포함한 문제점 환경을 완벽하게 설명하십시오. 지원되는 구성인 환경에서 실행 중인지 확인하십시오. 많은 문제점이 완전히 함께 테스트하지 않았거나 함께 실행하도록 설계되지 않은 소프트웨어의 호환 불가능한 레벨로 인해 발생할 수 있습니다.
언제 문제점이 발생합니까?
특히, 문제점이 한 번만 발생되는 경우 실패를 유발하는 이벤트의 자세한 일정표를 작성합니다. 역으로 작업하면 일정표를 가장 쉽게 개발할 수 있습니다. 즉, 가능한 한 사용 가능한 로그 및 정보를 통해 오류가 보고된 시각에서 시작하여(가능한 한 정확하게, 밀리초 단위로 내려가도 좋음) 역으로 작업하십시오. 일반적으로, 진단 로그에서 발견한 최초의 의심스러운 이벤트까지만 찾으면 됩니다.
이벤트의 자세한 일정표를 알려면 다음 질문에 대답하십시오.
- 주간 또는 야간의 특정 시간에만 문제점이 발생합니까?
- 문제점이 얼마나 자주 발생합니까?
- 문제점이 보고되는 시점에 이르기까지 이벤트가 어떤 순서로 발생합니까?
- 소프트웨어 또는 하드웨어 업그레이드나 설치와 같이 환경을 변경한 후 문제점이 발생합니까?
이러한 유형의 질문에 응답하면 문제점을 조사하기 위한 참조 프레임을 갖게 됩니다.
문제점이 어떤 조건에서 발생합니까?
문제점이 발생할 당시 실행 중이던 시스템과 애플리케이션을 아는 것은 문제점 해결의 중요한 부분입니다. 환경에 대한 다음 질문을 통해 문제점의 근본 원인을 파악할 수 있습니다.
- 동일한 태스크를 수행 중일 때 항상 문제점이 발생합니까?
- 문제점이 특성 이벤트 시퀀스에 따라 발생됩니까?
- 동시에 다른 애플리케이션도 장애가 발생합니까?
이러한 유형의 질문에 응답하면 문제점이 발생하는 환경을 설명하고 모든 종속성을 상관시키는 데 도움이 될 수 있습니다. 여러 문제점이 동시에 발생할 수 있으므로 문제점을 반드시 관련시킬 필요는 없습니다.
문제점을 재현할 수 있습니까?
문제점 해결 관점에서 이상적인 문제점은 재현할 수 있는 문제점입니다. 일반적으로, 어떤 문제점을 재현시킬 수 있는 경우 사용자는 더 많은 도구 세트 또는 사용자가 조사하는 데 도움이 되는 원하는 프로시저를 갖게 됩니다. 결과적으로, 재현할 수 있는 문제점은 쉽게 디버그하고 해결할 수 있는 경우가 많습니다. 그러나 재현 가능한 문제점에도 단점은 있습니다. 문제점이 비즈니스에 미치는 영향이 큰 경우 재현되는 것을 원하지 않습니다. 가능하면, 조사 중에 보다 많은 유연성 및 제어를 제공하는 테스트 또는 개발 환경에서 문제점을 다시 작성하십시오.
- 테스트 시스템에서 문제점을 다시 작성할 수 있습니까?
- 여러 사용자 또는 애플리케이션에서 동일한 유형의 문제점이 발생합니까?
- 단일 명령, 명령 세트 또는 특정 애플리케이션을 실행하여 문제점을 다시 작성할 수 있습니까?