문제 해결 규칙, 문제 해결 방법? [닫은]


22

어려운 네트워크 / 하드웨어 / 소프트웨어 문제를 해결할 때 고려해야 할 일반적인 규칙이 있습니까?

예 : "두 번째 컴퓨터로 주변 장치를 테스트하여 문제의 원인을 격리합니다"또는 "장치 전원을 켤 수있는 하드웨어를 최대한 많이 제거한 다음 문제를 재현 할 수있을 때까지 구성 요소를 하나씩 다시 추가합니다." 등


제목을 수정해야 할 수도 있습니다. 난 그냥 누군가가 "감사합니다! 나는 그것을 자랑스럽게 생각합니다"라고 대답 할 것임을 알고 있습니다 ;-)
username :

답변:


16

잠시 동안 문제와 싸우고 나 자신을 위해 적어 둔 요점 목록 :

  1. 기본 목표 는 무엇입니까 ? 명확하고 간결하게 언급해야합니다. 목표는 매우 구체적이어야합니다. 일반적이어서는 안됩니다. 바람직하게는 한 문장 이다.
  2. 당신의 문제는 무엇입니까?
  3. 바로 거기에 문제가 하나 또는 여러는 ? 많은 것이 있으면 한 번에 하나씩 해결하십시오.
  4. 다른 조건 에서 문제를 재현 해보십시오 . 가능한 모든 조건에서 재현 할 수 있습니까? 문제의 본질에 대해 말하고 있습니까?
  5. 긴급한 문제인 경우 해결 방법이 있습니까? 가능한 많은 해결 방법을 찾으십시오.
  6. 로 만들려고 많은 추측 하여 문제의 원인이 무엇인지에 가능한.
  7. 당신의 추측을 증명 하고 시스템을 실험 해보십시오 .
  8. 당신이하려는 일에 일관성 을 유지 하십시오 . 한 번에 한 가지 작업을 수행하십시오.
  9. 현재 하고있는 일, 이미 시도한 것을 추적하십시오 .
  10. 기본 목표에서 벗어나지 마십시오 . 차이점이 아닌 주요 문제를 여전히 해결하고 있는지 지속적으로 확인하십시오.
  11. 흥분시키는 없습니다 중 하나.

디버깅 규칙 목록도 ​​많았으며 각 규칙에 대한 설명과 설명이 포함 된 PDF 형식이었습니다. PDF를 빨리 찾을 수 없었지만 이것이 목록의 포스터라고 생각합니다.

여기에 이미지 설명을 입력하십시오


15
  • 인터넷과 관련된 문제라면 아마도 DNS 일 것입니다.

  • 문제를 진단하기 어려운 경우 RAM 일 수 있습니다.

  • Windows 워크 스테이션에 문제가있는 경우 이미지를 다시 작성하는 것이 가장 빠릅니다.

  • 금요일에 문제가 발생하면 심각한 문제 일 수 있습니다.


농담 게시물을 줄이려고했지만 놀랍도록 정확합니다!
TessellatingHeckler

나는 # 3을 좋아했다; 더 사실 수 없습니다.
Federer

10

나는 과학적인 방법으로 돌아가고 싶다 .

( http://en.wikipedia.org/wiki/Scientific_method )에서

  1. 질문을 정의하십시오
  2. 정보 및 자료 수집 (관찰)
  3. 형태 가설
  4. 실험 수행 및 데이터 수집
  5. 데이터 분석
  6. 새로운 가설의 출발점으로 작용하는 데이터 해석 및 결론 도출
  7. 문서 결과

일반적으로 저는 항상 기본 가정을 다시 확인하려고합니다. 전원이 연결되어 있거나 전원이 연결되어 있고 배선이 양호합니다. 케이블이 느슨 할 때 소프트웨어 문제를 살펴 보는 데 몇 시간을 소비하는 것은 매우 성가신 일입니다.

가설 생성 단계에서 가능한 한 많은 문제의 원인을 찾아내는 것이 매우 중요합니다. 그런 다음 테스트하기가 얼마나 쉬운 지, 아이디어가 얼마나 가능한지에 따라 먼저 테스트 할 아이디어를 선택하려고합니다.

도움을받는 것도 중요합니다. 가능한 경우 동료, 공급 업체 또는 문제가있는 시스템에 대해 가장 잘 알고있는 사람에게 문의하십시오. 문제를 해결하는 데 도움을 줄 수있는 사람이 있다면 문제에 대해 바퀴를 돌리는 데 많은 시간을 소비하지 마십시오.

O'Reilly는 훌륭한 책 네트워크 문제 해결 도구를 제공 합니다.이 단계에는 과학적 방법과 매우 유사합니다. 나는 그 책이 매우 유용하다는 것을 알았고 그것을 강력히 추천한다. 이 책은 훨씬 더 자세하게 다루고 많은 유용한 도구를 제안합니다.

에서 네트워크 문제 해결 도구

  1. 당신의 목표를 진술하십시오
  2. 시스템 정의
  3. 가능한 결과 파악
  4. 측정 대상을 식별하고 선택하십시오.
  5. 적절한 경우 테스트 매개 변수 및 요인을 식별하십시오.
  6. 도구 선택
  7. 측정 제한 조건 설정
  8. 실험 설계 검토
  9. 데이터 수집
  10. 데이터 분석

참조 :


명확히. 그럼에도 불구하고, 7 단계는 다소 유머러스합니다. 내 문서는 보통 "예, 수정되었습니다. 이제 작동합니다."
squillman

나는 과학적 방법을 존중하며, 그것이 일어나기 전에 인적 요소가 필요하다고 생각한다고 생각했다. 예를 들어,보고의 출처 (문제를보고하는 사람)를 고려해야합니다. 그리고 자신이 '신뢰할 수있는'출처라고 생각하지 않도록주의해야합니다 (신뢰할 수 있음을 의미합니다. 질문을 정의하고 정보를 수집하며 첫 번째 가설을 세우는 데 도움이되는 자료).
l0c0b0x 17:07에

10

(이 주요 내용은 "시스템 및 네트워크 관리 실습 "의 "디버깅"장에서 설명됩니다. )

알아야 할 두 가지 :

  1. "고정"버전이 어떻게 보이는지 알아 두십시오. 작업이 작동 할 때 특정 출력을 제공하는 명령을 실행할 수있는 것이 좋습니다. 예를 들어 : 키를 올바르게 설정했을 때 SSH가 암호를 묻는 이유를 알아 내려고 노력 중입니다. 내 테스트는 "ssh servername uptime"이며 암호를 요구하지 않고 작동합니다.

  2. 올바른 수준에서 문제를 설명하십시오. 서버를 핑할 수 없다고 불평하는 사용자는 서버를 실행하고 수정하기 위해 보내지 말아야합니다. 그 사람의 일은 하루 종일 앉아서 기계를 핑하는 것이 아닙니다. 그들은 기계를 DNS 서버로 사용하는 것과 같은 일종의 작업을 원합니다. 예 : 사용자가 전 세계 반쯤 머신을 ping 할 수 없다고 불평 한 경우. 나는 회사의 해당 부분에서 시스템 관리자를 추적하여 해당 시스템에 어떤 문제가 있는지 알아내는 데 하루를 보냈습니다. 해체되었고 그들은 잘못된 기계의 전원을 끈 것으로 생각했기 때문에 공황 상태에있었습니다. 사용자에게 연락하여 "이 기계를 핑해야하는 것 외에, 무엇을하고 싶습니까?"라고 말했습니다. 그는 특정 작업을 수행하고 싶었고 올바른 절차를 따르고 있다면 그의 작업이 자동으로 교체 기계로 리디렉션되었을 것입니다. 나는 하루 종일 로컬 시스템 관리자의 시간을 낭비했다. "핑할 수 없습니다"라는 또 다른 이유는 테스트 대상이 아닙니다. 방화벽은 종종 핑 패킷을 삭제하지만 다른 패킷은 통과하도록 구성되어 있습니다. 당신이 겪고 싶은 것을 테스트하십시오.

두 가지 전략 :

  1. 첨가제 : 문제가 시작될 때까지 구성 요소를 계속 추가하십시오. 마지막으로 추가 한 것은 문제입니다. 예 : 웹 브라우저가 서버와 통신 할 수 없습니다. 서버와 사용자 사이에는로드 밸런서, 방화벽, 캐시 및 사용자의 로컬 웹 프록시가 있습니다. 먼저 하나의 구성 요소를 추가 할 때마다 서버로 직접 쿼리를 보낸 다음 LB를 통해 서버로, 방화벽을 통해 LB로 서버 등을 보내십시오.

  2. 빼기 : 문제가 사라질 때까지 구성 요소를 계속 제거하십시오. 마지막으로 제거한 문제는 다음과 같습니다. 예 : 수십 개의 카드가있는 시스템이 부팅되지 않습니다. 기계가 부팅 될 때까지 카드를 제거하십시오.

멍청한 행운의 두 비트 :

  1. 내가 말한 모든 것을 잊어라. 시스템을 마지막으로 변경하여 문제가 발생했습니다. (이것은 99 %의 시간으로 작동합니다 ... 문제는 99 %의 시간이 마지막 변경이 실제로 무엇인지 알지 못한다는 것입니다)

  2. 다른 모든 것이 실패하면 어리석은 것들을 확인하십시오. http://whatexit.org/tal/mywritings/dumb-things-to-check.html 예 : 미친 문제는 설명 할 수 없었습니다. 그런 다음 구성 파일을 확인했습니다. 사용자가 파일을 Windows 상자에 복사하고 편집 한 다음 다시 복사하여 편집했습니다. 모든 줄 끝에 ^ M이 생겼습니다. 우리는 텍스트 편집기가이 사실을 조용히 숨 겼기 때문에 눈치 채지 못했습니다. 안타깝게도, 구성 파일을 읽는 소프트웨어는 이러한 ^ M을 방대한 공간으로 바꾸어 수많은 다른 절차를 망쳤습니다.


6

전체 과정에서 내가 기억하는 일반적인 관행 :

  1. 내가하는 모든 것을 쓰십시오.
  2. 한 번에 하나만 변경하십시오.
  3. 가능하면 명확한 진전이없는 한 다른 변경을 시도하기 전에 변경 사항을 되 돌리십시오.

문제 해결 중에 여기에 기본 방법이 정의되어 있습니다.

  • 시스템이 제대로 작동하면 문제가 발생하기 전에 시스템 작동 상태를 확인하려고합니다. Joe Richards는이 짧은 공간에서 내가 할 수있는 것보다 더 나은 이유를 설명합니다 .
  • 가장 간단한 솔루션부터 시작합니다. 예를 들어 네트워크 연결이 없습니까? 물리 계층을 확인하십시오. 간헐적 인 연결 문제가 서버 문제가 아니라 반 케이블 또는 불량 케이블이 몇 번인지 알 수 없습니다.
  • 변경을 시작하기 전에 가능한 모든 출처에서 볼 수있는 모든 증상을 파악하려고합니다.
  • 예비 진단 테스트를 실시합니다. 예를 들어 서버가 다운되었다고 들었을 때 가장 먼저하는 일은 ping과 nbtstat (Windows)를 사용하여 확인하는 것입니다. 문제는 먼 끝에있을 수 있습니다 (오래된 공군 기술 통제 말을 빌리기 위해).
  • 나는 연구를 두려워하지 않습니다. Google, support.microsoft.com, eventid.net 및 이와 유사한 사이트가 귀하의 친구입니다.
  • 나는 지역 사회에 도움을 요청하는 것을 두려워하지 않습니다. serverfault.com과 같은 사이트뿐만 아니라 트위터에서 신뢰하고 존중하는 사람들이 많이 있습니다.
  • 내가보고있는 내용으로 내가 찾은 답변을 평가합니다. 솔루션에보고 된 내용으로보고있는 증거를 충분히 고려할 수있을 때까지 하나의 솔루션이 올바른 솔루션이라고 생각하지 않습니다.

6

시도하고 유지하는 태도 :

  • 원인과 결과가 작동하고 아무것도 없다는 절대적인 자신감은 마법입니다. 실제로 이상한 일이 일어나지 않으며, 내가 이해하지 못하는 것만 발생합니다.
  • 계속 밀어 붙이면 해결 될 것이라는 절대적인 확신 (이것은 더 지식이 많고 배우고 도움을 청하거나 열심히 일하는 사람에게 가져갈 수 있음).
  • 설정, 프로그램 또는 시나리오가 잘못 설계되었거나 실제로 어리석은 방법에 대해 불평하는 것은 도움이되지 않으므로 그렇게하지 마십시오. (나는 이것을 어렵게 생각한다. 불평은 재미있다).

이것들은 내가 붙잡는 데 도움이되는 태도입니다. 그들은 무기를 공중에 던지거나 "기괴한"것을 선언 한 다음 포기하거나 "해결 불가능"하다고 느끼기 때문에 불행 해집니다.

문제 해결에 대한 생각 :

  • 시스템에 많은 부품이 연결되어 있거나 서로 연결되어 있거나 임의로 구성된 경우 원하는대로 작동하지 않습니다. 벽돌과 금속을 쌓는 수백만 가지 방법 중 하나 또는 두 개의 매우 구체적인 구성이 작동합니다. 몇 개만이 교량이며 한두 개만으로도 충분한 교량입니다. 원인은 텍스트 파일의 문자이거나 서버 오류 일 수 있지만 모든 부분이 옳 아야합니다. 필요한 경우 철저하고 세심한 배려가 필요합니다. 시스템은 "쇼를 계속해야합니다".
  • 지도와 같은 전체 시스템으로 시작하여 "문제가있는 곳"을 나타내는지도 위에 떠 다니는 확률의 구름을 상상해보십시오. 경험은 경험을 사용하고 일부 지역에서 다른 지역으로 확률을 밀어 내기위한 테스트를 찾는 것입니다. 확률이 높은 문제 위치 인 지점으로 압축 한 다음 공격합니다. 이것은 원인과 결과 지점으로 돌아옵니다. 문제는 시스템에 있으며 마술이 아닙니다. 존재하는 문제이므로 어딘가에 존재해야합니다.
  • 누구나 원하는 방식으로 설정할 수 있습니다. 우리가 한 행동을 "OK"로 정의하고 다른 행동을 "문제"로 정의 할 수있는 유일한 방법은 누군가가 얻는 것이 원하는 것이 아니기 때문입니다. 그들이 원하는 것, 그들이 명확하고 구체적으로 얻고있는 것을 이해해야합니다.

문제 해결 과정 :

  • 무엇이 문제입니까? 의사 소통이 없도록 상황이 발생하고 스스로 재현 할 수 있는지 확인하십시오. 종종 헬프 데스크에서 여러 사람들이 문제를 겪어 왔는데, 그들이 나에게 갈 때까지 아무도 그 문제가 실제로 무엇인지 설명 할 수 없습니다.
  • 그것은 재귀 적 이분법입니다-나누고 정복하기, 이진 검색 – 문제가 테스트의 측면인지 또는 그 측면인지를 증명하고 가능한 한 많이 제거하도록 테스트를 만듭니다. 해결 될 때까지 반복하십시오.
  • 당신이 그것을 피할 수 있는지 배우지 마십시오-데이터베이스 계정을 잠그고 데이터베이스가 어떻게 사용되는지 배우는 데 시간을 소비하는 것보다 데이터베이스가 관여하지 않을 때 문제가 여전히 발생한다는 것을 증명하는 것이 좋습니다.
  • "다음에 무엇을해야할지 모르겠습니다"라고 생각하기가 너무 쉽습니다. 언제 발생하는지 확인하고 문제를 찾는 테스트를 다시 시작하십시오.

인터넷이 작동하지 않습니까? 문제를 확인하고 그들이 얻을 수없는 웹 사이트임을 찾으십시오. 빠른 테스트는 인터넷 연결 (작동)과 관련이 있습니다.로드되지 않습니다 (아니요). 빠른 테스트는 사이트임을 지적합니다. 나에게 문제가 발생하는 것을 보면서 PC, 브라우저, DNS, 사용자 계정 방화벽 등에서 신속하게 가능성을 밀어 냈습니다.

따라서 사이트가로드되지 않습니다. 이제 무엇입니까? 그것은 아직 고칠 수 없으므로 문제를 더 작은 것으로 만들 장소를 찾으십시오. 서버가 켜져 있습니까? 핑합니까? DNS가 작동합니까? 예. 포트 80에서 서비스가 응답합니까? 아니요. 서비스가 실행 중입니까? 아니요. 시작합니까? 아니요. 이벤트 로그 / 로그 파일에 오류가 있습니까? 예! 그들은 무엇을 말합니까?

이는 문제의 범위를 좁히는 데 끊임없이 집중하기 때문에 효율적이고 빠른 문제 해결입니다. 인터넷이 작동하지 않는다는 보고서를 수락하면 연결 실패로 잘못 인식 될 수 있습니다. 로드가되지 않는다는 첫 번째 관찰을 수락하면 컴퓨터에 문제가 있다고 생각하는 시간을 낭비하게됩니다.

"할 수없는 것"을 최대한 크게 조각하십시오.

시스템을 이해하십시오. 시스템에 대한 일반적인 지식이 많을수록 더 쉽게 얻을 수 있습니다. 내가 이해력이 약한 곳에서는 문제가 더 협박되고, 더 어려워지고, 느리게 진행되며, 수정보다 해결책으로, 또는 작고 정확한 수술 수정보다 큰 바보 같은 느린 수정 (재설치)으로 끝날 가능성이 높습니다.


4

일반적으로 "이 문제를 유발했을 수있는 변경 사항"에 대해 묻습니다. 대부분의 문제는 알려진 양호한 구성 변경으로 인해 발생합니다. 변경 한 사람을 분리 할 수 ​​있으면 대개 답변을받습니다.


2

과학이 아닌 기술이라고 생각합니다. 잘못된 길을 갔지만 대부분의 경우 시간이 있습니다.

  • 네트워크, 하드웨어, OS, 소프트웨어, 개발 등 모든 관련 기술에 대한 기본적인 이해를 통해 이러한 "잘못된 경로"를 제거 할 수 있습니다.
  • 기본을 생각하십시오-가장 복잡한 시나리오로 넘어 가지 마십시오. 머리 속에 있기 때문에 기본적인 문제 해결을 수행하고 이끌어냅니다.

나는 한때 상사가 전화로 "고급"엔지니어에게 전화를 걸도록했다. 그는 연결할 수없는 서버 가 하나 있는데 케이블 전환을 시도했지만 여전히 기쁨은 없다고 말했다. 배터리의 UPS처럼 백그라운드에서 신호음이 들립니다. 나는 그가 스위치에서 활동을 볼 수 있는지 물었다. 나는 그에게 경고음이 UPS에서 나왔는지 물었다. 그는 그렇다고 말했다. 그는 랙에서 전혀 불이 들어오지 않는지 물었다.


1

나는 명백한 것을 확인하는 것으로 시작합니다. 문제가 무엇인지 설명하는 오류 메시지가 있습니까? 모든 것이 제대로 연결되어 있습니까? 몇 분 안에 해결할 수있는 문제를 해결하는 데 몇 시간을 낭비하는 것을 좋아하지 않습니다. 나는 너무 체계적인 것이 가능하다고 생각합니다. 나는 사람들이 문제가 무엇인지 정확하게 말 했음에도 불구하고 하루 종일 문제를 재현하는 것을 보았습니다. 그것은 내가 지불하는 것이 아닙니다.

대답이 명확하지 않으면 용의자를 정리하고 먼저 테스트하십시오. 가능성이있는 용의자를 테스트 한 후에 만 ​​가능성이없는 용의자를 테스트해야합니다. 그러면 원하는만큼 과학적으로 할 수 있습니다.


흠. 나는 부분적으로 동의한다-또는 적어도 나는 다른 사람의 규칙이 어떻게 / 언제 적절한 지 이해하지 않고 쉽게 따르는 것이 쉽다고 생각한다. 수학을 공부해야하지만 실제 생활에서 배운 것을 사용할 수있는 상황을 인식하지 못하는 고등학생처럼. 그러나 올바른 규칙을 적용 할 적절한 시간을 이해하는 것은 정말 유익 할 수 있습니다. 예 : 입증 할 수있는 효율적인 문제 해결 규칙의 예를위한 Google "HalfSplit 방법"
username

명백한 것을 배제하는 당신의 방법은 비 과학적이지 않습니다. 당신은 가정과 테스트 단계를 여러 번 반복하여 빠르게 진행하고 있습니다. 테스트 할 수있는 아이디어에 우선 순위를 두어야한다는 데 동의합니다.
Zoredache
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.