카테고리 없음

트러블슈팅(troubleshooting)에 대해 알아보겠습니다.

forward error correction Circle 2023. 2. 15. 07:53
반응형

Ⅰ. 트러블 슈팅이 필요한 이유

시스템이나 소프트웨어를 사용하다가 무언가 문제가 발생했을 때 해결하는 것이 트러블 슈팅입니다. 
갑작스럽게 발생한 문제는 누구나 당황하게 될 것입니다. 그러나, 해결했었던 이력, 같은 문제 혹은 비슷한 문제에 대한 해결에 대한 복구 매뉴얼이 있다면 최단 시간내 문제를 해결할 수 있습니다. 

트러블 슈팅의 개념과 방법에 대해 설명하겠습니다.

Ⅱ. 트러블 슈팅이란

시스템에서 발생하는 복잡한 문제들을 종합적으로 진단해 해결하는 것입니다.

 즉, 사용중인 시스템, 소프트웨어에서 무언가 문제가 발생했을 때 그 원인을 찾아 제거하는 것을 의미합니다.

문제의 상황에서 운영자 혹은 사용자가 대처할 수 있도록 장애・결함에 대한 대책이 따로 기재된 설명서를 볼 수 있습니다. 항목별 대책을 상세하게 정리해둔 가이드를 트러블 슈팅이라고 부르는 경우도 있습니다.

Ⅲ. 트러블 슈팅 단계

1) 이슈 정의

   이슈로 인해 어떤 곳에서 이슈가 발생한지, 이슈가 어떻게 발생한지, 이슈로 인해 무엇이 안되는지, 이슈가 되는 상황을 파악하는 것이 트러블 슈팅의 첫 번째 단계입니다. 겉으로 들어난 문제가 한개라고 내부의 문제가 한 개라고 할 수 없습니다. 이슈가 발생한 시점부터 이슈의 범위와 현상에 대해 정리하는 단계입니다.

2) 사실 수집
 이슈가 발생한 출처를 찾습니다. 분석의 시작은 Log 분석으로 부터 시작되며 OS 이슈일 경우 Error 발생 로그, Messages 로그 등 확인 프로세스 이슈 일 경우 Stdout, Stderr 로그  등 확인, 어플리케이션 이슈일 경우  Accesslog, Errorlog 등 확인 해볼 수 있습니다.

 Dump 와 Log 는  Dump는 현재상태, Log는 과거 기록입니다.

Dump는 문제 시점 당시의 상황을 자세하게 알 필요가 있을때 확인하며, 주로 Dump 의 경우 수행중인 프로세스에 영향을 줄 가능성이 높습니다. Dump 툴은 다음과 같습니다

OS = Core dump

JAVA = Heap Dump, Thread Dump

네트워크 = TCP Dump

 

Log와 Dump 를 통해 사실 근거를 수집합니다.


3) 원인 추론

 이슈가 발생함에 있어 특정 조건하에 발생하는 경우도 있습니다. 특정조건을 기록해 두어 원인을 정확히 특정할 수 있는 경우가 많습니다.

 자주 있는 발생 조건으로 들 수 있는 것이, 특정 시간대 외에 문제가 발생했을 때 실행한 시스템과 어플리케이션, 특정 작업・동작 등에 대한 로그입니다. 어떤 조건이 모이면 반드시 이상이 발생한다와 같은 재현성 유무도 원인 규명에 큰 역할을 할 수 있습니다. 이슈 상황에 대한 생각할 수 있는 요소를 하나 하나씩 확인하여 트러블 원인을 추정합니다. 또한 3가지 방법으로 원인을 추정하는데 도움이 됩니다.

 

 ⅰ. 하나씩 원인 분석하기
 어떤 단말기에서 어떤 문제가 발생하고 있는지 하나 하나씩 확인합니다. 한 번에 정리해 확인하게 될 경우 문제가 되는 출처를 놓칠 위험이 있기 때문입니다. 이것은 원인을 특정할 때 필요한 중요한 룰입니다.

 ⅱ. 가까운 곳에서 먼 곳으로 확인하기
 어떤 단말기에서 업무시스템에 연결되지 않는다는 이슈가 발생했을 때 그 단말기 자체에 문제가 있다고 단정하기는 어렵습니다. 그때에는 우선 이상이 보이는 단말기를 확인하고, 네트워크 흐름도에 따라 다음 방화벽까지, 다음 백본, 라우터와 같이 단말기에서 가장 가까운 곳에서 먼 곳을 향해 확인해갑니다. 

 ⅲ. 아래에서 위로 체크해가기
 아래에서 위라는 것은 기능상의 계층 구조에 주목한 체크 방법입니다. 특정 PC에 이상이 발생했을 때 우선은 기본이 되는 단말기의 하드웨어에 문제는 없는지, OS는 정상적으로 부팅되며, 기능하고 있는지, 네트워크는 연결되었는지, 설치된 어플리케이션은 어떤 상태인지와 같이 기본 부분에서 상위 계층으로 체크해 나가는 것입니다.

4) 조치 방안 검토
 추정한 원인으로 트러블 대책을 세우고 복구가 가능한지 검증 작업을 합니다. 여러 가지 대책을 한 번에 실행하여 해결할 경우 정확한 트러블의 원인을 특정할 수 없습니다. 한 개씩 조치를 해보면서 동작을 확인하여 원인을 특정해야 합니다. 

5) 결과 관찰
 추정한 원인과 조치 방안을 통해 조치한 결과에 대해 일정기간 모니터링을 합니다.

6) 문서화
 ⅰ. 우선 순위에 대한 체계 수립
  시스템 전체를 수시로 감시하는 모니터링 업무 및 고객이 1차적으로 콜이 유입되는 콜센터 업종이라면 가령 우선순위가 낮은 트러블이라도 문제가 발생하면 바로 대처하지 않으면 안되기 때문에 우선순위를 매기는 것 자체가 쓸데없는 작업이 될 수도 있습니다. 사소한 것이라도 큰 트러블 원인을 제공 될 수도 있습니다.
 ⅱ. 트러블 슈팅 대응 업무 문서 수립
  누구라도 동일한 대응이 가능하여 원활하게 해결・복구하여 처음접하거나 숙련도가 미숙한 사용자라도 가능하게 하는 것이 트러블 슈팅입니다. 
  전문성이 필요한 이슈에 대해서는 해당 이슈 업무의 부서가 대처를 하지만, 사람마다 스킬 차이가 있기 때문에 어려운 트러블은 스킬 높은 업무를 집중시킬 가능성이 있습니다. 

 ⅲ. IT 툴과 서비스 활용하기
  서버 모니터링, DB 모니터링, 어플리케이션 모니터링 등 사내 시스템과 네트워크를 감시하는 툴을 사용하여 트러블이 발생했을 때 원인규명을 서포트하는 툴은 시장에 다수 등장하고 있습니다. 또한, OS에 표준으로 내장되어 있는 트러블 슈팅 툴도 있도 잇습니다. 매우 넓은 범위의 내용도 있고, 사용자 커뮤니티에서 트러블과 그 해결방법에 대해 활발한 보고가 이루어지는 예도 있습니다.
  ex) 서버 모니터링 - Zabbix, Ontune

        DB 모니터링 - MaxGauge

        Application 모니터링 - Jennifer

반응형