# 운영
**Topics**
+ [OPS 8. 조직에서 워크로드 관찰성을 어떻게 활용하고 있나요?](ops-08.md)
+ [OPS 9. 운영 상태를 어떻게 파악하나요?](ops-09.md)
+ [OPS 10. 워크로드 및 운영 이벤트를 어떻게 관리하나요?](ops-10.md)
# OPS 8. 조직에서 워크로드 관찰성을 어떻게 활용하고 있나요?
관찰성을 활용하여 워크로드 상태를 최적화합니다. 관련 지표, 로그, 추적을 활용하여 워크로드 성능을 종합적으로 파악하고 문제를 효율적으로 해결합니다.
**Topics**
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 워크로드 로그 분석](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 워크로드 추적 데이터 분석](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 대시보드 만들기](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 워크로드 지표 분석
애플리케이션 원격 측정을 구현한 후 수집된 지표를 정기적으로 분석합니다. 지연 시간, 요청, 오류, 용량(또는 할당량)은 시스템 성능에 대한 인사이트를 제공하지만 비즈니스 성과 지표 검토의 우선순위를 정하는 것이 중요합니다. 이를 통해 비즈니스 목표에 부합하는 데이터 기반 의사 결정을 내릴 수 있습니다.
**원하는 성과:** 워크로드 성능에 대한 정확한 인사이트를 통해 데이터에 기반한 의사 결정을 내리고 비즈니스 목표에 부합하도록 합니다.
**일반적인 안티 패턴**:
+ 지표가 비즈니스 성과에 미치는 영향을 고려하지 않고 개별적으로 지표를 분석합니다.
+ 기술 지표에 지나치게 의존하고 비즈니스 지표는 배제합니다.
+ 지표를 자주 검토하지 않아 실시간 의사 결정 기회를 놓치고 있습니다.
**이 모범 사례 확립의 이점:**
+ 기술 성과와 비즈니스 성과 간의 상관관계에 대해 더 잘 이해합니다.
+ 실시간 데이터를 기반으로 의사 결정 프로세스를 개선합니다.
+ 비즈니스 성과에 영향을 미치기 전에 문제를 사전에 식별하고 완화합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
Amazon CloudWatch와 같은 도구를 활용하여 지표 분석을 수행합니다. CloudWatch 이상 탐지 및 Amazon DevOps Guru와 같은 AWS 서비스는 특히 정적 임곗값을 알 수 없거나 행동 패턴이 이상 탐지에 더 적합한 경우 이상을 탐지하는 데 사용할 수 있습니다.
### 구현 단계
1. **분석 및 검토:** 워크로드 지표를 정기적으로 검토하고 해석하세요.
1. 순전히 기술적인 지표보다 비즈니스 성과 지표를 우선시하세요.
1. 데이터의 급증, 하락 또는 패턴의 중요성을 이해하세요.
1. **Amazon CloudWatch 활용:** 중앙 집중식 보기 및 심층 분석을 위해 Amazon CloudWatch를 사용합니다.
1. 지표를 시각화하고 시간 경과에 따라 비교하도록 CloudWatch 대시보드를 구성합니다.
1. [CloudWatch에서 백분위수](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)를 사용하여 지표 분포를 명확하게 파악하면 SLA를 정의하고 이상치를 이해하는 데 도움이 될 수 있습니다.
1. [CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)를 설정하여 정적 임곗값에 의존하지 않고 비정상적 패턴을 식별합니다.
1. [CloudWatch 크로스 계정 관찰성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)을 구현하여 리전 내 여러 계정에 걸쳐 있는 애플리케이션을 모니터링하고 문제를 해결합니다.
1. [CloudWatch Metric Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)를 사용하여 계정 및 리전 전반의 지표 데이터를 쿼리하고 분석해 추세와 이상 현상을 식별합니다.
1. [CloudWatch 지표 수식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 적용하여 지표를 변환, 집계 또는 계산을 수행해 심층적인 인사이트를 확보할 수 있습니다.
1. **Amazon DevOps Guru 사용:** 서버리스 애플리케이션의 운영 문제에 관한 초기 징후를 식별하고 고객에게 영향을 미치기 전에 문제를 해결할 수 있도록 기계 학습에 기반한 향상된 이상 탐지를 위해 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)를 통합합니다.
1. **인사이트 기반 최적화:** 지표 분석을 기반으로 정보에 입각한 결정을 내려 워크로드를 조정하고 개선하세요.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS04-BP02 애플리케이션 원격 측정 구현](ops_observability_application_telemetry.md)
**관련 문서**:
+ [ The Wheel 블로그 - Emphasizing the importance of continually reviewing metrics ](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [ Percentile are important ](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [AWS Cost Anomaly Detection 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch 크로스 계정 관찰성 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ CloudWatch Metrics Insights를 사용하는 지표 쿼리 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**관련 비디오:**
+ [ Enable Cross-Account Observability in Amazon CloudWatch ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Introduction to Amazon DevOps Guru ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [ Continuously Analyze Metrics using AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)
**관련 예제:**
+ [ One Observability 워크숍 ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Gaining operation insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 워크로드 로그 분석
워크로드 로그를 정기적으로 분석하는 것은 애플리케이션의 운영 측면을 더 깊이 이해하는 데 필수적입니다. 로그 데이터를 효율적으로 선별, 시각화 및 해석함으로써 애플리케이션 성능과 보안을 지속적으로 최적화할 수 있습니다.
**원하는 성과:** 철저한 로그 분석을 통해 애플리케이션 동작 및 운영에 대한 풍부한 인사이트를 얻어 사전 예방적 문제 감지 및 완화를 보장합니다.
**일반적인 안티 패턴**:
+ 심각한 문제가 발생할 때까지 로그 분석을 무시합니다.
+ 로그 분석에 사용할 수 있는 모든 도구를 사용하지 않아 중요한 인사이트를 놓칩니다.
+ 자동화 및 쿼리 기능을 활용하지 않고 수동 로그 검토에만 의존합니다.
**이 모범 사례 확립의 이점:**
+ 운영 병목 현상, 보안 위협 및 기타 잠재적 문제를 사전에 식별합니다.
+ 지속적인 애플리케이션 최적화를 위해 로그 데이터를 효율적으로 활용합니다.
+ 애플리케이션 동작에 대한 이해도를 높여 디버깅 및 문제 해결을 지원합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)는 로그 분석을 위한 강력한 도구입니다. CloudWatch 로그 인사이트 및 Contributor Insights와 같은 통합 기능을 사용하면 로그에서 의미 있는 정보를 직관적이고 효율적으로 도출할 수 있습니다.
### 구현 단계
1. **CloudWatch Logs 설정**: CloudWatch Logs에 로그를 전송하도록 애플리케이션 및 서비스를 구성합니다.
1. **로그 이상 탐지 사용:** [Amazon CloudWatch Logs 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html) 기능을 활용하여 비정상적인 로그 패턴을 자동으로 식별하고 이에 대해 알립니다. 이 도구를 사용하면 로그의 이상 현상을 사전에 관리하고 잠재적 문제를 조기에 발견할 수 있습니다.
1. **CloudWatch 로그 인사이트 설정**: [CloudWatch 로그 인사이트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)를 사용하여 로그 데이터를 대화식으로 검색하고 분석합니다.
1. 쿼리를 만들어 패턴을 추출하고, 로그 데이터를 시각화하며, 실행 가능한 인사이트를 도출합니다.
1. [CloudWatch 로그 인사이트 패턴 분석](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Patterns.html)을 사용하여 빈번한 로그 패턴을 분석하고 시각화합니다. 이 기능은 로그 데이터의 일반적인 운영 추세와 잠재적 이상값을 이해하는 데 도움이 됩니다.
1. [CloudWatch Logs 비교(diff)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Compare.html)를 사용하여 서로 다른 기간 간 또는 여러 로그 그룹 간의 차이 분석을 수행합니다. 이 기능을 사용하여 변경 사항을 정확히 찾아내고 시스템 성능 또는 동작에 미치는 영향을 평가할 수 있습니다.
1. **Live Tail을 통한 실시간 로그 모니터링:** [Amazon CloudWatch Logs Live Tail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_LiveTail.html)을 사용하여 로그 데이터를 실시간으로 확인합니다. 애플리케이션의 운영 활동이 발생할 때 이를 적극적으로 모니터링할 수 있으므로 시스템 성능 및 잠재적 문제를 즉시 파악할 수 있습니다.
1. **Contributor Insights 활용:** [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)를 사용하여 IP 주소 또는 사용자 에이전트와 같은 높은 카디널리티 차원에서 볼륨이 높은 항목을 식별합니다.
1. **CloudWatch Logs 지표 필터 구현:** [CloudWatch Logs 지표 필터](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)를 구성하여 로그 데이터를 실행 가능한 지표로 변환합니다. 이를 통해 경보를 설정하거나 패턴을 추가로 분석할 수 있습니다.
1. **[CloudWatch 크로스 계정 관찰성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) 구현:** 한 리전 내 여러 계정에 걸쳐 있는 애플리케이션을 모니터링하고 문제를 해결합니다.
1. **정기적 검토 및 개선**: 정기적으로 로그 분석 전략을 검토하여 모든 관련 정보를 캡처하고 애플리케이션 성능을 지속적으로 최적화합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS04-BP02 애플리케이션 원격 측정 구현](ops_observability_application_telemetry.md)
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
**관련 문서**:
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Using CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [Creating and Managing CloudWatch Log Metric Filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**관련 비디오:**
+ [Analyze Log Data with CloudWatch Logs Insights](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [Use CloudWatch Contributor Insights to Analyze High-Cardinality Data](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**관련 예제:**
+ [CloudWatch Logs Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [One Observability 워크숍](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 워크로드 추적 데이터 분석
추적 데이터를 분석하는 것은 애플리케이션의 운영 여정을 포괄적으로 파악하는 데 매우 중요합니다. 다양한 구성 요소 간의 상호 작용을 시각화하고 이해함으로써 성능을 미세 조정하고 병목 현상을 식별하며 사용자 경험을 개선할 수 있습니다.
**원하는 성과:** 애플리케이션의 분산 운영에 대한 명확한 가시성을 확보하여 더 빠른 문제 해결과 향상된 사용자 경험을 제공합니다.
**일반적인 안티 패턴**:
+ 로그와 지표에만 의존하고 추적 데이터는 간과합니다.
+ 추적 데이터를 관련 로그와 연관시키지 않습니다.
+ 지연 시간 및 장애율과 같은 추적에서 도출된 지표를 무시합니다.
**이 모범 사례 확립의 이점:**
+ 문제 해결을 개선하고 평균 문제 해결 시간(MTTR)을 줄입니다.
+ 종속성과 그 영향에 대한 인사이트를 얻습니다.
+ 성능 문제를 신속하게 식별하고 수정합니다.
+ 정보에 입각한 의사 결정을 위해 추적에서 도출된 지표를 활용합니다.
+ 최적화된 구성 요소 상호 작용을 통해 사용자 경험을 개선합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
[AWS X-Ray](https://www.docs.aws.com/xray/latest/devguide/aws-xray.html)에서는 추적 데이터 분석을 위한 포괄적인 제품군을 제공하여 서비스 상호 작용에 대한 전체적인 보기를 제공하고, 사용자 활동을 모니터링하며, 성능 문제를 감지합니다. ServiceLens, X-Ray Insights, X-Ray Analytics, Amazon DevOps Guru와 같은 기능은 추적 데이터에서 더 심도 깊은 실행 가능한 인사이트를 얻을 수 있습니다.
### 구현 단계
아래 단계는 AWS 서비스를 사용하여 추적 데이터 분석을 효과적으로 구현하기 위한 체계적인 접근 방식을 제공합니다.
1. **AWS X-Ray 통합**: 애플리케이션과 X-Ray가 통합되어 추적 데이터를 캡처할 수 있도록 보장합니다.
1. **X-Ray 지표 분석**: [서비스 맵](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view)으로 애플리케이션 상태를 모니터링하여 지연 시간, 요청률, 장애율, 응답 시간 분포와 같은 X-Ray 추적에서 파생된 지표를 자세히 살펴봅니다.
1. **ServiceLens 사용**: [ServiceLens 맵](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html)을 활용하여 서비스 및 애플리케이션의 관찰성을 개선합니다. 이를 통해 추적, 지표, 로그, 경보 및 기타 건강 정보를 통합적으로 볼 수 있습니다.
1. **X-Ray Insights 활성화**:
1. 추적에서 자동 이상 탐지를 위해 [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html)를 켭니다.
1. 인사이트를 검토하여 패턴을 정확히 찾아내고 장애율 또는 지연 시간 증가와 같은 근본 원인을 파악합니다.
1. 인사이트 타임라인을 참조하여 감지된 문제를 시간순으로 분석합니다.
1. **X-Ray Analytics 사용**: [X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)를 사용하면 추적 데이터를 철저히 탐색하고, 패턴을 정확히 찾아내며, 인사이트를 추출할 수 있습니다.
1. **X-Ray에서 그룹 사용:** X-Ray에서 그룹을 생성하여 높은 지연 시간과 같은 기준에 따라 추적을 필터링하여 보다 표적화된 분석을 수행할 수 있습니다.
1. **Amazon DevOps Guru 통합**: [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)를 통해 추적에서 운영 이상을 찾아내는 기계 학습 모델의 이점을 활용합니다.
1. **CloudWatch Synthetics 사용**: [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html)를 사용하여 엔드포인트 및 워크플로를 지속적으로 모니터링하기 위한 canary를 생성합니다. 이러한 canary를 X-Ray와 통합하여 테스트 대상 애플리케이션의 심층 분석을 위한 추적 데이터를 제공할 수 있습니다.
1. **실제 사용자 모니터링(RUM) 사용**: [AWS X-Ray 및 CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)을 사용하면 애플리케이션의 최종 사용자부터 시작하여 다운스트림 AWS 관리형 서비스까지 요청 경로를 분석하고 디버그할 수 있습니다. 이를 통해 최종 사용자에게 영향을 미치는 지연 시간 추세와 오류를 파악할 수 있습니다.
1. **로그와의 상관관계 파악**: 애플리케이션 동작을 세부적으로 파악할 수 있도록 X-Ray 추적 보기 내에서 [추적 데이터와 관련 로그](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs)의 상관관계를 분석합니다. 이렇게 하면 추적된 트랜잭션과 직접 관련된 로그 이벤트를 볼 수 있습니다.
1. **[CloudWatch 크로스 계정 관찰성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) 구현:** 한 리전 내 여러 계정에 걸쳐 있는 애플리케이션을 모니터링하고 문제를 해결합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 워크로드 로그 분석](ops_workload_observability_analyze_workload_logs.md)
**관련 문서**:
+ [Using ServiceLens to Monitor Application Health](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [Exploring Trace Data with X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [Detecting Anomalies in Traces with X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [Continuous Monitoring with CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**관련 비디오:**
+ [Analyze and Debug Applications Using Amazon CloudWatch Synthetics & AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [Use AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**관련 예제:**
+ [One Observability 워크숍](https://catalog.workshops.aws/observability/en-US/intro)
+ [Implementing X-Ray with AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [CloudWatch Synthetics Canary Templates](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 실행 가능한 알림 생성
애플리케이션 동작의 편차를 즉시 감지하고 이에 대응하는 것이 중요합니다. 특히 중요한 것은 핵심 성과 지표(KPI)를 기반으로 한 결과가 위험에 처하거나 예상치 못한 이상 현상이 발생할 때를 인식하는 것입니다. KPI에 기반한 알림을 통해 수신되는 신호가 비즈니스 또는 운영상의 영향과 직접 연계되도록 할 수 있습니다. 실행 가능한 알림에 대한 이러한 접근 방식은 사전 대응을 촉진하고 시스템 성능 및 신뢰성을 유지하는 데 도움이 됩니다.
**원하는 성과:** 특히 KPI 결과가 위험할 때 잠재적 문제를 신속하게 식별하고 완화할 수 있도록 시기적절하고 실행 가능한 알림을 받을 수 있습니다.
**일반적인 안티 패턴**:
+ 중요하지 않은 알림을 너무 많이 설정하여 알림으로 인한 피로가 발생합니다.
+ KPI에 따라 알림의 우선순위를 정하지 않아 문제가 비즈니스에 미치는 영향을 파악하기 어렵습니다.
+ 근본 원인 해결을 소홀히 하여 동일한 문제에 대해 반복적인 알림이 발생합니다.
**이 모범 사례 확립의 이점:**
+ 실행 가능하고 관련성이 높은 알림에 집중하여 알림 피로가 줄어듭니다.
+ 사전 예방적 문제 감지 및 완화를 통해 시스템 가동 시간 및 신뢰성을 개선했습니다.
+ 널리 사용되는 알림 및 커뮤니케이션 도구와 통합하여 팀 협업을 강화하고 문제를 더 빠르게 해결합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
효과적인 알림 메커니즘을 만들려면 KPI를 기반으로 한 결과가 위험에 처하거나 이상 징후가 감지될 때 플래그를 표시하는 지표, 로그 및 추적 데이터를 사용하는 것이 중요합니다.
### 구현 단계
1. **핵심 성과 지표(KPI) 결정**: 애플리케이션의 KPI를 식별합니다. 알림을 이러한 KPI와 연계하여 비즈니스에 미치는 영향을 정확하게 반영해야 합니다.
1. **이상 감지 구현**:
+ **Amazon CloudWatch 이상 탐지 사용**: 비정상적인 패턴을 자동으로 탐지하도록 [Amazon CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)를 설정하면 실제 이상 징후가 있을 때만 알림을 생성할 수 있습니다.
+ **AWS X-Ray 인사이트 사용**:
1. [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html)를 설정하여 추적 데이터에서 이상을 감지합니다.
1. 탐지된 문제에 대해 알림을 받을 수 있도록 [X-Ray Insights에 대한 알림](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)을 구성합니다.
+ **Amazon DevOps Guru 통합**:
1. [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)의 기계 학습 기능을 활용하여 기존 데이터로 운영 이상 징후를 탐지합니다.
1. DevOps Guru의 [알림 설정](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings)으로 이동하여 이상 알림을 설정합니다.
1. **실행 가능한 알림 구현**: 즉각적인 조치를 위한 적절한 정보를 제공하는 알림을 설계합니다.
1. [Amazon EventBridge 규칙을 사용하여 AWS Health 이벤트](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)를 모니터링하거나 AWS Health API와 프로그래밍 방식으로 통합하여 AWS Health 이벤트를 수신할 때 작업을 자동화합니다. 이러한 작업은 계획된 모든 수명 주기 이벤트 메시지를 채팅 인터페이스로 보내는 것과 같은 일반적인 작업이거나 IT 서비스 관리 도구에서 워크플로를 시작하는 것과 같은 구체적인 작업일 수 있습니다.
1. **알림 피로 감소**: 중요하지 않은 알림을 최소화합니다. 대수롭지 않은 알림으로 팀이 부담을 느끼면 중요한 문제를 감독하지 못할 수 있고 결과적으로 알림 메커니즘의 전반적인 효율성이 떨어질 수 있습니다.
1. **복합 경보 설정**: [Amazon CloudWatch 복합 경보](https://aws.amazon.com/bloprove-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/)를 사용하여 여러 경보를 통합합니다.
1. **알림 도구와 통합**: [Ops Genie](https://www.atlassian.com/software/opsgenie) 및 [PagerDuty](https://www.pagerduty.com/)와 같은 도구를 통합합니다.
1. **채팅 애플리케이션 내 Amazon Q Developer 참여**: [채팅 애플리케이션 내 Amazon Q Developer](https://aws.amazon.com/chatbot/)를 통합하여 Amazon Chime, Microsoft Teams 및 Slack에 알림을 전달합니다.
1. **로그 기반 알림**: CloudWatch의 [로그 지표 필터](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)를 사용하여 특정 로그 이벤트를 기반으로 경보를 생성합니다.
1. **검토 및 반복**: 알림 구성을 정기적으로 재검토하고 개선합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS04-BP02 애플리케이션 원격 측정 구현](ops_observability_application_telemetry.md)
+ [OPS04-BP03 사용자 경험 원격 측정 구현](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 종속성 원격 측정 구현](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 분산 추적 구현](ops_observability_dist_trace.md)
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 워크로드 로그 분석](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 워크로드 추적 데이터 분석](ops_workload_observability_analyze_workload_traces.md)
**관련 문서**:
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [복합 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [이상 탐지를 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [DevOps Guru Notifications](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [X-ray insights notifications](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [상호작용형 ChatOps로 AWS 리소스 모니터링, 운영 및 문제 해결](https://aws.amazon.com/chatbot/)
+ [Amazon CloudWatch Integration Guide \$1 PagerDuty](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [Integrate Opsgenie with Amazon CloudWatch](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**관련 비디오:**
+ [Create Composite Alarms in Amazon CloudWatch](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [Amazon Q Developer in chat applications Overview](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS On Air ft. Mutative Commands in Amazon Q Developer in chat applications](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**관련 예제:**
+ [Alarms, incident management, and remediation in the cloud with Amazon CloudWatch](https://aws.amazon.com/bloarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [Tutorial: Creating an Amazon EventBridge rule that sends notifications to Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [One Observability 워크숍](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 대시보드 만들기
대시보드는 워크로드의 원격 측정 데이터를 사람 중심으로 볼 수 있는 보기입니다. 중요한 시각적 인터페이스를 제공하지만 경고 메커니즘을 대체하는 것이 아니라 보완해야 합니다. 주의를 기울여 제작하면 시스템 상태 및 성능에 대한 빠른 인사이트를 제공할 뿐만 아니라 이해관계자에게 비즈니스 성과 및 문제의 영향에 대한 실시간 정보를 제공할 수 있습니다.
**원하는 성과:**
시각적 표현을 사용하여 시스템 및 비즈니스 상태에 대한 명확하고 실행 가능한 인사이트를 제공합니다.
**일반적인 안티 패턴**:
+ 너무 많은 지표로 인해 대시보드가 지나치게 복잡해집니다.
+ 이상 항목 탐지에 대한 경고 없이 대시보드를 사용합니다.
+ 워크로드가 진화해도 대시보드를 업데이트하지 않습니다.
**이 모범 사례의 이점:**
+ 중요한 시스템 지표와 KPI에 대한 가시성을 즉각적으로 확보합니다.
+ 이해관계자 커뮤니케이션 및 이해 강화.
+ 운영 문제의 영향에 대해 신속한 인사이트를 얻습니다.
**이 모범 사례가 확립되지 않을 경우 위험 수준:** 중간
## 구현 지침
**비즈니스 중심 대시보드**
비즈니스 KPI에 맞게 조정된 대시보드는 다양한 이해관계자를 참여시킵니다. 이러한 개인은 시스템 지표에 관심이 없을 수도 있지만 이러한 수치가 비즈니스에 미치는 영향을 이해하는 데 관심이 있습니다. 비즈니스 중심 대시보드를 사용하면 모니터링 및 분석되는 모든 기술 및 운영 지표가 중요한 비즈니스 목표와 동기화됩니다. 이러한 정렬은 모든 사람이 무엇이 필수적이고 무엇이 아닌지에 대해 동일한 이해를 가질 수 있도록 명확성을 제공합니다. 또한 비즈니스 KPI를 강조하는 대시보드는 실행 가능성이 더 높은 경향이 있습니다. 이해관계자는 운영 상태, 주의가 필요한 영역, 비즈니스 성과에 미치는 잠재적 영향을 빠르게 이해할 수 있습니다.
이를 염두에 두고 대시보드를 만들 때는 기술 지표와 비즈니스 KPI 간에 균형을 유지해야 합니다. 둘 다 중요하지만 다양한 청중을 수용하도록 해야 합니다. 시스템의 상태와 성능을 전체적으로 볼 수 있는 동시에 주요 비즈니스 성과와 그 영향을 강조하는 대시보드를 사용하는 것이 가장 좋습니다.
Amazon CloudWatch 대시보드는 CloudWatch 콘솔에서 사용자 지정이 가능한 홈 페이지로, 다른 AWS 리전 및 계정에 분산되어 있는 리소스를 비롯하여 단일 보기에서 리소스를 모니터링하는 데 사용할 수 있습니다.
### 구현 단계
1. **기본 대시보드 생성:** [CloudWatch에서 새 대시보드를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)하고 설명이 포함된 이름을 지정합니다.
1. **마크다운 위젯 사용:** 지표를 자세히 살펴보기 전에 [마크다운 위젯을 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html)하여 대시보드 상단에 텍스트 컨텍스트를 추가합니다. 여기에는 대시보드에서 다루는 내용, 표시된 지표의 중요성이 설명되어야 하며 다른 대시보드 및 문제 해결 도구에 대한 링크도 포함될 수 있습니다.
1. **대시보드 변수 생성:** 유연한 동적 대시보드 보기를 위해 해당되는 경우 [대시보드 변수를 통합](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)합니다.
1. **지표 위젯 생성:** 애플리케이션이 내보내는 다양한 지표를 시각화하도록 [지표 위젯을 추가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html)합니다. 그리고 시스템 상태 및 비즈니스 결과를 효과적으로 나타내도록 이 위젯을 조정합니다.
1. **로그 인사이트 쿼리:** [CloudWatch 로그 인사이트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html)를 활용하여 로그에서 실행 가능한 지표를 도출하고 대시보드에 이러한 인사이트를 표시합니다.
1. **경보 설정:** [CloudWatch 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html)를 대시보드에 통합하여 임곗값을 위반하는 모든 지표를 빠르게 확인할 수 있습니다.
1. **Contributor Insights 사용:** [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html)를 통합하여 카디널리티가 높은 필드를 분석하고 리소스를 가장 많이 사용하는 항목을 더 명확하게 파악할 수 있습니다.
1. **사용자 지정 위젯 설계:** 표준 위젯으로는 충족되지 않는 특정 요구 사항에 대해서는 [사용자 지정 위젯](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)을 생성하는 방법을 고려합니다. 사용자 지정 위젯은 다양한 데이터 소스에서 데이터를 가져오거나 고유한 방식으로 데이터를 표현할 수 있습니다.
1. **AWS Health 사용:** AWS Health는 AWS 클라우드 리소스 상태에 대한 신뢰할 수 있는 정보 소스입니다. [AWS Health Dashboard](https://health.aws.amazon.com/health/status)를 바로 사용하거나, 자체 대시보드 및 도구의 AWS Health 데이터를 사용하여 정보에 입각한 결정을 내리는 데 적합한 정보를 확보할 수 있습니다.
1. **반복 및 개선:** 애플리케이션이 발전함에 따라 정기적으로 대시보드를 재검토하여 관련성을 확인합니다.
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 워크로드 로그 분석](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 워크로드 추적 데이터 분석](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
**관련 문서**:
+ [운영 가시성을 위한 대시보드 구축](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**관련 비디오:**
+ [Create Cross Account & Cross Region CloudWatch Dashboards](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with AWS 클라우드 operation dashboards)](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**관련 예제:**
+ [One Observability 워크숍](https://catalog.workshops.aws/observability/en-US/intro)
+ [Application Monitoring with Amazon CloudWatch](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
+ [AWS Health Events Intelligence Dashboards and Insights](https://aws.amazon.com/blogs/mt/aws-health-events-intelligence-dashboards-insights/)
+ [Visualize AWS Health events using Amazon Managed Grafana](https://aws.amazon.com/blogs/mt/visualize-aws-health-events-using-amazon-managed-grafana/)
# OPS 9. 운영 상태를 어떻게 파악하나요?
운영 지표를 정의, 캡처 및 분석하면 운영 이벤트에 대한 가시성을 확보하여 적절한 조치를 취할 수 있습니다.
**Topics**
+ [OPS09-BP01 지표를 통한 운영 목표 및 KPI 측정](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 상태 및 추세를 전달하여 운영에 대한 가시성 확보](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 운영 지표 검토 및 개선 우선순위 지정](ops_operations_health_review_ops_metrics_prioritize_improvement.md)
# OPS09-BP01 지표를 통한 운영 목표 및 KPI 측정
조직의 운영 성공을 정의하는 목표와 KPI를 확보하고 지표가 이를 반영하는지 결정하세요. 기준선을 참조 지점으로 설정하고 정기적으로 재평가하세요. 평가를 위해 팀으로부터 이러한 지표를 수집하는 메커니즘을 개발하세요. [DevOps Research and Assessment(DORA)](https://dora.dev/guides/dora-metrics-four-keys/) 지표는 소프트웨어 제공의 DevOps 방식에 대한 진행 상황을 측정하는 인기 있는 방법을 제공합니다.
**원하는 성과:**
+ 조직이 운영 팀을 위해 목표 및 KPI를 게시하고 공유합니다.
+ 이러한 KPI를 반영하는 지표를 설정합니다. 예제로 다음이 포함될 수 있습니다.
+ 티켓 대기열 길이 또는 티켓의 평균 수명
+ 문제 유형별로 그룹화된 티켓 수
+ 표준화된 운영 절차(SOP)를 사용하거나 사용하지 않고 문제를 해결하는 데 소요된 시간
+ 실패한 코드 푸시를 복구하는 데 소요된 시간
+ 통화 볼륨
**일반적인 안티 패턴:**
+ 개발자가 문제 해결 작업을 수행할 수 밖에 없기 때문에 배포 기한을 놓치는 경우가 있습니다. 개발 팀은 더 많은 인력을 확보하기 위해 노력하고 있지만 소요되는 시간을 측정할 수 없기 때문에 필요한 인원을 정량화할 수 없습니다.
+ 티어 1 데스크는 사용자 통화를 처리하도록 설정됩니다. 시간이 지나면서 더 많은 워크로드가 추가되었지만 티어 1 데스크에는 인력이 할당되지 않습니다. 통화 시간이 늘어나고 해결 없이 문제가 더 길어지면서 고객 만족도가 떨어지지만 경영진은 그러한 지표를 발견하지 못해 조치를 취하지 못합니다.
+ 문제가 되는 워크로드는 유지 관리를 위해 별도의 운영 팀에 전달되었습니다. 다른 워크로드와 달리 이 새 워크로드는 적절한 설명서 및 런북과 함께 제공되지 않습니다. 따라서 팀은 문제를 해결하고 장애를 해결하는 데 더 많은 시간을 할애합니다. 그러나 이를 문서화하는 지표가 없기 때문에 책임 소재를 찾기가 어렵습니다.
**이 모범 사례 확립의 이점:** 워크로드 모니터링을 통해 애플리케이션 및 서비스의 상태를 확인하여 모니터링 운영 팀이 소유자에게 워크로드 소비자들 사이에서 일어나는 변화(예: 비즈니스 요구 사항 변화)에 대한 인사이트를 제공할 수 있습니다. 운영 상태를 반영할 수 있는 지표를 만들어 이러한 팀의 효율성을 측정하고 비즈니스 목표와 비교하여 평가합니다. 지표를 통해 지원 문제를 강조하거나 서비스 수준 목표에서 벗어나는 편차가 발생하는 시점을 파악할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
비즈니스 리더 및 이해관계자와 일정을 맞춰 서비스의 전반적인 목표를 결정합니다. 다양한 운영팀의 업무가 무엇인지 그리고 어떤 과제에 직면할 수 있는지 결정합니다. 이를 사용하여 이러한 운영 목표를 반영할 수 있는 핵심 성과 지표(KPI)를 브레인스토밍하세요. 여기에는 고객 만족도, 기능 구상부터 배포까지의 시간, 평균 문제 해결 시간, 비용 효율성이 포함될 수 있습니다.
KPI를 바탕으로 이러한 목표를 가장 잘 반영할 수 있는 지표와 데이터 소스를 식별하세요. 고객 만족도는 통화 대기 또는 응답 시간, 만족도 점수, 제기된 문제 유형과 같은 다양한 지표의 조합일 수 있습니다. 배포 시간은 테스트 및 배포에 필요한 시간과 추가해야 하는 배포 후 수정 사항의 총합일 수 있습니다. 다양한 유형의 문제에 소요된 시간(또는 해당 문제의 수)을 보여주는 통계를 통해 목표 집중이 필요한 부분을 파악할 수 있습니다.
## 리소스
**관련 문서:**
+ [ Quick - KPI 사용 ](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [ Amazon CloudWatch 지표 사용 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ 대시보드 구축 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ How to track your cost optimization KPIs with KPI Dashboard ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [AWS DevOps Guidance ](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
**관련 예제:**
+ [ Monitor the performance of your software delivery using native AWS monitoring and observability tools ](https://catalog.us-east-1.prod.workshops.aws/workshops/3b7f3d77-c6ef-44b2-aa29-d2719b8be897/en-US)
+ [ Balance deployment speed and stability with DORA metrics ](https://aws.amazon.com/blogs/devops/balance-deployment-speed-and-stability-with-dora-metrics/)
+ [ Example MLOps operational metrics in the financial services industry ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-unlock-value-data-financial-services/operational-metrics.html)
+ [ How to track your cost optimization KPIs with the KPI Dashboard ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
# OPS09-BP02 상태 및 추세를 전달하여 운영에 대한 가시성 확보
결과가 위험에 처할 수 있는 시점, 추가된 작업을 지원할 수 있는지 여부, 변화가 팀에 미친 영향을 파악하려면 운영 상태와 추세 동향을 알아야 합니다. 운영 이벤트 중에 사용자와 운영팀이 참조하여 정보를 얻을 수 있는 상태 페이지를 마련하면 커뮤니케이션 채널에 가해지는 부담을 줄이고 정보를 사전에 전파할 수 있습니다.
**원하는 성과:**
+ 운영 책임자는 팀이 얼만큼의 통화 볼륨을 받고 있는지, 배포와 같이 어떤 작업을 진행 중인지 한눈에 파악할 수 있습니다.
+ 정상 운영에 영향이 발생할 경우 이해관계자와 사용자 커뮤니티에 알림이 전달됩니다.
+ 조직 경영진과 이해관계자는 경고 또는 영향에 대응하여 상태 페이지를 확인하고 연락처, 티켓 정보, 예상 복구 시간 등 운영 이벤트와 관련된 정보를 얻을 수 있습니다.
+ 경영진 및 기타 이해관계자에게 보고서를 제공하여 일정 기간의 통화 볼륨, 사용자 만족도 점수, 미결 티켓 수 및 연령과 같은 운영 통계를 보여줍니다.
**일반적인 안티 패턴**:
+ 워크로드가 다운되어 서비스를 사용할 수 없게 됩니다. 사용자가 무슨 일이 일어나고 있는지 알려달라고 요청하면 통화 볼륨이 급증합니다. 관리자는 볼륨에 추가하여 누가 문제를 해결하고 있는지 확인하도록 요청합니다. 여러 운영 팀이 조사를 위해 중복적인 노력을 기울입니다.
+ 새로운 기능에 대한 기대로 인해 여러 인력이 엔지니어링 작업에 재배치됩니다. 백필은 제공되지 않으며 문제 해결 시간이 급증합니다. 이 정보는 캡처되지 않으며, 몇 주 후 사용자 피드백이 만족스럽지 못한 후에야 경영진이 문제를 알게 됩니다.
**이 모범 사례 확립의 이점:** 비즈니스에 영향을 미치는 운영 이벤트 중에는 상황을 파악하기 위해 노력하는 여러 팀의 정보를 쿼리하느라 많은 시간과 에너지가 낭비될 수 있습니다. 널리 보급된 상태 페이지와 대시보드를 구축함으로써 이해관계자들은 문제가 감지되었는지 여부, 문제의 주체가 누구인지, 정상 운영 상태로 돌아갈 것으로 예상되는 시기와 같은 정보를 신속하게 얻을 수 있습니다. 이렇게 하면 팀원들이 다른 사람에게 상태를 전달하는 데 너무 많은 시간을 소비하지 않고 문제를 해결하는 데 더 많은 시간을 할애할 수 있습니다.
또한 대시보드와 보고서는 의사 결정권자와 이해관계자에게 운영 팀이 비즈니스 요구 사항에 어떻게 대응할 수 있는지, 리소스가 어떻게 할당되고 있는지를 파악할 수 있는 인사이트를 제공할 수 있습니다. 이는 비즈니스를 지원하는 데 필요한 적절한 리소스가 마련되어 있는지 판단하는 데 매우 중요합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
운영 팀의 현재 주요 지표를 보여주는 대시보드를 구축하고 운영 리더와 경영진이 쉽게 액세스할 수 있도록 하세요.
인시던트나 이벤트가 언제 일어나는지, 누가 소유권을 갖고 있는지, 누가 대응을 조율하는지 알 수 있도록 신속하게 업데이트할 수 있는 상태 페이지를 구축하세요. 이 페이지에서 사용자가 고려해야 하는 단계 또는 해결 방법을 공유하고 위치를 널리 알리세요. 알 수 없는 문제가 발생하면 사용자가 먼저 이 위치를 확인하도록 권장합니다.
시간 경과에 따른 운영 상태를 보여주는 보고서를 수집 및 제공하고, 이를 리더와 의사 결정권자에게 배포하여 과제 및 요구 사항과 함께 운영 업무를 설명합니다.
목표와 KPI를 가장 잘 반영하고 변화를 주도하는 데 어떤 영향을 미쳤는지 이러한 지표와 보고서를 팀 간에 공유하세요. 이러한 활동에 시간을 할애하여 팀 내부 및 팀 간 운영의 중요성을 높이세요.
자체 대시보드와 함께 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)를 사용하거나 AWS Health 이벤트를 여기에 통합하여 팀에서 애플리케이션 문제를 AWS 서비스 상태와 연관시킬 수 있도록 합니다.
## 리소스
**관련 모범 사례:**
+ [OPS09-BP01 지표를 통한 운영 목표 및 KPI 측정](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
**관련 문서:**
+ [ Measure Progress ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [ 운영 가시성을 위한 대시보드 구축 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
**관련 예제:**
+ [ Data Operations ](https://aws.amazon.com/solutions/app-development/data-operations)
+ [ How to track your cost optimization KPIs with KPI Dashboard ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [ The Importance of Key Performance Indicators (KPIs) for Large-Scale Cloud Migrations ](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
# OPS09-BP03 운영 지표 검토 및 개선 우선순위 지정
운영 상태를 검토하기 위한 전용 시간과 리소스를 따로 확보하면 일상적인 업무 부서에 서비스를 제공하는 것이 최우선 과제가 될 수 있습니다. 운영 리더와 이해관계자를 모아 정기적으로 지표를 검토하고, 목표와 목적을 재확인 또는 수정하고, 개선의 우선순위를 정하세요.
**원하는 성과:**
+ 운영 책임자와 직원은 정기적으로 만나 지정된 보고 기간의 지표를 검토합니다. 도전 과제를 전달하고, 긍정적인 결과를 축하하며, 배운 교훈을 공유합니다.
+ 이해관계자와 비즈니스 리더는 운영 현황에 대해 정기적으로 브리핑을 받고 목표, KPI 및 향후 이니셔티브에 대한 의견을 요청받습니다. 서비스 제공, 운영 및 유지 관리 사이에서 장단점을 논의하고 상황에 맞게 적용합니다.
**일반적인 안티 패턴**:
+ 신제품이 출시되었지만 티어 1 및 티어 2 운영 팀은 적절한 지원 교육을 받지 못했거나 추가 인력을 배치 받지 못했습니다. 티켓 해결 시간 감소 및 인시던트 볼륨 증가를 보여주는 지표는 리더에게 보이지 않습니다. 불만을 품은 사용자가 플랫폼을 떠나면서 구독 수가 감소하기 시작하면 몇 주 후 조치가 취해집니다.
+ 워크로드에 대한 유지 관리를 수행하는 수동 프로세스가 오랫동안 사용되어 왔습니다. 자동화에 대한 열망은 있었지만 시스템의 중요도가 낮았기 때문에 우선순위가 낮았습니다. 그러나 시간이 흐르면서 시스템의 중요성이 커져 이제는 이러한 수동 프로세스가 운영 시간의 대부분을 차지하게 됩니다. 운영 부서에 더 많은 도구를 제공하는 데 필요한 리소스가 계획되어 있지 않아 업무량이 증가함에 따라 직원 소진 문제가 발생합니다. 직원들이 다른 경쟁업체로 떠나고 있다는 소식이 전해지면 경영진은 이를 인지하게 됩니다.
**이 모범 사례 확립의 이점:** 일부 조직에서는 서비스 제공과 신제품 또는 서비스에 동일한 시간과 관심을 할당하는 것이 어려울 수 있습니다. 이 경우 예상 서비스 수준이 서서히 저하되어 업무 부서에 문제가 발생할 수 있습니다. 비즈니스가 성장해도 운영은 변화하지 않고 발전하지 않으며 곧 뒤쳐질 수 있기 때문입니다. 운영 팀에서 수집한 인사이트를 정기적으로 검토하지 않으면 비즈니스에 미치는 위험은 너무 늦었을 때만 가시화될 수 있습니다. 운영 담당자와 경영진 모두에게 지표와 절차를 검토하는 데 시간을 할당함으로써 운영팀이 수행하는 중요한 역할을 가시화하고 위험 수준이 위험한 수준에 도달하기 훨씬 전에 위험을 식별할 수 있습니다. 운영 팀은 임박한 비즈니스 변경 및 이니셔티브를 더 잘 파악하여 사전 조치를 취할 수 있습니다. 운영 지표에 대한 리더십 가시성은 이러한 팀이 내부 및 외부 모두에서 고객 만족도에서 수행하는 역할을 보여주고, 팀이 우선순위에 대한 선택을 더 잘 판단하거나 운영팀이 새로운 비즈니스 및 워크로드 이니셔티브를 통해 변화하고 발전하는 데 필요한 시간과 리소스를 확보할 수 있도록 합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
시간을 할애하여 이해관계자와 운영 팀 간의 운영 지표를 검토하고 보고서 데이터를 검토하세요. 이러한 보고서를 조직의 목표 및 목적의 맥락에 비추어 충족되고 있는지 판단하세요. 목표가 명확하지 않거나, 요청한 내용과 주어진 내용이 상충할 수 있는 모호함의 원인을 파악하세요.
시간, 인력, 도구가 운영 성과에 도움이 될 수 있는 부분을 파악하세요. 이것이 어떤 KPI에 영향을 미칠지 그리고 어떤 성공 목표를 세워야 하는지 결정하세요. 정기적으로 재검토하여 사업 부문을 지원할 수 있는 충분한 리소스가 운영되고 있는지 확인하세요.
## 리소스
**관련 문서**:
+ [ Amazon Athena ](https://aws.amazon.com/athena/)
+ [ Amazon CloudWatch 지표 및 차원 참조 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [ Amazon Quick ](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [ CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버에서 지표 및 로그 수집 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Amazon CloudWatch 지표 사용 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS 10. 워크로드 및 운영 이벤트를 어떻게 관리하나요?
이벤트로 인해 워크로드가 중단될 가능성을 최소화할 수 있도록 이벤트 대응을 위한 절차를 준비하고 검증합니다.
**Topics**
+ [OPS10-BP01 이벤트, 인시던트 및 문제 관리 프로세스 사용](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 비즈니스 영향을 기반으로 운영 이벤트의 우선순위 지정](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 에스컬레이션 경로 정의](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 서비스에 영향을 미치는 이벤트에 대한 고객 커뮤니케이션 계획 정의](ops_event_response_push_notify.md)
+ [OPS10-BP06 대시보드를 통해 상태 전달](ops_event_response_dashboards.md)
+ [OPS10-BP07 이벤트 대응 자동화](ops_event_response_auto_event_response.md)
# OPS10-BP01 이벤트, 인시던트 및 문제 관리 프로세스 사용
이벤트, 인시던트 및 문제를 효율적으로 관리하는 능력은 워크로드 상태 및 성능을 유지하는 데 매우 중요합니다. 효과적인 대응 및 해결 전략을 개발하려면 이러한 요소 간의 차이점을 인식하고 이해하는 것이 매우 중요합니다. 각 측면에 대해 잘 정의된 프로세스를 수립하고 준수하면 팀이 발생하는 모든 운영 문제를 신속하고 효과적으로 처리하는 데 도움이 됩니다.
**원하는 성과:** 체계적으로 문서화되고 중앙 집중식으로 저장된 프로세스를 통해 운영 이벤트, 인시던트 및 문제를 효과적으로 관리합니다. 이러한 프로세스는 변경 사항을 반영하여 지속적으로 업데이트되므로 처리가 간소화되고 높은 서비스 신뢰성과 워크로드 성능이 유지됩니다.
**일반적인 안티 패턴**:
+ 이벤트에 사전 대응보다는 사후 대응 방식으로 대응합니다.
+ 다양한 유형의 이벤트 또는 인시던트에 대해 일관되지 않은 접근 방식을 취합니다.
+ 조직은 향후 인시던트 방지를 위해 인시던트를 분석하고 학습하는 과정을 진행하지 않습니다.
**이 모범 사례 확립의 이점:**
+ 간소화되고 표준화된 대응 프로세스.
+ 인시던트가 서비스 및 고객에게 미치는 영향 감소.
+ 신속한 문제 해결.
+ 운영 프로세스의 지속적인 개선.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
이 모범 사례를 구현하면 워크로드 이벤트를 추적하게 됩니다. 인시던트 및 문제를 처리하기 위한 프로세스를 보유하게 됩니다. 이 프로세스는 문서화되고 공유되며 자주 업데이트됩니다. 문제가 파악되면 우선순위가 지정되고 해결됩니다.
**이벤트, 인시던트 및 문제에 대한 이해**
+ **이벤트:** *이벤트*는 동작, 발생 또는 상태 변경을 관찰한 결과일 수 있습니다. 이벤트는 계획된 것일 수도 있고 계획되지 않은 것일 수도 있으며 워크로드의 내부 또는 외부에서 발생할 수 있습니다.
+ **인시던트:** *인시던트*는 예상치 못한 중단이나 서비스 품질 저하와 같이 대응이 필요한 이벤트를 말합니다. 이는 정상적인 워크로드 운영을 복원하기 위해 즉각적인 조치가 필요한 장애를 나타냅니다.
+ **문제:** *문제*는 하나 이상의 인시던트의 근본 원인을 말합니다. 문제를 식별하고 해결하려면 인시던트를 더 깊이 파고들어 향후 발생을 방지해야 합니다.
### 구현 단계
**이벤트**
1. **이벤트 모니터링:**
+ [관찰성을 구현](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)하고 [워크로드 관찰성을 활용](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)하세요.
+ 사용자, 역할 또는 AWS 서비스에서 수행한 모니터링 작업은 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)에 이벤트로 기록됩니다.
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)에서 실시간으로 애플리케이션의 운영 변화에 대응합니다.
+ [AWS Config](https://aws.amazon.com/config/)에서 리소스 구성 변경 사항을 지속적으로 평가, 모니터링 및 기록합니다.
1. **프로세스 생성:**
+ 어떤 이벤트가 중요하고 모니터링이 필요한지 평가하는 프로세스를 개발합니다. 여기에는 정상 및 비정상 활동에 대한 임곗값 및 파라미터 설정이 포함됩니다.
+ 이벤트를 인시던트로 에스컬레이션하는 기준을 결정합니다. 심각도, 사용자에게 미치는 영향 또는 예상 행동과의 차이를 토대로 결정할 수 있습니다.
+ 이벤트 모니터링 및 대응 프로세스를 정기적으로 검토합니다. 여기에는 과거 인시던트 분석, 임곗값 조정, 경고 메커니즘 개선이 포함됩니다.
**인시던트**
1. **인시던트에 대응:**
+ 관찰성 도구의 인사이트를 사용하여 인시던트를 빠르게 식별하고 이에 대응합니다.
+ [AWS Systems Manager Ops Center](https://aws.amazon.com/systems-manager/features/#OpsCenter)를 구현하여 운영 항목 및 인시던트를 집계하고 체계화하며 우선순위를 지정합니다.
+ 심층적인 분석 및 문제 해결을 위해 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 및 [AWS X-Ray](https://aws.amazon.com/xray/) 같은 서비스를 사용합니다.
+ 향상된 인시던트 관리를 위해 선제적, 사전 예방 및 감지 기능을 활용하는 [AWS Managed Services(AMS)](https://aws.amazon.com/managed-services/)는 고려하세요. AMS는 모니터링, 인시던트 탐지 및 대응, 보안 관리와 같은 서비스를 통해 운영 지원을 확대합니다.
+ Enterprise Support 고객은 프로덕션 워크로드에 대한 지속적인 사전 모니터링 및 인시던트 관리를 제공하는 [AWS 인시던트 탐지 및 대응](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)을 사용할 수 있습니다.
1. **인시던트 관리 프로세스 만들기:**
+ 명확한 역할, 커뮤니케이션 프로토콜, 해결 단계를 포함한 구조화된 인시던트 관리 프로세스를 수립합니다.
+ 효율적인 대응 및 조정을 위해 [채팅 애플리케이션 내 Amazon Q Developer](https://aws.amazon.com/chatbot/)와 같은 도구를 통해 인시던트 관리를 통합합니다.
+ 각 범주에 대해 사전 정의된 [인시던트 대응 계획](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)을 사용하여 심각도를 기준으로 인시던트를 분류합니다.
1. **학습 및 개선:**
+ 근본 원인을 이해하고 해결 방법의 효과를 확인하기 위해 [인시던트 사후 분석](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)을 수행합니다.
+ 검토 및 발전하는 관행을 토대로 대응 계획을 지속적으로 업데이트하고 개선합니다.
+ 팀 전반에서 학습한 내용을 문서화하고 공유하여 운영 복원력을 개선합니다.
+ Enterprise Support 고객은 기술 계정 관리자로부터 [Incident Management 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)을 요청할 수 있습니다. 이 안내 워크숍에서는 기존 인시던트 대응 계획을 테스트하고 개선할 수 있는 영역을 식별하도록 돕습니다.
** 문제**
1. **문제 파악:**
+ 이전 인시던트의 데이터를 사용하여 심층적인 시스템 문제를 시사하는 반복 패턴을 식별합니다.
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 및 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)와 같은 도구를 활용하여 추세를 분석하고 근본적인 문제를 파악합니다.
+ 운영, 개발, 사업부를 비롯한 여러 팀이 참여하여 근본 원인에 대한 다양한 관점을 확보합니다.
1. **문제 관리 프로세스 만들기:**
+ 빠른 해결보다는 장기적인 해결책에 초점을 맞춰 체계적인 문제 관리 프로세스를 개발합니다.
+ 근본 원인 분석(RCA) 기술을 통합하여 인시던트의 근본 원인을 조사하고 이해합니다.
+ 결과를 기반으로 운영 정책, 절차 및 인프라를 업데이트하여 재발을 방지합니다.
1. **지속적인 개선:**
+ 지속적인 학습과 개선의 문화를 조성하여 팀이 잠재적인 문제를 사전에 식별하고 해결하도록 독려합니다.
+ 진화하는 비즈니스 및 기술 환경에 맞게 문제 관리 프로세스와 도구를 정기적으로 검토하고 수정합니다.
+ 조직 전반에 걸쳐 인사이트와 모범 사례를 공유하여 보다 복원력 있고 효율적인 운영 환경을 구축합니다.
1. **AWS Support 참여:**
+ 선제적 지침 및 최적화 권장 사항에 대해 AWS지원 리소스(예: [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/))를 사용합니다.
+ Enterprise Support 고객은 [AWS Countdown](https://aws.amazon.com/premiumsupport/aws-countdown/)과 같은 전문 프로그램을 통해 중요 이벤트 발생 시 지원을 받을 수 있습니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS04-BP02 애플리케이션 원격 측정 구현](ops_observability_application_telemetry.md)
+ [OPS07-BP03 런북을 사용한 절차 수행](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 플레이북을 사용하여 문제 조사](ops_ready_to_support_use_playbooks.md)
+ [OPS08-BP01 워크로드 지표 분석](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md)
**관련 문서**:
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Incident Detection and Response ](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)
+ [AWS Cloud Adoption Framework: Operations Perspective - Incident and problem management ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [Incident Management in the Age of DevOps and SRE](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - What is Incident Management?](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**관련 비디오:**
+ [ Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [AWS re:Invent 2022 - The Amazon Builders' Library: 25 yrs of Amazon operational excellence ](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - AWS Incident Detection and Response (SUP201) ](https://www.youtube.com/watch?v=IbSgM4IP9IE)
+ [ Introducing Incident Manager from AWS Systems Manager](https://www.youtube.com/watch?v=I6lScgh4qds)
**관련 예제:**
+ [AWS Proactive Services – Incident Management 워크숍 ](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [ How to Automate Incident Response with PagerDuty and AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/how-to-automate-incident-response-with-pagerduty-and-aws-systems-manager-incident-manager/)
+ [ Engage Incident Responders with the On-Call Schedules in AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/engage-incident-responders-with-the-on-call-schedules-in-aws-systems-manager-incident-manager/)
+ [ Improve the Visibility and Collaboration during Incident Handling in AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/improve-the-visibility-and-collaboration-during-incident-handling-in-aws-systems-manager-incident-manager/)
+ [ Incident reports and service requests in AMS ](https://docs.aws.amazon.com/managedservices/latest/userguide/support-experience.html)
**관련 서비스:**
+ [ Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
# OPS10-BP02 알림별 프로세스 마련
효과적이고 효율적인 인시던트 관리를 위해서는 시스템의 각 알림에 대해 명확하고 정의된 프로세스를 마련하는 것이 필수적입니다. 이렇게 하면 모든 알림이 구체적이고 실행 가능한 대응으로 이어져 운영의 신뢰성과 대응력이 향상됩니다.
**원하는 성과:** 모든 알림은 구체적이고 잘 정의된 대응 계획을 개시합니다. 가능한 경우 명확한 소유권과 정의된 에스컬레이션 경로를 통해 대응이 자동화됩니다. 알림은 모든 운영자가 일관되고 효과적으로 대응할 수 있도록 최신 지식 베이스에 연결됩니다. 대응이 전반적으로 빠르고 균일하여 운영 효율성과 신뢰성이 향상됩니다.
**일반적인 안티 패턴**:
+ 알림에는 사전 정의된 대응 프로세스가 없으므로 임시 조치 및 문제 해결이 지연될 수 있습니다.
+ 알림 오버로드로 인해 중요한 알림이 간과됩니다.
+ 명확한 소유권과 책임이 없기 때문에 알림이 일관되지 않은 방식으로 처리됩니다.
**이 모범 사례 확립의 이점:**
+ 실행 가능한 알림만 발생시켜 알림 피로를 줄입니다.
+ 운영 문제의 평균 해결 시간(MTTR)을 단축합니다.
+ 평균 조사 시간(MTTI)이 단축되어 MTTR을 단축합니다.
+ 운영 대응 규모를 조정할 수 있는 기능을 개선합니다.
+ 운영 이벤트 처리의 일관성과 신뢰성이 향상됩니다.
예를 들어 애플리케이션 경보, 운영 문제 및 계획된 수명 주기 이벤트(클러스터가 자동 업데이트되기 전에 Amazon EKS 버전 업데이트 등)를 포함하여 중요한 계정에 대한 AWS Health 이벤트에 대해 정의된 프로세스가 있으며 팀이 이러한 이벤트를 적극적으로 모니터링하고, 소통하고, 대응할 수 있는 역량을 제공합니다. 이러한 작업을 통해 AWS 측 변경으로 인한 서비스 중단을 방지하거나 예상치 못한 문제가 발생할 때 더 빠르게 완화할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
알림별 프로세스를 갖추려면 각 알림에 대한 명확한 대응 계획을 마련하고, 가능한 경우 대응을 자동화하며, 운영 피드백과 변화하는 요구 사항을 기반으로 이러한 프로세스를 지속적으로 개선해야 합니다.
### 구현 단계
다음 다이어그램은 [AWS Systems Manager Incident Manager](https://aws.amazon.com/systems-manager/features/incident-manager/) 내 인시던트 관리 워크플로를 보여줍니다. 이는 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 또는 [Amazon EventBridge](https://aws.amazon.com/eventbridge/)의 특정 이벤트에 대한 대응으로 인시던트를 자동으로 생성하여 운영 문제에 신속하게 대응할 수 있도록 설계되었습니다. 인시던트가 자동 또는 수동으로 생성되면 Incident Manager에서 인시던트 관리를 중앙 집중화하고 관련 AWS 리소스 정보를 구성하며 사전 정의된 대응 계획을 개시합니다. 여기에는 즉각적인 조치를 위한 Systems Manager Automation 런북 실행과 관련 작업 및 분석을 추적하기 위해 OpsCenter에 상위 운영 작업 항목을 생성하는 것도 포함됩니다. 이 간소화된 프로세스는 AWS 환경 전반에서 인시던트 대응을 가속화하고 조정합니다.
![\[Incident Manager의 운영 방식을 나타내는 플로차트 - 채팅 애플리케이션 내 Amazon Q Developer, 에스컬레이션 계획 및 연락처, 런북이 대응 계획으로 전달되어 인시던트 및 분석으로 이어집니다. Amazon CloudWatch는 대응 계획에도 적용됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/images/incident-manager-how-it-works.png)
1. **복합 경보 사용:** CloudWatch에서 [복합 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)를 생성하여 경보를 그룹화하고 노이즈를 줄이며 보다 의미 있는 대응이 가능하게 합니다.
1. **[AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)로 최신 정보를 확인하세요:** AWS Health는 AWS 클라우드 리소스 상태에 대한 신뢰할 수 있는 정보 소스입니다. AWS Health를 사용해 계획된 수명 주기 이벤트와 같은 현재 서비스 이벤트 및 예정된 변경 사항을 시각화하고 알림을 받아 영향 완화 조치를 취할 수 있습니다.
1. [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html)를 통해 이메일 및 채팅 채널에 [적합한 AWS Health 이벤트 알림을 생성](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)하고, [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 또는 [Amazon EventBridge를 통해 모니터링 및 알림 도구](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)와 프로그래밍 방식으로 통합할 수 있습니다.
1. Amazon EventBridge 또는 AWS Health API를 통해 이미 사용할 수 있는 변경 관리 또는 ITSM 도구(예: [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 또는 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html))와 통합하여 조치가 필요한 상태 이벤트에 대한 진행 상황을 계획하고 추적하세요.
1. AWS Organizations를 사용하는 경우 [AWS Health에 대한 조직 보기](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html)를 활성화하여 계정 간에 AWS Health 이벤트를 집계합니다.
1. **Amazon CloudWatch 경보를 Incident Manager와 통합:** [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)에서 인시던트를 자동으로 생성하도록 CloudWatch 경보를 구성합니다.
1. **Amazon EventBridge를 Incident Manager와 통합:** [EventBridge 규칙](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)을 만들어 정의된 대응 계획에 따라 이벤트에 대응하고 인시던트를 생성합니다.
1. **Incident Manager에서 인시던트 준비:**
+ 알림 유형별 세부 [대응 계획](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)을 Incident Manager에서 수립합니다.
+ Incident Manager의 대응 계획에 연결된 [채팅 애플리케이션 내 Amazon Q Developer](https://docs.aws.amazon.com/incident-manager/latest/userguide/chat.html)를 통해 채팅 채널을 설정하여 Slack, Microsoft Teams 및 Amazon Chime과 같은 여러 플랫폼에서 인시던트 발생 시 실시간 커뮤니케이션을 용이하게 합니다.
+ Incident Manager 내에서 [Systems Manager Automation 런북](https://docs.aws.amazon.com/incident-manager/latest/userguide/runbooks.html)을 통합하여 인시던트에 대한 자동 대응을 유도합니다.
## 리소스
**관련 모범 사례:**
+ [OPS04-BP01 핵심 성과 지표 파악](ops_observability_identify_kpis.md)
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
**관련 문서**:
+ [AWS Cloud Adoption Framework: Operations Perspective - Incident and problem management ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [ Setting up AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/setting-up.html)
+ [ Preparing for incidents in Incident Manager ](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-response.html)
**관련 비디오:**
+ [ Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [ re:Invent 2,023 \$1 Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**관련 예제:**
+ [AWS 워크숍 - AWS Systems Manager Incident Manager - Automate incident response to security events ](https://catalog.workshops.aws/automate-incident-response/en-US/settingupim/onboarding)
# OPS10-BP03 비즈니스 영향을 기반으로 운영 이벤트의 우선순위 지정
운영 이벤트에 즉시 대응하는 것이 중요하지만 모든 이벤트가 동일한 것은 아닙니다. 비즈니스 영향을 기준으로 우선순위를 정할 때는 안전, 재정적 손실, 규정 위반 또는 평판 손상과 같은 중대한 결과를 초래할 가능성이 있는 이벤트를 해결하는 데에도 우선순위를 둡니다.
**원하는 성과:** 운영 이벤트에 대한 대응은 비즈니스 운영 및 목표에 대한 잠재적 영향을 기반으로 우선순위가 지정됩니다. 이렇게 하면 효율적이고 효과적으로 대응할 수 있습니다.
**일반적인 안티 패턴**:
+ 모든 이벤트는 동일한 수준의 긴급도로 처리되므로 중요한 문제를 해결하는 데 혼란과 지연이 발생합니다.
+ 영향이 큰 이벤트와 그렇지 않은 이벤트를 구분하지 못해 리소스가 잘못 할당됩니다.
+ 조직에 명확한 우선순위 지정 프레임워크가 없기 때문에 운영 이벤트에 대한 대응이 일관되지 않습니다.
+ 이벤트는 비즈니스 성과에 미치는 영향보다는 보고된 순서를 기준으로 우선순위가 지정됩니다.
**이 모범 사례 확립의 이점:**
+ 중요한 비즈니스 기능에 먼저 주의를 기울이도록 하여 잠재적 피해를 최소화합니다.
+ 여러 동시 이벤트 발생 시 리소스 할당을 개선합니다.
+ 조직의 신뢰 유지 및 규제 요구 사항 충족 능력을 개선합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
여러 운영 이벤트가 발생하는 경우 영향과 긴급성을 기반으로 우선순위를 정하는 체계적인 접근 방식이 필수적입니다. 이 접근 방식을 사용하면 정보에 입각한 결정을 내리고, 가장 필요한 부분에 노력을 기울이며, 비즈니스 연속성에 대한 위험을 완화할 수 있습니다.
### 구현 단계
1. **영향 평가:** 이벤트가 비즈니스 운영 및 목표에 미치는 잠재적 영향을 기준으로 이벤트의 심각도를 평가하는 분류 체계를 개발합니다. 다음 예에서는 영향 범주를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **긴급성 평가:** 안전, 재정적 영향, 서비스 수준에 관한 계약(SLA)과 같은 요소를 고려하여 이벤트에 얼마나 빨리 대응해야 하는지에 대한 긴급 수준을 정의합니다. 다음 예는 긴급성 범주를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **우선순위 매트릭스 만들기:**
+ 매트릭스를 사용하여 영향과 긴급성을 상호 참조하여 다양한 조합에 우선순위 수준을 할당합니다.
+ 운영 이벤트 대응을 담당하는 모든 팀원이 매트릭스에 액세스하고 이를 이해할 수 있도록 하세요.
+ 다음 예제 매트릭스는 긴급성과 영향에 따라 인시던트 심각도를 표시합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **교육 및 커뮤니케이션:** 대응 팀에 우선순위 매트릭스와 이벤트 중 우선순위 매트릭스 준수의 중요성에 대해 교육합니다. 우선순위 지정 프로세스를 모든 이해관계자에게 전달하여 명확한 기대치를 설정합니다.
1. **인시던트 대응과 통합:**
+ 우선순위 매트릭스를 인시던트 대응 계획 및 도구에 통합합니다.
+ 가능한 경우 이벤트의 분류 및 우선순위 지정을 자동화하여 대응 시간을 단축합니다.
+ Enterprise Support 고객은 프로덕션 워크로드에 대한 연중무휴 사전 모니터링 및 인시던트 관리를 제공하는 [AWS 인시던트 탐지 및 대응](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)을 활용할 수 있습니다.
1. **검토 및 조정:** 우선순위 지정 프로세스의 효과를 정기적으로 검토하고 비즈니스 환경의 피드백과 변화를 기반으로 조정합니다.
## 리소스
**관련 모범 사례:**
+ [OPS03-BP03 에스컬레이션 장려](ops_org_culture_team_enc_escalation.md)
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
+ [OPS09-BP01 지표를 통한 운영 목표 및 KPI 측정](ops_operations_health_measure_ops_goals_kpis.md)
**관련 문서**:
+ [ Atlassian - Understanding incident severity levels ](https://www.atlassian.com/incident-management/kpis/severity-levels)
+ [ IT Process Map - Checklist Incident Priority ](https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority)
# OPS10-BP04 에스컬레이션 경로 정의
인시던트 대응 프로토콜 내에 명확한 에스컬레이션 경로를 설정하여 시의적절하고 효과적인 조치를 취합니다. 여기에는 에스컬레이션 프롬프트 지정, 에스컬레이션 프로세스 상세 설명, 신속한 의사 결정 및 평균 해결 시간(MTTR) 단축을 위한 사전 승인 조치가 포함됩니다.
**원하는 성과:** 인시던트를 적절한 담당자에게 에스컬레이션하여 대응 시간과 영향을 최소화하는 체계적이고 효율적인 프로세스입니다.
**일반적인 안티 패턴**:
+ 복구 절차가 명확하지 않으면 중대한 인시던트가 발생했을 때 임시방편책으로 대응해야 합니다.
+ 정의된 권한 및 소유권이 없으면 긴급 조치가 필요한 경우 지연이 발생합니다.
+ 이해관계자와 고객에게는 기대에 부합하는 정보가 제공되지 않습니다.
+ 중요한 결정이 지연됩니다.
**이 모범 사례 확립의 이점:**
+ 사전 정의된 에스컬레이션 절차를 통해 인시던트 대응을 간소화합니다.
+ 사전 승인된 조치와 명확한 소유권을 통해 가중 중지 시간을 줄입니다.
+ 인시던트 심각도에 따라 리소스 할당 및 지원 수준 조정을 개선합니다.
+ 이해관계자 및 고객과의 커뮤니케이션을 개선합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
적절하게 정의된 에스컬레이션 경로는 신속한 인시던트 대응에 매우 중요합니다. AWS Systems Manager Incident Manager에서는 인시던트 발생 시 적절한 조치를 취할 수 있도록 적절한 담당자에게 알림을 보내는 구조화된 에스컬레이션 계획 및 당직 일정을 설정할 수 있도록 지원합니다.
### 구현 단계
1. **에스컬레이션 프롬프트 설정:** [CloudWatch 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)를 설정하여 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com//incident-manager/latest/userguide/incident-creation.html)에서 인시던트를 생성합니다.
1. **당직 일정 설정:** Incident Manager에서 에스컬레이션 경로에 맞게 조정된 [당직 일정](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule-create.html)을 생성합니다. 당직 근무 중인 직원에게 신속하게 조치를 취하는 데 필요한 권한과 도구를 제공합니다.
1. ** 상세 에스컬레이션 절차: **
+ 인시던트를 에스컬레이션해야 하는 구체적인 조건을 결정합니다.
+ Incident Manager에서 [에스컬레이션 계획](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)을 생성합니다.
+ 에스컬레이션 채널은 연락처 또는 당직 일정으로 구성되어야 합니다.
+ 각 에스컬레이션 수준에서 팀의 역할과 책임을 정의합니다.
1. **완화 조치 사전 승인:** 의사 결정권자와 협업하여 예상 시나리오에 대한 조치를 사전 승인합니다. Incident Manager와 통합된 [Systems Manager Automation 런북](https://docs.aws.amazon.com//incident-manager/latest/userguide/tutorials-runbooks.html)을 사용하여 인시던트을 빠르게 해결합니다.
1. **소유권 지정:** 에스컬레이션 경로의 각 단계에서 내부 소유자를 명확하게 식별합니다.
1. **서드파티 에스컬레이션에 대한 세부 정보:**
+ 서드파티의 서비스 수준에 관한 계약(SLA)을 문서화하고 내부 목표에 맞게 조정합니다.
+ 인시던트 발생 시 공급업체 커뮤니케이션을 위한 명확한 프로토콜을 설정합니다.
+ 공급업체 연락처를 인시던트 관리 도구에 통합하여 직접 액세스할 수 있습니다.
+ 서드파티 대응 시나리오가 포함된 정기적인 훈련을 실시합니다.
+ 공급업체 에스컬레이션 정보를 체계적으로 문서화하고 쉽게 액세스할 수 있도록 합니다.
1. **에스컬레이션 계획 교육 및 연습:** 에스컬레이션 프로세스에 대해 팀을 교육하고 정기적인 인시던트 대응 훈련 또는 게임 데이를 실시합니다. Enterprise Support 고객은 [Incident Management 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)을 요청할 수 있습니다.
1. **지속적인 개선:** 에스컬레이션 경로의 효과를 정기적으로 검토합니다. 인시던트 사후 분석 및 지속적인 피드백을 통해 학습한 교훈을 기반으로 프로세스를 업데이트합니다.
**구현 계획의 작업 수준:** 보통
## 리소스
**관련 모범 사례:**
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md)
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md)
**관련 문서**:
+ [AWS Systems Manager Incident Manager Escalation Plans ](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
+ [ Working with on-call schedules in Incident Manager ](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule.html)
+ [ 런북 생성 및 관리 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ Temporary elevated access management with AWS IAM Identity Center](https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/)
+ [ Atlassian - Escalation policies for effective incident management ](https://www.atlassian.com/incident-management/on-call/escalation-policies)
# OPS10-BP05 서비스에 영향을 미치는 이벤트에 대한 고객 커뮤니케이션 계획 정의
서비스에 영향을 미치는 이벤트 발생 시 효과적인 커뮤니케이션은 고객과의 신뢰와 투명성을 유지하는 데 매우 중요합니다. 체계적으로 정의된 커뮤니케이션 계획을 통해 조직은 인시던트 발생 시 내부 및 외부에서 정보를 빠르고 명확하게 공유할 수 있습니다.
**원하는 성과:**
+ 서비스에 영향을 미치는 이벤트 발생 시 고객과 이해관계자에게 효과적으로 정보를 제공하는 탄탄한 커뮤니케이션 계획.
+ 신뢰를 구축하고 고객의 불안을 줄이기 위한 커뮤니케이션의 투명성.
+ 서비스에 영향을 미치는 이벤트가 고객 경험 및 비즈니스 운영에 미치는 영향 최소화.
**일반적인 안티 패턴**:
+ 부적절하거나 지연된 커뮤니케이션은 고객 혼란과 불만족으로 이어집니다.
+ 지나치게 기술적이거나 모호한 메시지는 실제로 사용자에게 미치는 영향을 전달하지 못합니다.
+ 사전 정의된 커뮤니케이션 전략이 없기 때문에 메시지가 일관되지 않고 반응성이 떨어집니다.
**이 모범 사례 확립의 이점:**
+ 적극적이고 명확한 커뮤니케이션을 통해 고객 신뢰와 만족도를 개선합니다.
+ 고객 문제를 선제적으로 해결하여 지원 팀의 부담을 완화합니다.
+ 인시던트를 효과적으로 관리하고 복구하는 능력을 개선합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
서비스에 영향을 미치는 이벤트에 대한 포괄적인 커뮤니케이션 계획을 수립하려면 적절한 채널 선택부터 메시지 작성 및 어조 조정에 이르기까지 다양한 측면이 필요합니다. 계획은 조정 가능하고 확장 가능하며 다양한 중단 시나리오에 적합해야 합니다.
### 구현 단계
1. **역할과 책임 정의:**
+ 주요 인시던트 관리자를 지정하여 인시던트 대응 활동을 감독합니다.
+ 모든 외부 및 내부 커뮤니케이션을 조정할 책임이 있는 커뮤니케이션 관리자를 지정합니다.
+ 지원 티켓을 통해 일관된 커뮤니케이션이 가능하도록 지원 관리자를 포함합니다.
1. **커뮤니케이션 채널 파악:** 워크플레이스 채팅, 이메일, SMS, 소셜 미디어, 앱 내 알림, 상태 페이지와 같은 채널을 선택합니다. 이러한 채널은 복원력이 있어야 하며 서비스에 영향을 미치는 이벤트 발생 시 독립적으로 운영될 수 있어야 합니다.
1. ** 고객에게 빠르고 명확하게 정기적으로 커뮤니케이션 전달: **
+ 단순성과 필수 세부 정보를 강조하여 다양한 서비스 장애 시나리오에 대한 템플릿을 개발합니다. 템플릿에 서비스 장애, 예상 해결 시간 및 영향에 대한 정보를 포함합니다.
+ Amazon Pinpoint를 사용하여 푸시 알림, 인앱 알림, 이메일, 문자 메시지, 음성 메시지 및 사용자 지정 채널을 통한 메시지를 사용하여 고객에게 알립니다.
+ Amazon Simple Notification Service(SNS)를 사용하여 프로그래밍 방식으로 또는 이메일, 모바일 푸시 알림 및 문자 메시지를 통해 구독자에게 알립니다.
+ Amazon CloudWatch 대시보드를 공개적으로 공유하여 대시보드를 통해 상태를 전달합니다.
+ 소셜 미디어 참여 장려:
+ 소셜 미디어를 적극적으로 모니터링하여 고객의 분위기를 파악합니다.
+ 소셜 미디어 플랫폼에 게시하여 공개 업데이트 및 커뮤니티 참여를 확인합니다.
+ 일관되고 명확한 소셜 미디어 커뮤니케이션을 위한 템플릿을 준비합니다.
1. **내부 커뮤니케이션 조정:** 팀 조정 및 커뮤니케이션을 위해 채팅 애플리케이션 내 Amazon Q Developer 같은 도구를 사용하여 내부 프로토콜을 구현합니다. CloudWatch 대시보드를 사용하여 상태를 전달합니다.
1. ** 전용 도구 및 서비스를 사용하여 커뮤니케이션 조율: **
+ 채팅 애플리케이션 내 Amazon Q Developer와 함께 AWS Systems Manager Incident Manager를 사용하여 인시던트 발생 시 실시간 내부 커뮤니케이션 및 조정을 위한 전용 채팅 채널을 설정합니다.
+ AWS Systems Manager Incident Manager 런북을 사용하여 인시던트 발생 시 Amazon Pinpoint, Amazon SNS 또는 소셜 미디어 플랫폼과 같은 서드파티 도구를 통해 고객 알림을 자동화합니다.
+ 런북에 승인 워크플로를 통합하여 선택적으로 전송 전에 모든 외부 커뮤니케이션을 검토하고 승인할 수 있습니다.
1. ** 연습 및 개선: **
+ 커뮤니케이션 도구 및 전략의 사용에 대한 교육을 실시합니다. 팀이 인시던트 발생 시 시의적절하게 결정을 내릴 수 있도록 지원합니다.
+ 정기적인 훈련이나 게임 데이를 통해 커뮤니케이션 계획을 테스트합니다. 이 테스트를 사용하여 메시징을 구체화하고 채널의 효과를 평가합니다.
+ 피드백 메커니즘을 구현하여 인시던트 발생 시 커뮤니케이션 효과를 평가합니다. 피드백과 변화하는 요구 사항을 기반으로 커뮤니케이션 계획을 지속적으로 발전시킵니다.
**구현 계획의 작업 수준:** 높음
## 리소스
**관련 모범 사례:**
+ [OPS07-BP03 런북을 사용한 절차 수행](ops_ready_to_support_use_runbooks.md)
+ [OPS10-BP06 대시보드를 통해 상태 전달](ops_event_response_dashboards.md)
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md)
**관련 문서**:
+ [ Atlassian - Incident communication best practices ](https://www.atlassian.com/incident-management/incident-communication)
+ [ Atlassian - How to write a good status update ](https://www.atlassian.com/blog/statuspage/how-to-write-a-good-status-update)
+ [ PagerDuty - A Guide to Incident Communications ](https://www.pagerduty.com/resources/learn/a-guide-to-incident-communications/)
**관련 비디오:**
+ [ Atlassian - Create your own incident communication plan: Incident templates ](https://www.youtube.com/watch?v=ZROVn6-K2qU)
**관련 예제:**
+ [AWS Health Dashboard ](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
# OPS10-BP06 대시보드를 통해 상태 전달
대시보드를 전략적 도구로 사용하여 내부 기술팀, 경영진, 고객 등 다양한 대상에게 실시간 운영 상태 및 주요 지표를 전달합니다. 이러한 대시보드는 시스템 상태 및 비즈니스 성과를 중앙 집중식으로 시각적으로 표현하여 투명성과 의사 결정 효율성을 향상시킵니다.
**원하는 성과:**
+ 대시보드는 다양한 이해관계자와 관련된 시스템 및 비즈니스 지표에 대한 포괄적인 보기를 제공합니다.
+ 이해관계자가 운영 정보에 사전에 액세스할 수 있으므로 빈번히 상태를 요청하지 않아도 됩니다.
+ 정상적인 운영 및 인시던트 발생 시 실시간 의사 결정이 향상됩니다.
**일반적인 안티 패턴**:
+ 엔지니어가 인시던트 관리 통화에 참여하려면 빠른 진행을 위해 상태 업데이트가 필요합니다.
+ 관리를 위해 수동 보고에 의존하기 때문에 지연이 발생하고 정확성이 떨어질 수 있습니다.
+ 인시던트 발생 시 운영 팀은 상태 업데이트를 위해 빈번히 업무를 중단해야 합니다.
**이 모범 사례 확립의 이점:**
+ 이해관계자가 중요한 정보에 즉시 액세스할 수 있도록 하여 정보에 입각한 의사 결정을 촉진합니다.
+ 수동 보고 및 빈번한 상태 조회를 최소화하여 운영 비효율성을 완화합니다.
+ 시스템 성능 및 비즈니스 지표에 대한 실시간 가시성을 통해 투명성과 신뢰도를 높입니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
대시보드는 시스템 및 비즈니스 지표의 상태를 효과적으로 전달하며 다양한 대상 그룹의 요구에 맞게 조정할 수 있습니다. Amazon CloudWatch 대시보드 및 Amazon Quick과 같은 도구를 사용하면 시스템 모니터링 및 비즈니스 인텔리전스를 위한 대화형 실시간 대시보드를 만들 수 있습니다.
### 구현 단계
1. **이해관계자의 요구 사항 파악:** 기술팀, 경영진, 고객 등 다양한 대상 그룹의 특정 정보 요구 사항을 결정합니다.
1. ** 적절한 도구 선택:** 시스템 모니터링을 위한 [Amazon CloudWatch 대시보드](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) 및 대화형 비즈니스 인텔리전스를 위한 [Amazon Quick](https://aws.amazon.com/quicksight/)과 같은 적절한 도구를 선택합니다. [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)는 [AWS Health Dashboard](https://health.aws.amazon.com/health/home)에서 즉시 사용 가능한 환경을 제공하며, Amazon EventBridge 또는 AWS Health API를 통해 상태 이벤트를 사용하여 자체 대시보드를 보강할 수도 있습니다.
1. **효과적인 대시보드 설계:**
+ 관련 지표와 KPI를 명확하게 제시하여 이해할 수 있고 실행 가능한 방식으로 대시보드를 설계합니다.
+ 필요에 따라 시스템 수준 및 비즈니스 수준 보기를 통합합니다.
+ 상위 수준(광범위한 개요용) 및 하위 수준(세부 분석용) 대시보드를 모두 포함합니다.
+ 대시보드 내에 자동 경보를 통합하여 중요한 문제를 강조 표시합니다.
+ 대시보드에 중요한 지표 임곗값 및 목표를 주석으로 추가하여 즉시 확인할 수 있습니다.
1. **데이터 소스 통합:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)를 사용하여 다양한 AWS 서비스의 지표를 집계 및 표시하고 [다른 데이터 소스의 지표를 쿼리](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)하여 시스템의 상태 및 비즈니스 지표에 대한 통합된 보기를 생성합니다.
+ [CloudWatch 로그 인사이트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)와 같은 기능을 사용하여 다양한 애플리케이션 및 서비스의 로그 데이터를 쿼리하고 시각화합니다.
+ [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 또는 [Amazon EventBridge의 AWS Health 이벤트](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)를 통해 AWS Health 이벤트를 사용하여 AWS 서비스의 운영 상태와 확인된 운영 문제에 대한 정보를 얻습니다.
1. **셀프 서비스 액세스 제공:**
+ 셀프 서비스 정보에 액세스하도록 [대시보드 공유 기능](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)을 사용하여 관련 이해관계자와 CloudWatch 대시보드를 공유합니다.
+ 대시보드에 쉽게 액세스할 수 있도록 하고 실시간 최신 정보를 제공합니다.
1. **정기적으로 업데이트 및 개선:**
+ 진화하는 비즈니스 요구 사항 및 이해관계자 피드백에 맞춰 대시보드를 지속적으로 업데이트하고 수정합니다.
+ 대시보드를 정기적으로 검토하여 필요한 정보를 전달하는 데 적합하고 효과적인지 확인합니다.
## 리소스
**관련 모범 사례:**
+ [OPS08-BP05 대시보드 만들기](ops_workload_observability_create_dashboards.md)
**관련 문서:**
+ [ 운영 가시성을 위한 대시보드 구축 ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Amazon CloudWatch 대시보드 사용 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ 대시보드 변수를 사용하여 유연한 대시보드 생성 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)
+ [ CloudWatch 대시보드 공유 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)
+ [ 다른 데이터 소스의 쿼리 지표 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)
+ [ CloudWatch 대시보드에 사용자 지정 위젯 추가 ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)
**관련 예제:**
+ [ One Observability 워크숍 - 대시보드 ](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/aws-native/dashboards)
# OPS10-BP07 이벤트 대응 자동화
이벤트 대응 자동화는 빠르고 일관되며 오류 없는 운영 처리를 위한 핵심 비결입니다. 간소화된 프로세스를 만들고 도구를 사용하여 이벤트를 자동으로 관리하고 대응하여 수동 개입을 최소화하고 운영 효율성을 개선하세요.
**원하는 성과:**
+ 자동화를 통한 인적 오류 감소 및 해결 시간 단축.
+ 일관되고 신뢰할 수 있는 운영 이벤트 처리.
+ 운영 효율성 및 시스템 신뢰성 향상.
**일반적인 안티 패턴**:
+ 수동으로 이벤트를 처리하면 지연과 오류가 발생합니다.
+ 반복적이고 중요한 작업에서 자동화가 간과됩니다.
+ 반복적인 수동 작업으로 인해 알림에 대한 피로감이 쌓이고 중요한 문제가 누락됩니다.
**이 모범 사례 확립의 이점:**
+ 이벤트 대응 가속화를 통한 시스템 가동 중지 감소.
+ 자동화되고 일관된 이벤트 처리를 통한 신뢰할 수 있는 운영.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
자동화를 통합하여 효율적인 운영 워크플로를 만들고 수동 개입을 최소화합니다.
### 구현 단계
1. **자동화 기회 파악:** 문제 해결, 티켓 강화, 용량 관리, 규모 조정, 배포 및 테스트와 같은 자동화를 위한 반복 작업을 결정합니다.
1. **자동화 프롬프트 확인:**
+ 이 단계에서는 [Amazon CloudWatch 작업](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)을 사용하여 자동 응답을 개시하는 특정 조건이나 지표를 평가 및 정의합니다.
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)를 사용하여 AWS 서비스, 사용자 지정 워크로드, SaaS 애플리케이션의 이벤트에 응답합니다.
+ AWS 리소스에서 [특정 로그 항목](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html), [성과 지표 임곗값](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 또는 [상태 변경](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 등의 시작 이벤트를 고려해 보세요.
1. **이벤트 기반 자동화 구현:**
+ AWS Systems Manager 자동화 런북을 사용하여 유지 관리, 배포 및 수정 작업을 간소화합니다.
+ [Incident Manager에서 인시던트를 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)하면 AWS 관련 리소스에 대한 세부 정보를 자동으로 수집하고 인시던트에 추가할 수 있습니다.
+ [Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)를 사용하여 할당량을 사전에 모니터링합니다.
+ 가용성과 성능을 유지하기 위해 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)을 사용하여 용량을 자동으로 조정합니다.
+ [Amazon CodeCatalyst](https://codecatalyst.aws/explore)를 사용하여 개발 파이프라인을 자동화합니다.
+ [가상 모니터링을 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)하여 엔드포인트 및 API를 스모크 테스트하거나 지속적으로 모니터링합니다.
1. **자동화를 통한 위험 완화 수행:**
+ 위험을 신속하게 해결하기 위해 [자동화된 보안 대응](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)을 구현합니다.
+ [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)를 사용하여 구성 편차를 줄입니다.
+ [AWS Config 규칙를 사용하여 규정 미준수 리소스를 수정합니다.](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**구현 계획의 작업 수준:** 높음
## 리소스
**관련 모범 사례:**
+ [OPS08-BP04 실행 가능한 알림 생성](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md)
**관련 문서**:
+ [Using Systems Manager Automation runbooks with Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/tutorials-runbooks.html)
+ [Creating incidents in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Monitor resource usage and send notifications when approaching quotas](https://docs.aws.amazon.com/solutions/latest/quota-monitor-for-aws/solution-overview.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [What is Amazon CodeCatalyst?](https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch 경보 작업 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)
+ [Remediating Noncompliant Resources with AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [Creating metrics from log events using filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
**관련 비디오:**
+ [ Create Automation Runbooks with AWS Systems Manager](https://www.youtube.com/watch?v=fQ_KahCPBeU)
+ [ How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Security Hub CSPM automation rules ](https://www.youtube.com/watch?v=XaMfO_MERH8)
+ [ Start your software project fast with Amazon CodeCatalyst blueprints ](https://www.youtube.com/watch?v=rp7roaoPzFE)
**관련 예제:**
+ [ Amazon CodeCatalyst Tutorial: Creating a project with the Modern three-tier web application blueprint ](https://docs.aws.amazon.com/codecatalyst/latest/userguide/getting-started-template-project.html)
+ [ One Observability 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US)
+ [ Respond to incidents using Incident Manager ](https://catalog.workshops.aws/getting-started-with-com/en-US/operations-management/incident-manager)