문제점 해결 프로세스의 처음 단계는 문제점을 완벽하게 설명하는 것으로 시작됩니다. 문제점 설명을 통해 사용자와 IBM 기술 지원 담당자는 문제점 원인 파악의 시작점을 찾을 수 있습니다. 이 단계에는 다음과 같은 기본 질문이 포함됩니다.
일반적으로 이 질문에 대해 응답하면서 문제점을 잘 설명하고 결국 이는 문제점 해결책으로 연결됩니다.
문제점에 대해 설명할 때 가장 명확한 질문은 "무엇이 문제인가?"입니다. 이 질문은 너무 직설적일 수도 있지만 이를 통해 문제점에 대해 더 자세한 그림을 그려서 문제점을 더 구체적으로 세분화할 수 있습니다. 이 질문에는 다음이 포함됩니다.
문제점의 근원을 아는 것은 항상 쉬운 것은 아니지만 이는 문제점을 해결할 때 가장 중요한 단계 중 하나이기도 합니다. 많은 기술 계층이 컴포넌트의 보고와 실패 사이에 존재할 수 있습니다. 네트워크, 데이터 그리드 및 서버는 문제점을 조사할 때 고려해야 하는 컴포넌트 중 일부일 뿐입니다.
다음과 같은 질문으로 문제점 계층을 분리하기 위해 문제점이 발생한 위치에 중점을 둘 수 있습니다.
한 개의 계층만 문제점을 보고한다고 해서 해당 계층에서 반드시 문제가 시작된 것은 아닙니다. 문제점이 시작된 위치 식별은 문제가 발생한 환경을 이해하는 것으로 시작됩니다. 운영 체제와 버전, 모든 해당 소프트웨어와 버전 및 하드웨어 정보를 비롯하여 문제점 환경을 완벽하게 설명하십시오. 지원되는 구성이 포함된 환경에서 실행하고 있는지 확인하십시오. 다수의 문제가 같이 실행하지 않아야 하거나 같이 사용하기 위해 완벽하게 테스트하지 않은 호환되지 않는 소프트웨어 레벨 때문으로 판별됩니다.
실패한 이벤트, 특히 한 번만 발생한 경우는 더욱 이벤트의 타임라인을 명시하십시오. 작업을 거슬러 올라가서 쉽게 타임라인을 정할 수 있습니다. 오류가 보고된 시간을 시작으로(가능한 밀리초 단위까지 자세하게) 사용 가능한 로그 및 정보로 역방향으로 작업하십시오. 일반적으로 진단 로그에서 찾은 의심스러운 처음 이벤트까지만 검사하면 됩니다.
이벤트에 대한 자세한 타임라인을 명시하려면 다음과 같은 질문에 응답하십시오.
이 유형의 질문에 응답하면 문제점을 조사하기 위한 참조의 프레임이 제공됩니다.
문제점이 발생할 때 실행 중이던 시스템과 애플리케이션을 파악하는 것은 문제점 해결에서 중요한 파트입니다. 환경에 대한 이 질문으로 문제점의 근본 원인을 식별할 수 있습니다.
이 유형의 질문에 응답하여 문제가 발생한 환경을 설명하고 모든 종속 항목을 연관시킬 수 있습니까? 단순히 여러 문제가 동시에 발생했다고 해서 문제점이 서로 연관된 것은 아닙니다.
문제점 해결을 위한 관점에서 볼 때 다시 작성할 수 있는 문제점은 이상적인 문제점입니다. 일반적으로 문제점을 다시 작성할 수 있는 경우, 조사할 때 원하는 대로 사용 가능한 다양한 도구나 프로시저가 있는 것입니다. 뿐만 아니라 다시 작성할 수 있는 문제점이 더 쉽게 디버그하고 해결할 수 있는 경우가 많습니다.
그렇지만 다시 작성할 수 있는 문제점인 경우 단점도 있습니다. 문제점이 비즈니스에 큰 영향을 주는 경우, 이를 다시 발생시키고 싶지 않을 것입니다. 가능하다면 테스트 또는 개발 환경에서 문제점을 다시 작성하십시오. 그렇게 하면 일반적으로 조사 중에 더 융통성있고 제어하기도 쉽습니다.