Support Case Review (지원 케이스 검토)
인시던트를 조사할 때 AWS Support 케이스를 검토해야 하는 경우 이 스킬을 사용하세요. 현재 인시던트와 관련된 케이스뿐만 아니라 관련 컨텍스트, 유사 증상 또는 입증된 해결 단계가 포함된 과거 케이스도 포함됩니다.
이 스킬을 사용해야 하는 경우
- 활성 인시던트가 이전에 해결된 문제와 증상을 공유하는 경우
- 지난 24개월 동안 유사한 지원 케이스가 제출되었는지 확인해야 하는 경우
- 현재 인시던트를 알려진 AWS 서비스 이벤트와 연관시키려는 경우
- 이전 케이스의 커뮤니케이션 및 해결 세부 정보를 검색해야 하는 경우
- 여러 지원 케이스에서 반복되는 패턴을 식별하려는 경우
전제 조건
- AWS 계정에 Business Support+, Enterprise Support 또는 Unified Operations 플랜이 있어야 합니다(AWS Support API 필요).
- 에이전트에 대상 계정에서
support:DescribeCases및support:DescribeCommunications를 호출할 수 있는 권한이 있어야 합니다. - 지원 케이스 데이터는 생성 후 24개월 동안만 사용할 수 있습니다. 24개월이 지난 케이스는 API를 통해 검색할 수 없습니다.
1단계: 현재 인시던트 컨텍스트 파악
지원 케이스를 검색하기 전에 현재 인시던트에서 주요 세부 정보를 수집합니다.
- 영향을 받은 AWS 서비스(예: EC2, RDS, Lambda, ELB)
- 로그 또는 알람에서 관찰된 오류 메시지 또는 오류 코드
- 인시던트 시간대(시작 시간, 기간)
- 영향을 받은 리소스(인스턴스 ID, ARN, 엔드포인트 이름)
- 증상(지연 시간 급증, 5xx 오류, 연결 시간 초과, 스로틀링)
지원 케이스를 필터링할 때 이러한 세부 정보를 검색 기준으로 사용합니다.
2단계: 관련 지원 케이스 검색
AWS Support API를 사용하여 관련성이 있을 수 있는 케이스를 검색합니다.
모든 최근 케이스 검색(열린 케이스 및 해결된 케이스)
aws support describe-cases \
--include-resolved-cases \
--include-communications \
--after-time "<ISO-8601-start>" \
--before-time "<ISO-8601-end>" \
--language "en"
특정 케이스 ID로 필터링(알고 있는 경우)
aws support describe-cases \
--case-id-list "case-123456789010-muen-2024" \
--include-communications
주요 필터링 전략
| 전략 | 적용 방법 |
|---|---|
| 시간 범위별 | --after-time 및 --before-time을 사용하여 관련 기간(예: 지난 30일 또는 이전 인시던트 날짜 기준)으로 케이스를 범위를 지정합니다. 최근 케이스가 현재 인프라 상태를 반영할 가능성이 더 높기 때문입니다. |
| 서비스별 | 반환된 케이스의 serviceCode 필드를 검토하여 영향을 받은 서비스(예: amazon-elastic-compute-cloud, amazon-rds)와 일치시킵니다. 동일한 서비스는 종종 반복되는 실패 패턴을 보이기 때문입니다. |
| 심각도별 | severityCode 필드를 확인합니다. 주요 인시던트의 경우 urgent 및 critical 케이스에 집중합니다. 심각도가 높은 케이스일수록 AWS Support의 근본 원인 분석이 더 자세한 경향이 있기 때문입니다. |
| 상태별 | --include-resolved-cases를 사용하여 종결된 케이스를 포함합니다. 해결된 케이스에는 현재 인시던트와의 상관 관계에 가장 유용한 근본 원인 및 해결 단계가 포함되어 있기 때문입니다. |
| 제목 키워드별 | 반환된 케이스의 subject 필드에서 현재 인시던트 증상과 일치하는 키워드를 스캔합니다. 유사한 증상은 종종 동일한 근본 원인을 공유하기 때문입니다. |
3단계: 케이스 커뮤니케이션 검토
includeCommunications: true가 포함된 describe-cases 응답은 각 케이스의 가장 최근 커뮤니케이션을 recentCommunications 필드에 반환합니다(최대 5개 메시지). 근본 원인 분석 및 해결 단계는 일반적으로 해결된 케이스의 마지막 메시지에 있으므로 일반적으로 이것으로 충분합니다.
recentCommunications 필드에 nextToken이 포함된 경우 케이스에 추가적인 이전 메시지가 있습니다. 최근 메시지에 명확한 근본 원인 또는 해결 방법이 포함되어 있지 않은 경우에만 describe-communications를 사용하여 페이지를 매기십시오. 예를 들어 마지막 메시지가 최종 답변이 아닌 후속 질문인 경우입니다.
aws support describe-communications \
--case-id "case-123456789010-muen-2024" \
--max-results 10 \
--next-token "<nextToken-from-recentCommunications>"
커뮤니케이션을 검토할 때 다음을 확인합니다.
- 근본 원인 진술 - AWS Support 엔지니어는 종종 최종 응답에서 근본 원인을 요약합니다.
- 해결 단계 - 문제를 해결하기 위해 취한 특정 조치(예: "max_connections 증가", "보안 그룹 규칙 적용", "인스턴스 유형 확장").
- 구성 권장 사항 - AWS에서 제공하는 모범 사례 또는 튜닝 제안.
- 에스컬레이션 메모 - 케이스가 에스컬레이션된 경우 전문 팀의 심층 기술 분석을 확인합니다.
4단계: 현재 인시던트와 결과 상관 관계 분석
관련 케이스를 검토한 후 결과를 상호 연관시킵니다.
패턴 일치 확인 목록
- 과거 케이스가 동일한 영향을 받은 서비스 및 리소스 유형을 공유합니까?
- 오류 메시지 또는 코드가 동일하거나 유사합니까?
- 과거 인시던트가 비슷한 시간대 또는 요일에 발생했습니까(부하 패턴을 나타냄)?
- 근본 원인이 여전히 존재할 수 있는 구성 문제였습니까?
- 해결 방법이 만료되었거나 되돌려진 임시 해결책이었습니까?
- AWS에서 재발 가능성이 있는 서비스 측 문제를 식별했습니까?
관련성 점수화
현재 인시던트와의 관련성에 따라 각 과거 케이스의 점수를 매깁니다.
| 점수 | 기준 |
|---|---|
| 높음 | 동일한 서비스, 동일한 오류, 동일한 리소스 유형, 유사한 시간대 |
| 중간 | 동일한 서비스, 다른 오류지만 관련 증상 |
| 낮음 | 다른 서비스지만 유사한 아키텍처 패턴 또는 실패 모드 |
5단계: 결과 요약
구조화된 요약을 제공합니다.
- 발견된 관련 케이스 수 - 검색 기준과 일치하는 과거 케이스 수.
- 가장 관련성 높은 케이스 - 상위 일치 항목의 케이스 ID, 제목, 상태 및 생성 날짜.
- 과거 근본 원인 - 과거에 유사한 문제의 원인이었던 것.
- 과거 해결 방법 - 적용된 해결 단계와 영구적인 수정인지 임시 해결책인지 여부.
- 권장 사항 - 과거 패턴을 기반으로 현재 인시던트에 대한 조사 경로 또는 해결 단계를 제안합니다.
- 반복 패턴 경고 - 동일한 문제가 여러 번 발생한 경우 영구적인 수정 또는 아키텍처 변경이 필요한 반복 문제로 플래그를 지정합니다.
의사 결정 트리: 케이스 검색 전략
현재 인시던트와 관련된 알려진 케이스 ID가 있습니까?
├── 예 → 해당 특정 케이스와 커뮤니케이션 검색(2단계, 케이스 ID로 필터링)
└── 아니요 → 아래 계속
영향을 받은 AWS 서비스를 알고 있습니까?
├── 예 → 지난 90일 동안 해당 서비스의 케이스를 검색하고, 필요한 경우 12개월로 확장
└── 아니요 → 지난 30일 동안 모든 케이스를 검색하고 오류 키워드로 필터링
관련 과거 케이스를 찾았습니까?
├── 예 → 커뮤니케이션 검토(3단계), 결과 상관 관계 분석(4단계), 요약(5단계)
└── 아니요 → 검색 기준 확대:
- 시간 범위 확장
- 관련 서비스 검색(예: ELB가 영향을 받은 경우 EC2 및 Target Group 케이스도 확인)
- 케이스 제목에서 오류 코드 또는 증상 키워드 검색
효과적인 케이스 검토를 위한 팁
- 좁게 시작한 다음 넓히기: 특정 필터(서비스 + 시간 범위)로 시작하고 관련 케이스가 없을 때만 확장합니다.
- 해결된 케이스 확인: 근본 원인과 수정 사항이 문서화된 해결된 케이스에서 가장 중요한 정보를 얻을 수 있는 경우가 많습니다.
- 케이스 심각도 패턴 확인: 동일한 문제에 대한 과거 케이스가
critical심각도로 제출된 경우 현재 인시던트도 유사한 긴급성이 필요할 수 있습니다. - 배포와 교차 참조: 과거 케이스가 배포로 인해 발생한 경우 현재 인시던트 전에 유사한 배포가 있었는지 확인합니다.