# OPS 9 운영 상태를 어떻게 파악하십니까?
운영 지표를 정의, 캡처 및 분석하면 운영 이벤트에 대한 가시성을 확보하여 적절한 조치를 취할 수 있습니다.
**Topics**
+ [OPS09-BP01 핵심 성과 지표 파악](ops_operations_health_define_ops_kpis.md)
+ [OPS09-BP02 운영 지표 정의](ops_operations_health_design_ops_metrics.md)
+ [OPS09-BP03 운영 지표 수집 및 분석](ops_operations_health_collect_analyze_ops_metrics.md)
+ [OPS09-BP04 운영 지표 기준 설정](ops_operations_health_ops_metric_baselines.md)
+ [OPS09-BP05 운영의 예상 활동 패턴 파악](ops_operations_health_learn_ops_usage_patterns.md)
+ [OPS09-BP06 운영 성과가 위험한 상태이면 알림 생성](ops_operations_health_ops_outcome_alerts.md)
+ [OPS09-BP07 운영 이상이 감지되면 알림 생성](ops_operations_health_ops_anomaly_alerts.md)
+ [OPS09-BP08 성과 달성 여부와 KPI 및 지표의 효율성 확인](ops_operations_health_biz_level_view_ops.md)
# OPS09-BP01 핵심 성과 지표 파악
원하는 비즈니스 성과(예: 새로운 기능 제공)와 고객 성과(예: 고객 지원 사례)를 기반으로 핵심 성과 지표(KPI)를 파악합니다. 그리고 KPI를 평가하여 운영의 성공 여부를 결정합니다.
**일반적인 안티 패턴:**
+ 경영진으로부터 운영이 얼마나 성공적으로 비즈니스 목표를 달성하고 있는지에 대한 질문을 받지만 성공 여부를 판단하기 위한 준거 기준이 없습니다.
+ 유지 관리 기간이 비즈니스 성과에 영향을 미치는지 판단할 수 없습니다.
**이 모범 사례 정립의 이점:** 핵심 성과 지표를 파악하면 운영 상태 및 성공 여부를 테스트하여 비즈니스 성과를 달성할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 핵심 성과 지표 파악: 원하는 비즈니스 성과와 고객 성과를 기준으로 핵심 성과 지표(KPI)를 확인합니다. 그리고 KPI를 평가하여 운영의 성공 여부를 결정합니다.
# OPS09-BP02 운영 지표 정의
KPI 성과(예: 성공한 배포와 실패한 배포)를 측정하는 데 사용할 운영 지표를 정의합니다. 운영 활동 상태(예: 인시던트의 MTTD(평균 탐지 시간) 및 인시던트의 MTTR(평균 복구 시간))를 측정하는 데 사용할 운영 지표를 정의합니다. 그런 다음, 해당 지표를 평가해 운영 과정에서 적절한 성과를 달성할 수 있는지를 확인하고 운영 활동 상태를 파악합니다.
**일반적인 안티 패턴:**
+ 운영 지표는 팀이 합리적이라고 생각하는 것을 기반으로 합니다.
+ 지표 계산에 잘못된 결과를 산출하는 오류가 있습니다.
+ 작업 활동에 대해 정의된 지표가 없습니다.
**이 모범 사례 정립의 이점:** 운영 지표를 정의하고 평가하여 운영 활동의 상태를 파악하고 비즈니스 성과 달성 여부를 측정할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 운영 지표 정의: 운영 지표를 정의하여 KPI의 성과를 측정합니다. 운영 및 해당 활동의 상태를 측정하는 데 사용할 운영 지표를 정의합니다. 그런 다음 해당 지표를 평가해 운영 과정에서 적절한 성과를 달성할 수 있는지를 확인하고 운영 상태를 파악합니다.
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## 리소스
**관련 문서:**
+ [AWS Answers: 중앙 집중식 로깅](https://aws.amazon.com/answers/logging/centralized-logging/)
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon CloudWatch Events를 사용하여 파이프라인 상태에서 변경 감지 및 대처](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**관련 동영상:**
+ 모니터링 플랜 세우기
# OPS09-BP03 운영 지표 수집 및 분석
지표를 정기적으로 사전 예방 차원에서 점검하여 추세를 확인하고 어느 부분에 적절한 대응이 필요한지 파악합니다.
운영 활동 및 운영 API 호출의 실행에서 CloudWatch Logs와 같은 서비스로 로그 데이터를 집계해야 합니다. 운영 활동의 성과에 대한 인사이트를 얻을 수 있도록 필요한 로그 콘텐츠를 관찰하여 지표를 생성합니다.
AWS에서는 [Amazon S3로 로그 데이터를 내보내거나](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 또는 [장기 보관을 위해](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html) 을 [Amazon S3](https://aws.amazon.com/s3/) 로 로그를 직접 전송할 수 있습니다. 여러분은 [AWS Glue](https://aws.amazon.com/glue/)를 사용하여 다음에 관련 메타데이터를 저장하면서 분석을 위해 Amazon S3의 로그 데이터를 검색 및 준비할 수 있습니다. [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html). [Amazon Athena](https://aws.amazon.com/athena/)에서 AWS Glue와의 기본 통합을 통해 로그 데이터를 분석하고 표준 SQL을 사용해 쿼리할 수 있습니다. 여러분은 [Quick](https://aws.amazon.com/quicksight/) 와 같은 비즈니스 인텔리전스 도구를 사용하여 데이터를 시각화하고 탐색하며 분석할 수 있습니다.
**일반적인 안티 패턴:**
+ 새로운 기능의 일관된 제공이 핵심 성능 지표로 간주됩니다. 배포가 발생하는 빈도를 측정할 방법이 없습니다.
+ 배포, 롤백된 배포, 패치 및 롤백된 패치를 로깅하여 작업 활동을 추적하지만 아무도 지표를 검토하지 않습니다.
+ 손실된 데이터베이스를 15분 내에 복원해야 하는 복구 시간 목표가 있습니다. 이 목표는 시스템이 배포되고 사용자가 없을 때 정의되었습니다. 현재 1만 명의 사용자를 보유하고 있으며, 운영한 지 2년이 지났습니다. 최근 복원에 2시간이 넘게 걸렸습니다. 이는 기록되지 않았으며 아무도 모릅니다.
**이 모범 사례 수립의 이점:** 운영 지표를 수집하고 분석하면 운영 상태를 파악하고 운영 또는 비즈니스 성과 달성에 영향을 미칠 수 있는 추세에 대한 인사이트를 얻을 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 운영 지표 수집 및 분석: 사전 예방 차원에서 지표를 정기적으로 점검하여 추세를 확인하고 어느 부분에 적절한 대응이 필요한지를 파악합니다.
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버에서 지표 및 로그 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## 리소스
**관련 문서:**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS 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)
# OPS09-BP04 운영 지표 기준 설정
지표의 기준을 설정해 성능이 기준보다 높은/낮은 운영 활동을 확인하고 각 프로세스의 성능을 비교할 수 있는 기준으로 필요한 값을 제공합니다.
**일반적인 안티 패턴:**
+ 예상되는 배포 시간을 묻는 메시지가 표시됩니다. 배포에 걸리는 시간을 측정하지 않았으며 예상 시간을 확인할 수 없습니다.
+ 애플리케이션 서버 문제에서 복구하는 데 얼마나 걸릴지 묻는 메시지가 표시됩니다. 첫 번째 고객 연락처에서 복구하는 데 걸리는 시간에 대한 정보가 없습니다. 모니터링을 통해 첫 번째 문제 식별에서 복구하는 데 걸리는 시간에 대한 정보가 없습니다.
+ 주말 동안 몇 명의 지원 인력이 필요한지에 대한 질문을 받았습니다. 주말 동안 몇 가지 지원 사례가 일반적인지 모르며 추정을 제공할 수 없습니다.
+ 손실된 데이터베이스를 15분 내에 복원해야 하는 복구 시간 목표가 있습니다. 이 목표는 시스템이 배포되고 사용자가 없을 때 정의되었습니다. 현재 1만 명의 사용자를 보유하고 있으며, 운영한 지 2년이 지났습니다. 데이터베이스에 대한 복원 시간이 어떻게 변경되었는지에 대한 정보가 없습니다.
**이 모범 사례 정립의 이점:** 기준 지표 값을 정의하면 현재 지표 값과 지표 추세를 평가하여 조치가 필요한지 여부를 결정할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 운영의 예상 활동 패턴 파악: 운영 활동 패턴을 설정하여 동작이 필요한 값의 범위를 벗어나는 경우를 확인합니다. 그러면 필요 시 적절하게 대응할 수 있습니다.
# OPS09-BP05 운영의 예상 활동 패턴 파악
필요한 경우 적절하게 대응할 수 있도록 비정상적인 활동을 식별할 운영 활동 패턴을 설정합니다.
**일반적인 안티 패턴:**
+ 최근에 배포 실패율이 크게 증가했습니다. 각 실패를 독립적으로 해결합니다. 실패 원인이 배포 관리 시스템에 익숙하지 않은 신입 직원의 배포임을 인식하지 못합니다.
**이 모범 사례 수립의 이점:** 동작 패턴을 파악하면 예기치 않은 동작을 확인하고 필요 시 조치를 취할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 운영의 예상 활동 패턴 파악: 운영 활동 패턴을 설정하여 동작이 필요한 값의 범위를 벗어나는 경우를 확인합니다. 그러면 필요 시 적절하게 대응할 수 있습니다.
# OPS09-BP06 운영 성과가 위험한 상태이면 알림 생성
운영 성과에 위험이 있을 때마다 알림이 발생하고 적절한 조치가 이루어져야 합니다. 운영 성과는 프로덕션의 워크로드를 지원하는 모든 활동입니다. 여기에는 새로운 버전의 애플리케이션 배포부터 중단 복구까지의 모든 것이 포함됩니다. 운영 성과는 비즈니스 성과와 동일한 중요성이 있는 것으로 다루어야 합니다.
소프트웨어 팀은 주요 운영 지표 및 활동을 파악하고 이를 위한 알림을 구축해야 합니다. 알림은 적시에 이루어지고 실행 가능해야 합니다. 알림이 발생하면 해당 런북 또는 플레이북에 대한 참조가 포함되어 있어야 합니다. 해당 조치가 없는 알림은 알림 피로감으로 이어집니다.
**원하는 결과:** 운영 활동에 위험이 있는 경우 조치를 취할 수 있도록 알림이 전송됩니다. 알림에는 알림이 발생한 이유에 대한 컨텍스트와 조사를 위한 플레이북 또는 완화를 위한 런북이 명시됩니다. 가능한 경우, 런북이 자동화되고 알림이 전송됩니다.
**일반적인 안티 패턴:**
+ 인시던트를 조사 중이며 지원 사례가 접수되고 있습니다. 지원 사례가 서비스 수준 계약(SLA)을 침해하지만 어떤 알림도 발생하지 않습니다.
+ 자정으로 예약된 프로덕션 배포가 막바지 코드 변경으로 인해 지연됩니다. 알림이 발생하지 않고 배포가 중단됩니다.
+ 프로덕션 중단이 발생하지만 알림이 전송되지 않습니다.
+ 배포 시간이 지속적으로 예상보다 늦어지고 있습니다. 조사를 위한 조치가 이루어지지 않습니다.
**이 모범 사례 확립의 이점:**
+ 운영 성과에 위험이 있을 때 알림을 생성함으로써, 문제 발생 전에 워크로드를 지원할 수 있는 기능이 확대됩니다.
+ 우수한 운영 성과를 통해 비즈니스 성과가 개선됩니다.
+ 운영 문제의 탐지 및 개선 조치가 향상됩니다.
+ 전반적인 운영 상태가 향상됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
운영 성과에 대한 알림을 생성하기 전에 운영 성과를 정의해야 합니다. 조직에 가장 중요한 운영 활동이 어떤 것인지 정의하는 것으로 시작합니다. 2시간 이내에 프로덕션에 배포하거나 정해진 시간 내에 지원 사례에 응답합니까? 조직은 핵심 운영 활동 및 그 측정 방법을 정의하여 모니터링, 개선 및 알림이 이루어지도록 해야 합니다. 워크로드 및 운영 텔레메트리를 저장 및 분석할 중앙 위치가 필요합니다. 운영 성과가 위험할 경우 동일한 메커니즘에서 알림을 생성할 수 있어야 합니다.
**고객 사례**
AnyCompany Retail에서 일상적인 배포 작업 중 CloudWatch 알람이 트리거되었습니다. 배포 리드 타임에 위반이 발생했습니다. Amazon EventBridge가 AWS Systems Manager OpsCenter에서 OpsItem을 생성했습니다. 클라우드 운영 팀이 플레이북을 사용하여 문제를 조사했고, 스키마 변경이 예상보다 오래 걸렸음을 파악했습니다. 당직 근무 중인 개발자에게 알림이 생성되고 배포를 계속 모니터링했습니다. 배포가 완료된 후 클라우드 운영 팀이 OpsItem을 해결했습니다. 사후 기간 동안 팀에서 인시던트를 분석합니다.
## 구현 단계
1. 운영 KPI, 지표 및 활동을 파악하지 않았다면 이 질문에 대한 앞선 모범 사례를 구현하는 것이 좋습니다(OPS09-BP01 - OPS09-BP05).
+ 지원 고객( [Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/) 고객)은 기술 지원 관리자에게 [운영 KPI 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 을 요청할 수 있습니다. 추가 비용 없이 제공되는 이러한 협업 워크숍을 통해 비즈니스 목표에 따른 운영 KPI 및 지표를 정의할 수 있습니다. 자세한 내용은 기술 지원 관리자에게 문의하시기 바랍니다.
1. 운영 활동, KPI 및 지표를 설정했다면 관찰성 플랫폼에서 알림을 구성해야 합니다. 알림은 플레이북 또는 런북과 같이 이와 연관된 활동이 있어야 합니다. 활동이 없는 알림은 피하는 것이 좋습니다.
1. 시간이 지나면서 운영 지표, KPI 및 활동을 평가하여 개선 영역을 파악합니다. 운영자의 런북 및 플레이북에서 피드백을 수집하여 알림 대응 개선 영역을 파악합니다.
1. 알림은 오탐으로 플래그를 지정하는 메커니즘을 포함해야 하며 이것은 지표 임계값의 검토로 이어져야 합니다.
**구현 계획의 작업 수준:** 보통. 이 모범 사례를 구현하기 전에 갖춰야 하는 몇 가지 모범 사례가 있습니다. 운영 활동이 파악되고 운영 KPI가 설정되었다면 알림을 설정해야 합니다.
## 리소스
**관련 모범 사례:**
+ [OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별](ops_ops_model_def_activity_owners.md): 모든 운영 활동 및 성과는 책임이 있는 식별된 소유자가 있어야 합니다. 이 소유자는 성과가 위험할 때 알림을 받는 대상입니다.
+ [OPS03-BP02 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여](ops_org_culture_team_emp_take_action.md): 알림이 발생하면 팀은 문제를 해결하기 위한 조치를 취하는 에이전시가 있어야 합니다.
+ [OPS09-BP01 핵심 성과 지표 파악](ops_operations_health_define_ops_kpis.md): 운영 성과에 대한 알림은 운영 KPI를 파악하는 것에서 시작합니다.
+ [OPS09-BP02 운영 지표 정의](ops_operations_health_design_ops_metrics.md): 알림 생성을 시작하기 전에 이 모범 사례를 확립합니다.
+ [OPS09-BP03 운영 지표 수집 및 분석](ops_operations_health_collect_analyze_ops_metrics.md): 알림을 구축하려면 중앙에서 수집하는 운영 지표가 필요합니다.
+ [OPS09-BP04 운영 지표 기준 설정](ops_operations_health_ops_metric_baselines.md): 운영 지표 기준은 알림을 조정하고 알림 피로감을 예방하기 위한 기능을 제공합니다.
+ [OPS09-BP05 운영의 예상 활동 패턴 파악](ops_operations_health_learn_ops_usage_patterns.md): 운영 이벤트의 활동 패턴을 이해함으로써 알림의 정확도를 개선할 수 있습니다.
+ [OPS09-BP08 성과 달성 여부와 KPI 및 지표의 효율성 확인](ops_operations_health_biz_level_view_ops.md): 운영 성과 달성을 평가하여 KPI 및 지표가 유효한지 확인합니다.
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md): 모든 알림에는 연관된 런북이나 플레이북이 있어야 하며 알림을 받는 사람에게 컨텍스트를 제공해야 합니다.
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md): 알림 후에는 인시던트 사후 분석을 수행하여 개선이 필요한 영역을 파악합니다.
**관련 문서:**
+ [AWS 배포 파이프라인 참조 아키텍처: 애플리케이션 파이프라인 아키텍처](https://pipelines.devops.aws.dev/application-pipeline/)
+ [GitLab: Agile/DevOps Metrics 시작하기](https://about.gitlab.com/handbook/marketing/strategic-marketing/devops-metrics/)
**관련 동영상:**
+ [AWS Systems Manager OpsCenter를 사용하여 운영 문제 집계 및 해결](https://www.youtube.com/watch?v=r6ilQdxLcqY)
+ [AWS Systems Manager OpsCenter와 Amazon CloudWatch 알람의 통합](https://www.youtube.com/watch?v=Gpc7a5kVakI)
+ [Amazon EventBridge를 사용하여 AWS Systems Manager OpsCenter에 데이터 소스 통합](https://www.youtube.com/watch?v=Xmmu5mMsq3c)
**관련 예시:**
+ [Amazon EC2 Systems Manager Automation 및 AWS Health를 사용하여 Amazon EC2 알림 등에 대한 개선 조치 자동화](https://aws.amazon.com/blogs/mt/automate-remediation-actions-for-amazon-ec2-notifications-and-beyond-using-ec2-systems-manager-automation-and-aws-health/)
+ [2022년 AWS 관리 및 거버넌스 도구 워크숍 - 운영](https://mng.workshop.aws/operations-2022.html)
+ [AWS의 DevOps 모니터링 대시보드를 사용한 지표 수집, 분석 및 시각화](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/welcome.html)
**관련 서비스:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [지원 사전 예방 서비스 - 운영 KPI 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [CloudWatch 이벤트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP07 운영 이상이 감지되면 알림 생성
운영에서 이상이 감지되면 필요 시 적절히 대응할 수 있도록 알림을 생성합니다.
시간에 따른 운영 지표를 분석하면 이벤트를 정의하거나 이벤트 응답으로 경보를 울리기 위해 정량화할 수 있는 동작의 패턴을 설정할 수 있습니다.
훈련된 후에는 [CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 기능을 사용하여 탐지된 이상 현상에 대한 [경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) 를 생성하거나 비교를 위해 지표 데이터의 [그래프](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 에서 중첩된 예상되는 값을 제공할 수 있습니다.
[Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) 를 사용하여 이벤트 상관 관계, 로그 분석, 기계 학습 적용을 통해 워크로드 원격 측정을 분석하여 비정상적인 동작을 식별할 수 있습니다. 유효한 [인사이트가](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 관련 데이터, 권장 사항과 함께 표시됩니다.
**일반적인 안티 패턴:**
+ 인스턴스 플릿에 패치를 적용하고 있습니다. 테스트 환경에서 패치를 성공적으로 테스트했습니다. 플릿에서 많은 비율의 인스턴스에 대해 패치가 실패하고 있습니다. 아무 작업도 하지 않습니다.
+ 금요일이 끝나면 배포가 시작된다는 점에 유의하십시오. 조직에 화요일과 목요일에 사전 정의된 유지 관리 기간이 있습니다. 아무 작업도 하지 않습니다.
**이 모범 사례 정립의 이점:** 운영 동작의 패턴을 파악하면 예기치 않은 동작을 식별하고 필요 시 조치를 취할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 운영에 이상이 감지되면 알림 생성: 운영에서 이상 상태가 감지되면 알림을 생성합니다. 그러면 필요할 때 적절하게 대응할 수 있습니다.
+ [Amazon CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 알림을 사용하여 Lambda 함수 호출](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## 리소스
**관련 문서:**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch Events를 사용하여 파이프라인 상태에서 변경 감지 및 대처](https://docs.aws.amazon.com/codepipeline/latest/userguide/detect-state-changes-cloudwatch-events.html)
+ [Amazon SNS 알림을 사용하여 Lambda 함수 호출](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS09-BP08 성과 달성 여부와 KPI 및 지표의 효율성 확인
운영 활동을 실무 수준에서 확인할 수 있는 보기를 생성합니다. 그러면 요구를 충족하고 있는지를 확인할 수 있으며 업무 목표 달성을 위해 개선해야 하는 영역을 파악할 수 있습니다. 또한 KPI와 지표의 효율성을 확인하고 필요한 경우 KPI/지표를 수정합니다.
AWS는 AWS 서비스 API 및 SDK(예: Grafana, Kibana, Logstash)를 통해 타사 로그 분석 시스템 및 비즈니스 인텔리전스 도구도 지원합니다.
**일반적인 안티 패턴:**
+ 개발 팀 수가 증가함에 따라 배포 빈도가 증가했습니다. 정의된 예상 배포 수는 매주 한 번입니다. 매일 정기적으로 배포하고 있습니다. 배포 시스템의 문제이고 배포가 불가능한 경우 며칠 동안 감지되지 않습니다.
+ 이전에 비즈니스에서 월요일부터 금요일까지 핵심 업무 시간 동안에만 지원을 제공했습니다. 인시던트에 대해 ‘익일(영업일 기준)’ 응답 시간 목표를 설정했습니다. 최근에 2시간의 응답 시간을 목표로 연중무휴 24시간 지원 서비스를 제공하기 시작했습니다. 야간에 근무하는 직원은 과중한 업무에 압도되고 고객은 만족하지 않습니다. ‘익일(영업일 기준)’ 목표에 대해 보고하기 때문에 인시던트 대응 시간에 문제가 있다는 징후는 없습니다.
**이 모범 사례 정립의 이점:** KPI와 지표를 검토하고 수정하면 워크로드가 어떻게 비즈니스 성과 달성을 지원하는지 이해하고 비즈니스 목표 달성을 위해 개선이 필요한 영역을 식별할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 성과 달성 여부와 KPI 및 지표의 효율성 확인: 운영 활동을 실무 수준에서 확인할 수 있는 보기를 생성합니다. 그러면 요구를 충족하고 있는지 확인할 수 있으며 비즈니스 목표 달성을 위해 개선해야 하는 영역을 파악할 수 있습니다. 또한 KPI와 지표의 효율성을 확인하고 필요한 경우 KPI/지표를 수정합니다.
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)