인시던트 보고서에서 5 Whys 분석 사용 - Amazon CloudWatch
5 Whys 분석이란?인시던트 보고의 이점인시던트 보고서의 예제 시나리오가이드형 5 Whys 워크플로 사용원인이 여러 개인 복잡한 인시던트 처리효과적인 5 Whys 분석을 위한 모범 사례

인시던트 보고서에서 5 Whys 분석 사용

인시던트 보고서를 생성할 경우, CloudWatch 조사 기능은 5 Whys(5가지 이유 분석)에 입각한 근본 원인 분석을 수행하여 운영 문제의 근본 원인을 체계적으로 식별할 수 있습니다. 이러한 구조화된 접근 방식에서는 심층적인 인사이트 및 실행 가능한 수정 단계를 통해 인시던트 보고서를 개선합니다.

이 기능은 Amazon Q를 사용하여 대화형 채팅을 제공합니다. AWS Management Console에 로그인한 사용자는 다음과 같은 권한이 있어야 합니다.

{ 
    "Sid" : "AmazonQAccess",
    "Effect" : "Allow",
    "Action" : [
       "q:StartConversation", 
       "q:SendMessage", 
       "q:GetConversation", 
       "q:ListConversations", 
       "q:UpdateConversation", 
       "q:DeleteConversation", 
       "q:PassRequest" 
     ],
    "Resource" : "*"
 }

이러한 권한을 직접 추가하거나, AIOpsConsoleAdminPolicy 또는 AIOpsOperatorAccess 관리형 정책을 사용자 또는 역할에 연결하여 추가할 수 있습니다.

5 Whys 분석이란?

5 Whys는 인시던트 증상에서 출발하여 근본 원인에 도달할 때까지 자세히 파악하기 위해 '이유'를 반복적으로 묻는 근본 원인 분석 기법입니다. 각 답변은 다음 질문의 근거가 되므로, 단순히 표면적인 증상이 아닌 진정한 근본 원인을 밝히는 논리적 연결 고리를 만듭니다.

인시던트 보고서를 생성하는 동안, CloudWatch 조사 기능은 이 방법을 사용하여 조사 결과를 분석하며 당장의 기술적 실패를 넘어 프로세스, 구성 또는 시스템 문제를 식별하는 구조화된 근본 원인 분석을 제공합니다.

인시던트 보고의 이점

인시던트 보고서에 5 Whys 분석을 포함하면 여러 가지 이점이 제공됩니다.

  • 포괄적인 근본 원인 식별 - 당장의 기술적인 원인을 넘어 기본 프로세스 또는 시스템 문제를 식별합니다.

  • 실행 가능한 문제 해결 계획 - 임시 방편이 아닌 재발을 방지하기 위한 구체적이고 타겟팅된 조치를 제공합니다.

  • 조직의 학습 - 향후 참조할 수 있고 팀 지식을 공유할 수 있도록 전체 인과 고리를 문서화합니다.

  • 구조화된 분석 - 임시 방편의 문제 해결이 아닌 체계적인 조사를 보장합니다.

인시던트 보고서의 예제 시나리오

데이터베이스 연결 실패 인시던트

초기 인시던트: 500가지 오류가 광범위하게 발생한 전자상거래 애플리케이션

  1. 이유 1: 사용자에게 500가지 오류가 발생한 이유는 무엇인가요? 애플리케이션이 프라이머리 데이터베이스에 연결할 수 없습니다.

  2. 이유 2: 애플리케이션이 해당 데이터베이스에 연결할 수 없는 이유는 무엇인가요? 데이터베이스 인스턴스의 가용 연결 수가 부족합니다.

  3. 이유 3: 데이터베이스 연결 수가 부족한 이유는 무엇인가요? 배치 처리 작업을 제대로 종료하지 않은 상태에서 많은 연결을 열었습니다.

  4. 이유 4: 배치 작업이 연결을 제대로 종료하지 않은 이유는 무엇인가요? 작업의 오류 처리에 실패 시나리오 발생 시 연결을 정리하는 내용이 포함되지 않았습니다.

  5. 이유 5: 올바른 오류 처리가 구현되지 않은 이유는 무엇인가요? 코드 검토 프로세스에 리소스 관리 패턴을 위한 특정 검사가 포함되지 않았습니다.

근본 원인: 리소스 관리에 부적합한 코드 검토 표준

권장 조치: 코드 검토 체크리스트 업데이트, 연결 풀링 모니터링 구현, 자동 리소스 누수 감지 추가

성능 저하 인시던트

초기 인시던트: 트래픽 스파이크가 발생한 동안 API 응답 시간이 200ms에서 5000ms로 증가했습니다.

  1. 이유 1: 응답 시간이 증가한 이유는 무엇인가요? CPU 사용률이 모든 애플리케이션 인스턴스에서 100%에 도달했습니다.

  2. 이유 2: 오토 스케일링을 통해 인스턴스가 더 추가되지 않은 이유는 무엇인가요? 오토 스케일링이 트리거되었지만 새 인스턴스가 상태 확인에 실패했습니다.

  3. 이유 3: 새 인스턴스가 상태 확인에 실패한 이유는 무엇인가요? 애플리케이션 시작 프로세스에 8분이 소요되는데, 이는 상태 확인 제한 시간을 초과하는 시간입니다.

  4. 이유 4: 시작 시간이 오래 걸리는 이유는 무엇인가요? 애플리케이션이 시작할 때마다 S3에서 대용량 구성 파일을 다운로드합니다.

  5. 이유 5: 오토 스케일링 구성에서 이러한 시작 지연을 고려하지 않는 이유는 무엇인가요? 성능 테스트를 콜드 스타트가 아닌 사전 워밍된 인스턴스로 수행했습니다.

근본 원인: 성능 테스트 방법론에 프로덕션 오토 스케일링 시나리오가 반영되지 않았습니다.

권장 조치: 콜드 스타트 테스트 포함, 애플리케이션 시작 최적화, 상태 확인 제한 시간 조정, 구성 캐싱 구현

브랜치 분석을 활용하는 복잡한 인시던트

초기 인시던트: OpenSearch Serverless 고객이 11시간 동안 가용성이 48.3% 저하되는 경험을 함

주요 분석 연결 고리:

  1. 이유 1: 고객이 서비스 저하를 겪은 이유는 무엇인가요? 수집기의 규모 조정이 잘못되어 서비스 가용성이 48.3%로 떨어졌습니다.

  2. 이유 2: 수집기의 규모 조정이 잘못된 이유는 무엇인가요? CortexOperator에서 AZ 밸런스 계산 오류로 인해 수집기 수를 223개에서 174개로 줄였습니다.

  3. 이유 3: CortexOperator에서 AZ 밸런스를 잘못 계산한 이유는 무엇인가요? 버전 1.17 업그레이드 후 코드가 새 Kubernetes 레이블 형식을 처리하지 못했습니다.

  4. 이유 4(브랜치 A - 기술): 코드가 새 레이블 형식을 처리하지 못한 이유는 무엇인가요? 코드에서는 'failure-domain.beta.kubernetes.io/zone' 레이블을 예상했지만 Kubernetes 1.17은 'topology.kubernetes.io/zone'으로 변경되었습니다.

  5. 이유 5(브랜치 A): 이전 버전과의 호환성이 구현되지 않은 이유는 무엇인가요? 배포 계획 중에 검토한 업그레이드 정보에 레이블 형식 변경이 문서화되지 않았습니다.

브랜치 B - 프로세스 분석:

  1. 이유 4(브랜치 B - 프로세스): 이 내용이 테스트에서 발견되지 않은 이유는 무엇인가요? 통합 테스트에서 이전 레이블 형식의 사전 구성된 클러스터를 사용했습니다.

  2. 이유 5(브랜치 B): 테스트에 레이블 형식 검증이 포함되지 않은 이유는 무엇인가요? 테스트 환경 설정이 프로덕션 Kubernetes 버전 업그레이드 시퀀스를 미러링하지 않았습니다.

식별된 근본 원인:

  • 기술: Kubernetes 레이블 형식 변경 사항을 위한 이전 버전과의 호환성 누락

  • 프로세스: 테스트 방법론에서 버전 업그레이드가 미치는 영향을 검증하지 않음

통합 문제 해결 계획: 레이블 형식 탐지 로직을 구현하고, 업그레이드 테스트 절차를 개선하고, 자동 호환성 검증을 추가하고, 버전 변경이 미치는 영향을 평가하는 프로세스를 설정합니다.

가이드형 5 Whys 워크플로 사용

CloudWatch 조사 기능에서는 누락된 사실을 해결하고, 인시던트 보고서를 강화하는 데 도움이 되는 가이드형 5 Whys 분석 워크플로를 제공합니다. 이 기능은 시스템에서 근본 원인 분석을 개선할 기회를 식별할 때 권장 워크플로로 표시됩니다.

대화형 분석 경험

CloudWatch 조사 기능의 5 Whys 분석은 조사 프로세스를 안내하는 대화형 채팅에 기반한 접근 방식을 사용합니다. 이러한 대화형 방법은 질문 간의 논리적 흐름을 유지하면서 포괄적인 분석을 보장하는 데 도움이 됩니다.

대화형 경험의 주요 기능:

  • 사실에 기반한 초기화 - 시스템에서는 조사를 통해 얻은 관련 사실을 미리 제시하므로, 이를 사용하여 명확한 답변을 미리 입력하고 사실 기반 제안과 추론 기반 제안을 명확하게 표시합니다.

  • 가이드형 탐색 - '이유'를 묻는 각 질문에 대해 시스템에서는 사용 가능한 사실을 기반으로 답변을 제안하고, 특정한 추가 컨텍스트를 요청하고, 계속 진행하기 전에 중요한 요소를 고려하도록 안내합니다.

  • 브랜치 관리 - 원인 제공 요인이 여러 개인 것으로 식별될 경우 시스템에서는 브랜치 옵션을 명확하게 제시하고, 브랜치 간의 관계를 설명하고, 병렬 조사의 우선순위를 정하는 데 도움이 됩니다.

  • 점진적 검증 - 각 응답에 대해 시스템에서는 명확성을 위해 답변을 재구성하고, 확인을 요청하고, 핵심 인사이트를 강조 표시하고, 조사 결과를 더 광범위한 컨텍스트에 연결합니다.

이러한 접근 방식을 사용하면 가장 중요한 인과관계에 중점을 두면서 모든 관련 정보를 캡처할 수 있습니다.

가이드형 워크플로에 액세스:

  1. 인시던트 보고서를 생성하는 동안 오른쪽 패널의 Facts need attention 섹션을 검토합니다.

  2. Suggested workflow에서 Guided 5-Whys analysis 제안을 찾습니다.

  3. Guide me를 선택하여 대화형 5 Whys 프로세스를 시작합니다.

  4. 가이드형 프롬프트에 따라 '이유'를 묻는 각각의 질문을 체계적으로 진행하여 증상에서 근본 원인까지 전체 인과관계를 구축합니다.

가이드형 워크플로는 5 Whys 방법론의 각 단계를 안내하여 포괄적인 근본 원인 정보를 캡처할 수 있도록 지원합니다. 분석 결과가 인시던트 보고서에 자동으로 통합되므로, 인시던트 발생 후 검토 및 조직의 학습을 위한 구조화된 설명서가 제공됩니다.

또한 채팅 인터페이스를 통해 '이 인시던트에 대한 5 Whys 분석을 수행해 주세요' 또는 '5 Whys 방법론을 사용했을 때 근본 원인은 무엇인가요?' 등과 같은 질문을 하여 5 Whys 분석을 요청할 수 있습니다.

원인이 여러 개인 복잡한 인시던트 처리

일부 인시던트는 원인 제공 요인이 여러 가지이며, 이 경우 병렬 분석 경로가 필요합니다. CloudWatch 조사에서는 브랜치 분석을 지원하여 모든 중요한 원인을 식별하고 해결할 수 있도록 보장합니다.

브랜치 분석이 필요한 경우:

  • 여러 단독 실패가 동시에 발생함

  • 서로 다른 시스템 구성 요소가 동일한 고객 영향에 원인을 제공하고 있음

  • 기술 실패와 프로세스 실패가 둘 다 중대한 요인으로 작용함

  • 연쇄적인 실패로 인해 여러 개의 인과 연결 고리가 생성됨

브랜치 분석 프로세스:

  1. 브랜치 식별 - 여러 개의 원인이 수렴하거나 발산하는 지점이 식별됩니다.

  2. 병렬 조사 - 완전한 5 Whys 방법론을 사용하여 각 브랜치를 분석합니다.

  3. 연결 매핑 - 브랜치 간의 관계를 문서화하여 서로 어떻게 상호 작용하는지 나타냅니다.

  4. 통합형 문제 해결 - 해결 계획을 통해 지금까지 식별된 모든 근본 원인과 상호 작용을 해결합니다.

이러한 포괄적인 접근 방식을 활용하면 복잡한 인시던트를 꼼꼼히 분석하고, 최종 문제 해결 계획에서 모든 원인 제공 요인을 해결할 수 있습니다.

효과적인 5 Whys 분석을 위한 모범 사례

인시던트 보고서에서 5 Whys 분석의 효과를 극대화하려면 운영 경험에서 도출된 다음과 같은 모범 사례를 따르시기 바랍니다.

질문 구성 지침

  • 고객 영향에서 시작 - 고객에게 직접 영향을 미치는 문제를 기점으로 각 분석을 시작하여 비즈니스 영향을 중점적으로 다룹니다.

  • 점진적으로 심층적인 기술 다루기 - 질문을 진행하면서 비즈니스 영향에서 기술적인 세부 사항으로 주제를 옮겨갑니다.

  • 논리적 연속성 유지 - 논리적 간극 없이 각각의 답변이 자연스럽게 다음 질문으로 이어지도록 합니다.

  • 뒷받침 증거 포함 - 특정 지표, 로그 또는 타임라인 이벤트를 참조하여 각각의 답변을 검증합니다.

분석 검증

다음과 같은 기준을 사용하여 5 Whys 분석을 검증합니다.

  • 논리적 흐름 - 누락된 단계 없이 증상에서 근본 원인까지 명확하게 진행

  • 기술 정확도 - 올바른 용어, 정확한 시스템 동작 설명, 올바른 구성 요소 상호 작용

  • 완전성 - 관찰된 모든 증상을 분석을 통해 설명하고, 증상이 해결된 경우 재발을 방지할 근본적인 원인에 도달해야 합니다.

  • 실행 가능성 - 식별된 근본 원인은 구체적이고 구현 가능한 문제 해결 조치로 이어져아 합니다.

피해야 할 일반적인 위험

  • 증상 발생 시 중단 - 처음으로 기술 실패가 발생한 경우 분석을 종료하지 말고 시스템 또는 프로세스 원인에 도달할 때까지 계속 진행합니다.

  • 책임 소재에 중점을 둔 분석 - 개별 작업이 아닌 시스템 및 프로세스 실패에 중점을 둡니다.

  • 단일 경로에 기반한 생각 - 여러 가지 원인 제공 요인을 고려하고, 적절한 경우 브랜치 분석을 사용합니다.

  • 증거 부족 - 각 답변이 조사를 통한 구체적인 데이터에 의해 뒷받침되는지 확인합니다.

인시던트 보고서 섹션과 통합

5 Whys 분석은 인시던트 보고서의 다른 섹션과 통합되어 포괄적인 설명서를 제공할 수 있습니다.

  • 타임라인 상관관계 - '이유'를 묻는 각 질문은 특정 타임라인 이벤트를 참조할 수 있으므로, 인과관계에 대한 시간적 컨텍스트가 제공됩니다.

  • 지표 검증 - 묘사된 기술의 동작을 보여주는 지표 및 그래프를 통해 답변을 뒷받침합니다.

  • 영향 평가 조정 - 영향 평가 섹션에 설명된 고객 영향 지표에 첫 번째 '이유'가 직접 연결됩니다.

  • 학습한 교훈 기반 - 5 Whys 분석을 통해 식별된 근본 원인은 학습한 교훈 및 수정 조치 섹션에 직접적으로 정보를 제공하는 역할을 합니다.

이러한 통합으로 인해 인시던트 보고서 전체의 일관성을 보장하며, 초기 증상에서 근본 원인, 문제 해결 계획에 이르는 완전하고 일관된 서술 자료를 이해관계자에게 제공할 수 있습니다.