# 인시던트 보고서 생성
인시던트 보고서는 인시던트 조사에 대한 보고서를 더 쉽고 빠르게 작성하는 데 도움이 됩니다. 이 보고서를 사용하면 경영진에게 세부 정보를 제공하거나, 팀원들이 인시던트를 통해 교훈을 얻고 향후 이러한 인시던트 발생을 방지하기 위한 조치를 취하도록 지원할 수 있습니다. 보고서의 구조는 이러한 유형의 보고서에 대한 업계 표준을 기반으로 하며, 장기 보존하려는 경우 다른 리포지토리에 복사할 수 있습니다.
AWS Management Console을 사용하여 CloudWatch 조사에서 *조사 그룹* 리소스를 생성할 경우, 해당 그룹에 대한 IAM 역할이 생성되어 조사 중에도 리소스에 대한 액세스 권한을 부여할 수 있습니다. CloudWatch 조사 인시던트 보고서를 생성하려면 조사 그룹에 추가 권한을 부여해야 합니다. 새로운 관리형 정책인 `AIOpsAssistantIncidentReportPolicy`는 필요한 권한을 제공하며, 2025년 10월 10일 이후 AWS Management Console을 사용하여 생성된 조사 그룹에는 이 정책이 자동으로 추가됩니다. 자세한 내용은 [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy) 섹션을 참조하세요.
**참고**
CDK 또는 SDK를 사용할 경우, 조사 그룹 역할을 명시적으로 추가한 후 역할에 대한 역할 정책 또는 그에 상응하는 인라인 권한을 지정해야 합니다. 권한에 대한 자세한 내용은 [CloudWatch 조사의 보안](Investigations-Security.md) 섹션을 참조하세요.
이러한 보고서는 이해관계자와 쉽게 공유하고 조직의 학습에 사용할 수 있는 구조화된 형식으로 조사 결과, 근본 원인, 타임라인 이벤트, 권장 수정 조치를 캡처합니다.
인시던트 보고서 생성은 모든 CloudWatch 조사 사용자에게 추가 비용 없이 제공되며 조사 워크플로와 원활하게 통합됩니다.
**인시던트 보고서의 작동 방식**
1. 인시던트에 대한 조사를 실행합니다.
1. 하나 이상의 가설을 수락합니다. 수락하는 각 가설은 보고서에 반영됩니다. 가설은 100% 정확하지 않아도 괜찮습니다.
1. **인시던트 보고서**를 선택합니다. 조사가 진행되는 동안 AI는 조사를 위해 수집된 데이터 및 도출된 사실을 구문 분석합니다. '사실'이라는 건 보고서 생성의 근거를 형성하는 인시던트에 대한 원자성 정보입니다. 사실 추출을 마치려면 몇 분 정도 걸릴 수 있습니다.
1. 사실 추출이 완료되면 다음과 같은 영역에서 사용 가능한 사실을 검토할 수 있습니다.
1. **인시던트 개요** - 심각도, 기간, 운영 가설을 비롯한 인시던트에 대한 대략적인 개요입니다.
1. **영향 평가** - 인시던트가 고객, 서비스 기능, 비즈니스 운영에 미치는 영향과 관련된 지표 및 분석입니다.
1. **감지 및 대응** - 인시던트를 탐지한 방법과 시점, 인시던트에 대응한 방법과 관련된 지표 및 분석입니다.
1. **근본 원인 분석** - 조사 가설을 기반으로 근본적인 원인을 자세히 분석합니다.
1. **완화 및 해결** - 완화 단계 및 해결 조치와 관련된 지표 및 분석으로, 인시던트 완화 및 해결에 걸리는 시간을 측정한 값도 함께 다룹니다.
1. **학습 및 다음 단계** - 팀원 전체가 고려해야 할 권장 조치 목록으로, 조사 결과를 통해 자동으로 생성됩니다. 이러한 권장 사항에는 유사한 인시던트에 대한 예방 조치, 모니터링 및 대응 프로세스에 대한 권장 개선 사항이 포함될 수 있습니다.
1. 사실을 검토한 후, **보고서 생성**을 선택하여 인시던트에 대한 포괄적인 분석을 생성합니다. 선택된 사실은 핵심적인 참조 기준 역할을 하는 반면, 보고서는 조사 동안 수집된 모든 사용 가능한 정보를 가져옵니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
1. 보고서를 생성한 후 다음 작업 중 하나를 수행할 수 있습니다.
+ 보고서를 있는 그대로 사용:
+ 필요한 경우 이를 복사하여 외부 편집기에서 편집합니다.
+ 나중에 참조할 수 있도록 저장합니다.
+ 데이터를 더 추가하여 보고서 개선:
+ **Add facts**(권장 방법)를 선택하여 인시던트 티켓 또는 사용자 지정 서술 같은 추가적인 텍스트 기반 콘텐츠를 입력합니다. AI가 이 콘텐츠를 분석하여 기존 사실을 보강하거나 새로운 사실을 추론합니다.
+ 사실을 직접 편집(매우 제한적으로 사용) - 수동으로 편집한 사실은 조사 타임라인과 일치하지 않을 수 있습니다. **Add facts**를 선택했을 때 원하는 결과를 달성하지 못한 경우에만 최후의 수단으로 사용해야 합니다.
+ **보고서 재생성**을 선택해 업데이트된 정보를 사용하여 새 보고서를 생성합니다.
**Topics**
+ [인시던트 보고서에 있는 AI 도출 사실에 대한 이해](Investigations-IncidentReports-ai-facts.md)
+ [인시던트 보고서 용어](Investigations-IncidentReports-terms.md)
+ [조사에서 보고서 생성](Investigations-IncidentReports-Generate.md)
+ [인시던트 보고서에서 5 Whys 분석 사용](incident-report-5whys.md)
# 인시던트 보고서에 있는 AI 도출 사실에 대한 이해
AI 도출 사실은 CloudWatch 조사 인시던트 보고서의 토대를 형성합니다. 이러한 사실은 AI 시스템이 AWS 환경에 대한 포괄적인 분석에 기반했을 때 객관적으로 참이거나, 참일 가능성이 높다고 간주하는 정보를 나타냅니다. 이러한 사실은 기계 학습 패턴 인식과 체계적인 확인 방법을 결합한 정교한 프로세스를 통해 도출됩니다. 이로 인해 인시던트 분석을 위한 강력한 프레임워크가 생성되어, 프로덕션 환경에 필요한 운영 엄격성을 유지할 수 있습니다.
AI 도출 사실을 개발하는 방법을 잘 이해하면 인시던트 대응 과정에서 신뢰성을 평가하고 정보에 입각한 결정을 내리는 데 도움이 됩니다. 이러한 프로세스는 인공 지능이 인간의 전문 지식을 대체하는 게 아니라 한층 더 강화하는 하이브리드 접근 방식을 나타냅니다. 이와 같은 하이브리드 접근 방식을 통해 포괄적이고 신뢰할 수 있는 인사이트가 생성됩니다.
## AI 도출 사실을 개발하는 프로세스
원시 원격 분석 데이터에서 출발하여 실행 가능한 AI 도출 사실을 이끌어내는 여정은 패턴 관찰에서 시작됩니다. 이 과정에서 CloudWatch 조사 AI는 정교한 기계 학습 알고리즘을 사용하여 방대한 양의 AWS 원격 분석을 분석합니다. AI는 여러 차원 전체에서 CloudWatch 지표, 로그, 트레이스를 동시에 검사하여 인간 작업자가 즉시 명확하게 파악하지 못할 수 있는 반복 패턴 및 관계를 식별합니다. 분석에는 인시던트가 일반적으로 발생하는 시기와 지속 시간의 특성을 보여주는 시간 패턴, 실패 시나리오 발생 시 다양한 AWS 서비스가 상호 작용하는 방식을 보여주는 서비스 상관관계, 인시던트 이전에 나타나거나 인시던트와 함께 나타나는 지표 이상 징후, 특정한 실패 모드를 나타내는 로그 이벤트 시퀀스가 포함됩니다.
예를 들어 애플리케이션 응답 시간이 허용 가능한 임곗값을 초과하기 약 15분 전마다 Amazon EC2 인스턴스 CPU 사용률이 90% 이상으로 일관되게 급증하는 경우를 가정해 보겠습니다. 이때 AI가 이러한 스파이크 현상을 어떤 방식으로 관찰할지 생각해 보세요. 이러한 시간적 관계가 여러 인시던트에서 관찰될 경우, 추가적으로 조사할 가치가 있는 중요한 패턴이 됩니다. AI는 단순히 상관관계만 기록하는 것이 아니라, 관계의 통계적 유의성을 측정하고 패턴에 영향을 미칠 수 있는 다양한 교란 요인을 고려합니다.
이러한 관찰된 패턴을 토대로 AI는 가설 생성 단계로 넘어간 후, 발견된 관계에 대한 잠재적인 설명을 구성합니다. 이 프로세스에는 여러 가지 상충되는 가설을 생성하고, 뒷받침 증거의 신빙성을 기반으로 확률에 따라 순위를 매기는 작업이 포함됩니다. AI가 관찰했을 때 응답 시간 저하보다 CPU 스파이크가 먼저 일어날 경우, AI는 몇 가지 가설을 생성할 수 있습니다. 컴퓨팅 용량 부족으로 인한 리소스 소진, CPU 오버헤드 증가를 유발하는 메모리 누수, 특정 입력 패턴에 의해 트리거되는 비효율적인 알고리즘 등이 이에 해당됩니다. 각 가설은 관찰된 데이터를 얼마나 잘 설명하는지, 그리고 알려진 AWS 서비스 동작에 얼마나 잘 부합하는지에 따라 예비 신뢰도가 부여됩니다.
이러한 가설을 사람이 확인하고 검증하는 단계를 거쳐 이러한 AI 생성 인사이트가 운영 표준을 충족하도록 보장합니다. 그런 후에야 AI 생성 인사이트를 인시던트 보고서에 사실로 기록합니다. 이 프로세스에는 AI 도출 패턴과 기존의 확립된 AWS 서비스 동작 모델의 상관관계를 분석하고, 인시던트 대응에 대한 업계 모범 사례와 일치하는지 확인하고, 유사한 환경의 과거 인시던트 데이터와 대조하여 검증하는 작업이 포함됩니다. AI는 도출한 발견 결과가 다양한 분석 방법 및 기간에 걸쳐 재현 가능한지, 운영 의사 결정에 필요한 통계적 유의성 요건을 충족하는지, AWS 서비스 동작의 실증적 관찰 결과와 일치하는지, 인시던트 해결 또는 예방을 위한 실행 가능한 인사이트를 제공하는지 여부를 입증해야 합니다.
이러한 프로세스 전체에서 AI는 몇 가지 고유한 문제에 직면하게 되는데, 작업자는 AI 도출 사실을 해석할 때 이러한 점을 이해해야 합니다. 상관관계와 인과관계를 구분하는 것은 여전히 근본적인 과제입니다. AI는 네트워크 트래픽 스파이크와 인시던트 발생 간의 뚜렷한 상관관계를 식별할 수 있지만, 직접적인 인과관계를 확립하려면 추가적인 조사와 특정 분야에 대한 전문 지식이 필요합니다. 이를테면 서드 파티 서비스 종속성 또는 외부 네트워크 공급자 문제처럼, AWS 원격 분석의 범위를 벗어나는 숨겨진 변수는 AI 분석에 캡처되지 않은 채로 인시던트에 영향을 미칠 수 있습니다. AI 도출 사실의 품질은 전적으로 기본 CloudWatch 데이터의 완전성과 정확성에 달려 있으므로, 신뢰할 수 있는 인사이트를 얻으려면 포괄적인 모니터링 범위가 필수적입니다.
새로운 인시던트 패턴은 AI 훈련 데이터에 존재하지 않으므로 또 다른 문제로 작용하며, AI는 익숙하지 않은 실패 모드를 해석하는 데 어려움을 겪을 때가 많습니다. 이런 제약이 있기 때문에 AI 도출 사실을 해석한 후 전문 분야에 대한 지식이 있고 맥락을 이해하는 사람이 그 내용을 보완해야 하며, 이 과정에서 사람의 전문 지식이 매우 중요합니다.
## 인시던트 대응 시 AI 도출 사실 적용
AI는 사람이 수동으로 분석하는 게 불가능한 대규모 데이터세트 전체에서 패턴을 식별하는 기능이 뛰어나므로, 인시던트 진단 및 해결에 걸리는 시간을 크게 단축할 수 있는 인사이트를 제공합니다. AI는 맥락을 제시하고, 결론을 검증하고, 원격 분석 데이터에 캡처되지 않을 가능성이 있는 요소를 식별할 수 있는 사람의 전문 지식과 함께 사용했을 때 가장 효과적입니다.
가장 효과적으로 접근하려면 AI 도출 사실을 확정적인 결론이 아닌, 고도의 정보에 입각한 조사의 시작점으로 생각해야 합니다. '인시던트가 발생하기 8분 전에 데이터베이스 연결 풀 소진이 먼저 발생했다'는 사실을 AI가 식별한 경우, 이는 데이터베이스 지표 및 애플리케이션 로그를 타겟 분석하여 신속하게 확인할 수 있는 중요한 단서를 제공합니다. 이러한 '사실'을 통해 작업자는 어떤 구체적인 기간과 잠재적인 근본 원인을 조사해야 하는지 알 수 있으므로, 사용 가능한 모든 원격 분석을 수동으로 검색하는 것에 비해 문제를 식별하는 데 필요한 시간이 크게 줄어듭니다.
데이터 품질은 AI 파생 사실의 신뢰성에 중요한 역할을 합니다. 포괄적인 CloudWatch 모니터링 적용 범위를 활용하면 AI가 분석에 필요한 완전하고 정확한 정보에 액세스할 수 있습니다. 모니터링에 간극이 있으면 불완전한 또는 허위 사실이 도출될 수 있습니다. AI는 오로지 주어진 데이터로만 작업할 수 있기 때문입니다. 자세한 지표 수집, 포괄적인 로깅, 분산 추적을 비롯하여 꼼꼼한 관찰성 방식을 활용하는 조직은 인시던트 보고서에 정확하고 실행 가능한 AI 파생 사실을 담아낼 수 있는 가능성이 더 높습니다.
# 인시던트 보고서 용어
CloudWatch 조사 인시던트 보고서에는 다음과 같은 용어가 사용됩니다.
AI 파생 사실(AI-derived fact)
AWS 서비스 내에서 사용 가능한 데이터, 원격 분석, 로그, 기록 패턴을 기반으로 AI 시스템이 객관적으로 참이거나 참일 가능성이 높다고 간주하는 정보 또는 관찰 결과입니다. 이러한 '사실'은 알고리즘 분석 및 기계 학습 모델을 통해 도출되며, 시스템에서 신뢰할 수 있는 것으로 처리되지만 사람의 확인을 거쳐야 합니다. 중요한 의사 결정 맥락에서는 더욱 그렇습니다. AI 파생 사실에는 이벤트, 이상 탐지 또는 인간 작업자가 즉시 명확하게 파악하지 못할 수 있는 시스템 동작에 대한 추론의 상관관계가 포함될 수 있습니다.
시정 조치(Corrective actions)
AWS 모범 사례 및 영향을 받은 리소스의 특정 컨텍스트를 기반으로 인시던트의 근본 원인을 해결하고 재발을 방지하기 위해 CloudWatch 조사에서 권장하는 구체적이고 실행 가능한 단계입니다.
사실 범주(Fact categories)
보고서 생성을 위한 데이터를 구성하는 데 사용되는 영향 지표, 탐지 세부 정보, 완화 단계 등과 같은 인시던트 관련 정보를 구조적으로 그룹화한 것입니다.
영향 평가(Impact assessment)
인시던트가 시스템 성능, 사용자 경험, 비즈니스 운영에 미치는 영향을 정량적 및 정성적으로 평가합니다. 이러한 평가는 CloudWatch 지표 및 조사에 추가된 기타 AWS 서비스 데이터에서 도출됩니다.
인시던트 보고서 생성(Incident report generation)
CloudWatch 조사 기능의 조사 과정에서 수집된 데이터를 기반으로 타임라인, 영향, 근본 원인, 해결 단계를 비롯하여 운영 인시던트에 대한 포괄적인 문서를 생성하는 자동화된 프로세스입니다.
조사 피드(Investigation Feed)
CloudWatch 조사 기능의 조사 내에서 수락된 관찰 결과, 가설, 사용자가 추가한 메모를 시간순으로 표시하여, 조사 진행 상황 및 조사 결과의 기본 레코드 역할을 합니다.
학습한 교훈(Lessons learned)
인시던트 조사 프로세스를 통해 식별되는 자동 생성된 인사이트 및 개선 기회로, 조직 전체의 시스템 신뢰성, 운영 효율성, 인시던트 대응 역량을 강화하는 것이 목적입니다.
평가 보고서(Report assessment)
생성된 인시던트 보고서를 자동으로 평가하여, 보고서의 완전성과 품질을 개선하기 위해 추가 정보가 필요한 잠재적인 데이터 격차 또는 영역을 식별합니다.
근본 원인 분석(Root cause analysis)
운영 문제의 근본 원인을 식별하는 체계적인 프로세스로, CloudWatch 조사 기능을 통해 도출한 AI 기반 가설과 여러 AWS 서비스의 상관관계 분석을 활용합니다.
제안 탭(Suggestions tab)
CloudWatch 조사의 한 가지 기능으로, 시스템 원격 분석 및 로그 분석을 토대로 잠재적 원인 또는 관련 문제에 대해 AI가 관찰 결과 및 가설을 생성하여 제공합니다.
타임라인 이벤트(Timeline events)
인시던트 동안 발생한 중요한 사건을 시간순으로 나타낸 것으로, 인시던트 진행에 대한 명확한 개요를 제공하기 위해 CloudWatch 로그, 지표 및 기타 AWS 서비스 데이터에서 자동으로 추출됩니다.
# 조사에서 보고서 생성
진행 중이거나 완료된 조사에서 인시던트 보고서를 생성할 수 있습니다. 조사 초기에 생성된 인시던트 보고서에는 근본 원인 및 권장 조치 같은 주요 정보가 포함되지 않을 수 있습니다. 조사가 활성화되어 있는 동안에는 제공되는 사실을 편집하여 추가 정보를 통해 조사를 보완할 수 있습니다. 조사가 종료된 후에는 조사에서 사실을 편집하거나 추가할 수 없습니다.
**사전 조건**
인시던트를 생성하기 전에 다음과 같은 요구 사항을 충족하는지 확인합니다.
+ 조사 그룹이 필요한 KMS 키를 사용 중이고, AWS 서비스에서 데이터를 해독하기 위한 역할에 올바른 IAM 정책이 연결되어 있는지 확인합니다. AWS 리소스가 고객 관리형 KMS 키로 암호화된 경우, 조사 그룹 역할에 IAM 정책 문을 추가하여 이러한 데이터를 해독하고 액세스하는 데 필요한 권한을 CloudWatch 조사에 부여해야 합니다.
+ 조사 그룹 역할에 다음과 같은 권한이 부여되었습니다.
+ `aiops:GetInvestigation`
+ `aiops:ListInvestigationEvents`
+ `aiops:GetInvestigationEvent`
+ `aiops:PutFact`
+ `aiops:UpdateReport`
+ `aiops:CreateReport`
+ `aiops:GetReport`
+ `aiops:ListFacts`
+ `aiops:GetFact`
+ `aiops:GetFactVersions`
**참고**
이러한 권한을 조사 그룹 역할에 인라인 정책으로 추가하거나, 추가적인 권한 정책을 조사 그룹 역할에 연결할 수 있습니다. 자세한 내용은 [인시던트 보고서 생성 권한](Investigations-Security.md#Investigations-Security-IAM-IRG) 단원을 참조하십시오.
새로운 관리형 정책인 `AIOpsAssistantIncidentReportPolicy`는 필요한 권한을 제공하며, 2025년 10월 10일 이후 을 사용하여 생성된 조사 그룹에는 이 정책이 자동으로 추가됩니다. 자세한 내용은 [AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy) 섹션을 참조하세요.
**인시던트 보고서를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **AI Operations**, **조사**를 선택합니다.
1. 조사의 이름을 선택합니다.
1. 조사 페이지의 **피드**에서 관련 가설을 수락한 후, 추가 메모를 조사에 추가합니다.
**참고**
보고서를 생성하려면 하나 이상의 수락된 가설이 포함된 조사가 필요합니다.
1. 조사 페이지의 맨 위에서 **인시던트 보고서**를 선택합니다. 조사를 통해 발견한 관련 사실을 수집하고 동기화하는 동안 기다립니다.
1. **인시던트 보고서** 페이지에서 보고서를 생성하는 데 사용되고 있는 사실을 검토합니다. 사실은 오른쪽 창에서 확인할 수 있습니다. 왼쪽 및 오른쪽 화살표를 사용하여 사실 범주 탭을 탐색하거나, 창을 펼쳐서 모든 범주를 확인합니다.
1. 사실 패널에서 **편집**을 선택하여 해당 범주의 데이터를 수동으로 추가하거나 편집합니다.
1. 사실 패널에서 **세부 정보 보기**를 선택하여 AI 어시스턴트가 수집한 뒷받침 증거 및 팩트 히스토리를 확인합니다. 사실 세부 정보 창에서 **편집**을 선택해도 됩니다.
1. 외부 이벤트 또는 정상 참작이 가능한 상황 같은 추가 컨텍스트를 조사에 제공하려면 **Add facts**를 선택합니다.
1. **보고서 생성**을 선택합니다.
CloudWatch 조사는 조사 데이터를 분석하고 구조화된 보고서를 생성합니다. 이 프로세스는 다소 시간이 걸릴 수 있습니다.
1. 미리 보기 창에서 생성된 보고서를 검토합니다. 보고서에는 다음 내용이 포함됩니다.
+ 자동으로 추출된 타임라인 이벤트
+ 수락한 가설을 토대로 한 근본 원인 분석
+ 조사 원격 분석에서 도출한 영향 평가
+ 권장 수정 조치 및 AWS 모범 사례에 따라 학습한 교훈
1. 보고서 사본을 다른 위치에 보관하려면 보고서의 텍스트를 복사한 후 원하는 위치에 붙여 넣도록 선택하면 됩니다.
1. **보고서 평가** 선택하여 보고서의 데이터 격차 목록을 검토합니다. 이 정보를 사용하여 보고서에 대한 추가 데이터를 수집한 다음, 그에 따라 사실을 업데이트한 후 보고서를 재생성할 수 있습니다.
# 인시던트 보고서에서 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](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) 또는 [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) 관리형 정책을 사용자 또는 역할에 연결하여 추가할 수 있습니다.
## 5 Whys 분석이란?
5 Whys는 인시던트 증상에서 출발하여 근본 원인에 도달할 때까지 자세히 파악하기 위해 '이유'를 반복적으로 묻는 근본 원인 분석 기법입니다. 각 답변은 다음 질문의 근거가 되므로, 단순히 표면적인 증상이 아닌 진정한 근본 원인을 밝히는 논리적 연결 고리를 만듭니다.
인시던트 보고서를 생성하는 동안, CloudWatch 조사 기능은 이 방법을 사용하여 조사 결과를 분석하며 당장의 기술적 실패를 넘어 프로세스, 구성 또는 시스템 문제를 식별하는 구조화된 근본 원인 분석을 제공합니다.
## 인시던트 보고의 이점
인시던트 보고서에 5 Whys 분석을 포함하면 여러 가지 이점이 제공됩니다.
+ **포괄적인 근본 원인 식별** - 당장의 기술적인 원인을 넘어 기본 프로세스 또는 시스템 문제를 식별합니다.
+ **실행 가능한 문제 해결 계획** - 임시 방편이 아닌 재발을 방지하기 위한 구체적이고 타겟팅된 조치를 제공합니다.
+ **조직의 학습** - 향후 참조할 수 있고 팀 지식을 공유할 수 있도록 전체 인과 고리를 문서화합니다.
+ **구조화된 분석** - 임시 방편의 문제 해결이 아닌 체계적인 조사를 보장합니다.
## 인시던트 보고서의 예제 시나리오
### 데이터베이스 연결 실패 인시던트
**초기 인시던트:** 500가지 오류가 광범위하게 발생한 전자상거래 애플리케이션
1. **이유 1:** 사용자에게 500가지 오류가 발생한 이유는 무엇인가요? 애플리케이션이 프라이머리 데이터베이스에 연결할 수 없습니다.
1. **이유 2:** 애플리케이션이 해당 데이터베이스에 연결할 수 없는 이유는 무엇인가요? 데이터베이스 인스턴스의 가용 연결 수가 부족합니다.
1. **이유 3:** 데이터베이스 연결 수가 부족한 이유는 무엇인가요? 배치 처리 작업을 제대로 종료하지 않은 상태에서 많은 연결을 열었습니다.
1. **이유 4:** 배치 작업이 연결을 제대로 종료하지 않은 이유는 무엇인가요? 작업의 오류 처리에 실패 시나리오 발생 시 연결을 정리하는 내용이 포함되지 않았습니다.
1. **이유 5:** 올바른 오류 처리가 구현되지 않은 이유는 무엇인가요? 코드 검토 프로세스에 리소스 관리 패턴을 위한 특정 검사가 포함되지 않았습니다.
**근본 원인:** 리소스 관리에 부적합한 코드 검토 표준
**권장 조치:** 코드 검토 체크리스트 업데이트, 연결 풀링 모니터링 구현, 자동 리소스 누수 감지 추가
### 성능 저하 인시던트
**초기 인시던트:** 트래픽 스파이크가 발생한 동안 API 응답 시간이 200ms에서 5000ms로 증가했습니다.
1. **이유 1:** 응답 시간이 증가한 이유는 무엇인가요? CPU 사용률이 모든 애플리케이션 인스턴스에서 100%에 도달했습니다.
1. **이유 2:** 오토 스케일링을 통해 인스턴스가 더 추가되지 않은 이유는 무엇인가요? 오토 스케일링이 트리거되었지만 새 인스턴스가 상태 확인에 실패했습니다.
1. **이유 3:** 새 인스턴스가 상태 확인에 실패한 이유는 무엇인가요? 애플리케이션 시작 프로세스에 8분이 소요되는데, 이는 상태 확인 제한 시간을 초과하는 시간입니다.
1. **이유 4:** 시작 시간이 오래 걸리는 이유는 무엇인가요? 애플리케이션이 시작할 때마다 S3에서 대용량 구성 파일을 다운로드합니다.
1. **이유 5:** 오토 스케일링 구성에서 이러한 시작 지연을 고려하지 않는 이유는 무엇인가요? 성능 테스트를 콜드 스타트가 아닌 사전 워밍된 인스턴스로 수행했습니다.
**근본 원인:** 성능 테스트 방법론에 프로덕션 오토 스케일링 시나리오가 반영되지 않았습니다.
**권장 조치:** 콜드 스타트 테스트 포함, 애플리케이션 시작 최적화, 상태 확인 제한 시간 조정, 구성 캐싱 구현
### 브랜치 분석을 활용하는 복잡한 인시던트
**초기 인시던트:** OpenSearch Serverless 고객이 11시간 동안 가용성이 48.3% 저하되는 경험을 함
**주요 분석 연결 고리:**
1. **이유 1:** 고객이 서비스 저하를 겪은 이유는 무엇인가요? 수집기의 규모 조정이 잘못되어 서비스 가용성이 48.3%로 떨어졌습니다.
1. **이유 2:** 수집기의 규모 조정이 잘못된 이유는 무엇인가요? CortexOperator에서 AZ 밸런스 계산 오류로 인해 수집기 수를 223개에서 174개로 줄였습니다.
1. **이유 3:** CortexOperator에서 AZ 밸런스를 잘못 계산한 이유는 무엇인가요? 버전 1.17 업그레이드 후 코드가 새 Kubernetes 레이블 형식을 처리하지 못했습니다.
1. **이유 4(브랜치 A - 기술):** 코드가 새 레이블 형식을 처리하지 못한 이유는 무엇인가요? 코드에서는 'failure-domain.beta.kubernetes.io/zone' 레이블을 예상했지만 Kubernetes 1.17은 'topology.kubernetes.io/zone'으로 변경되었습니다.
1. **이유 5(브랜치 A):** 이전 버전과의 호환성이 구현되지 않은 이유는 무엇인가요? 배포 계획 중에 검토한 업그레이드 정보에 레이블 형식 변경이 문서화되지 않았습니다.
**브랜치 B - 프로세스 분석:**
1. **이유 4(브랜치 B - 프로세스):** 이 내용이 테스트에서 발견되지 않은 이유는 무엇인가요? 통합 테스트에서 이전 레이블 형식의 사전 구성된 클러스터를 사용했습니다.
1. **이유 5(브랜치 B):** 테스트에 레이블 형식 검증이 포함되지 않은 이유는 무엇인가요? 테스트 환경 설정이 프로덕션 Kubernetes 버전 업그레이드 시퀀스를 미러링하지 않았습니다.
**식별된 근본 원인:**
+ 기술: Kubernetes 레이블 형식 변경 사항을 위한 이전 버전과의 호환성 누락
+ 프로세스: 테스트 방법론에서 버전 업그레이드가 미치는 영향을 검증하지 않음
**통합 문제 해결 계획:** 레이블 형식 탐지 로직을 구현하고, 업그레이드 테스트 절차를 개선하고, 자동 호환성 검증을 추가하고, 버전 변경이 미치는 영향을 평가하는 프로세스를 설정합니다.
## 가이드형 5 Whys 워크플로 사용
CloudWatch 조사 기능에서는 누락된 사실을 해결하고, 인시던트 보고서를 강화하는 데 도움이 되는 가이드형 5 Whys 분석 워크플로를 제공합니다. 이 기능은 시스템에서 근본 원인 분석을 개선할 기회를 식별할 때 권장 워크플로로 표시됩니다.
### 대화형 분석 경험
CloudWatch 조사 기능의 5 Whys 분석은 조사 프로세스를 안내하는 대화형 채팅에 기반한 접근 방식을 사용합니다. 이러한 대화형 방법은 질문 간의 논리적 흐름을 유지하면서 포괄적인 분석을 보장하는 데 도움이 됩니다.
**대화형 경험의 주요 기능:**
+ **사실에 기반한 초기화** - 시스템에서는 조사를 통해 얻은 관련 사실을 미리 제시하므로, 이를 사용하여 명확한 답변을 미리 입력하고 사실 기반 제안과 추론 기반 제안을 명확하게 표시합니다.
+ **가이드형 탐색** - '이유'를 묻는 각 질문에 대해 시스템에서는 사용 가능한 사실을 기반으로 답변을 제안하고, 특정한 추가 컨텍스트를 요청하고, 계속 진행하기 전에 중요한 요소를 고려하도록 안내합니다.
+ **브랜치 관리** - 원인 제공 요인이 여러 개인 것으로 식별될 경우 시스템에서는 브랜치 옵션을 명확하게 제시하고, 브랜치 간의 관계를 설명하고, 병렬 조사의 우선순위를 정하는 데 도움이 됩니다.
+ **점진적 검증** - 각 응답에 대해 시스템에서는 명확성을 위해 답변을 재구성하고, 확인을 요청하고, 핵심 인사이트를 강조 표시하고, 조사 결과를 더 광범위한 컨텍스트에 연결합니다.
이러한 접근 방식을 사용하면 가장 중요한 인과관계에 중점을 두면서 모든 관련 정보를 캡처할 수 있습니다.
**가이드형 워크플로에 액세스:**
1. 인시던트 보고서를 생성하는 동안 오른쪽 패널의 **Facts need attention** 섹션을 검토합니다.
1. **Suggested workflow**에서 **Guided 5-Whys analysis** 제안을 찾습니다.
1. **Guide me**를 선택하여 대화형 5 Whys 프로세스를 시작합니다.
1. 가이드형 프롬프트에 따라 '이유'를 묻는 각각의 질문을 체계적으로 진행하여 증상에서 근본 원인까지 전체 인과관계를 구축합니다.
가이드형 워크플로는 5 Whys 방법론의 각 단계를 안내하여 포괄적인 근본 원인 정보를 캡처할 수 있도록 지원합니다. 분석 결과가 인시던트 보고서에 자동으로 통합되므로, 인시던트 발생 후 검토 및 조직의 학습을 위한 구조화된 설명서가 제공됩니다.
또한 채팅 인터페이스를 통해 '이 인시던트에 대한 5 Whys 분석을 수행해 주세요' 또는 '5 Whys 방법론을 사용했을 때 근본 원인은 무엇인가요?' 등과 같은 질문을 하여 5 Whys 분석을 요청할 수 있습니다.
## 원인이 여러 개인 복잡한 인시던트 처리
일부 인시던트는 원인 제공 요인이 여러 가지이며, 이 경우 병렬 분석 경로가 필요합니다. CloudWatch 조사에서는 브랜치 분석을 지원하여 모든 중요한 원인을 식별하고 해결할 수 있도록 보장합니다.
**브랜치 분석이 필요한 경우:**
+ 여러 단독 실패가 동시에 발생함
+ 서로 다른 시스템 구성 요소가 동일한 고객 영향에 원인을 제공하고 있음
+ 기술 실패와 프로세스 실패가 둘 다 중대한 요인으로 작용함
+ 연쇄적인 실패로 인해 여러 개의 인과 연결 고리가 생성됨
**브랜치 분석 프로세스:**
1. **브랜치 식별** - 여러 개의 원인이 수렴하거나 발산하는 지점이 식별됩니다.
1. **병렬 조사** - 완전한 5 Whys 방법론을 사용하여 각 브랜치를 분석합니다.
1. **연결 매핑** - 브랜치 간의 관계를 문서화하여 서로 어떻게 상호 작용하는지 나타냅니다.
1. **통합형 문제 해결** - 해결 계획을 통해 지금까지 식별된 모든 근본 원인과 상호 작용을 해결합니다.
이러한 포괄적인 접근 방식을 활용하면 복잡한 인시던트를 꼼꼼히 분석하고, 최종 문제 해결 계획에서 모든 원인 제공 요인을 해결할 수 있습니다.
## 효과적인 5 Whys 분석을 위한 모범 사례
인시던트 보고서에서 5 Whys 분석의 효과를 극대화하려면 운영 경험에서 도출된 다음과 같은 모범 사례를 따르시기 바랍니다.
### 질문 구성 지침
+ **고객 영향에서 시작** - 고객에게 직접 영향을 미치는 문제를 기점으로 각 분석을 시작하여 비즈니스 영향을 중점적으로 다룹니다.
+ **점진적으로 심층적인 기술 다루기** - 질문을 진행하면서 비즈니스 영향에서 기술적인 세부 사항으로 주제를 옮겨갑니다.
+ **논리적 연속성 유지** - 논리적 간극 없이 각각의 답변이 자연스럽게 다음 질문으로 이어지도록 합니다.
+ **뒷받침 증거 포함** - 특정 지표, 로그 또는 타임라인 이벤트를 참조하여 각각의 답변을 검증합니다.
### 분석 검증
다음과 같은 기준을 사용하여 5 Whys 분석을 검증합니다.
+ **논리적 흐름** - 누락된 단계 없이 증상에서 근본 원인까지 명확하게 진행
+ **기술 정확도** - 올바른 용어, 정확한 시스템 동작 설명, 올바른 구성 요소 상호 작용
+ **완전성** - 관찰된 모든 증상을 분석을 통해 설명하고, 증상이 해결된 경우 재발을 방지할 근본적인 원인에 도달해야 합니다.
+ **실행 가능성** - 식별된 근본 원인은 구체적이고 구현 가능한 문제 해결 조치로 이어져아 합니다.
### 피해야 할 일반적인 위험
+ **증상 발생 시 중단** - 처음으로 기술 실패가 발생한 경우 분석을 종료하지 말고 시스템 또는 프로세스 원인에 도달할 때까지 계속 진행합니다.
+ **책임 소재에 중점을 둔 분석** - 개별 작업이 아닌 시스템 및 프로세스 실패에 중점을 둡니다.
+ **단일 경로에 기반한 생각** - 여러 가지 원인 제공 요인을 고려하고, 적절한 경우 브랜치 분석을 사용합니다.
+ **증거 부족** - 각 답변이 조사를 통한 구체적인 데이터에 의해 뒷받침되는지 확인합니다.
### 인시던트 보고서 섹션과 통합
5 Whys 분석은 인시던트 보고서의 다른 섹션과 통합되어 포괄적인 설명서를 제공할 수 있습니다.
+ **타임라인 상관관계** - '이유'를 묻는 각 질문은 특정 타임라인 이벤트를 참조할 수 있으므로, 인과관계에 대한 시간적 컨텍스트가 제공됩니다.
+ **지표 검증** - 묘사된 기술의 동작을 보여주는 지표 및 그래프를 통해 답변을 뒷받침합니다.
+ **영향 평가 조정** - 영향 평가 섹션에 설명된 고객 영향 지표에 첫 번째 '이유'가 직접 연결됩니다.
+ **학습한 교훈 기반** - 5 Whys 분석을 통해 식별된 근본 원인은 학습한 교훈 및 수정 조치 섹션에 직접적으로 정보를 제공하는 역할을 합니다.
이러한 통합으로 인해 인시던트 보고서 전체의 일관성을 보장하며, 초기 증상에서 근본 원인, 문제 해결 계획에 이르는 완전하고 일관된 서술 자료를 이해관계자에게 제공할 수 있습니다.