

AWS Systems Manager Incident Manager 는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [AWS Systems Manager Incident Manager 가용성 변경](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html)을 참조하세요.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Incident Manager의 인시던트 수명 주기
<a name="incident-lifecycle"></a>

AWS Systems Manager Incident Manager 는 서비스 중단 또는 보안 위협과 같은 인시던트를 식별하고 이에 대응하기 위한 모범 사례를 기반으로 step-by-step 프레임워크를 제공합니다. Insident Manager의 주요 초점은 완전한 인시던트 라이프사이클 관리 솔루션을 통해 영향을 받는 서비스 또는 애플리케이션을 최대한 빨리 정상 상태로 복원할 수 있도록 지원하는 것입니다.

다음 그림과 같이 Incident Manager는 인시던트 수명 주기의 모든 단계에 대한 도구와 모범 사례를 제공합니다.
+ [알림 및 참여](#alerting-engagement)
+ [심사](#triage)
+ [조사 및 완화](#investigation-mitigation)
+ [인시던트 사후 분석](#lifecycle-post-incident-analysis)

![\[인시던트 수명 주기에는 알림, 참여, 분류, 조사 및 분석이 포함됩니다.\]](http://docs.aws.amazon.com/ko_kr/incident-manager/latest/userguide/images/incident-lifecycle.png)


## 알림 및 참여
<a name="alerting-engagement"></a>

인시던트 라이프사이클의 알림 및 참여 단계는 애플리케이션 및 서비스 내에서 인시던트를 인지하는 데 중점을 둡니다. 이 단계는 인시던트가 감지되기 전에 시작되며 애플리케이션에 대한 깊은 이해가 필요합니다. [Amazon CloudWatch 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)를 사용하여 애플리케이션의 성능에 대한 데이터를 모니터링하거나 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/)를 사용하여 다양한 소스, 애플리케이션 및 서비스의 알림을 집계할 수 있습니다. 애플리케이션에 대한 모니터링을 설정한 후에는 과거 기준을 벗어나는 지표에 대해 경고를 보낼 수 있습니다. 모니터링 모범 사례에 대한 자세한 내용은 [모니터링](incident-response.md#incident-response-monitoring)을 참조하세요.

대응 담당자의 인시던트 진단을 지원하기 위해 Incident Manager에서 조사 결과 기능을 활성화할 수 있습니다. 조사 결과는 인시던트 발생 시점 즈음에 발생한 AWS CodeDeploy 배포 및 AWS CloudFormation 스택 업데이트에 대한 정보입니다. 이 정보가 있으면 잠재적 원인을 평가하는 데 필요한 시간이 줄어들어 인시던트의 평균 복구 시간(MTTR)을 줄일 수 있습니다.

이제 애플리케이션에서 인시던트를 모니터링하고 있으므로 인시던트 중에 사용할 인시던트 *대응 계획*을 정의할 수 있습니다. 대응 계획 생성에 대한 자세한 내용은 [Incident Manager에서 대응 계획 생성 및 구성](response-plans.md) 섹션을 참조하세요. Amazon EventBridge 이벤트 또는 CloudWatch 경보는 대응 계획을 템플릿으로 사용하여 자동으로 인시던트를 생성할 수 있습니다. 인시던트 생성에 대한 자세한 내용은 [Incident Manager에서 자동으로 또는 수동으로 인시던트 생성](incident-creation.md)을 참조하세요.

대응 계획은 관련 *에스컬레이션 계획* 및 *참여 계획*을 수립하여 최초 대응 인력을 인시던트에 투입합니다. 에스컬레이션 계획 설정에 대한 자세한 내용은 [에스컬레이션 계획 만들기](escalation.md#escalation-create) 섹션을 참조하세요. 동시에 채팅 애플리케이션의 Amazon Q Developer는 채팅 *채널을* 사용하여 대응자에게 인시던트 세부 정보 페이지로 안내하는 알림을 보냅니다. 팀은 채팅 채널과 *인시던트 세부 정보*를 사용하여 의견을 교환하고 인시던트를 분류할 수 있습니다. Incident Manager의 채팅 채널 설정에 대한 자세한 내용은 [작업 2: 채팅 애플리케이션의 Amazon Q Developer에서 채팅 채널 생성](chat.md#chat-create) 섹션을 참조하세요.

## 심사
<a name="triage"></a>

심사는 최초 대응 담당자가 고객에게 미치는 영향을 파악하는 것을 말합니다. Incident Manager 콘솔의 인시던트 세부 정보 보기는 대응 담당자가 인시던트를 평가하는 데 도움이 되는 타임라인과 지표를 제공합니다. 또한 인시던트의 영향을 평가하면 인시던트에 대한 대응 시간, 해결 및 커뮤니케이션을 위한 토대를 마련할 수 있습니다. 대응 담당자는 1(중요)에서 5(영향 없음)까지의 영향 등급을 사용하여 인시던트의 우선 순위를 정합니다.

조직은 원하는 대로 각 영향 등급의 정확한 범위를 정의할 수 있습니다. 다음 표에는 각 영향 수준이 일반적으로 정의되는 방법의 예가 나와 있습니다.


| 영향 코드 | 영향 이름 | 샘플 정의 범위 | 
| --- | --- | --- | 
| 1 | Critical |  대부분의 고객에게 영향을 미치는 전체 애플리케이션 장애  | 
| 2 | High |  일부 고객에게 영향을 미치는 전체 애플리케이션 장애  | 
| 3 | Medium |  고객에게 발생하는 부분적인 애플리케이션 장애  | 
| 4 | Low |  고객에게 제한적인 영향을 미치는 간헐적인 장애  | 
| 5 | No Impact |  고객은 현재 영향을 받지 않지만 영향을 피하기 위해 긴급 조치가 필요합니다.  | 

## 조사 및 완화
<a name="investigation-mitigation"></a>

*인시던트* 세부 정보 보기는 팀에 런북, 타임라인 및 지표를 제공합니다. 인시던트 처리 방법을 알아보려면 [콘솔에서 인시던트 세부 정보 보기](tracking.md#tracking-details) 섹션을 참조하세요.

*런북*은 일반적으로 조사 단계를 제공하며 자동으로 데이터를 가져오거나 일반적으로 사용되는 솔루션을 시도할 수 있습니다. 또한 런북은 팀에서 인시던트를 완화하는 데 유용하다고 판단한 명확하고 반복 가능한 단계를 제공합니다. 런북 탭은 현재 런북 단계에 초점을 맞추고 과거 및 미래 단계를 보여줍니다.

Incident Manager는 Systems Manager 자동화와 통합되어 런북을 구축합니다. 런북을 사용하여 다음을 수행하십시오.
+ 인스턴스 및 AWS 리소스 관리
+ 스크립트 자동 실행
+  CloudFormation 리소스 관리

지원되는 작업 유형에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [Systems Manager 자동화 작업 참조](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)를 참조하세요.

**타임라인** 탭에는 수행된 조치가 표시됩니다. 타임라인은 타임스탬프와 자동으로 생성된 세부 정보와 함께 각각을 기록합니다. 타임라인에 사용자 지정 이벤트를 추가하려면 이 사용 설명서의 *인시던트 세부 정보* 페이지에 있는 [타임라인](tracking.md#tracking-details-timeline) 섹션을 참조하세요.

**진단** 탭에는 자동으로 채워진 지표와 수동으로 추가한 지표가 표시됩니다. 이 뷰는 인시던트 발생 시 애플리케이션 활동에 대한 중요한 정보를 제공합니다.

**참여** 탭에서는 인시던트에 연락처를 추가할 수 있으며, 인시던트에 연루된 담당자가 신속하게 조치를 취할 수 있도록 리소스를 제공할 수 있습니다. 연락처는 정의된 에스컬레이션 계획 또는 개인 참여 계획을 통해 참여합니다.

*채팅 채널*을 사용하면 인시던트 및 팀의 다른 대응 담당자와 직접 대화할 수 있습니다. 채팅 애플리케이션에서 Amazon Q Developer를 사용하면 , Slack Microsoft Teams및 Amazon Chime에서 채팅 채널을 구성할 수 있습니다. Slack 및 Microsoft Teams 채널에서 대응 담당자는 여러 `ssm-incidents` 명령을 사용하여 채팅 채널에서 직접 인시던트와 상호 작용할 수 있습니다. 자세한 내용은 [채팅 채널을 통한 상호작용](chat.md#chat-interact) 단원을 참조하십시오.

## 인시던트 사후 분석
<a name="lifecycle-post-incident-analysis"></a>

Insident Manager는 인시던트를 반영하고, 향후 인시던트가 다시 발생하지 않도록 방지하는 데 필요한 조치를 취하고, 인시던트 대응 활동을 전반적으로 개선하기 위한 프레임워크를 제공합니다. 개선 사항에는 다음이 포함됩니다.
+ 인시던트와 관련된 애플리케이션 변경. 팀은 이 시간을 활용하여 시스템을 개선하고 내결함성을 높일 수 있습니다.
+ 인시던트 대응 계획 변경. 시간을 내어 학습한 교훈을 통합하십시오.
+ 런북에 대한 변경. 팀에서 해결에 필요한 단계와 자동화할 수 있는 단계를 자세히 알아볼 수 있습니다.
+ 알림 변경. 인시던트가 발생한 후 팀에 인시던트를 더 빨리 알리는 데 사용할 수 있는 지표에서 중요한 포인트를 발견했을 수도 있습니다.

Insident Manager는 인시던트 타임라인과 함께 일련의 인시던트 사후 분석 질문 및 조치 항목을 사용하여 이러한 잠재적 개선을 촉진합니다. 분석을 통한 개선에 대해 자세히 알아보려면 [Incident Manager에서 인시던트 사후 분석 수행](analysis.md) 섹션을 참조하세요.