# OPS 10  워크로드 및 운영 이벤트를 어떻게 관리하십니까?
<a name="w2aac19b5b9b9"></a>

 이벤트로 인해 워크로드가 중단될 가능성을 최소화할 수 있도록 이벤트 대응을 위한 절차를 준비/확인합니다. 

**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 이벤트, 인시던트 및 문제 관리 프로세스 사용
<a name="ops_event_response_event_incident_problem_process"></a>

조직에는 이벤트, 인시던트 및 문제를 처리하기 위한 프로세스가 있습니다. *이벤트* 는 워크로드에서 발생하는 일이지만 개입이 필요하지 않을 수 있습니다. *인시던트* 는 개입이 필요한 이벤트입니다. *문제* 는 개입이 필요하거나 해결할 수 없는 반복 이벤트입니다. 이러한 이벤트가 비즈니스에 미치는 영향을 줄일 수 있는 프로세스가 필요하며 적절하게 대응하는지 확인해야 합니다.

인시던트 및 문제가 워크로드에 발생하면 처리하기 위한 프로세스가 필요합니다. 이해관계자에게 이벤트 상태를 어떻게 전달할 수 있을까요? 대응 주도를 감독하는 사람은 누구인가요? 이벤트로 인한 피해를 줄이기 위해 사용하는 도구는 무엇인가요? 이는 확실한 대응 프로세스를 갖추기 위해 답변해야 하는 질문의 몇 가지 예입니다. 

프로세스는 중앙 위치에 문서화해 두어야 하며 워크로드와 관련된 사람은 누구나 사용할 수 있어야 합니다. 중앙 Wiki 또는 문서 저장소가 없다면 버전 관리 리포지토리를 사용할 수 있습니다. 프로세스 발전에 맞춰 이러한 계획을 최신 상태로 유지하게 됩니다. 

문제는 자동화 후보입니다. 이러한 이벤트는 혁신 역량에서 시간을 빼앗아 갑니다. 문제를 완화하기 위한 반복 프로세스를 구축하는 것부터 시작하세요. 시간이 흐른 후에는 완화 프로세스 자동화 또는 기본 문제 수정에 집중하세요. 그러면 워크로드 개선에 투자할 시간을 확보할 수 있습니다. 

**원하는 결과:** 조직에는 이벤트, 인시던트 및 문제를 처리하기 위한 프로세스가 있습니다. 이러한 프로세스는 문서화되어 중앙 위치에 저장되고 프로세스가 변함에 따라 업데이트됩니다. 

**일반적인 안티 패턴:** 
+  인시던트가 주말에 발생했는데 당직 근무 중인 엔지니어가 무엇을 해야 할지 모릅니다. 
+  고객은 여러분에게 애플리케이션이 다운되었다는 이메일을 보내고 여러분은 서버를 재부팅하여 문제를 해결합니다. 이러한 상황이 빈번하게 발생합니다. 
+  한 가지 인시던트를 여러 팀에서 해결하기 위해 따로 노력합니다. 
+  워크로드에서 배포가 있었는데, 기록되지 않습니다. 

 **이 모범 사례 확립의 이점:** 
+  워크로드에서 이벤트를 감사 추적합니다. 
+  인시던트에서 복구 시간이 단축됩니다. 
+  팀원이 일관된 방식으로 인시던트와 문제를 해결할 수 있습니다. 
+  인시던트를 조사할 때 더욱 통합된 노력을 기울일 수 있습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

이 모범 사례를 구현하면 워크로드 이벤트를 추적하게 됩니다. 인시던트 및 문제를 처리하기 위한 프로세스를 보유하게 되며, 프로세스는 문서화되고 공유되며 자주 업데이트됩니다. 문제가 파악되면 우선순위가 지정되고 해결됩니다. 

 **고객 사례** 

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) 을(를) 사용하여 인시던트를 관리하고 피해를 줄이기 위한 작업을 조정합니다. 

## 구현 단계
<a name="implementation-steps"></a>

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) 를 사용하여 문제를 식별하고 해당 문제에 런북을 첨부한 다음 문제를 추적할 수 있습니다. 

**구현 계획의 작업 수준:** 보통. 모범 사례를 구현하기 위한 프로세스 및 도구가 둘 다 필요합니다. 프로세스를 문서화하고 워크로드와 관련된 모든 사람들이 사용할 수 있도록 설정합니다. 프로세스를 자주 업데이트합니다. 문제를 관리하고 문제를 완화 또는 해결하기 위한 프로세스가 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 모범 사례:** 
+  [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 알림별 프로세스 마련
<a name="ops_event_response_process_per_alert"></a>

 경계심을 갖는 이벤트가 있는 경우, 특정하게 식별된 소유자를 지정함과 동시에 명확하게 정의된 대응 방법(런북 또는 지침서)을 마련합니다. 이렇게 하면 운영 이벤트에 빠르고 효과적으로 대응할 수 있으며 중요하지 않은 알림 때문에 실행 가능한 이벤트를 제대로 확인하지 못하는 상황을 방지할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  모니터링 시스템은 승인된 연결 스트림을 다른 메시지와 함께 제공합니다. 메시지 볼륨이 너무 커서 개입이 필요한 주기적인 오류 메시지를 놓칠 수 있습니다. 
+  웹 사이트가 중단되었다는 알림이 표시됩니다. 이 경우에 대해 정의된 프로세스가 없습니다. 문제를 진단하고 해결하기 위해 임시 접근 방식을 취해야 합니다. 작업을 진행하면서 이 프로세스를 개발하면 복구 시간이 길어집니다. 

 **이 모범 사례 수립의 이점:** 조치가 필요한 경우에만 알림을 보내서 중요하지 않은 알림으로 인해 중요한 알림을 놓치게 되는 상황을 막을 수 있습니다. 실행 가능한 알림을 위한 프로세스를 마련하면 환경의 이벤트에 대해 일관되고 신속한 응답이 가능합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  알림별 프로세스: 알림 생성 대상 이벤트에 대해서는 런북이나 플레이북을 통해 대응 방법을 적절하게 정의해야 하며, 정상적인 프로세스 완료를 담당하는 소유자(예: 개인, 팀, 역할)를 구체적으로 명시해야 합니다. 대응 작업은 자동화되거나 다른 팀이 수행할 수 있지만 프로세스가 예상된 결과를 제공하는지 여부에 대한 책임은 소유자에게 있습니다. 이러한 프로세스를 마련해 두면 운영 이벤트에 빠르고 효과적으로 대응할 수 있으며 중요하지 않은 알림 때문에 실행 가능한 이벤트를 제대로 확인하지 못하는 상황을 방지할 수 있습니다. 예를 들어 웹 프런트 엔드의 크기를 조정하려면 자동 조정 기능을 적용할 수 있지만, 운영 팀은 자동 조정 규칙 및 한도가 워크로드 요구 사항에 적합한지 확인해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 비즈니스 영향을 기반으로 운영 이벤트의 우선순위 지정
<a name="ops_event_response_prioritize_events"></a>

 여러 이벤트에 대해 조치를 취해야 할 때는 실무에 가장 큰 영향을 주는 이벤트를 먼저 해결해야 합니다. 이러한 영향에는 사망 또는 부상, 재정적 손실, 평판 또는 신뢰의 손상이 포함될 수 있습니다. 

 **일반적인 안티 패턴:** 
+  사용자의 프린터 구성 추가를 위한 지원 요청을 받습니다. 이 문제를 해결하는 동안 소매 사이트가 다운되었다는 지원 요청을 받습니다. 사용자의 프린터 구성을 완료한 후 웹 사이트 문제 해결에 착수합니다. 
+  소매 웹 사이트와 급여 시스템이 모두 다운되었다는 알림을 받습니다. 어느 것에 우선순위를 두어야 하는지 알 수 없습니다. 

 **이 모범 사례 수립의 이점:** 비즈니스에 가장 큰 영향을 미치는 인시던트에 대한 대응의 우선순위를 정하면 이러한 영향을 관리할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  비즈니스 영향에 기반하여 운영 이벤트 우선순위 지정: 여러 이벤트에 대해 조치를 취해야 할 때는 실무에 가장 큰 영향을 주는 이벤트를 먼저 해결해야 합니다. 이러한 영향에는 사망 또는 부상, 재정적 손실, 규정 위반 또는 평판이나 신뢰의 손상이 포함될 수 있습니다. 

# OPS10-BP04 에스컬레이션 경로 정의
<a name="ops_event_response_define_escalation_paths"></a>

 에스컬레이션을 트리거하는 요소와 에스컬레이션 절차를 포함한 에스컬레이션 경로를 런북과 플레이북에 정의합니다. 운영 이벤트에 즉시 효율적으로 대응할 수 있도록 각 작업의 소유자를 구체적으로 명시합니다. 

 작업을 수행하기 전에 사람의 결정이 필요한 경우를 확인합니다. 의사 결정권자와 협력하여 미리 의사 결정을 내리고 작업을 사전에 승인합니다. 그러면 답변을 기다리기 위한 MTTR이 연장되지 않습니다. 

 **일반적인 안티 패턴:** 
+  소매 사이트가 다운되었습니다. 사이트 복구를 위한 런북을 봐도 모르겠습니다. 도움을 구하기 위해 동료에게 전화를 걸기 시작합니다. 
+  연결할 수 없는 애플리케이션에 대한 지원 사례를 받습니다. 시스템을 관리할 권한이 없습니다. 누구에게 권한이 있는지 알 수 없습니다. 사례를 개시한 시스템 소유자에게 연락을 시도하는데 응답이 없습니다. 시스템에 대한 연락처가 없으며 동료가 시스템에 익숙하지 않습니다. 

 **이 모범 사례 수립의 이점:** 에스컬레이션, 에스컬레이션 트리거 및 에스컬레이션 절차를 정의하면 영향에 대해 적절한 속도로 인시던트에 리소스를 체계적으로 추가할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  에스컬레이션 경로 정의: 에스컬레이션을 트리거하는 요소와 에스컬레이션 절차를 포함한 에스컬레이션 경로를 런북과 플레이북에 정의합니다. 예를 들어 런북을 통해 문제를 해결할 수 없거나 미리 정의된 시간이 지난 경우에는 지원 엔지니어가 수석 지원 엔지니어에게 문제를 에스컬레이션하도록 정의합니다. 플레이북을 통해 문제 해결 경로를 확인할 수 없거나 미리 정의된 시간이 지난 경우에는 수석 지원 엔지니어가 개발 팀에게 문제를 에스컬레이션할 수도 있습니다. 운영 이벤트에 즉시 효율적으로 대응할 수 있도록 각 작업의 소유자를 구체적으로 명시합니다. 에스컬레이션 과정에는 제3자가 포함될 수 있습니다. 제3자의 예로는 네트워크 연결 공급자, 소프트웨어 공급업체 등이 있습니다. 영향을 받는 시스템에 대해 권한이 부여된 의사 결정자가 에스컬레이션 과정에 참여할 수 있습니다. 

# OPS10-BP05 푸시 알림 활성화
<a name="ops_event_response_push_notify"></a>

 사용 중인 서비스가 이벤트의 영향을 받을 때와 정상 작동 상태로 다시 되돌아갈 때 사용자에게 이메일이나 SMS 등을 통해 직접 알립니다. 그러면 사용자가 적절한 조치를 취할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  애플리케이션에서 분산 서비스 거부 인시던트가 발생하여 며칠 동안 응답이 없습니다. 오류 메시지가 없습니다. 알림 이메일을 전송하지 않았습니다. 문자 알림을 전송하지 않았습니다. 소셜 미디어에서 정보를 공유하지 않았습니다. 고객이 불만을 품고 지원을 제공할 수 있는 다른 공급자를 찾고 있습니다. 
+  월요일에 패치 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 다운되었습니다. 화요일에는 코드 배포 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 불안정했습니다. 수요일에는 실패한 패치와 관련된 보안 취약성을 완화하기 위해 코드를 배포한 후 애플리케이션에서 문제가 발생하여 몇 시간 동안 사용할 수 없었습니다. 목요일에는 실망한 고객이 지원을 제공할 수 있는 다른 공급자를 찾기 시작했습니다. 
+  주말에는 유지 관리를 위해 애플리케이션이 다운될 예정입니다. 고객에게 알리지 않습니다. 일부 고객이 애플리케이션 사용과 관련된 활동을 예약했습니다. 애플리케이션을 사용할 수 없음을 알게 되어 매우 낙담합니다. 

 **이 모범 사례 수립의 이점:** 알림, 알림 트리거, 알림 절차를 정의하여 워크로드 관련 문제가 고객에게 영향을 줄 때 고객에게 이를 알리고 대응할 수 있도록 합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  푸시 알림 활성화: 사용자가 이용 중인 서비스가 이벤트의 영향을 받을 때 사용자에게 이메일이나 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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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 대시보드를 통해 상태 전달
<a name="ops_event_response_dashboards"></a>

 목표 대상(예: 내부 기술 팀, 리더십 및 고객)에게 맞춘 대시보드를 제공하여 비즈니스의 현재 운영 상태를 알리고 관심 있는 지표를 제공합니다. 

 대시보드는 [Amazon CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 를 사용하여 CloudWatch 콘솔을 통해 사용자 지정 가능한 홈 페이지에서 생성할 수 있습니다. 그리고 [Quick](https://aws.amazon.com/quicksight/) 와 같은 비즈니스 인텔리전스 서비스를 사용하면 워크로드 및 운영 상태(예: 주문율, 연결된 사용자 수 및 트랜잭션 시간)에 대한 대화형 대시보드를 생성하고 게시할 수 있습니다. 그리고 이러한 지표의 시스템 및 비즈니스 수준의 보기를 제공하는 대시보드를 생성합니다. 

 **일반적인 안티 패턴:** 
+  요청 시 관리를 위해 애플리케이션의 현재 사용률에 대한 보고서를 실행합니다. 
+  인시던트 발생 시 해결 여부를 확인하고자 관련 시스템 소유자가 20분마다 연락합니다. 

 **이 모범 사례 수립의 이점:** 대시보드를 생성하면 정보에 직접 액세스할 권한을 활성화하여 고객이 스스로 정보를 파악하고 조치를 취해야 하는지 판단할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  대시보드를 통해 상태 전달: 목표 대상(예: 내부 기술 팀, 리더십 및 고객)에 맞춤화된 대시보드를 제공하여 비즈니스의 현재 운영 상태를 전달하고 관심 있는 지표를 안내합니다. 상태 정보 확인을 위한 셀프 서비스 옵션을 제공하면 운영 팀의 필딩 요청이 중단되는 상황을 줄일 수 있습니다. 예로는 Amazon CloudWatch 대시보드와 AWS Health Dashboard가 있습니다. 
  +  [사용자 지정 지표 보기를 생성 및 사용하는 CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [Quick](https://aws.amazon.com/quicksight/) 
+  [사용자 지정 지표 보기를 생성 및 사용하는 CloudWatch 대시보드](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) 

# OPS10-BP07 이벤트 대응 자동화
<a name="ops_event_response_auto_event_response"></a>

 이벤트 대응을 자동화하면 수동 프로세스에서 발생하는 오류를 줄일 수 있으며 일관된 방식으로 즉시 대응할 수 있습니다. 

 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시에 오류가 발생하여 시스템 수정을 담당하는 당직 직원으로서 호출을 받습니다. 

 **이 모범 사례 수립의 이점:** 이벤트에 대한 자동 응답을 사용하여 응답 시간을 줄이고 수동 활동으로 인한 오류 발생을 제한할 수 있습니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  이벤트에 대한 응답 자동화: 이벤트 응답을 자동화하면 수동 프로세스에서 발생하는 오류를 줄일 수 있으며 일관된 방식으로 즉시 대응할 수 있습니다. 
  +  [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) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [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) 

 **관련 예시:**