# 운영
**Topics**
+ [OPS 8 워크로드의 상태를 어떻게 파악하십니까?](w2aac19b5b9b5.md)
+ [OPS 9 운영 상태를 어떻게 파악하십니까?](w2aac19b5b9b7.md)
+ [OPS 10 워크로드 및 운영 이벤트를 어떻게 관리하십니까?](w2aac19b5b9b9.md)
# OPS 8 워크로드의 상태를 어떻게 파악하십니까?
워크로드 지표를 정의, 캡처 및 분석하면 워크로드 이벤트에 대한 가시성을 확보하여 적절한 조치를 취할 수 있습니다.
**Topics**
+ [OPS08-BP01 핵심 성과 지표 파악](ops_workload_health_define_workload_kpis.md)
+ [OPS08-BP02 워크로드 지표 정의](ops_workload_health_design_workload_metrics.md)
+ [OPS08-BP03 워크로드 지표 수집 및 분석](ops_workload_health_collect_analyze_workload_metrics.md)
+ [OPS08-BP04 워크로드 지표 기준 설정](ops_workload_health_workload_metric_baselines.md)
+ [OPS08-BP05 워크로드의 예상 활동 패턴 파악](ops_workload_health_learn_workload_usage_patterns.md)
+ [OPS08-BP06 워크로드 성과가 위험한 상태이면 알림 생성](ops_workload_health_workload_outcome_alerts.md)
+ [OPS08-BP07 워크로드 이상이 감지되면 알림 생성](ops_workload_health_workload_anomaly_alerts.md)
+ [OPS08-BP08 성과 달성 여부와 KPI 및 지표의 효율성 확인](ops_workload_health_biz_level_view_workload.md)
# OPS08-BP01 핵심 성과 지표 파악
원하는 비즈니스 성과(예: 주문율, 고객 유지율, 이익 및 운영 지출 비교)과 고객 성과(예: 고객 만족도)를 기반으로 KPI(핵심 성과 지표)를 파악합니다. 그리고 KPI를 평가하여 워크로드의 성공 여부를 결정합니다.
**일반적인 안티 패턴:**
+ 경영진으로부터 워크로드가 얼마나 성공적으로 비즈니스 요구를 충족하고 있는지에 대한 질문을 받지만 성공 여부를 판단하기 위한 준거 기준이 없습니다.
+ 조직에서 운영하는 자체 상용 애플리케이션이 비용 효율적인지 판단할 수 없습니다.
**이 모범 사례 정립의 이점:** 핵심 성과 지표를 파악하면 워크로드 상태 및 성공 여부를 테스트하여 비즈니스 성과를 달성할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 핵심 성과 지표 파악: 원하는 비즈니스 성과와 고객 성과를 기준으로 핵심 성과 지표(KPI)를 확인합니다. 그리고 KPI를 평가하여 워크로드의 성공 여부를 결정합니다.
# OPS08-BP02 워크로드 지표 정의
KPI 달성(예: 주문하지 않은 장바구니, 제출된 주문, 비용, 가격 및 할당된 워크로드 지출)을 측정하도록 워크로드 지표를 정의합니다. 워크로드 상태(예: 인터페이스 응답 시간, 오류 발생률, 제출된 요청, 완료된 요청 및 사용률)를 측정하도록 워크로드 지표를 정의합니다. 그런 다음 해당 지표를 평가해 워크로드에서 적절한 성과를 달성할 수 있는지를 확인하고 워크로드의 상태를 파악합니다.
CloudWatch Logs와 같은 서비스로 로그 데이터를 전송하고 필요한 로그 콘텐츠를 관찰하여 지표를 생성해야 합니다.
CloudWatch에는 [Amazon CloudWatch Insights for .NET and SQL Server](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/appinsights-what-is.html) 및 [Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) 와 같은 특별한 기능이 있습니다. 이 기능을 사용하면 특별히 지원되는 애플리케이션 리소스 및 기술 스택에서 핵심 지표, 로그 및 경보를 파악하고 설정할 수 있습니다.
**일반적인 안티 패턴:**
+ KPI와 관련이 없거나 워크로드에 맞게 조정된 표준 지표를 정의했습니다.
+ 지표 계산에 잘못된 결과를 산출하는 오류가 있습니다.
+ 워크로드에 대해 정의된 지표가 없습니다.
+ 가용성에 대해서만 측정합니다.
**이 모범 사례 정립의 이점:** 워크로드 지표를 정의하고 평가하여 워크로드의 상태를 파악하고 비즈니스 성과 달성 여부를 측정할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 워크로드 지표 정의: 워크로드 지표를 정의하여 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)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [로그 데이터 검색 및 필터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
# OPS08-BP03 워크로드 지표 수집 및 분석
지표를 정기적으로 사전 예방 차원에서 점검하여 추세를 확인하고 어느 부분에 적절한 대응이 필요한지를 파악합니다.
애플리케이션, 워크로드 구성 요소, 서비스 및 API 호출의 로그 데이터를 CloudWatch Logs와 같은 서비스로 집계해야 합니다. 운영 활동의 성과에 대한 인사이트를 얻을 수 있도록 필요한 로그 콘텐츠를 관찰하여 지표를 생성합니다.
AWS에서는 [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)의 기계 학습 기능을 사용하여 워크로드 지표를 분석하고 운영 문제를 식별할 수 있습니다. AWS DevOps Guru는 [운영 문제에 대한 알림과 함께](https://docs.aws.amazon.com/devops-guru/latest/userguide/view-insights.html) 문제를 해결하고 애플리케이션 상태를 유지하는 데 도움이 되는 대상별 사전 예방적 권장 사항을 제공합니다.
AWS 공동 책임 모델에서는 다음을 통해 모니터링 정보의 일부가 사용자에게 전달됩니다. [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/). 이 대시보드는 AWS에서 사용자에게 영향을 줄 수 있는 이벤트가 발생할 때 경고를 보내고 해결 지침을 제공합니다. Business 및 Enterprise Support 구독 고객은 API에도 액세스하여 [이벤트 관리 시스템에](https://docs.aws.amazon.com/health/latest/ug/getting-started-api.html)통합할 수 있습니다.
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/) 와 같은 비즈니스 인텔리전스 도구를 사용하여 데이터를 시각화하고 탐색하며 분석할 수 있습니다.
대안 [솔루션](https://aws.amazon.com/solutions/centralized-logging/?did=sl_card&trk=sl_card) 으로서 [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) 및 [OpenSearch 대시보드](https://aws.amazon.com/elasticsearch-service/the-elk-stack/kibana/) 를 사용하여 여러 계정 및 AWS 리전에 걸쳐 AWS의 로그를 수집, 분석 및 표시하는 방법도 있습니다.
**일반적인 안티 패턴:**
+ 네트워크 설계 팀으로부터 현재 네트워크 대역폭 사용률에 대한 질문을 받습니다. 현재 지표를 제공합니다. 네트워크 사용률은 35%입니다. 특정 시점 측정에 사용률 추세가 반영되지 않았기 때문에 비용 절감 수단으로 회로 용량을 줄여 광범위한 연결 문제가 발생합니다.
+ 라우터가 실패했습니다. 심각하지 않은 메모리 오류가 완전히 실패할 때까지 더 잦은 빈도로 로깅되었습니다. 이러한 추세를 감지하지 못했고 결과적으로 라우터가 서비스 중단을 야기하기 전에 결함이 있는 메모리를 교체하지 못했습니다.
**이 모범 사례 정립의 이점:** 워크로드 지표를 수집하고 분석하면 워크로드 상태를 파악하고 워크로드 또는 비즈니스 성과 달성에 영향을 미칠 수 있는 추세에 대한 인사이트를 얻을 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 워크로드 지표 수집 및 분석: 사전 예방 차원에서 지표를 정기적으로 점검하여 추세를 확인하고 어느 부분에 적절한 대응이 필요한지를 파악합니다.
+ [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)
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWSAWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/)
+ [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [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)
# OPS08-BP04 워크로드 지표 기준 설정
지표의 기준을 설정하여 성과가 기준보다 높은/낮은 구성 요소를 확인하고 각 구성 요소의 성과를 비교할 수 있는 기준으로 필요한 값을 제공합니다. 개선, 조사 및 개입을 위한 임계값을 파악합니다.
**일반적인 안티 패턴:**
+ 서버가 95%의 CPU 사용률로 실행되고 있습니다. 이것이 좋은 것인지 아니면 나쁜 것인지에 대한 질문을 받습니다. 해당 서버의 CPU 사용률에 대한 기준이 설정되지 않았으므로 좋은지 아니면 나쁜지 알 수 없습니다.
**이 모범 사례 정립의 이점:** 기준 지표 값을 정의하면 현재 지표 값과 지표 추세를 평가하여 조치가 필요한지 여부를 결정할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드 지표 기준 설정: 워크로드 지표의 기준을 설정하여 비교의 기준으로 필요한 값을 제공합니다.
+ [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
# OPS08-BP05 워크로드의 예상 활동 패턴 파악
필요한 경우 적절히 대응할 수 있도록 비정상적인 동작을 식별할 워크로드 활동 패턴을 설정합니다.
CloudWatch에서는 [CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 기능을 통해 통계 및 기계 학습 알고리즘을 적용해 정상 지표 동작을 나타내는 예상되는 값의 범위를 생성합니다.
[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) 동작을 해결하기 위한 권장 사항이 제공됩니다.
**일반적인 안티 패턴:**
+ 네트워크 사용률 로그를 검토하여 네트워크 사용률이 오전 11시 30분에서 오후 1시 30분 사이에 증가한 다음 오후 4시 30분부터 오후 6시까지 다시 증가했음을 확인합니다. 정상으로 간주되어야 하는지 여부를 알 수 없습니다.
+ 웹 서버는 매일 밤 3시에 재부팅됩니다. 예상된 동작인지 알 수 없습니다.
**이 모범 사례 수립의 이점:** 행동 패턴을 파악하면 예기치 않은 행동을 인식하고 필요한 경우 조치를 취할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드의 예상 활동 패턴 파악: 워크로드 활동 패턴을 설정하여 워크로드의 동작이 필요한 값의 범위를 벗어나는 경우를 확인합니다. 그러면 필요 시 적절하게 대응할 수 있습니다.
## 리소스
**관련 문서:**
+ [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)
# OPS08-BP06 워크로드 성과가 위험한 상태이면 알림 생성
워크로드 성과가 위험한 상태이면 필요 시 적절히 대응할 수 있도록 알림을 생성합니다.
이전에는 자동화된 응답을 트리거하는 데 사용할 수 있는 이벤트 또는 경보를 알릴 수 있는 지표 임계값을 식별했습니다.
AWS에서는 [Amazon CloudWatch Synthetics를 통해](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 고객과 동일한 작업을 수행하여 엔드포인트 및 API를 모니터링하는 canary 스크립트를 작성할 수 있습니다. 생성된 원격 측정과 [획득한 인사이트를 바탕으로](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) 고객이 영향을 받기 전에 문제를 식별할 수 있습니다.
또한 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 에서 특별히 구축된 쿼리 언어를 사용해 로그 데이터를 대화식으로 검색하고 분석할 수 있습니다. CloudWatch Logs Insights는 자동으로 AWS 서비스에서 [로그의 필드와](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) JSON 형식의 사용자 지정 로그 이벤트를 검색합니다. 그러면 로그 볼륨 및 쿼리 복잡성에 대한 지원을 확장하고 몇 초 안에 답변을 제공하므로 인시던트의 원인을 파악하는 데 도움이 됩니다.
**일반적인 안티 패턴:**
+ 네트워크에 연결되어 있지 않습니다. 아무도 이 상황을 모릅니다. 아무도 이유를 파악하려고 하거나 연결 복원 조치를 취하고 있지 않습니다.
+ 패치 후 영구 인스턴스를 사용할 수 없게 되어 사용자 작업이 중단됩니다. 사용자가 지원 사례를 개설했습니다. 아무도 알림을 받지 않았습니다. 아무도 조치를 취하지 않습니다.
**이 모범 사례 정립의 이점:** 비즈니스 성과가 위험에 처하고 조치를 취해야 한다는 사실을 파악함으로써 인시던트의 영향을 예방하거나 완화할 수 있는 기회를 얻게 됩니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 워크로드 성과가 위험한 상태이면 알림 생성: 워크로드 성과가 위험한 상태이면 알림을 생성합니다. 그러면 필요할 때 적절하게 대응할 수 있습니다.
+ [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 CloudWatch Synthetics를 통해](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.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 CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-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) 에서 중첩된 예상되는 값을 제공할 수 있습니다.
**일반적인 안티 패턴:**
+ 소매 웹 사이트 매출이 갑자기 급증했습니다. 아무도 이 상황을 모릅니다. 아무도 이러한 급증을 초래하는 원인을 파악하려고 하지 않습니다. 아무도 추가 로드 발생 시에 훌륭한 고객 경험을 보장하기 위한 조치를 취하고 있지 않습니다.
+ 패치를 적용한 후 영구 서버가 재부팅되어 사용자 작업이 중단되는 경우가 많습니다. 서버는 일반적으로 최대 3회까지 재부팅되지만 그 이상 부팅되지는 않습니다. 아무도 이 상황을 모릅니다. 아무도 이런 일이 발생하는 이유를 파악하려고 하지 않습니다.
**이 모범 사례 정립의 이점:** 워크로드 동작의 패턴을 파악하면 예기치 않은 동작을 식별하고 필요 시 조치를 취할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 워크로드에 이상이 감지되면 알림 생성: 워크로드에서 이상 상태가 감지되면 알림을 생성합니다. 그러면 필요할 때 적절하게 대응할 수 있습니다.
+ [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 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch 이상 탐지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.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)
# OPS08-BP08 성과 달성 여부와 KPI 및 지표의 효율성 확인
워크로드 운영을 실무 수준에서 확인할 수 있는 보기를 생성합니다. 그러면 요구를 충족하고 있는지를 확인할 수 있으며 업무 목표 달성을 위해 개선해야 하는 영역을 파악할 수 있습니다. 또한 KPI와 지표의 효율성을 확인하고 필요한 경우 KPI/지표를 수정합니다.
AWS는 AWS 서비스 API 및 SDK(예: Grafana, Kibana, Logstash)를 통해 타사 로그 분석 시스템 및 비즈니스 인텔리전스 도구도 지원합니다.
**일반적인 안티 패턴:**
+ 페이지 응답 시간은 고객 만족도에 기여하는 것으로 간주된 적은 없습니다. 페이지 응답 시간에 대한 지표 또는 임계값을 설정한 적이 없습니다. 고객이 느린 속도에 대해 불만을 제기하고 있습니다.
+ 최소 응답 시간 목표를 달성하지 않았습니다. 응답 시간 개선을 위해 애플리케이션 서버를 스케일 업했습니다. 이제 상당한 마진으로 응답 시간 목표를 초과 달성하고 비용을 지불하고 있는 미사용 용량도 상당히 확보하게 됩니다.
**이 모범 사례 수립의 이점:** 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/)
# 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/)
# 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 이벤트, 인시던트 및 문제 관리 프로세스 사용
조직에는 이벤트, 인시던트 및 문제를 처리하기 위한 프로세스가 있습니다. *이벤트* 는 워크로드에서 발생하는 일이지만 개입이 필요하지 않을 수 있습니다. *인시던트* 는 개입이 필요한 이벤트입니다. *문제* 는 개입이 필요하거나 해결할 수 없는 반복 이벤트입니다. 이러한 이벤트가 비즈니스에 미치는 영향을 줄일 수 있는 프로세스가 필요하며 적절하게 대응하는지 확인해야 합니다.
인시던트 및 문제가 워크로드에 발생하면 처리하기 위한 프로세스가 필요합니다. 이해관계자에게 이벤트 상태를 어떻게 전달할 수 있을까요? 대응 주도를 감독하는 사람은 누구인가요? 이벤트로 인한 피해를 줄이기 위해 사용하는 도구는 무엇인가요? 이는 확실한 대응 프로세스를 갖추기 위해 답변해야 하는 질문의 몇 가지 예입니다.
프로세스는 중앙 위치에 문서화해 두어야 하며 워크로드와 관련된 사람은 누구나 사용할 수 있어야 합니다. 중앙 Wiki 또는 문서 저장소가 없다면 버전 관리 리포지토리를 사용할 수 있습니다. 프로세스 발전에 맞춰 이러한 계획을 최신 상태로 유지하게 됩니다.
문제는 자동화 후보입니다. 이러한 이벤트는 혁신 역량에서 시간을 빼앗아 갑니다. 문제를 완화하기 위한 반복 프로세스를 구축하는 것부터 시작하세요. 시간이 흐른 후에는 완화 프로세스 자동화 또는 기본 문제 수정에 집중하세요. 그러면 워크로드 개선에 투자할 시간을 확보할 수 있습니다.
**원하는 결과:** 조직에는 이벤트, 인시던트 및 문제를 처리하기 위한 프로세스가 있습니다. 이러한 프로세스는 문서화되어 중앙 위치에 저장되고 프로세스가 변함에 따라 업데이트됩니다.
**일반적인 안티 패턴:**
+ 인시던트가 주말에 발생했는데 당직 근무 중인 엔지니어가 무엇을 해야 할지 모릅니다.
+ 고객은 여러분에게 애플리케이션이 다운되었다는 이메일을 보내고 여러분은 서버를 재부팅하여 문제를 해결합니다. 이러한 상황이 빈번하게 발생합니다.
+ 한 가지 인시던트를 여러 팀에서 해결하기 위해 따로 노력합니다.
+ 워크로드에서 배포가 있었는데, 기록되지 않습니다.
**이 모범 사례 확립의 이점:**
+ 워크로드에서 이벤트를 감사 추적합니다.
+ 인시던트에서 복구 시간이 단축됩니다.
+ 팀원이 일관된 방식으로 인시던트와 문제를 해결할 수 있습니다.
+ 인시던트를 조사할 때 더욱 통합된 노력을 기울일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
이 모범 사례를 구현하면 워크로드 이벤트를 추적하게 됩니다. 인시던트 및 문제를 처리하기 위한 프로세스를 보유하게 되며, 프로세스는 문서화되고 공유되며 자주 업데이트됩니다. 문제가 파악되면 우선순위가 지정되고 해결됩니다.
**고객 사례**
AnyCompany Retail은 이벤트, 인시던트, 문제 관리를 위한 프로세스 전용 내부 Wiki를 갖추고 있습니다. 모든 이벤트는 다음 프로그램으로 전송됩니다. [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html). 문제는 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 에서 OpsItems로 식별되고 문제를 해결하도록 우선순위가 지정되어 획일적인 작업이 줄어듭니다. 프로세스가 변경되면 내부 Wiki에서 업데이트됩니다. 프로세스는 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 을(를) 사용하여 인시던트를 관리하고 피해를 줄이기 위한 작업을 조정합니다.
## 구현 단계
1. 이벤트
+ 인간의 개입이 필요 없는 경우에도 워크로드에서 발생한 이벤트를 추적합니다.
+ 워크로드 이해관계자와 협력하여 추적해야 할 이벤트 목록을 작성합니다. 이러한 이벤트의 몇 가지 예시로는 완료된 배포 또는 성공적인 패치 등이 있습니다.
+ 또한 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) 또는 [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) 등과 같은 서비스를 사용하여 추적할 사용자 지정 이벤트를 생성할 수 있습니다.
1. 인시던트
+ 인시던트에 대한 의사소통 계획을 정의하는 것으로 시작합니다. 인시던트에 대해 반드시 알아야 하는 이해 관계자는 누구인가요? 이해관계자를 루프 내에서 어떻게 유지하나요? 작업 조정은 누가 감독하나요? 의사소통 및 조정을 위한 내부 채팅 채널을 마련하는 것이 좋습니다.
+ 특히, 팀에 당직 순환 근무자가 없는 경우 워크로드를 지원하는 팀에 대한 에스컬레이션 경로를 정의하세요. 지원 수준에 따라 지원를 사용하여 사례를 제출할 수도 있습니다.
+ 인시던트를 조사하기 위한 플레이북을 생성합니다. 플레이북에는 의사소통 계획 및 자세한 조사 단계를 포함해야 합니다. 조사에 [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 확인을 포함하세요.
+ 인시던트 대응 계획을 문서화합니다. 내부 및 외부 고객이 참여 규칙과 자신에게 기대되는 행동을 이해할 수 있도록 인시던트 관리 규칙을 전달합니다. 이러한 규칙을 사용하는 방법을 팀원에게 교육합니다.
+ 고객은 [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 를 사용하여 인시던트 대응 규칙을 설정 및 관리할 수 있습니다.
+ Enterprise Support 고객은 기술 지원 관리자의 [인시던트 관리 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) 을 요청할 수 있습니다. 이 안내 워크숍에서는 기존 인시던트 대응 계획을 테스트하고 개선할 수 있는 영역을 식별하도록 돕습니다.
1. 문제
+ 문제는 ITSM 시스템에서 식별하고 추적해야 합니다.
+ 알려진 문제를 모두 식별하고 해결에 필요한 작업 수준 및 워크로드에 미치는 영향별로 우선순위를 지정합니다.
![\[문제 우선순위 지정을 위한 조치 우선순위 매트릭스.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/impact-effort-chart.png)
+ 미치는 영향이 크지만 노력이 적게 드는 문제부터 먼저 해결합니다. 해결되면 영향력이 낮고 노력이 적게 드는 문제로 진행합니다.
+ [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) 를 사용하여 문제를 식별하고 해당 문제에 런북을 첨부한 다음 문제를 추적할 수 있습니다.
**구현 계획의 작업 수준:** 보통. 모범 사례를 구현하기 위한 프로세스 및 도구가 둘 다 필요합니다. 프로세스를 문서화하고 워크로드와 관련된 모든 사람들이 사용할 수 있도록 설정합니다. 프로세스를 자주 업데이트합니다. 문제를 관리하고 문제를 완화 또는 해결하기 위한 프로세스가 있습니다.
## 리소스
**관련 모범 사례:**
+ [OPS07-BP03 런북을 사용한 절차 수행](ops_ready_to_support_use_runbooks.md): 일관된 완화 작업을 위해 알려진 문제에 연결된 런북이 필요합니다.
+ [OPS07-BP04 플레이북을 사용하여 문제 조사](ops_ready_to_support_use_playbooks.md): 런북을 사용하여 인시던트를 조사해야 합니다.
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md): 인시던트에서 복구한 후에는 항상 사후 분석을 수행합니다.
**관련 문서:**
+ [Atlassian - Incident management in the age of DevOps(Atlassian - DevOps 시대에 인시던트 관리)](https://www.atlassian.com/incident-management/devops)
+ [AWS Security Incident Response Guide(AWS 보안 인시던트 대응 안내서)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [Incident Management in the Age of DevOps and SRE(DevOps 및 SRE 시대에 인시던트 관리)](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - What is Incident Management?(PagerDuty - 인시던트 관리란 무엇인가요?)](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**관련 동영상:**
+ [AWS re:Invent 2020: Incident management in a distributed organization(AWS re:Invent 2020: 분산 조직에서 인시던트 관리)](https://www.youtube.com/watch?v=tyS1YDhMVos)
+ [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures(AWS re:Invent 2021 - 이벤트 기반 아키텍처로 차세대 애플리케이션 구축)](https://www.youtube.com/watch?v=U5GZNt0iMZY)
+ [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise(인시던트 관리 살펴보기 탁상 연습)](https://www.youtube.com/watch?v=0m8sGDx-pRM)
+ [AWS Systems Manager Incident Manager - AWS 가상 워크숍](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS What's Next ft. Incident Manager \$1 AWS 이벤트](https://www.youtube.com/watch?v=uZL-z7cII3k)
**관련 예시:**
+ [AWS Management and Governance Tools Workshop - OpsCenter(AWS 관리 및 거버넌스 도구 워크숍 - OpsCenter)](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html)
+ [AWS Proactive Services – Incident Management Workshop(AWS 사전 예방 서비스 – 인시던트 관리 워크숍)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [Building an event-driven application with Amazon EventBridge(Amazon EventBridge를 사용하여 이벤트 기반 애플리케이션 구축)](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [Building event-driven architectures on AWS(AWS에 이벤트 기반 아키텍처 구축)](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
**관련 서비스:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS10-BP02 알림별 프로세스 마련
경계심을 갖는 이벤트가 있는 경우, 특정하게 식별된 소유자를 지정함과 동시에 명확하게 정의된 대응 방법(런북 또는 지침서)을 마련합니다. 이렇게 하면 운영 이벤트에 빠르고 효과적으로 대응할 수 있으며 중요하지 않은 알림 때문에 실행 가능한 이벤트를 제대로 확인하지 못하는 상황을 방지할 수 있습니다.
**일반적인 안티 패턴:**
+ 모니터링 시스템은 승인된 연결 스트림을 다른 메시지와 함께 제공합니다. 메시지 볼륨이 너무 커서 개입이 필요한 주기적인 오류 메시지를 놓칠 수 있습니다.
+ 웹 사이트가 중단되었다는 알림이 표시됩니다. 이 경우에 대해 정의된 프로세스가 없습니다. 문제를 진단하고 해결하기 위해 임시 접근 방식을 취해야 합니다. 작업을 진행하면서 이 프로세스를 개발하면 복구 시간이 길어집니다.
**이 모범 사례 수립의 이점:** 조치가 필요한 경우에만 알림을 보내서 중요하지 않은 알림으로 인해 중요한 알림을 놓치게 되는 상황을 막을 수 있습니다. 실행 가능한 알림을 위한 프로세스를 마련하면 환경의 이벤트에 대해 일관되고 신속한 응답이 가능합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 알림별 프로세스: 알림 생성 대상 이벤트에 대해서는 런북이나 플레이북을 통해 대응 방법을 적절하게 정의해야 하며, 정상적인 프로세스 완료를 담당하는 소유자(예: 개인, 팀, 역할)를 구체적으로 명시해야 합니다. 대응 작업은 자동화되거나 다른 팀이 수행할 수 있지만 프로세스가 예상된 결과를 제공하는지 여부에 대한 책임은 소유자에게 있습니다. 이러한 프로세스를 마련해 두면 운영 이벤트에 빠르고 효과적으로 대응할 수 있으며 중요하지 않은 알림 때문에 실행 가능한 이벤트를 제대로 확인하지 못하는 상황을 방지할 수 있습니다. 예를 들어 웹 프런트 엔드의 크기를 조정하려면 자동 조정 기능을 적용할 수 있지만, 운영 팀은 자동 조정 규칙 및 한도가 워크로드 요구 사항에 적합한지 확인해야 합니다.
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 기능](https://aws.amazon.com/cloudwatch/features/)
+ [Amazon CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**관련 동영상:**
+ [모니터링 플랜 세우기](https://www.youtube.com/watch?v=OMmiGETJpfU)
# OPS10-BP03 비즈니스 영향을 기반으로 운영 이벤트의 우선순위 지정
여러 이벤트에 대해 조치를 취해야 할 때는 실무에 가장 큰 영향을 주는 이벤트를 먼저 해결해야 합니다. 이러한 영향에는 사망 또는 부상, 재정적 손실, 평판 또는 신뢰의 손상이 포함될 수 있습니다.
**일반적인 안티 패턴:**
+ 사용자의 프린터 구성 추가를 위한 지원 요청을 받습니다. 이 문제를 해결하는 동안 소매 사이트가 다운되었다는 지원 요청을 받습니다. 사용자의 프린터 구성을 완료한 후 웹 사이트 문제 해결에 착수합니다.
+ 소매 웹 사이트와 급여 시스템이 모두 다운되었다는 알림을 받습니다. 어느 것에 우선순위를 두어야 하는지 알 수 없습니다.
**이 모범 사례 수립의 이점:** 비즈니스에 가장 큰 영향을 미치는 인시던트에 대한 대응의 우선순위를 정하면 이러한 영향을 관리할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 비즈니스 영향에 기반하여 운영 이벤트 우선순위 지정: 여러 이벤트에 대해 조치를 취해야 할 때는 실무에 가장 큰 영향을 주는 이벤트를 먼저 해결해야 합니다. 이러한 영향에는 사망 또는 부상, 재정적 손실, 규정 위반 또는 평판이나 신뢰의 손상이 포함될 수 있습니다.
# OPS10-BP04 에스컬레이션 경로 정의
에스컬레이션을 트리거하는 요소와 에스컬레이션 절차를 포함한 에스컬레이션 경로를 런북과 플레이북에 정의합니다. 운영 이벤트에 즉시 효율적으로 대응할 수 있도록 각 작업의 소유자를 구체적으로 명시합니다.
작업을 수행하기 전에 사람의 결정이 필요한 경우를 확인합니다. 의사 결정권자와 협력하여 미리 의사 결정을 내리고 작업을 사전에 승인합니다. 그러면 답변을 기다리기 위한 MTTR이 연장되지 않습니다.
**일반적인 안티 패턴:**
+ 소매 사이트가 다운되었습니다. 사이트 복구를 위한 런북을 봐도 모르겠습니다. 도움을 구하기 위해 동료에게 전화를 걸기 시작합니다.
+ 연결할 수 없는 애플리케이션에 대한 지원 사례를 받습니다. 시스템을 관리할 권한이 없습니다. 누구에게 권한이 있는지 알 수 없습니다. 사례를 개시한 시스템 소유자에게 연락을 시도하는데 응답이 없습니다. 시스템에 대한 연락처가 없으며 동료가 시스템에 익숙하지 않습니다.
**이 모범 사례 수립의 이점:** 에스컬레이션, 에스컬레이션 트리거 및 에스컬레이션 절차를 정의하면 영향에 대해 적절한 속도로 인시던트에 리소스를 체계적으로 추가할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 에스컬레이션 경로 정의: 에스컬레이션을 트리거하는 요소와 에스컬레이션 절차를 포함한 에스컬레이션 경로를 런북과 플레이북에 정의합니다. 예를 들어 런북을 통해 문제를 해결할 수 없거나 미리 정의된 시간이 지난 경우에는 지원 엔지니어가 수석 지원 엔지니어에게 문제를 에스컬레이션하도록 정의합니다. 플레이북을 통해 문제 해결 경로를 확인할 수 없거나 미리 정의된 시간이 지난 경우에는 수석 지원 엔지니어가 개발 팀에게 문제를 에스컬레이션할 수도 있습니다. 운영 이벤트에 즉시 효율적으로 대응할 수 있도록 각 작업의 소유자를 구체적으로 명시합니다. 에스컬레이션 과정에는 제3자가 포함될 수 있습니다. 제3자의 예로는 네트워크 연결 공급자, 소프트웨어 공급업체 등이 있습니다. 영향을 받는 시스템에 대해 권한이 부여된 의사 결정자가 에스컬레이션 과정에 참여할 수 있습니다.
# OPS10-BP05 푸시 알림 활성화
사용 중인 서비스가 이벤트의 영향을 받을 때와 정상 작동 상태로 다시 되돌아갈 때 사용자에게 이메일이나 SMS 등을 통해 직접 알립니다. 그러면 사용자가 적절한 조치를 취할 수 있습니다.
**일반적인 안티 패턴:**
+ 애플리케이션에서 분산 서비스 거부 인시던트가 발생하여 며칠 동안 응답이 없습니다. 오류 메시지가 없습니다. 알림 이메일을 전송하지 않았습니다. 문자 알림을 전송하지 않았습니다. 소셜 미디어에서 정보를 공유하지 않았습니다. 고객이 불만을 품고 지원을 제공할 수 있는 다른 공급자를 찾고 있습니다.
+ 월요일에 패치 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 다운되었습니다. 화요일에는 코드 배포 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 불안정했습니다. 수요일에는 실패한 패치와 관련된 보안 취약성을 완화하기 위해 코드를 배포한 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 사용할 수 없었습니다. 목요일에는 실망한 고객이 지원을 제공할 수 있는 다른 공급자를 찾기 시작했습니다.
+ 주말에는 유지 관리를 위해 애플리케이션이 다운될 예정입니다. 고객에게 알리지 않습니다. 일부 고객이 애플리케이션 사용과 관련된 활동을 예약했습니다. 애플리케이션을 사용할 수 없음을 알게 되어 매우 낙담합니다.
**이 모범 사례 수립의 이점:** 알림, 알림 트리거, 알림 절차를 정의하여 워크로드 관련 문제가 고객에게 영향을 줄 때 고객에게 이를 알리고 대응할 수 있도록 합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 푸시 알림 활성화: 사용자가 이용 중인 서비스가 이벤트의 영향을 받을 때 사용자에게 이메일이나 SMS 등을 통해 직접 알리고, 정상 작동 상태로 복구되면 알림을 보냅니다. 그러면 사용자가 적절한 조치를 취할 수 있습니다.
+ [Amazon SES 기능](https://aws.amazon.com/ses/details/)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon SNS 알림 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
## 리소스
**관련 문서:**
+ [Amazon SES 기능](https://aws.amazon.com/ses/details/)
+ [Amazon SNS 알림 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
# OPS10-BP06 대시보드를 통해 상태 전달
목표 대상(예: 내부 기술 팀, 리더십 및 고객)에게 맞춘 대시보드를 제공하여 비즈니스의 현재 운영 상태를 알리고 관심 있는 지표를 제공합니다.
대시보드는 [Amazon CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 를 사용하여 CloudWatch 콘솔을 통해 사용자 지정 가능한 홈 페이지에서 생성할 수 있습니다. 그리고 [Quick](https://aws.amazon.com/quicksight/) 와 같은 비즈니스 인텔리전스 서비스를 사용하면 워크로드 및 운영 상태(예: 주문율, 연결된 사용자 수 및 트랜잭션 시간)에 대한 대화형 대시보드를 생성하고 게시할 수 있습니다. 그리고 이러한 지표의 시스템 및 비즈니스 수준의 보기를 제공하는 대시보드를 생성합니다.
**일반적인 안티 패턴:**
+ 요청 시 관리를 위해 애플리케이션의 현재 사용률에 대한 보고서를 실행합니다.
+ 인시던트 발생 시 해결 여부를 확인하고자 관련 시스템 소유자가 20분마다 연락합니다.
**이 모범 사례 수립의 이점:** 대시보드를 생성하면 정보에 직접 액세스할 권한을 활성화하여 고객이 스스로 정보를 파악하고 조치를 취해야 하는지 판단할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 대시보드를 통해 상태 전달: 목표 대상(예: 내부 기술 팀, 리더십 및 고객)에 맞춤화된 대시보드를 제공하여 비즈니스의 현재 운영 상태를 전달하고 관심 있는 지표를 안내합니다. 상태 정보 확인을 위한 셀프 서비스 옵션을 제공하면 운영 팀의 필딩 요청이 중단되는 상황을 줄일 수 있습니다. 예로는 Amazon CloudWatch 대시보드와 AWS Health Dashboard가 있습니다.
+ [사용자 지정 지표 보기를 생성 및 사용하는 CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
## 리소스
**관련 문서:**
+ [Quick](https://aws.amazon.com/quicksight/)
+ [사용자 지정 지표 보기를 생성 및 사용하는 CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
# OPS10-BP07 이벤트 대응 자동화
이벤트 대응을 자동화하면 수동 프로세스에서 발생하는 오류를 줄일 수 있으며 일관된 방식으로 즉시 대응할 수 있습니다.
AWS에서 여러 방법으로 런북 및 플레이북 작업을 자동화할 수 있습니다. AWS 리소스의 상태 변경으로 인해 발생하는 이벤트나 사용자 지정 이벤트에 응답하려는 경우 [CloudWatch Events 규칙](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) 을 생성하여 CloudWatch 대상(예: Lambda 함수, Amazon Simple Notification Service(Amazon SNS) 주제, Amazon ECS 작업, AWS Systems Manager Automation)을 통해 응답을 트리거해야 합니다.
리소스의 임계값(예: 대기 시간)을 초과하는 지표에 응답하려는 경우에는 [CloudWatch 경보](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 를 생성하여 Amazon EC2 작업, Auto Scaling 작업을 통해 하나 이상의 작업을 수행하거나 Amazon SNS 주제에 알림을 보내면 됩니다. 경보에 대응하여 사용자 지정 작업을 수행해야 하는 경우 Amazon SNS 알림을 통해 Lambda를 호출합니다. 직원들이 정보를 계속 확인할 수 있도록 Amazon SNS를 사용하여 이벤트 알림 및 에스컬레이션 메시지를 게시합니다.
AWS는 AWS 서비스 API 및 SDK를 통해 서드 파티 시스템도 지원합니다. AWS 파트너 및 서드 파티에서 제공하는 다양한 모니터링 도구를 모니터링, 알림 및 응답에 사용할 수 있습니다. 이러한 도구의 예로는 New Relic, Splunk, Loggly, SumoLogic, Datadog 등이 있습니다.
자동 절차에서 오류가 발생하는 경우를 대비해서 중요 수동 절차를 사용 가능한 상태로 유지해야 합니다.
**일반적인 안티 패턴:**
+ 개발자가 코드를 확인합니다. 빌드를 시작한 다음 테스트를 수행하는 데 이 이벤트가 사용되었을 수 있지만 아무 일도 일어나지 않습니다.
+ 애플리케이션이 작업을 중지하기 전에 특정 오류를 기록합니다. 애플리케이션을 다시 시작하는 절차는 잘 이해하고 스크립팅할 수 있습니다. 로그 이벤트를 사용하여 스크립트를 호출하고 애플리케이션을 다시 시작할 수 있습니다. 대신 일요일 오전 3시에 오류가 발생하여 시스템 수정을 담당하는 당직 직원으로서 호출을 받습니다.
**이 모범 사례 수립의 이점:** 이벤트에 대한 자동 응답을 사용하여 응답 시간을 줄이고 수동 활동으로 인한 오류 발생을 제한할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 이벤트에 대한 응답 자동화: 이벤트 응답을 자동화하면 수동 프로세스에서 발생하는 오류를 줄일 수 있으며 일관된 방식으로 즉시 대응할 수 있습니다.
+ [Amazon CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [이벤트에서 트리거되는 CloudWatch Events 규칙 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [AWS CloudTrail를 사용하여 AWS API 호출에서 트리거되는 CloudWatch Events 규칙 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [지원되는 서비스의 CloudWatch Events 이벤트 예제](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 기능](https://aws.amazon.com/cloudwatch/features/)
+ [지원되는 서비스의 CloudWatch Events 이벤트 예제](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
+ [AWS CloudTrail를 사용하여 AWS API 호출에서 트리거되는 CloudWatch Events 규칙 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [이벤트에서 트리거되는 CloudWatch Events 규칙 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [Amazon CloudWatch Events란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**관련 동영상:**
+ [모니터링 플랜 세우기](https://www.youtube.com/watch?v=OMmiGETJpfU)
**관련 예시:**