# 준비
**Topics**
+ [OPS 4 운영 상태를 파악할 수 있도록 어떻게 워크로드를 설계하십니까?](w2aac19b5b7b5.md)
+ [OPS 5 귀사는 어떻게 결함을 줄이고 수정 작업을 쉽게 수행하고 프로덕션으로 이어지는 흐름을 개선하십니까?](w2aac19b5b7b7.md)
+ [OPS 6 배포 위험을 어떻게 최소화하고 있습니까?](w2aac19b5b7b9.md)
+ [OPS 7 귀사가 워크로드를 지원할 준비가 되어있는지 어떻게 알 수 있습니까?](w2aac19b5b7c11.md)
# OPS 4 운영 상태를 파악할 수 있도록 어떻게 워크로드를 설계하십니까?
모든 구성 요소에서 지표, 로그, 추적 등의 내부 상태를 파악하는 데 필요한 정보를 제공하도록 워크로드를 설계합니다. 이렇게 하면 효율적으로 적절한 대응을 할 수 있습니다.
**Topics**
+ [OPS04-BP01 애플리케이션 원격 측정 구현](ops_telemetry_application_telemetry.md)
+ [OPS04-BP02 워크로드 원격 측정 구현 및 구성](ops_telemetry_workload_telemetry.md)
+ [OPS04-BP03 사용자 활동 원격 측정 구현](ops_telemetry_customer_telemetry.md)
+ [OPS04-BP04 종속성 원격 측정 구현](ops_telemetry_dependency_telemetry.md)
+ [OPS04-BP05 트랜잭션 추적 기능 구현](ops_telemetry_dist_trace.md)
# OPS04-BP01 애플리케이션 원격 측정 구현
애플리케이션 원격 측정 기능은 워크로드를 관찰하기 위한 기반입니다. 애플리케이션은 애플리케이션의 상태와 비즈니스 성과 달성에 대한 인사이트를 제공하는 원격 측정 기능을 지원해야 합니다. 문제 해결부터 새로운 기능의 영향력 측정까지, 애플리케이션 원격 측정 기능은 워크로드의 구축, 운영 및 발전 방법을 제시합니다.
애플리케이션 원격 측정 기능은 지표와 로그로 구성됩니다. 지표는 맥박이나 온도와 같은 진단 정보라고 할 수 있습니다. 지표는 종합적으로 사용되어 애플리케이션의 상태를 설명합니다. 시간의 흐름에 따라 지표를 수집하면 기준을 설정하고 이상 징후를 탐지할 수 있습니다. 로그는 애플리케이션이 내부 상태 또는 발생한 이벤트와 관련해서 보내는 메시지입니다. 로깅되는 이벤트의 예로는 오류 코드, 거래 식별자, 사용자 활동을 들 수 있습니다.
**원하는 결과:**
+ 애플리케이션은 비즈니스 성과 달성 여부와 상태에 대한 인사이트를 알려 주는 지표와 로그를 제공합니다.
+ 지표와 로그는 워크로드의 모든 애플리케이션에 대해 중앙 집중식으로 저장됩니다.
**일반적인 안티 패턴:**
+ 애플리케이션이 원격 측정을 내보내지 않습니다. 무언가 잘못되었을 때 고객이 제공하는 정보에 의존할 수 밖에 없습니다.
+ 고객이 애플리케이션이 응답하지 않다고 보고했습니다. 원격 측정이 없으며 현재 사용자 경험을 파악하기 위해 애플리케이션을 직접 사용하지 않고 문제가 존재하는지 확인하거나 문제를 특징 지울 수 없습니다.
**이 모범 사례 수립의 이점:**
+ 애플리케이션의 상태, 사용자 경험 및 비즈니스 성과 달성을 파악할 수 있습니다.
+ 애플리케이션 상태 변화에 신속하게 대처할 수 있습니다.
+ 애플리케이션 상태 추세를 파악할 수 있습니다.
+ 정보를 바탕으로 애플리케이션 개선을 위한 결정을 내릴 수 있습니다.
+ 애플리케이션 문제를 신속하게 감지하고 해결할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
애플리케이션 원격 측정은 원격 측정을 저장할 위치를 파악하고, 애플리케이션 상태를 설명하는 원격 측정을 식별하고, 애플리케이션이 원격 측정을 내보내도록 계측하는 3단계로 구현됩니다.
한 전자 상거래 회사에서 마이크로서비스 기반 아키텍처를 사용 중이라고 가정해 봅니다. 이 회사에서는 아키텍처 설계 과정에서 각 마이크로서비스의 상태를 이해하는 데 도움이 되는 애플리케이션 원격 측정을 식별했습니다. 예를 들어, 사용자 장바구니 서비스에서 장바구니에 추가, 구매 포기, 장바구니에 항목을 추가하는 데 걸린 시간 등의 이벤트에 대한 원격 측정을 내보냈습니다. 그러면 모든 마이크로서비스에서 오류, 경고 및 트랜잭션 정보를 기록하고, 원격 측정이 저장 및 분석을 위해 Amazon CloudWatch로 보내집니다.
**구현 단계**
첫 번째 단계로, 워크로드에서 애플리케이션의 원격 측정을 저장할 중앙 위치를 파악합니다. 기존에 사용 중인 플랫폼이 없는 경우 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) 에서 원격 측정 수집, 대시보드, 분석 및 이벤트 생성 기능을 제공합니다.
어떤 원격 측정이 필요한지 확인하려면 다음 질문의 답을 찾아 봅니다.
+ 애플리케이션 상태가 양호합니까?
+ 애플리케이션으로 비즈니스 성과를 달성하고 있습니까?
애플리케이션에서 이러한 질문의 답을 줄 수 있는 로그와 지표를 내보내야 합니다. 기존 애플리케이션 원격 측정으로 해당 질문에 답할 수 없는 경우 비즈니스 및 엔지니어링 이해관계자와 협력하여 원격 측정 가능 목록을 작성하십시오. 새로운 애플리케이션 원격 측정을 식별하고 개발할 때는 AWS 계정 팀에 전문 기술 조언을 요청할 수 있습니다.
추가 애플리케이션 원격 측정이 확인되면 엔지니어링 이해관계자와 협력하여 애플리케이션을 계측합니다. [AWS Distro for Open Telemetry](https://aws-otel.github.io/) 에서는 애플리케이션 원격 측정을 수집하는 에이전트, 라이브러리, API를 제공합니다. [이 예에서는 사용자 지정 지표를 통해 JavaScript 애플리케이션을 계측하는 방법을 보여 줍니다](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr).
AWS에서 제공하는 관찰성 서비스를 알아보려는 고객은 직접 [One Observability Workshop](https://catalog.workshops.aws/observability/en-US) 에 참여하거나 담당 AWS 계정 팀에 지원을 요청하여 안내받을 수 있습니다. 이 워크숍에서는 AWS의 관찰성 솔루션을 소개하고, 솔루션 사용법을 안내하는 예시 실습을 제공합니다.
애플리케이션 원격 측정에 대한 자세한 내용은 Amazon Builder’s Library에서 [운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 문서를 참조하십시오. Amazon이 애플리케이션을 계측하는 방법이 나와 있으며, 자체 계측 가이드라인을 구상하는 데 도움이 되는 지침으로 삼을 수 있습니다.
**구현 계획의 작업 수준:** 보통
## 리소스
**관련 모범 사례:**
[OPS04-BP02 워크로드 원격 측정 구현 및 구성](ops_telemetry_workload_telemetry.md) - 애플리케이션 원격 측정은 워크로드 원격 측정을 구성하는 요소입니다. 전체 워크로드의 상태를 이해하려면 워크로드를 구성하는 개별 애플리케이션의 상태를 파악해야 합니다.
[OPS04-BP03 사용자 활동 원격 측정 구현](ops_telemetry_customer_telemetry.md) - 사용자 활동 원격 측정은 애플리케이션 원격 측정의 하위 집합인 경우가 많습니다. 장바구니에 추가 이벤트, 클릭 스트림 또는 완료된 트랜잭션과 같은 사용자 활동은 사용자 경험에 대한 인사이트를 제공합니다.
[OPS04-BP04 종속성 원격 측정 구현](ops_telemetry_dependency_telemetry.md) - 종속성 점검은 애플리케이션 원격 측정과 관련이 있으며, 애플리케이션에 계측될 수 있습니다. 애플리케이션이 DNS 또는 데이터베이스와 같은 외부 종속성에 의존하는 경우 애플리케이션이 도달 가능성, 시간 초과, 기타 이벤트에 대한 로그와 지표를 내보낼 수 있습니다.
[OPS04-BP05 트랜잭션 추적 기능 구현](ops_telemetry_dist_trace.md) - 워크로드 전체에서 트랜잭션을 추적하려면 각 애플리케이션이 공유 이벤트를 처리하는 방법에 대한 정보를 생성해야 합니다. 애플리케이션 원격 측정을 통해 개별 애플리케이션에서 해당 이벤트를 처리하는 방식이 내보내집니다.
[OPS08-BP02 워크로드 지표 정의](ops_workload_health_design_workload_metrics.md) - 워크로드 지표는 워크로드의 주요 상태를 나타냅니다. 주요 애플리케이션 지표는 워크로드 지표의 일부입니다.
**관련 문서:**
+ [AWS Builders Library - 운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
+ [AWS Well-Architected 운영 우수성 백서 - 원격 측정 설계](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html)
+ [필터를 사용하여 로그 이벤트에서 지표 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch를 통한 로깅 및 모니터링 구현](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)
+ [AWS Distro for OpenTelemetry를 사용한 애플리케이션 상태 및 성능 모니터링](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/)
+ [신규 - Amazon CloudWatch 에이전트를 통해 사용자 지정 애플리케이션 지표를 효과적으로 모니터링하는 방법](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/)
+ [AWS에서의 관찰성](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/)
+ [시나리오 - CloudWatch로 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html)
+ [구축 시작 - 애플리케이션을 효과적으로 모니터링하는 방법](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [AWS SDK에서 CloudWatch 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html)
**관련 동영상:**
+ [AWS re:Invent 2021 - 오픈 소스 방식의 관찰 가능성](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스에서 지표 및 로그 수집](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [AWS 워크로드에 적합한 애플리케이션 모니터링을 쉽게 설정하는 방법 - AWS Online Tech Talks](https://www.youtube.com/watch?v=LKCth30RqnA)
+ [서버리스 애플리케이션의 관찰성 마스터링 - AWS Online Tech Talks](https://www.youtube.com/watch?v=CtsiXhiAUq8)
+ [AWS를 통한 오픈 소스 관찰성 - AWS 가상 워크숍](https://www.youtube.com/watch?v=vAnIhIwE5hY)
**관련 예시:**
+ [AWS 로깅 및 모니터링 예시 리소스](https://github.com/aws-samples/logging-monitoring-apg-guide-examples)
+ [AWS 솔루션: Amazon CloudWatch 모니터링 프레임워크](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card)
+ [AWS 솔루션: 중앙 집중식 로깅](https://aws.amazon.com/solutions/implementations/centralized-logging/)
+ [One Observability Workshop](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 워크로드 원격 측정 구현 및 구성
내부 상태와 현재 상태 관련 정보(예: API 호출 볼륨, HTTP 상태 코드, 크기 조정 이벤트)를 내보내도록 워크로드를 설계 및 구성합니다. 이 정보를 사용하면 대응이 필요한 경우를 확인할 수 있습니다.
서비스, 즉 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 와 같은 서비스를 사용하여 워크로드 구성 요소(예: 다음의 API 로그 - [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), [AWS Lambda 지표](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html), [Amazon VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)및 [기타 서비스](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html))는 SAP NetWeaver Guide Finder 및 SAP NetWeaver Security Guide를 참조하세요.
**일반적인 안티 패턴:**
+ 고객이 성능 저하에 대해 불만을 제기하고 있습니다. 애플리케이션에 대한 최근 변경 사항이 없으므로 워크로드 구성 요소에 문제가 있다고 의심됩니다. 성능 저하를 유발하는 구성 요소를 확인하기 위해 분석할 원격 측정이 없습니다.
+ 애플리케이션에 연결할 수 없습니다. 원격 측정이 부족하여 네트워크 문제인지 확인할 수 없습니다.
**이 모범 사례 수립의 이점:** 워크로드 내부에서 어떤 일이 일어나는지 파악하면 필요한 경우 대응이 가능합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 로그 및 지표 원격 측정 구현: 워크로드를 계측하여 내부 상태 및 비즈니스 성과 달성에 대한 정보를 내보냅니다. 이 정보를 사용하여 대응이 필요한 경우를 확인합니다.
+ [Amazon CloudWatch를 사용하여 VM에 대한 관찰성 향상 - AWS Online Tech Talks](https://youtu.be/1Ck_me4azMw)
+ [Amazon CloudWatch 작동 방식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch Logs란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ 워크로드 원격 측정 구현 및 구성: 내부 상태와 현재 상태 관련 정보(예: API 호출 볼륨, HTTP 상태 코드, 크기 조정 이벤트)를 내보내도록 워크로드를 설계 및 구성합니다.
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [AWS CloudTrail란 무엇입니까?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
## 리소스
**관련 문서:**
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch 설명서](https://docs.aws.amazon.com/cloudwatch/index.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/cloudwatch_architecture.html)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [VPC 흐름 로그](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [AWS CloudTrail란 무엇입니까?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Amazon CloudWatch Logs란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon CloudWatch란 무엇입니까?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
**관련 동영상:**
+ [AWS에서의 애플리케이션 성능 관리](https://www.youtube.com/watch?v=5T4stR-HFas)
+ [Amazon CloudWatch를 사용하여 VM에 대한 관찰 가능성 향상](https://youtu.be/1Ck_me4azMw)
+ [Amazon CloudWatch를 사용하여 VM에 대한 관찰성 향상 - AWS Online Tech Talks](https://youtu.be/1Ck_me4azMw)
# OPS04-BP03 사용자 활동 원격 측정 구현
사용자 활동 관련 정보(예: 클릭 스트림 또는 시작/중단/완료된 트랜잭션)를 생성하도록 애플리케이션 코드를 설계합니다. 이 정보를 사용하면 애플리케이션 사용 방법과 사용 패턴을 파악하고 대응이 필요한 경우를 확인할 수 있습니다.
**일반적인 안티 패턴:**
+ 개발자는 사용자 원격 측정 없이 새로운 기능을 배포했으며 사용률이 향상되었습니다. 새 기능 사용으로 인해 사용률이 증가했는지 아니면 새 코드에 문제가 발생한 것인지 확인할 수 없습니다.
+ 개발자는 사용자 원격 측정 없이 새로운 기능을 배포했습니다. 새로운 기능을 사용하고 있는지 고객에게 여부를 묻지 않고는 알 수 없습니다.
**이 모범 사례 정립의 이점:** 고객이 애플리케이션을 사용하여 사용 패턴과 예기치 않은 동작을 식별하고 필요한 경우 대응할 수 있도록 하는 방법을 파악합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 사용자 활동 원격 측정 구현: 사용자 활동 관련 정보(예: 클릭 스트림 또는 시작/중단/완료된 트랜잭션)를 내보내도록 애플리케이션 코드를 설계합니다. 이 정보를 사용하면 애플리케이션 사용 방법과 사용 패턴을 파악하고 대응이 필요한 경우를 확인할 수 있습니다.
# OPS04-BP04 종속성 원격 측정 구현
종속된 리소스의 상태에 대한 정보(도달 가능성 또는 응답 시간)를 생성하도록 워크로드를 설계하고 구성합니다. 외부 종속성의 예로는 외부 데이터베이스, DNS, 네트워크 연결 등이 있습니다. 이 정보를 사용하여 대응이 필요한 경우를 확인합니다.
**일반적인 안티 패턴:**
+ DNS 공급자가 작동하는지 확인하기 위해 수동으로 점검하지 않고는 애플리케이션에 연결할 수 없는 이유가 DNS 문제인지 확인할 수 없습니다.
+ 장바구니 애플리케이션에서 트랜잭션을 완료할 수 없습니다. 확인을 위해 연락하지 않고는 신용 카드 처리 공급자에게 문제가 있는지 확인할 수 없습니다.
**이 모범 사례 수립의 이점:** 종속성 상태를 파악하면 필요한 경우 대응할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 종속성 원격 측정 구현: 워크로드가 사용하는 시스템의 상태 관련 정보를 내보내도록 워크로드를 설계하고 구성합니다. 외부 데이터베이스, DNS, 네트워크 연결 및 외부 신용 카드 처리 서비스를 예로 들 수 있습니다.
+ [Amazon CloudWatch 에이전트와 AWS Systems Manager 통합 - Linux 및 Windows용 통합 지표 및 로그 수집](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버에서 지표 및 로그 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch 에이전트와 AWS Systems Manager 통합 - Linux 및 Windows용 통합 지표 및 로그 수집](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch 에이전트를 사용하여 Amazon EC2 인스턴스 및 온프레미스 서버에서 지표 및 로그 수집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
**관련 예시:**
+ [Well-Architected 랩 - 종속성 모니터링](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
# OPS04-BP05 트랜잭션 추적 기능 구현
워크로드 전반에 걸친 트랜잭션 흐름 관련 정보를 내보내도록 애플리케이션 코드를 구현하고 워크로드 구성 요소를 구성합니다. 이 정보를 사용하면 대응이 필요한 경우를 확인하고 문제의 원인을 파악할 수 있습니다.
AWS에서는 [AWS X-Ray](https://aws.amazon.com/xray/)와 같은 분산 추적 서비스를 사용하여 워크로드에서 트랜잭션이 이동할 때 추적을 수집 및 기록하고, 워크로드 및 서비스에서 트랜잭션의 흐름을 알 수 있는 맵을 생성하며, 구성 요소 간 관계에 대한 인사이트를 얻고, 실시간으로 문제를 식별하고 분석할 수 있습니다.
**일반적인 안티 패턴:**
+ 여러 계정에 걸쳐 서버리스 마이크로서비스 아키텍처를 구현했습니다. 고객에게 간헐적인 성능 문제가 있습니다. 애플리케이션에서 성능 문제가 있는 영역과 문제의 원인을 정확히 찾아낼 수 있는 정보와 기록이 부족하여 원인이 되는 기능이나 구성 요소를 파악할 수 없습니다.
+ 개발 과정에서 해결할 수 있도록 워크로드에서 성능 병목 현상이 있는 위치를 파악하려고 합니다. 애플리케이션 구성 요소와 상호 작용하는 서비스 간의 관계를 확인할 수 없습니다. 애플리케이션 성능에 영향을 미치는 특정 서비스 및 경로로 드릴다운할 수 있는 정보와 기록이 부족하기 때문입니다.
**이 모범 사례 수립의 이점:** 워크로드 전반의 트랜잭션 흐름을 파악하면 워크로드 트랜잭션의 예상 동작과 워크로드 전반의 예상 동작 변형을 파악할 수 있으므로 필요한 경우 대응할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 트랜잭션 추적 기능 구현: 트랜잭션 단계, 활성 구성 요소, 활동 완료 시간 등의 시스템 구성 요소 간의 트랜잭션 흐름 관련 정보를 내보내도록 애플리케이션과 워크로드를 설계합니다. 이 정보를 사용하여 진행 중인 활동과 완료된 활동, 그리고 완료된 활동의 결과를 확인합니다. 그러면 대응이 필요한 경우를 확인할 수 있습니다. 구성 요소 내에서 트랜잭션 응답 시간이 예상보다 길면 해당 구성 요소에 문제가 있는 것일 수 있습니다.
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
## 리소스
**관련 문서:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray란 무엇입니까?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# OPS 5 귀사는 어떻게 결함을 줄이고 수정 작업을 쉽게 수행하고 프로덕션으로 이어지는 흐름을 개선하십니까?
프로덕션 환경으로 변경 사항을 전달하는 흐름을 개선할 수 있는 방식을 도입합니다. 이 방식은 리팩터링, 품질과 관련된 빠른 피드백 및 버그 수정을 지원해야 합니다. 이러한 방식을 도입하면 유용한 변경 사항을 프로덕션 환경으로 빠르게 전달할 수 있고, 문제 배포 가능성을 제한할 수 있으며, 배포 활동을 통해 발생하는 문제를 빠르게 파악하고 해결할 수 있습니다.
**Topics**
+ [OPS05-BP01 버전 관리 사용](ops_dev_integ_version_control.md)
+ [OPS05-BP02 변경 사항 테스트 및 확인](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 구성 관리 시스템 사용](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 빌드 및 배포 관리 시스템 사용](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 패치 관리 수행](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 설계 표준 공유](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 코드 품질 개선을 위한 사례 구현](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 여러 환경 사용](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 되돌릴 수 있는 작은 단위의 변경 내용 자주 적용](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 통합 및 배포 완전 자동화](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 버전 관리 사용
버전 관리를 사용하면 변경 사항과 릴리스를 추적할 수 있습니다.
많은 AWS 서비스가 버전 관리 기능을 제공합니다. 수정본 또는 소스 제어 시스템(예: [AWS CodeCommit](https://aws.amazon.com/codecommit/) )을 사용하여 코드 및 버전을 관리하는 인프라의 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 템플릿과 같은 기타 아티팩트를 관리합니다.
**일반적인 안티 패턴:**
+ 워크스테이션에서 코드를 개발하고 저장해 왔습니다. 코드가 손실된 워크스테이션에서 복구할 수 없는 스토리지 장애가 발생했습니다.
+ 기존 코드를 변경 사항으로 덮어쓴 후 애플리케이션을 다시 시작하면 애플리케이션이 더 이상 작동하지 않습니다. 변경 사항으로 되돌릴 수 없습니다.
+ 다른 사람이 편집해야 하는 보고서 파일에 대한 쓰기 잠금이 있습니다. 태스크를 완료할 수 있도록 태스크 작업 중지를 요청하는 연락을 받습니다.
+ 연구 팀은 향후 작업을 결정할 세부 분석을 수행해 왔습니다. 누군가 실수로 최종 보고서에 쇼핑 목록을 저장했습니다. 변경 사항을 되돌릴 수 없으며 보고서를 다시 생성해야 합니다.
**이 모범 사례 정립의 이점:** 버전 관리 기능을 사용하면 쉽게 알려진 정상 상태와 이전 버전으로 되돌리고 자산 손실 위험을 제한할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 버전 관리 사용: 버전 제어 리포지토리에서 자산을 유지 관리합니다. 이렇게 하면 변경 사항을 추적하고, 새 버전을 배포하고, 기존 버전의 변경 사항을 감지하고, 장애 시 알려진 정상 상태로 롤백하는 등 이전 버전으로 되돌릴 수 있습니다. 구성 관리 시스템의 버전 제어 기능을 프로시저에 통합합니다.
+ [AWS CodeCommit 소개](https://youtu.be/46PRLMW8otg)
+ [AWS CodeCommit란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [AWS CodeCommit란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**관련 동영상:**
+ [AWS CodeCommit 소개](https://youtu.be/46PRLMW8otg)
# OPS05-BP02 변경 사항 테스트 및 확인
변경 사항을 테스트하고 확인하면 오류를 제한하고 감지할 수 있습니다. 그리고 테스트를 자동화하면 수동 프로세스에서 발생하는 오류와 테스트해야 하는 작업량을 줄일 수 있습니다.
많은 AWS 서비스가 버전 관리 기능을 제공합니다. 수정본 또는 소스 제어 시스템(예: [AWS CodeCommit](https://aws.amazon.com/codecommit/) )을 사용하여 코드 및 버전을 관리하는 인프라의 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 템플릿과 같은 기타 아티팩트를 관리합니다.
**일반적인 안티 패턴:**
+ 새 코드를 프로덕션에 배포하면 애플리케이션이 더 이상 작동하지 않기 때문에 고객이 호출을 시작합니다.
+ 새 보안 그룹을 적용하여 경계 보안을 강화합니다. 이렇게 되면 의도하지 않은 결과가 발생하므로, 사용자가 애플리케이션에 액세스할 수 없습니다.
+ 새 함수에서 호출하는 메서드를 수정합니다. 또 다른 함수도 해당 메서드에 종속되어 더 이상 작동하지 않습니다. 문제가 감지되지 않고 프로덕션에 들어갑니다. 다른 함수는 일정 시간 동안 호출되지 않으며 원인과 상관없이 프로덕션에서 결국 실패합니다.
**이 모범 사례 수립의 이점:** 변경 사항을 조기에 테스트하고 검증함으로써 최소화된 비용으로 문제를 해결하고 고객에게 미치는 영향을 제한할 수 있습니다. 배포 전에 테스트하면 오류 도입을 최소화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 변경 사항 테스트 및 확인: 개발, 테스트, 프로덕션 등의 모든 수명 주기 단계에서 변경 사항을 테스트하고 결과를 확인해야 합니다. 테스트 결과를 사용하여 새 기능을 확인하고 배포 실패의 위험과 영향을 완화합니다. 테스트 및 확인을 자동화하면 검토의 일관성을 보장하고, 수동 프로세스로 인해 발생하는 오류를 줄이고, 작업량을 줄일 수 있습니다.
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild를 위한 로컬 빌드 지원](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
## 리소스
**관련 문서:**
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild를 위한 로컬 빌드 지원](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/)
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
# OPS05-BP03 구성 관리 시스템 사용
구성 관리 시스템을 사용하면 구성을 변경하고 변경 사항을 추적할 수 있습니다. 이러한 시스템에서는 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업량을 줄일 수 있습니다.
정적 구성 관리는 리소스를 초기화할 때 리소스 수명 주기 전체에 걸쳐 일관성을 유지할 것으로 예상되는 값을 설정합니다. 예를 들어, 인스턴스의 웹 또는 애플리케이션 서버의 구성을 설정하거나 AWS 서비스 구성을 정의하는 작업이 포함됩니다( [AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) 내에서 또는 [AWS CLI](https://aws.amazon.com/cli/)를 통해).
동적 구성 관리는 초기화 시 리소스 수명 주기 동안 변경될 수 있거나 변경될 것으로 예상되는 값을 설정합니다. 예를 들어, 구성 변경을 통해 코드의 기능을 활성화하도록 기능 전환을 설정하거나, 인시던트 중에 로그 세부 정보 수준을 변경하여 더 많은 데이터를 캡처하고 나서 인시던트 이후에 다시 변경함으로써 불필요한 로그와 관련 비용이 발생하지 않도록 할 수 있습니다.
인스턴스, 컨테이너, 서버리스 기능 또는 디바이스에서 실행 중인 애플리케이션에 동적 구성을 적용한 경우 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 를 사용하여 환경 전반에 걸쳐 이를 관리하고 배포할 수 있습니다.
AWS에서는 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 를 사용하여 계정과 리전 전체에서 AWS 리소스 구성을 [계속해서 모니터링할 수 있습니다](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html). 이를 통해 구성 이력을 추적하고, 구성 변경이 다른 리소스에 어떤 영향을 미치는지 이해하며, [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 및 [AWS Config 규정 준수 팩](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)을 사용하여 예상되거나 원하는 구성을 기준으로 감사할 수 있습니다.
AWS에서는 [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/) (예: AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)및 [AWS CodeStar](https://aws.amazon.com/codestar/))와 같은 서비스를 사용하여 CI/CD(지속적 통합/지속적 전달) 파이프라인을 구축할 수 있습니다.
변경 구현에 영향을 줄 수 있는 중요한 비즈니스나 운영 활동 또는 이벤트가 계획된 경우 변경 일정을 정하고 이를 추적합니다. 활동을 조정하여 이러한 계획에 관한 위험을 관리합니다. [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) 에서는 변경의 개시 또는 종료에 해당하는 시간 블록과 변경 이유를 문서화하고, 다른 AWS 계정과 [이 정보를 공유](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar-share.html) 할 수 있습니다(기타 AWS 계정 대상). AWS Systems Manager Automation 스크립트는 변경 일정 상태를 준수하도록 구성할 수 있습니다.
[AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) 를 사용하여 지정된 시간에 AWS SSM Run Command 또는 Automation 스크립트, AWS Lambda 호출 또는 AWS Step Functions 활동 수행을 예약할 수 있습니다. 이러한 활동이 평가에 포함될 수 있도록 변경 일정에서 활동을 표시합니다.
**일반적인 안티 패턴:**
+ 플릿 전체에서 웹 서버 구성을 수동으로 업데이트하면 업데이트 오류로 인해 여러 서버가 응답하지 않게 됩니다.
+ 여러 시간 동안 애플리케이션 서버 플릿을 수동으로 업데이트합니다. 변경 중 구성 불일치로 인해 예기치 않은 동작이 발생합니다.
+ 누군가가 보안 그룹을 업데이트했으며 웹 서버에 더 이상 액세스할 수 없습니다. 변경된 사항을 알지 못하면 문제를 조사하는 데 상당한 시간이 들어서 복구 시간이 늘어납니다.
**이 모범 사례 수립의 이점:** 구성 관리 시스템을 도입하면 변경 수행 및 추적을 위한 작업량과 수동 절차로 인한 오류 발생 빈도가 줄어듭니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 구성 관리 시스템 사용: 구성 관리 시스템을 사용하면 변경 사항을 추적/구현하고, 수동 프로세스로 인해 발생하는 오류를 줄이고, 작업량을 줄일 수 있습니다.
+ [인프라 구성 관리](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Config란 무엇입니까?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS CloudFormation 소개](https://youtu.be/Omppm_YUG2g)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [AWS OpsWorks란 무엇입니까?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk 소개](https://youtu.be/SrwxAScdyT0)
+ [AWS Elastic Beanstalk란 무엇입니까?](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
## 리소스
**관련 문서:**
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS OpsWorks](https://aws.amazon.com/opsworks/)
+ [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)
+ [인프라 구성 관리](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS Config란 무엇입니까?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Elastic Beanstalk란 무엇입니까?](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [AWS OpsWorks란 무엇입니까?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html)
**관련 동영상:**
+ [AWS CloudFormation 소개](https://youtu.be/Omppm_YUG2g)
+ [AWS Elastic Beanstalk 소개](https://youtu.be/SrwxAScdyT0)
# OPS05-BP04 빌드 및 배포 관리 시스템 사용
빌드 및 배포 관리 시스템을 사용합니다. 이러한 시스템에서는 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업량을 줄일 수 있습니다.
AWS에서는 다음과 같은 서비스를 사용하여 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 구축할 수 있습니다. [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/) (예: AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) 및 [AWS CodeStar](https://aws.amazon.com/codestar/))는 SAP NetWeaver Guide Finder 및 SAP NetWeaver Security Guide를 참조하세요.
**일반적인 안티 패턴:**
+ 개발 시스템에서 코드를 컴파일한 후 실행 파일을 프로덕션 시스템에 복사하면 실행 파일이 시작되지 않습니다. 로컬 로그 파일은 누락된 종속성으로 인해 실패했음을 나타냅니다.
+ 개발 환경에서 새로운 기능을 사용하여 애플리케이션을 성공적으로 빌드하고 코드를 품질 보증(QA) 팀에 제공합니다. 정적 자산이 누락되어 QA에 실패합니다.
+ 금요일에는 많은 노력을 기울이고 새로 코딩된 기능을 포함하여 개발 환경에서 수동으로 애플리케이션을 성공적으로 빌드했습니다. 월요일에는 애플리케이션을 성공적으로 빌드할 수 있는 단계를 반복할 수 없습니다.
+ 새 릴리스에 대해 생성한 테스트를 수행합니다. 그리고 다음 주에 테스트 환경을 설정하고 모든 기존 통합 테스트를 수행한 후 성능 테스트를 수행합니다. 새 코드는 용인할 수 없는 성능 영향을 미치므로 재개발한 후 다시 테스트해야 합니다.
**이 모범 사례 수립의 이점:** 빌드 및 배포 활동을 관리하는 메커니즘을 제공하여 반복적인 작업 수행을 위한 작업량을 줄이고, 팀원들이 고가치 창조 작업에 집중할 수 있게 하고, 수동 절차에서 발생하는 오류의 도입을 제한할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 빌드 및 배포 관리 시스템 사용: 빌드 및 배포 관리 시스템을 사용하면 변경 사항을 추적/구현하고, 수동 프로세스로 인해 발생하는 오류와 작업량을 줄일 수 있습니다. 코드 체크 인에서 빌드, 테스트, 배포 및 확인까지의 전체 통합 및 배포 파이프라인을 완전히 자동화합니다. 이렇게 하면 리드 시간을 단축하고 변경을 더 자주 수행할 수 있으며 작업량을 줄일 수 있습니다.
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**관련 동영상:**
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS05-BP05 패치 관리 수행
패치 관리를 수행하면 기능을 확인하고, 문제를 해결하고, 거버넌스 규정 준수 상태를 유지할 수 있습니다. 그리고 패치 관리를 자동화하면 수동 프로세스에서 발생하는 오류와 패치를 위한 작업량을 줄일 수 있습니다.
패치 및 취약성 관리는 이점 관리 및 위험 관리 활동의 일부입니다. 변경이 불가능한 인프라를 보유하고 검증된 정상 상태의 워크로드를 배포하는 것이 좋습니다. 이 방식을 실현할 수 없으면 남은 방법은 패치를 적용하는 것입니다.
취약성을 없애기 위해 머신 이미지, 컨테이너 이미지 또는 Lambda [사용자 지정 런타임 및 추가 라이브러리](https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html) 를 업데이트하는 것도 패치 관리에 속합니다. Linux 또는 Windows Server용 [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 다음을 사용하여 (AMI)에 대한 업데이트를 관리해야 합니다. [EC2 Image Builder](https://aws.amazon.com/image-builder/). 기존 파이프라인과 함께 [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 를 사용하여 [Amazon ECS 이미지](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) 및 [Amazon EKS 이미지](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html)를 관리할 수 있습니다. AWS Lambda에는 [버전](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 관리 기능이 있습니다.
패치는 먼저 안전한 환경에서 테스트를 거치지 않고는 프로덕션 환경에서 수행해서는 안 됩니다. 패치는 운영 또는 비즈니스 성과를 지원하는 경우에만 적용해야 합니다. AWS에서는 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 를 사용하여 관리형 시스템에 패치를 적용하는 프로세스를 자동화하고 다음을 사용하여 이 활동을 예약할 수 있습니다. [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html).
**일반적인 안티 패턴:**
+ 2시간 내에 최신 보안 패치를 모두 적용해야 하는데 애플리케이션과 패치가 호환되지 않아 여러 번 중단될 수 있습니다.
+ 패치가 적용되지 않은 라이브러리는 알 수 없는 당사자가 워크로드에 액세스하기 위해 해당 라이브러리의 취약성을 이용하므로 의도하지 않은 결과를 초래합니다.
+ 개발자에게 알리지 않고 개발자 환경에 자동으로 패치를 적용합니다. 개발자가 환경이 예상대로 작동하지 않는다는 불만을 여러 번 제기합니다.
+ 영구 인스턴스에서 자체 상용 소프트웨어에 패치를 적용하지 않았습니다. 소프트웨어에 문제가 있어서 공급자에게 문의하면 해당 버전이 지원되지 않으며 지원을 받으려면 특정 수준으로 패치해야 한다는 답을 듣습니다.
+ 사용한 암호화 소프트웨어에 대해 최근에 릴리스된 패치의 성능이 크게 향상되었습니다. 패치가 적용되지 않은 시스템에 성능 문제가 있습니다.
**이 모범 사례 정립의 이점:** 패치 적용 기준 및 환경 전체에 배포를 위한 방법론을 포함하여 패치 관리 프로세스를 설정하면 이러한 프로세스의 이점을 실현하고 그 영향을 제어할 수 있습니다. 이를 통해 원하는 기능을 도입하고, 문제를 제거하고, 거버넌스를 지속적으로 준수할 수 있습니다. 패치 관리 시스템 및 자동화를 구현하여 패치 배포를 위한 작업량을 줄이고 수동 프로세스로 인한 오류를 제한합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 패치 관리: 원하는 기능을 생성하고 거버넌스 정책과 공급업체 지원 요구 사항을 준수하는 상태를 유지할 수 있도록 시스템에 패치를 적용하여 문제를 해결합니다. 변경 불가능한 시스템에서는 원하는 결과를 달성할 수 있도록 설정된 적절한 패치를 배포합니다. 패치 관리 메커니즘을 자동화하면 패치에 걸리는 시간, 수동 프로세스에서 발생하는 오류 및 패치를 위한 작업량을 줄일 수 있습니다.
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
## 리소스
**관련 문서:**
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
**관련 동영상:**
+ [AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [운영 설계를 염두에 두세요](https://youtu.be/uh19jfW7hw4)
**관련 예시:**
+ [Well-Architected 랩 - 인벤토리 및 패치 관리](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
# OPS05-BP06 설계 표준 공유
여러 팀이 모범 사례를 공유하면 표준에 대한 인지도를 높이고 개발 작업의 이점을 극대화할 수 있습니다.
AWS에서는 코드 방법론을 사용해 애플리케이션, 컴퓨팅, 인프라 및 운영을 정의하고 관리할 수 있습니다. 따라서 기능을 쉽게 릴리스, 공유 및 도입할 수 있습니다.
많은 AWS 서비스와 리소스는 여러 계정 간에 공유가 가능하도록 설계되어 있으므로, 만들어진 자산과 파악한 정보를 여러 팀이 공유할 수 있습니다. 예를 들어 [CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) 리포지토리, [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) 함수, [Amazon S3 버킷](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/) 및 [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 을 특정 계정과 공유할 수 있습니다.
새 리소스 또는 업데이트를 게시할 때는 Amazon SNS를 사용하여 다음을 제공합니다. [교차 계정 알림](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html). 구독자는 Lambda를 사용하여 새 버전을 얻을 수 있습니다.
조직에 공유 표준이 적용되면 팀 활동을 지원하기 위해 표준에 대한 추가, 변경 및 예외 처리를 요청하는 메커니즘을 갖추어야 합니다. 이 옵션이 없으면 표준이 혁신의 제약 요인이 됩니다.
**일반적인 안티 패턴:**
+ 조직 내 다른 개발 팀과 마찬가지로 자체 사용자 인증 메커니즘을 생성했습니다. 사용자는 액세스하려는 시스템의 각 부분에 대해 별도의 자격 증명 세트를 유지해야 합니다.
+ 조직 내 다른 개발 팀과 마찬가지로 자체 사용자 인증 메커니즘을 생성했습니다. 조직에 충족해야 하는 새로운 규정 준수 요구 사항이 부여됩니다. 모든 개별 개발 팀은 이제 새로운 요구 사항을 구현하기 위해 리소스를 투자해야 합니다.
+ 조직 내 다른 개발 팀과 마찬가지로 자체 화면 레이아웃을 생성했습니다. 사용자가 일관되지 않은 인터페이스를 탐색하는 데 어려움을 겪고 있습니다.
**이 모범 사례 정립의 이점:** 공유 표준을 사용하여 모범 사례 도입을 지원하고 표준이 여러 애플리케이션 또는 조직의 요구 사항을 충족하는 개발 작업의 이점을 극대화합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 설계 표준 공유: 팀 전반에 걸쳐 기존 모범 사례, 설계 표준, 체크리스트, 운영 절차 및 지침과 거버넌스 요구 사항을 공유하면 복잡한 작업을 줄이고 개발 작업의 이점을 극대화할 수 있습니다. 지속적인 개선 및 혁신을 지원하기 위해 설계 표준에 대한 변경 사항, 추가 및 예외를 요청할 절차가 있는지 확인합니다. 팀이 게시된 콘텐츠를 활용하고 재작업 및 불필요한 작업을 제한할 수 있게 해당 콘텐츠를 지속적으로 확인하도록 합니다.
+ [AWS 환경에 대한 액세스 위임](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
+ [AWS CodeCommit 리포지토리 공유](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [간편한 AWS Lambda 함수 인증](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [특정 AWS 계정와 AMI 공유](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [AWS CloudFormation Designer URL을 사용한 Speed Template 공유](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [Amazon SNS에서 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
## 리소스
**관련 문서:**
+ [간편한 AWS Lambda 함수 인증](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [AWS CodeCommit 리포지토리 공유](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [특정 AWS 계정와 AMI 공유](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [AWS CloudFormation Designer URL을 사용한 Speed Template 공유](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [Amazon SNS에서 AWS Lambda 사용](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
**관련 동영상:**
+ [AWS 환경에 대한 액세스 위임](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
# OPS05-BP07 코드 품질 개선을 위한 사례 구현
코드 품질을 개선하고 결함을 최소화하는 사례를 구현합니다. 테스트 중심 개발, 코드 검토, 표준 도입 등을 몇 가지 예로 들 수 있습니다.
AWS에서는 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 와 같은 서비스를 파이프라인과 통합하여 [프로그램 분석과 기계 학습을 통해](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/how-codeguru-reviewer-works.html) 잠재적인 코드 및 보안 문제를 자동으로 식별할 수 있습니다. CodeGuru에서는 이러한 문제를 해결하기 위한 AWS 모범 사례를 구현하는 권장 방법을 안내합니다.
**일반적인 안티 패턴:**
+ 기능을 더 빨리 테스트할 수 있도록 표준 입력 삭제 라이브러리를 통합하지 않기로 결정했습니다. 테스트 후 라이브러리 통합을 완료해야 함을 잊고 코드를 커밋합니다.
+ 처리 중인 데이터 세트에 대한 경험이 적고 데이터 세트에 존재할 수 있는 일련의 엣지 케이스가 있음을 인식하지 못합니다. 이러한 엣지 케이스는 구현한 코드와 호환되지 않습니다.
**이 모범 사례 수립의 이점:** 코드 품질 개선을 위한 사례를 도입하여 프로덕션에서 발생하는 문제를 최소화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 코드 품질 개선을 위한 사례 구현: 코드 품질을 개선하고 결함 및 결함이 배포될 위험을 최소화하는 사례를 구현합니다. 테스트 중심 개발, 페어 프로그래밍, 코드 검토, 표준 도입 등을 예로 들 수 있습니다.
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
## 리소스
**관련 문서:**
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
# OPS05-BP08 여러 환경 사용
여러 환경을 사용하여 워크로드를 실험, 개발 및 테스트합니다. 프로덕션 환경에 배포하는 단계에 가까워질수록 제어 수준을 높이면 배포되었을 때 워크로드가 의도한 대로 작동할 것이라는 신뢰성을 높일 수 있습니다.
**일반적인 안티 패턴:**
+ 공유 개발 환경에서 개발을 수행하고 있으며 다른 개발자가 코드 변경 사항을 덮어씁니다.
+ 공유 개발 환경에 대한 제한적인 보안 제어로 인해 새로운 서비스와 기능을 실험할 수 없습니다.
+ 프로덕션 시스템에서 로드 테스트를 수행하고 사용자를 중단시킵니다.
+ 프로덕션 환경에서 데이터 손실을 일으키는 심각한 오류가 발생했습니다. 데이터 손실이 어떻게 발생했는지 파악하고 다시 발생하지 않도록 프로덕션 환경에서 데이터 손실을 일으키는 조건을 재현하려고 합니다. 테스트 중 추가 데이터 손실을 방지하기 위해 사용자가 애플리케이션을 이용할 수 없도록 해야 합니다.
+ 멀티 테넌트 서비스를 운영 중이며 전용 환경에 대한 고객 요청을 지원할 수 없습니다.
+ 항상 테스트하지 못할 수 있지만, 테스트할 때는 프로덕션 환경에서 해야 합니다.
+ 단일 환경의 단순성이 환경 내 변경 사항의 영향 범위를 재정의합니다.
**이 모범 사례 정립의 이점:** 여러 환경을 배포하여 개발자 또는 사용자 커뮤니티 간에 충돌을 일으키지 않고 여러 동시 개발, 테스트 및 프로덕션 환경을 지원할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 여러 환경 사용: 실험이 가능한 최소한의 제어 기능이 있는 샌드박스 환경을 개발자에게 제공합니다. 개별 개발 환경을 제공하면 병렬 작업이 가능하므로 개발을 더 빠르게 진행할 수 있습니다. 프로덕션 환경과 인접한 환경에는 더욱 엄격한 제어 기능을 구현하여 개발자가 혁신을 이룰 수 있도록 합니다. 코드형 인프라 및 구성 관리 시스템을 사용하여 프로덕션 환경의 제어 기능과 일치하는 방식으로 구성된 환경을 배포합니다. 그러면 배포된 시스템이 정상적으로 작동합니다. 사용되고 있지 않은 환경은 유휴 리소스 관련 비용이 발생하지 않도록 해제합니다. 예를 들어 개발 시스템은 야간 시간과 주말에 해제합니다. 로드 테스트 시에는 올바른 결과를 얻을 수 있도록 프로덕션 환경과 동일한 환경을 배포합니다.
+ [AWS CloudFormation란 무엇입니까?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS Lambda를 사용하여 Amazon EC2 인스턴스를 정기적으로 중지 및 시작하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
## 리소스
**관련 문서:**
+ [AWS Lambda를 사용하여 Amazon EC2 인스턴스를 정기적으로 중지 및 시작하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/)
+ [AWS CloudFormation란 무엇입니까?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# OPS05-BP09 되돌릴 수 있는 작은 단위의 변경 내용 자주 적용
되돌릴 수 있는 소규모 변경 작업을 자주 수행하면 변경의 영향과 범위가 감소합니다. 이렇게 하면 문제를 더 빠르고 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용할 수 있습니다.
**일반적인 안티 패턴:**
+ 분기별로 애플리케이션의 새 버전을 배포합니다.
+ 데이터베이스 스키마를 자주 변경합니다.
+ 수동 인 플레이스 업데이트를 수행하여 기존 설치 및 구성을 덮어씁니다.
**이 모범 사례 수립의 이점:** 작은 변경 사항을 자주 배포하여 개발 작업의 이점을 더 빠르게 파악합니다. 변경 사항이 작으면 의도하지 않은 결과가 있는지 파악하기가 훨씬 더 쉽습니다. 변경 사항을 되돌릴 수 있는 경우 복구가 간소화됨에 따라 변경 사항을 구현할 위험이 적습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 되돌릴 수 있는 작은 단위의 변경 내용 자주 적용: 되돌릴 수 있는 작은 단위의 변경 내용을 자주 적용하면 변경의 범위와 그로 인한 영향을 줄일 수 있습니다. 이렇게 하면 문제를 더 빠르고 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용할 수 있습니다. 또한 업무에 유용한 기능을 더 빠르게 제공할 수 있습니다.
# OPS05-BP10 통합 및 배포 완전 자동화
워크로드 빌드, 배포 및 테스트를 자동화합니다. 이렇게 하면 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업을 줄일 수 있습니다.
메타데이터를 [리소스 태그](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 및 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 을 통해 적용하고, 일관된 [태깅 전략](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 을 시행하면 리소스를 식별할 수 있습니다. 리소스에 조직, 비용 회계, 액세스 제어에 대한 리소스에 태그를 지정하여 자동화된 운영 활동을 실행할 대상을 설정합니다.
**일반적인 안티 패턴:**
+ 금요일에는 기능 브랜치에 대한 새 코드 작성을 마칩니다. 월요일에는 코드 품질 테스트 스크립트와 각 단위 테스트 스크립트를 실행한 후 예정된 다음 릴리스를 위해 코드를 체크인합니다.
+ 프로덕션 환경에서 많은 고객에게 영향을 미치는 중요한 문제에 대한 수정을 코딩해야 합니다. 수정 사항을 테스트한 후 코드 및 이메일 변경 관리를 커밋하여 프로덕션에 배포하기 위한 승인을 요청합니다.
**이 모범 사례 수립의 이점:** 자동화된 빌드 및 배포 관리 시스템을 구현하면 수동 프로세스로 인한 오류와 변경 사항 배포를 위한 작업이 줄어 팀원이 비즈니스 가치를 제공하는 데 집중할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 빌드 및 배포 관리 시스템 사용: 빌드 및 배포 관리 시스템을 사용하면 변경 사항을 추적/구현하고, 수동 프로세스로 인해 발생하는 오류와 작업량을 줄일 수 있습니다. 코드 체크 인에서 빌드, 테스트, 배포 및 확인까지의 전체 통합 및 배포 파이프라인을 완전히 자동화합니다. 이렇게 하면 리드 시간을 단축하고 변경을 더 자주 수행할 수 있으며 작업량을 줄일 수 있습니다.
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**관련 동영상:**
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS 6 배포 위험을 어떻게 최소화하고 있습니까?
품질과 관련한 피드백을 빠르게 제공하며, 적절한 성과를 달성하는 데 도움이 되지 않는 변경을 수행한 경우 신속하게 복구할 수 있는 방식을 도입합니다. 이러한 사례를 사용하면 변경 사항 배포로 인해 발생하는 문제의 영향을 완화할 수 있습니다.
**Topics**
+ [OPS06-BP01 변경이 적절하지 못한 경우에 대한 계획 수립](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 변경 사항 테스트 및 확인](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 배포 관리 시스템 사용](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 제한된 배포를 사용하여 테스트](ops_mit_deploy_risks_test_limited_deploy.md)
+ [OPS06-BP05 병렬 환경을 사용하여 배포](ops_mit_deploy_risks_deploy_to_parallel_env.md)
+ [OPS06-BP06 작게 자주 발생하고 되돌릴 수 있는 변경 내용 배포](ops_mit_deploy_risks_freq_sm_rev_chg.md)
+ [OPS06-BP07 통합 및 배포 완전 자동화](ops_mit_deploy_risks_auto_integ_deploy.md)
+ [OPS06-BP08 테스트 및 롤백 자동화](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 변경이 적절하지 못한 경우에 대한 계획 수립
변경을 수행했는데 적절한 성과를 달성하는 데 도움이 되지 않는다면 알려진 정상 상태로 되돌릴 수 있는 계획을 세우거나 프로덕션 환경에서 관련 문제를 해결합니다. 이와 같이 준비를 하면 문제에 더욱 신속하게 대응함으로써 복구 시간을 단축할 수 있습니다.
**일반적인 안티 패턴:**
+ 배포를 수행했으며 애플리케이션이 불안정해졌지만 시스템에 활성 사용자가 있는 것 같습니다. 변경 사항을 롤백하고 활성 사용자에게 영향을 줄 것인지 아니면 사용자에게 영향을 줄 수 있음을 알고 변경 사항을 롤백할 때까지 기다려야 합니다.
+ 라우팅을 변경한 후에는 새 환경에 액세스할 수 있지만, 서브넷 중 하나에 연결할 수 없게 됩니다. 모든 것을 롤백할지 아니면 액세스할 수 없는 서브넷을 수정할지 결정해야 합니다. 이러한 결정을 내리는 동안 서브넷에는 계속 연결할 수 없습니다.
**이 모범 사례 수립의 이점:** 계획을 수립하면 변경에 실패하여 발생하는 평균 복구 시간(MTTR)이 줄어들어 최종 사용자에게 미치는 영향을 완화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 변경이 적절하지 못한 경우에 대한 계획 수립: 변경을 수행했는데 적절한 성과를 달성하는 데 도움이 되지 않는다면 알려진 정상 상태로 되돌릴 수 있는(변경 사항 롤백) 계획을 세우거나 프로덕션 환경에서 관련 문제를 해결합니다(변경 사항 롤포워드). 배포 실패 시 롤백할 수 없는 변경 사항이 확인되면 해당 변경 사항을 커밋하기 전에 적절한 판단에 따라 조치를 결정합니다.
# OPS06-BP02 변경 사항 테스트 및 확인
수명 주기의 모든 단계에서 변경 사항을 테스트하고 결과를 검증하여 새 기능을 확인하고 배포 실패의 영향과 위험을 최소화합니다.
AWS에서는 실험과 테스트의 위험, 작업량 및 비용을 줄일 수 있는 임시 병렬 환경을 생성할 수 있습니다. 이러한 환경의 배포를 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 을 사용하여 자동화하면 임시 환경을 일관되게 구현할 수 있습니다.
**일반적인 안티 패턴:**
+ 애플리케이션에 새로운 기능을 배포합니다. 기능이 작동하지 않습니다. 모릅니다.
+ 인증서를 업데이트합니다. 잘못된 구성 요소에 실수로 인증서를 설치합니다. 모릅니다.
**이 모범 사례 정립의 이점:** 배포 후 변경 사항을 테스트하고 확인하면 문제를 조기에 식별하여 고객에게 미치는 영향을 완화할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 변경 사항 테스트 및 확인: 개발, 테스트, 프로덕션 등 수명 주기의 모든 단계에서 변경 사항을 테스트하고 결과를 검증하여 새 기능을 확인하고 배포 실패의 영향과 위험을 최소화합니다.
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [AWS Cloud9란 무엇입니까?](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
+ [코드 전달 전에 AWS CodeDeploy를 로컬로 테스트 및 디버깅하는 방법](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
## 리소스
**관련 문서:**
+ [AWS Cloud9](https://aws.amazon.com/cloud9/)
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [코드 전달 전에 AWS CodeDeploy를 로컬로 테스트 및 디버깅하는 방법](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [AWS Cloud9란 무엇입니까?](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
# OPS06-BP03 배포 관리 시스템 사용
배포 관리 시스템을 사용하여 변경을 추적하고 구현합니다. 이렇게 하면 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업을 줄일 수 있습니다.
AWS에서는 [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/) (예: AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)및 [AWS CodeStar](https://aws.amazon.com/codestar/))와 같은 서비스를 사용하여 지속적 통합/지속적 배포(CI/CD) 파이프라인을 구축할 수 있습니다.
**일반적인 안티 패턴:**
+ 플릿 전체에서 애플리케이션 서버에 대한 업데이트를 수동으로 배포하면 업데이트 오류로 인해 여러 서버가 응답하지 않게 됩니다.
+ 여러 시간 동안 애플리케이션 서버 플릿에 수동으로 배포합니다. 변경 중 버전 불일치로 인해 예기치 않은 동작이 발생합니다.
**이 모범 사례 수립의 이점:** 배포 관리 시스템을 도입하면 변경 사항 배포를 위한 작업량과 수동 절차로 인한 오류 빈도가 줄어듭니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 관리 시스템 사용: 배포 관리 시스템을 사용하여 변경을 추적하고 구현합니다. 이렇게 하면 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업량을 줄일 수 있습니다. 코드 체크 인에서 테스트, 배포 및 확인까지의 전체 통합 및 배포 파이프라인을 자동화합니다. 이렇게 하면 리드 시간을 단축하고 변경을 더 자주 수행할 수 있으며 작업량을 더욱 줄일 수 있습니다.
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy란 무엇인가요?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk란 무엇입니까?](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [Amazon API Gateway란 무엇입니까?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
## 리소스
**관련 문서:**
+ [AWS CodeDeploy 사용 설명서](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS 개발자 도구](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy란 무엇인가요?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk란 무엇입니까?](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)
+ [Amazon API Gateway란 무엇입니까?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
**관련 동영상:**
+ [AWS를 사용한 고급 연속 딜리버리 기술의 심층 분석](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
# OPS06-BP04 제한된 배포를 사용하여 테스트
전체 배포를 진행하기 전에 기존 시스템과 함께 제한된 배포를 사용해 테스트를 진행하여 원하는 결과를 달성할 수 있는지를 확인합니다. 예를 들어 Canary 배포 테스트나 원박스 배포를 사용합니다.
**일반적인 안티 패턴:**
+ 실패한 변경 사항을 모든 프로덕션에 한 번에 배포합니다. 모릅니다.
**이 모범 사례 정립의 이점:** 제한된 배포 후 변경 사항을 테스트하고 확인하면 고객에게 미치는 영향을 최소화하면서 문제를 조기에 식별하여 고객에게 미치는 영향을 더욱 완화할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 제한된 배포를 사용한 테스트: 전체 배포를 진행하기 전에 기존 시스템과 함께 제한된 배포를 사용하여 테스트를 진행하고 원하는 결과를 달성할 수 있는지를 확인합니다. 예를 들어 Canary 배포 테스트나 원박스 배포를 사용합니다.
+ [AWS CodeDeploy 사용 설명서](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk를 통한 블루/그린 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary 릴리스 배포 설정](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy에서 배포 구성 사용](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
## 리소스
**관련 문서:**
+ [AWS CodeDeploy 사용 설명서](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk를 통한 블루/그린 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary 릴리스 배포 설정](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy에서 배포 구성 사용](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
# OPS06-BP05 병렬 환경을 사용하여 배포
병렬 환경에 변경 사항을 구현한 다음 새 환경으로 이전합니다. 배포가 정상 완료되었음이 확인될 때까지는 이전 환경을 유지합니다. 이렇게 하면 만일의 경우 이전 환경을 롤백할 수 있으므로 복구 시간을 최소화할 수 있습니다.
**일반적인 안티 패턴:**
+ 기존 시스템을 수정하여 변경 가능한 배포를 수행합니다. 변경이 실패했음을 발견한 후에는 이전 버전 복원을 위해 시스템을 다시 수정하여 복구 시간을 연장해야 합니다.
+ 유지 관리 기간 동안 이전 환경을 폐기한 다음 새 환경 구축을 시작합니다. 절차를 몇 시간 진행한 상태에서 배포에서 복구할 수 없는 문제가 발견되었습니다. 매우 지친 상태에서 이전 배포 절차를 찾아 이전 환경을 다시 구축하기 시작해야 합니다.
**이 모범 사례 수립의 이점:** 병렬 환경을 사용하면 새 환경을 미리 배포하고 원하는 경우 해당 환경으로 전환할 수 있습니다. 새 환경이 성공적이지 않으면 원래 환경으로 다시 전환하여 신속하게 복구할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 병렬 환경을 사용한 배포: 병렬 환경에 변경 사항을 구현한 다음 새로운 환경으로 이전하거나 전환할 수 있습니다. 배포가 정상 완료되었음이 확인될 때까지는 이전 환경을 유지합니다. 이렇게 하면 만일의 경우 이전 환경을 롤백할 수 있으므로 복구 시간을 최소화할 수 있습니다. 예를 들어 블루/그린 배포를 수행하여 변경 불가능한 인프라를 사용합니다.
+ [AWS CodeDeploy에서 배포 구성 사용](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [AWS Elastic Beanstalk를 통한 블루/그린 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary 릴리스 배포 설정](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
## 리소스
**관련 문서:**
+ [AWS CodeDeploy 사용 설명서](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Elastic Beanstalk를 통한 블루/그린 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
+ [API Gateway Canary 릴리스 배포 설정](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeDeploy에서 배포 구성 사용](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
**관련 동영상:**
+ [AWS를 사용한 고급 연속 딜리버리 기술의 심층 분석](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
# OPS06-BP06 작게 자주 발생하고 되돌릴 수 있는 변경 내용 배포
되돌릴 수 있는 소규모 변경 작업을 자주 수행하면 변경의 범위가 감소합니다. 그러면 문제를 더 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용해 문제 해결 시간을 단축할 수 있습니다.
**일반적인 안티 패턴:**
+ 분기별로 애플리케이션의 새 버전을 배포합니다.
+ 데이터베이스 스키마를 자주 변경합니다.
+ 수동 인 플레이스 업데이트를 수행하여 기존 설치 및 구성을 덮어씁니다.
**이 모범 사례 정립의 이점:** 작은 변경 사항을 자주 배포하여 개발 작업의 이점을 더 빠르게 파악합니다. 변경 사항이 작으면 의도하지 않은 결과가 있는지 파악하기가 훨씬 더 쉽습니다. 변경 사항을 되돌릴 수 있는 경우 복구가 간소화됨에 따라 변경 사항을 구현할 위험이 적습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 되돌릴 수 있는 작은 단위의 변경 내용 자주 배포: 되돌릴 수 있는 작은 단위의 변경 내용을 자주 적용하면 변경 범위를 줄일 수 있습니다. 그러면 문제를 더 쉽게 해결할 수 있으며 변경 사항 롤백 옵션을 사용해 문제 해결 시간을 단축할 수 있습니다.
# OPS06-BP07 통합 및 배포 완전 자동화
워크로드 빌드, 배포 및 테스트를 자동화합니다. 이렇게 하면 수동 프로세스에서 발생하는 오류와 변경 사항 배포를 위한 작업을 줄일 수 있습니다.
메타데이터를 [리소스 태그](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) 및 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) 을 통해 적용하고, 일관된 [태깅 전략](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) 을 시행하면 리소스를 식별할 수 있습니다. 리소스에 조직, 비용 회계, 액세스 제어에 대한 리소스에 태그를 지정하여 자동화된 운영 활동을 실행할 대상을 설정합니다.
**일반적인 안티 패턴:**
+ 금요일에는 기능 브랜치에 대한 새 코드 작성을 마칩니다. 월요일에는 코드 품질 테스트 스크립트와 각 단위 테스트 스크립트를 실행한 후 예정된 다음 릴리스를 위해 코드를 체크인합니다.
+ 프로덕션 환경에서 많은 고객에게 영향을 미치는 중요한 문제에 대한 수정을 코딩해야 합니다. 수정 사항을 테스트한 후 코드 및 이메일 변경 관리를 커밋하여 프로덕션에 배포하기 위한 승인을 요청합니다.
**이 모범 사례 수립의 이점:** 자동화된 빌드 및 배포 관리 시스템을 구현하면 수동 프로세스로 인한 오류와 변경 사항 배포를 위한 작업이 줄어 팀원이 비즈니스 가치를 제공하는 데 집중할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 빌드 및 배포 관리 시스템 사용: 빌드 및 배포 관리 시스템을 사용하면 변경 사항을 추적/구현하고, 수동 프로세스로 인해 발생하는 오류와 작업량을 줄일 수 있습니다. 코드 체크 인에서 빌드, 테스트, 배포 및 확인까지의 전체 통합 및 배포 파이프라인을 완전히 자동화합니다. 이렇게 하면 리드 시간을 단축하고 변경을 더 자주 수행할 수 있으며 작업량을 줄일 수 있습니다.
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS를 사용한 고급 지속적 전달 기술 심층 분석](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
## 리소스
**관련 문서:**
+ [AWS CodeDeploy에서의 샘플 블루/그린 배포 시도](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [AWS CodeBuild란 무엇입니까?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**관련 동영상:**
+ [소프트웨어 개발을 위한 지속적 통합 모범 사례](https://www.youtube.com/watch?v=GEPJ7Lo346A)
+ [AWS를 사용한 고급 지속적 전달 기술 심층 분석](https://www.youtube.com/watch?v=Lrrgd0Kemhw)
+ [AWS CodeDeploy 소개 - Amazon Web Services를 통해 자동화된 소프트웨어 배포](https://www.youtube.com/watch?v=Wx-ain8UryM)
+ [Slalom: AWS의 서버리스 애플리케이션용 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE)
# OPS06-BP08 테스트 및 롤백 자동화
배포된 환경의 테스트를 자동화하여 원하는 성과를 달성할 수 있는지를 확인합니다. 원하는 결과를 달성할 수 없는 경우 알려진 정상 상태로 롤백하는 과정을 자동화하면 수동 프로세스에서 발생하는 오류를 줄이고 복구 시간을 최소화할 수 있습니다.
**일반적인 안티 패턴:**
+ 변경 사항을 워크로드에 배포합니다. 변경 사항이 완료되면 배포 후 테스트를 시작합니다. 작업이 완료되면 워크로드가 작동하지 않으며 고객 연결이 끊어짐을 알게 됩니다. 그런 다음 이전 버전으로 롤백을 시작합니다. 문제 감지에 시간이 오래 걸리면 수동 재배포에 의해 복구 시간이 연장됩니다.
**이 모범 사례 수립의 이점:** 배포 후 변경 사항을 테스트하고 검증하면 문제를 즉시 식별할 수 있습니다. 이전 버전으로 자동 롤백하면 고객에게 미치는 영향이 최소화됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 테스트 및 롤백 자동화: 배포된 환경에서 테스트를 자동화하여 원하는 성과를 달성할 수 있는지를 확인합니다. 원하는 결과를 달성할 수 없는 경우 알려진 정상 상태로 롤백하는 과정을 자동화하면 수동 프로세스에서 발생하는 오류를 줄이고 복구 시간을 최소화할 수 있습니다. 예를 들어 배포 후에 세부 통합 사용자 트랜잭션을 수행하여 결과를 확인한 후 트랜잭션이 실패했다면 변경을 롤백합니다.
+ [AWS CodeDeploy로 재배포 및 배포 롤백](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
## 리소스
**관련 문서:**
+ [AWS CodeDeploy로 재배포 및 배포 롤백](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
# OPS 7 귀사가 워크로드를 지원할 준비가 되어있는지 어떻게 알 수 있습니까?
워크로드, 프로세스, 절차 및 직원의 운영 준비 상태를 평가하여 워크로드와 관련된 운영 위험을 파악합니다.
**Topics**
+ [OPS07-BP01 직원의 역량 확보](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 일관된 방식으로 운영 준비 상태 검토](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 런북을 사용한 절차 수행](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 플레이북을 사용하여 문제 조사](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 정보에 입각하여 시스템 및 변경 사항 배포 결정](ops_ready_to_support_informed_deploy_decisions.md)
# OPS07-BP01 직원의 역량 확보
운영상의 요구 사항에 대해 지원하기 위해 적절한 수의 숙련된 인력이 있는지 확인하는 메커니즘을 확보합니다. 효과적인 지원을 유지하기 위해 필요한 경우 직원을 교육하고 직원의 역량을 조정합니다.
업무 대기 중인 인력을 포함하여 모든 활동을 다룰 수 있는 팀원을 충분히 보유해야 합니다. 팀이 워크로드, 운영 도구 및 AWS에 대한 교육을 성공적으로 이수하는 데 필요한 기술을 갖추었는지 확인합니다.
AWS에서는 [AWS 시작하기 리소스 센터](https://aws.amazon.com/getting-started/), [AWS 블로그](https://aws.amazon.com/blogs/), [AWS Online Tech Talks](https://aws.amazon.com/getting-started/), [AWS 이벤트 및 웨비나](https://aws.amazon.com/events/) 및 [AWS Well-Architected 랩과](https://wellarchitectedlabs.com/)같은 다양한 리소스를 제공합니다. 이러한 리소스에서는 팀을 대상으로 교육을 진행하는 데 활용할 수 있는 지침, 예제 및 자세한 연습 과정을 제공합니다. 또한 [AWS 교육 and Certification](https://aws.amazon.com/training/) 에서는 AWS 기초에 관한 자습형 디지털 과정을 통해 무료 교육을 제공합니다. 또한 팀의 AWS 기술 개발을 추가로 지원하기 위해 강사 주도형 교육에 등록할 수 있습니다.
**일반적인 안티 패턴:**
+ 사용 중인 플랫폼과 서비스를 지원하는 데 숙련된 팀원 없이 워크로드를 배포합니다.
+ 원하는 지원 시간 동안 팀원 없이 워크로드를 배포합니다.
+ 휴가를 갔거나 병가 중인 팀원이 있는 경우 지원을 위한 충분한 팀원 없이 워크로드를 배포합니다.
+ 워크로드를 지원하는 팀원이나 다른 워크로드에 대한 추가 영향을 검토하지 않고 추가 워크로드를 배포합니다.
**이 모범 사례 정립의 이점:** 숙련된 팀원이 있으면 워크로드를 효과적으로 지원할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 직원의 역량: 워크로드를 효과적으로 지원할 훈련을 받은 인력이 충분히 있는지 검증합니다.
+ 팀 규모: 직무 대기 중인 인력을 포함하여 운영 활동을 처리할 수 있는 팀원이 충분히 있는지 확인합니다.
+ 팀 역량: 팀원이 AWS, 워크로드 및 운영 도구에 대해 충분한 교육을 받고 직무를 수행할 수 있도록 합니다.
+ [AWS 이벤트 및 웨비나](https://aws.amazon.com/about-aws/events/)
+ [AWS 교육 and Certification 소개](https://aws.amazon.com/training/)
+ 역량 검토: 운영 조건 및 워크로드의 변화에 따라 팀 규모와 기술을 검토하여 운영 우수성을 유지할 수 있는 충분한 역량을 확보합니다. 팀 규모와 기술이 팀이 지원하는 워크로드의 운영 요구 사항과 일치하도록 조정합니다.
## 리소스
**관련 문서:**
+ [AWS 블로그](https://aws.amazon.com/blogs/)
+ [AWS 이벤트 및 웨비나](https://aws.amazon.com/about-aws/events/)
+ [AWS 시작하기 리소스 센터](https://aws.amazon.com/getting-started/)
+ [AWS Online Tech Talks](https://aws.amazon.com/getting-started/)
+ [AWS 교육 and Certification 소개](https://aws.amazon.com/training/)
**관련 예시:**
+ [Well-Architected 실습](https://wellarchitectedlabs.com/)
# OPS07-BP02 일관된 방식으로 운영 준비 상태 검토
ORR(운영 준비 상태 검토)을 사용하여 워크로드를 운영할 수 있는지 검증할 수 있습니다. ORR은 팀에서 워크로드를 안전하게 운영할 수 있는지 검증할 수 있도록 Amazon에서 개발한 메커니즘입니다. ORR은 요구 사항의 체크리스트를 사용한 검토 및 검사 프로세스입니다. ORR은 팀이 자체 워크로드를 인증하는 데 사용하는 셀프 서비스 경험입니다. ORR에는 다년간의 소프트웨어 구축을 통해 얻은 교훈을 바탕으로 한 모범 사례가 포함되어 있습니다.
ORR 체크리스트는 아키텍처 권장 사항, 운영 프로세스, 이벤트 관리 및 릴리스 품질로 구성되어 있습니다. 오류 수정(CoE) 프로세스는 이러한 항목을 위한 주요 동인입니다. 자체적인 인시던트 사후 분석을 통해 자체 ORR의 발전이 이루어져야 합니다. ORR은 모범 사례를 따르는 것 뿐만 아니라 이전에 경험한 이벤트의 재발을 방지하는 것도 포함됩니다. 마지막으로, 보안, 거버넌스 및 규정 준수 요구 사항 또한 ORR에 포함될 수 있습니다.
워크로드를 일반적인 사용 용도로 시작하기 전에 ORR을 실행한 다음 소프트웨어 개발 수명 주기 전반에 걸쳐 실행합니다. 시작 전에 ORR을 실행하면 워크로드를 안전하게 실행할 수 있는 역량이 향상됩니다. 모범 사례에서 벗어난 부분이 있는지 파악할 수 있도록 워크로드에서 ORR을 주기적으로 다시 실행합니다. 새로운 서비스 출시를 위한 ORR 체크리스트 및 주기적 검토를 위한 ORR을 준비해 둘 수 있습니다. 이렇게 하면 인시던트 사후 분석으로부터 얻은 교훈을 반영하고 포함할 수 있는 새로운 모범 사례를 항상 최신 상태로 유지할 수 있습니다. 클라우드 사용이 성숙해지면 아키텍처에 ORR 요구 사항을 기본으로 구축할 수 있습니다.
**원하는 결과:** 조직을 위한 모범 사례가 포함된 ORR 체크리스트를 보유합니다. 워크로드 시작 전에 ORR을 수행합니다. 워크로드 수명 주기 동안 ORR을 주기적으로 실행합니다.
**일반적인 안티 패턴:**
+ 운영 가능 여부를 알 수 없는 상태에서 워크로드를 시작합니다.
+ 워크로드의 시작을 인증하는 과정에 거버넌스 및 보안 요구 사항이 포함되어 있지 않습니다.
+ 워크로드를 주기적으로 재평가하지 않습니다.
+ 워크로드 시작 시 필요한 절차를 갖추고 있지 않습니다.
+ 여러 워크로드에서 동일한 근본 원인 실패가 반복됩니다.
**이 모범 사례 확립의 이점:**
+ 워크로드에 아키텍처, 프로세스 및 관리 모범 사례가 포함됩니다.
+ 얻은 교훈이 ORR 프로세스에 포함됩니다.
+ 워크로드 시작 시 필요한 절차가 갖춰져 있습니다.
+ 워크로드의 소프트웨어 수명 주기 전반에 걸쳐 ORR이 실행됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
ORR은 프로세스와 체크리스트로 이루어져 있습니다. ORR 프로세스는 조직에서 채택해야 하며 경영진 후원자가 지원해야 합니다. 최소한, 워크로드가 일반적인 사용을 시작하기 전에 ORR을 수행해야 합니다. 소프트웨어 개발 수명 주기 전반에 걸쳐 ORR을 실행하여 모범 사례나 새 요구 사항이 최신 상태로 포함되도록 해야 합니다. ORR 체크리스트에는 구성 항목, 보안 및 거버넌스 요구 사항, 조직의 모범 사례가 포함되어야 합니다. 시간이 지남에 따라 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)및 [AWS Control Tower 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)과 같은 서비스를 사용하여 모범 사례의 자동 탐지를 위해 ORR의 모범 사례를 가드레일에 구축할 수 있습니다.
**고객 사례**
몇 번의 프로덕션 인시던트 후 AnyCompany Retail은 ORR 프로세스를 구현하기로 했습니다. 이를 위해 모범 사례, 거버넌스 및 규정 준수 요구 사항, 그리고 중단으로부터 얻은 교훈을 통해 구성된 체크리스트를 구축했습니다. 새 워크로드를 시작하기 전에 ORR을 수행합니다. 모든 워크로드는 ORR 체크리스트에 추가되는 새로운 모범 사례 및 요구 사항을 통합하기 위해 모범 사례의 하위 집합이 포함된 연간 ORR을 수행합니다. 시간이 지나면서 AnyCompany Retail은 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 를 사용하여 일부 모범 사례를 탐지하고 ORR 프로세스의 속도를 높였습니다.
**구현 단계**
ORR에 대해 자세히 알아보려면 [ORR(운영 준비 상태 검토) 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)를 확인하세요. ORR 프로세스의 이력, 자체적인 ORR 사례를 구축하는 방법, ORR 체크리스트를 개발하는 방법에 대한 자세한 정보를 제공합니다. 다음 단계는 해당 문서의 축약 버전입니다. ORR이 무엇인지와 구축 방법을 심층적으로 이해하려면 이 백서를 읽어보시는 것이 좋습니다.
1. 보안, 운영 및 개발 담당자를 포함한 핵심 이해 관계자를 한 자리에 모읍니다.
1. 각 이해 관계자가 한 가지 이상의 요구 사항을 제공하도록 합니다. 첫 반복의 경우 항목의 수를 30개 이하로 제한합니다.
+ [부록 B: ORR 질문 예시](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) 는 ORR(운영 준비 상태 검토) 백서에 수록되어 있으며 시작 시 사용 가능한 샘플 질문이 포함되어 있습니다.
1. 요구 사항을 스프레드시트에 수집합니다.
+ 이때 [사용자 지정 렌즈](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) ( [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 에 포함)를 사용하여 ORR을 개발하고 계정 및 AWS Organization 전체에서 이를 공유할 수 있습니다.
1. ORR을 수행할 하나의 워크로드를 식별합니다. 출시 전 워크로드나 내부 워크로드가 가장 좋습니다.
1. ORR 체크리스트를 실행하고 탐색 내용을 기록합니다. 완화 조치가 적용된 경우 탐색 결과가 좋지 않을 수 있습니다. 완화 조치가 부족한 탐색 결과에 대해서는 항목의 백로그에 이를 추가하고 시작 전에 구현합니다.
1. 시간이 지나는 동안 ORR 체크리스트에 모범 사례 및 요구 사항을 계속 추가합니다.
Enterprise Support를 이용하는 지원 고객은 기술 지원 관리자에게 [운영 준비 상태 검토 워크숍](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) 을 요청할 수 있습니다. 워크숍은 ORR 체크리스트 개발을 위한 대화형 *프로세스 뒤집기* 세션입니다.
**구현 계획의 작업 수준:** 높음. 조직에서 ORR 사례를 도입하려면 경영진의 후원과 이해 관계자의 승인이 필요합니다. 조직 전체의 의견을 받아 체크리스트를 구축 및 업데이트해야 합니다.
## 리소스
**관련 모범 사례:**
+ [OPS01-BP03 거버넌스 요구 사항 평가](ops_priorities_governance_reqs.md) – 거버넌스 요구 사항은 ORR 체크리스트에 매우 적합합니다.
+ [OPS01-BP04 규정 준수 요구 사항 평가](ops_priorities_compliance_reqs.md) – 규정 준수 요구 사항이 ORR 체크리스트에 포함되는 경우도 있습니다. 그 외에는 별도의 프로세스입니다.
+ [OPS03-BP07 리소스 팀 적절히 관리](ops_org_culture_team_res_appro.md) – 팀 역량은 ORR 요구 사항을 위한 좋은 후보입니다.
+ [OPS06-BP01 변경이 적절하지 못한 경우에 대한 계획 수립](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 롤백이나 롤포워드 계획은 워크로드를 시작하기 전에 수립해야 합니다.
+ [OPS07-BP01 직원의 역량 확보](ops_ready_to_support_personnel_capability.md) – 워크로드를 지원하려면 필수 인력이 있어야 합니다.
+ [SEC01-BP03 제어 목표 파악 및 검증](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 보안 제어 목표는 우수한 ORR 요구 사항을 수립하는 데 도움이 됩니다.
+ [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 재해 복구 계획은 ORR 요구 사항으로 적합합니다.
+ [COST02-BP01 조직 요구 사항에 따라 정책 개발](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 비용 관리 정책은 ORR 체크리스트에 포함하는 것이 좋습니다.
**관련 문서:**
+ [AWS Control Tower - AWS Control Tower의 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - 사용자 지정 렌즈](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Adrian Hornsby의 운영 준비 상태 검토 템플릿](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [ORR(운영 준비 상태 검토) 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**관련 동영상:**
+ [AWS Supports You \$1 효과적인 ORR(운영 준비 상태 검토) 구축](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**관련 예시:**
+ [샘플 ORR(운영 준비 상태 검토) 렌즈](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**관련 서비스:**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 런북을 사용한 절차 수행
*런북* 은 특정 결과를 달성하기 위해 문서화된 프로세스입니다. 런북은 누군가가 어떤 것을 수행하기 위해 따르는 일련의 단계로 구성됩니다. 런북은 항공 산업 초창기부터 운영에 사용되어 왔습니다. Amazon은 클라우드 운영 시 런북을 사용하여 위험을 줄이고 원하는 결과를 얻습니다. 가장 간단하게 표현하자면, 런북은 작업 완료를 위한 체크리스트입니다.
런북은 워크로드 운영을 위해 필수적인 부분입니다. 새로운 팀원의 온보딩부터 주요 릴리스의 배포에 이르기까지 런북은 사용자가 누구든 일관된 결과를 얻을 수 있는 코드화된 프로세스입니다. 런북 업데이트는 변경 관리 프로세스의 중요한 구성 요소이기 때문에 런북은 중앙 위치에서 게시되고 프로세스가 발전함에 따라 업데이트됩니다. 또한 오류 처리, 도구, 권한, 예외 및 문제 발생 시 에스컬레이션에 대한 지침도 포함해야 합니다.
조직이 성숙해지면 런북 자동화를 시작합니다. 간단하고 자주 사용하는 런북으로 시작합니다. 스크립팅 언어를 사용하여 단계를 자동화하거나 단계를 수행하기 쉽게 만듭니다. 처음 런북을 몇 개 자동화해 보면 더 복잡한 런북을 자동화하는 데 시간을 할애하게 될 것입니다. 시간이 흐르면 대부분의 런북이 자동화되어야 합니다.
**원하는 결과:** 팀에 워크로드 작업을 수행하기 위한 단계별 가이드 모음이 있습니다. 런북에는 원하는 결과, 필요한 도구, 권한 및 오류 처리 지침이 들어 있습니다. 런북은 중앙 위치에 저장해 두고 자주 업데이트합니다.
**일반적인 안티 패턴:**
+ 프로세스의 각 단계를 완료하기 위해 메모리를 사용합니다.
+ 체크리스트 없이 변경 사항을 수동으로 배포합니다.
+ 동일한 프로세스를 팀원 여러 명이 수행하지만 사용하는 단계와 결과가 다릅니다.
+ 런북이 시스템 변경 사항과 동기화되지 않고 자동화와 상관 없이 변경됩니다.
**이 모범 사례 확립의 이점:**
+ 수동 작업의 오류 발생률이 감소합니다.
+ 작업이 일관된 방식으로 수행됩니다.
+ 새로운 팀원이 작업 수행을 더 빨리 시작할 수 있습니다.
+ 런북을 자동화해 노력을 줄일 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
런북은 조직의 성숙도에 따라 여러 가지 형태일 수 있습니다. 최소한 단계별 텍스트 문서로 구성되어야 합니다. 원하는 결과가 명확하게 명시되어 있어야 합니다. 필요한 특수 권한 및 도구도 확실하게 기록해야 합니다. 오류 처리 및 문제 발생 시 에스컬레이션에 대한 자세한 지침을 제공합니다. 런북 소유자를 나열하고 런북을 중앙 위치에 게시합니다. 런북을 문서화하면 다른 팀원이 실행해보도록 하여 확인합니다. 절차가 발전하면 변경 관리 프로세스에 따라 런북을 업데이트합니다.
텍스트 런북은 조직이 성숙함에 따라 자동화해야 합니다. 또한 [AWS Systems Manager 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)등과 같은 서비스를 사용하여 일반 텍스트를 워크로드에 대해 실행할 수 있는 자동화로 변환할 수 있습니다. 이러한 자동화는 이벤트에 대응하여 실행해 워크로드 유지를 위한 운영 부담을 줄일 수 있습니다.
**고객 사례**
AnyCompany Retail은 소프트웨어를 배포하는 중 데이터베이스 스키마 업데이트를 수행해야 합니다. 클라우드 운영 팀은 데이터베이스 관리 팀과 협력하여 이러한 변경 사항을 수동으로 배포하기 위한 런북을 빌드했습니다. 이 런북에는 프로세스의 각 단계를 체크리스트 형식으로 나열되어 있습니다. 또한 문제 발생 시 오류 처리에 대한 섹션이 포함되어 있습니다. 팀은 내부 Wiki에 다른 런북과 함께 이 런북을 게시했습니다. 클라우드 운영 팀은 향후 스프린트에서 런북을 자동화할 계획입니다.
## 구현 단계
기존 문서 리포지토리가 없는 경우에는 버전 제어 리포지토리에서 런북 라이브러리 빌드를 시작하는 것이 좋습니다. 런북은 Markdown을 사용하여 빌드할 수 있습니다. 런북 빌드를 시작하는 데 사용할 수 있는 런북 템플릿 예시를 제공합니다.
```
# 런북 제목 ## 런북 정보 | 런북 ID | 설명 | 사용된 도구 | 특별 권한 | 런북 작성자 | 마지막 업데이트 | 에스컬레이션 POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | 런북 용도 원하는 결과 | 도구 | 권한 | 이름 | 2022-09-21 | 에스컬레이션 이름 | ## 단계 1 1단계 2. 2단계
```
1. 기존 문서 리포지토리 또는 Wiki가 없는 경우 버전 관리 시스템에서 새로운 버전 관리 리포지토리를 생성합니다.
1. 런북이 없는 프로세스를 파악합니다. 이상적인 프로세스는 반규칙적으로 수행되며 단계 수가 적고 장애 영향이 적은 프로세스입니다.
1. 문서 리포지토리에서 템플릿을 사용하여 새로운 Markdown 문서 초안을 작성합니다. 그런 다음 `런북 제목` 을 작성하고 `런북 정보 아래 필수 필드를 작성합니다`.
1. 첫 번째 단계를 시작하고 런북의 `단계` 부분을 작성합니다.
1. 팀원에게 런북을 제공하고 런북을 사용하여 단계를 확인하도록 합니다. 누락된 부분이 있거나 명확히 설명해야 할 부분이 있다면 런북을 업데이트합니다.
1. 내부 문서 저장소에 런북을 게시합니다. 게시한 다음 팀 및 다른 이해관계자에게 알립니다.
1. 시간이 흐르면 런북 라이브러리를 구축합니다. 라이브러리가 커지면 런북 자동화 작업을 시작합니다.
**구현 계획의 작업 수준:** 낮음. 런북의 최소 표준은 단계별 텍스트 가이드입니다. 런북 자동화는 구현 작업을 늘릴 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](ops_ops_model_def_proc_owners.md): 런북에는 런북 유지 관리를 담당하는 소유자가 있어야 합니다.
+ [OPS07-BP04 플레이북을 사용하여 문제 조사](ops_ready_to_support_use_playbooks.md): 런북과 플레이북은 서로 비슷하지만 런북에는 원하는 결과가 있다는 중요한 차이점이 있습니다. 대부분의 경우 플레이북이 근본 원인을 식별하면 런북이 트리거됩니다.
+ [OPS10-BP01 이벤트, 인시던트 및 문제 관리 프로세스 사용](ops_event_response_event_incident_problem_process.md): 런북은 적절한 이벤트, 인시던트, 문제 관리 방침의 일부입니다.
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md): 런북과 플레이북은 알림에 대응하기 위해 사용해야 합니다. 시간이 흐르면 이러한 대응은 자동화해야 합니다.
+ [OPS11-BP04 지식 관리 수행](ops_evolve_ops_knowledge_management.md): 런북 유지 관리는 지식 관리의 중요한 부분입니다.
**관련 문서:**
+ [자동화된 플레이북 및 런북을 사용하여 운영 우수성 달성](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: 런북을 사용한 작업](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [AWS 대규모 마이그레이션을 위한 마이그레이션 플레이북 - 작업 4: 마이그레이션 런북 개선](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [AWS Systems Manager 자동화 런북을 사용하여 운영 작업 해결](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**관련 동영상:**
+ [AWS re:Invent 2019: 런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드(SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS에서 IT 운영을 자동화하는 방법 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Systems Manager(으)로 스크립트 통합](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**관련 예시:**
+ [AWS Systems Manager: 자동화 시연](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: 최신 스냅샷 런북에서 루트 볼륨 복원](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Jupyter Notebook 및 CloudTrail Lake를 사용하여 AWS 인시던트 응답 런북 빌드](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab - 런북](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix - Jupyter Notebook의 런북 빌드를 위한 Python 라이브러리](https://github.com/Nurtch/rubix)
+ [Document Builder를 사용하여 사용자 지정 런북 만들기](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [Well-Architected 실습: 플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
**관련 서비스:**
+ [AWS Systems Manager 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 플레이북을 사용하여 문제 조사
플레이북은 인시던트를 조사하는 데 사용하는 단계별 지침입니다. 인시던트가 발생하면 플레이북을 사용하여 조사하고, 영향의 범위를 살펴보고, 근본 원인을 파악합니다. 플레이북은 배포 실패부터 보안 인시던트까지 다양한 시나리오에 사용됩니다. 대부분의 경우, 플레이북으로 근본 원인을 파악하고 런북을 사용하여 이를 완화합니다. 플레이북은 조직의 인시던트 대응 계획을 위한 필수 구성 요소입니다.
우수한 플레이북에는 몇 가지 주요 기능이 있으며 이를 통해 사용자에게 탐색 프로세스를 단계별로 안내합니다. 외부 관점에서 생각할 때, 인시던트를 진단하기 위해 어떤 단계를 따라야 할까요? 플레이북에 특수 도구나 승격된 권한이 필요한 경우 플레이북에서 이를 명확하게 정의합니다. 이해 관계자에게 조사 상황을 알리기 위한 커뮤니케이션 계획을 수립하는 것이 중요합니다. 근본 원인을 파악할 수 없는 경우에 대비한 에스컬레이션 계획도 있어야 합니다. 근본 원인이 파악되었다면 플레이북은 해결 방법을 설명하는 런북을 명시해야 합니다. 플레이북은 중앙 집중식으로 저장하고 정기적으로 유지 관리해야 합니다. 플레이북이 특정 알림에 사용되는 경우, 알림에 플레이북에 대한 포인터를 추가하여 팀에 제공해야 합니다.
조직이 성숙해지면 플레이북을 자동화합니다. 위험성이 낮은 인시던트를 다루는 플레이북으로 시작합니다. 스크립팅을 사용하여 검색 단계를 자동화합니다. 일반적인 근본 원인을 완화하는 데 사용할 수 있는 지원 런북을 반드시 갖추도록 합니다.
**원하는 결과:** 조직에 일반적인 인시던트를 위한 플레이북이 있습니다. 플레이북을 중앙 위치에 저장해 두고 팀원들이 사용할 수 있습니다. 플레이북이 자주 업데이트됩니다. 알려진 모든 근본 원인에 대한 지원 런북이 구축되어 있습니다.
**일반적인 안티 패턴:**
+ 인시던트를 조사하기 위한 표준 방식이 없습니다.
+ 팀원들이 기억이나 제도적 지식에 의존하여 배포 실패 문제를 해결합니다.
+ 새로운 팀원이 시행 착오를 거쳐 문제 조사 방법을 배웁니다.
+ 문제 조사의 모범 사례가 팀 내에서 공유되고 있지 않습니다.
**이 모범 사례 확립의 이점:**
+ 플레이북은 인시던트를 완화하는 데 큰 도움이 됩니다.
+ 다양한 팀원이 동일한 플레이북을 사용함으로써 일관적인 방법으로 근본 원인을 파악할 수 있습니다.
+ 알려진 근본 원인의 경우 이에 대비하여 개발된 런북을 통해 복구 시간을 앞당길 수 있습니다.
+ 플레이북을 통해 팀원들이 더 빨리 문제 해결에 참여할 수 있습니다.
+ 팀이 반복 가능한 플레이북을 통해 프로세스를 확장할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
플레이북의 구축 및 사용 방법은 조직의 성숙도에 따라 다릅니다. 클라우드가 처음인 경우 플레이북을 중앙 문서 리포지토리에 텍스트 형식으로 구축합니다. 조직이 성숙해지면서 Python과 같은 스크립팅 언어를 통해 플레이북을 반자동화할 수 있습니다. 이러한 스크립트를 Jupyter Notebook 내부에서 실행하여 탐색 속도를 높일 수 있습니다. 완전히 성숙된 조직은 런북으로 자동 복구할 수 있는 일반적인 문제에 대한 완전히 자동화된 플레이북을 보유합니다.
워크로드에 발생하는 일반적인 인시던트를 리스팅하여 플레이북의 구축을 시작할 수 있습니다. 시작하려면 위험성이 낮고 근본 원인이 몇 가지 문제로 좁혀진 인시던트에 대한 플레이북을 선택합니다. 간단한 시나리오에 대한 플레이북을 갖춘 후에는 근본 원인이 잘 알려지지 않았고 위험성이 더 높은 시나리오로 넘어가도록 합니다.
텍스트 플레이북은 조직이 성숙해지면 자동화해야 합니다. 또한 [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)등과 같은 서비스를 사용하여 일반 텍스트를 자동화로 변환할 수 있습니다. 이러한 자동화는 워크로드에 대해 실행함으로써 조사 속도를 높일 수 있습니다. 이벤트에 대한 대응으로 이러한 자동화를 활성화하여 인시던트를 발견하고 해결하는 데 걸리는 평균 시간을 단축할 수 있습니다.
고객은 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 를 사용하여 인시던트에 대응합니다. 이 서비스는 인시던트를 분류하고, 복구 및 완화 과정에서 이해 관계자에게 이를 알리고, 인시던트 전반에서 협업할 수 있는 단일 인터페이스를 제공합니다. 또한 AWS Systems Manager Automations를 사용하여 탐지 및 복구 속도를 높입니다.
**고객 사례**
AnyCompany Retail에 생산 인시던트가 발생했고 당직 근무 중인 엔지니어가 플레이북을 사용하여 문제를 조사했습니다. 단계에 따라 진행하면서 플레이북에서 파악한 주요 이해 관계자에게 계속 최신 정보를 보고했습니다. 엔지니어는 백엔드 서비스의 경합 상태가 근본 원인임을 확인했습니다. 엔지니어는 런북에 따라 서비스를 다시 시작하고 AnyCompany Retail을 온라인으로 전환했습니다.
## 구현 단계
기존 문서 리포지토리가 없는 경우 플레이북 라이브러리에 대한 버전 제어 리포지토리를 생성하는 것이 좋습니다. 플레이북은 대부분의 플레이북 자동화 시스템과 호환되는 Markdown을 사용하여 구축할 수 있습니다. 처음부터 시작하는 경우 다음 예시 플레이북 템플릿을 사용합니다.
```
# 플레이북 제목 ## 플레이북 정보 | 플레이북 ID | 설명 | 사용된 도구 | 특별 권한 | 플레이북 작성자 | 최종 업데이트 날짜 | 에스컬레이션 POC | 이해 관계자 | 커뮤니케이션 계획 | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | 이 플레이북의 용도는 무엇인가요? 어떤 인시던트에 사용됩니까? | 도구 | 권한 | 담당자 이름 | 2022-09-21 | 에스컬레이션 이름 | 이해 관계자 이름 | 조사 중 업데이트는 어떻게 전달되나요? | ## 단계 1. 1단계 2. 2단계
```
1. 기존 문서 리포지토리 또는 Wiki가 없는 경우 버전 관리 시스템에서 플레이북에 대한 새로운 버전 관리 리포지토리를 생성합니다.
1. 조사가 필요한 일반적인 문제를 파악합니다. 근본 원인이 몇 가지 문제로 한정되어 있고 해결 방법의 위험성이 낮은 시나리오여야 합니다.
1. Markdown 템플릿을 사용하여 `플레이북 이름` 섹션과 `플레이북 정보`필드를 작성합니다.
1. 문제 해결 단계를 작성합니다. 수행해야 하는 작업 또는 조사해야 하는 영역을 최대한 명확하게 작성합니다.
1. 팀원에게 플레이북을 전달하여 살펴보고 확인할 수 있도록 합니다. 누락되거나 명확하지 않은 사항이 있는 경우 플레이북을 업데이트합니다.
1. 문서 리포지토리에 플레이북을 게시하고 팀과 모든 이해 관계자에게 이를 알립니다.
1. 더 많은 플레이북을 추가할수록 이 플레이북 라이브러리는 더 발전하게 됩니다. 여러 플레이북이 있다면 플레이북의 자동화와 동기화를 유지할 수 있도록 AWS Systems Manager Automations와 같은 도구를 사용하여 자동화를 시작합니다.
**구현 계획의 작업 수준:** 낮음. 플레이북은 중앙 위치에 저장되는 텍스트 문서여야 합니다. 더 성숙한 조직은 플레이북 자동화를 진행합니다.
## 리소스
**관련 모범 사례:**
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](ops_ops_model_def_proc_owners.md): 플레이북에는 플레이북 유지 관리를 담당하는 소유자가 있어야 합니다.
+ [OPS07-BP03 런북을 사용한 절차 수행](ops_ready_to_support_use_runbooks.md): 런북과 플레이북은 비슷하지만 런북에는 원하는 결과가 있다는 중요한 차이점이 있습니다. 대부분의 경우 플레이북으로 근본 원인을 파악하고 난 뒤 런북이 사용됩니다.
+ [OPS10-BP01 이벤트, 인시던트 및 문제 관리 프로세스 사용](ops_event_response_event_incident_problem_process.md): 플레이북은 적절한 이벤트, 인시던트, 문제 관리 방침의 일부입니다.
+ [OPS10-BP02 알림별 프로세스 마련](ops_event_response_process_per_alert.md): 런북과 플레이북은 알림에 대응하는 데 사용해야 합니다. 시간이 흐르면 이러한 대응은 자동화되어야 합니다.
+ [OPS11-BP04 지식 관리 수행](ops_evolve_ops_knowledge_management.md): 플레이북 유지 관리는 지식 관리의 중요한 부분입니다.
**관련 문서:**
+ [ 자동화된 플레이북 및 런북을 사용하여 운영 우수성 달성 ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: 런북을 사용한 작업](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [AWS Systems Manager Automation 런북을 사용하여 운영 작업 해결 ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**관련 동영상:**
+ [AWS re:Invent 2019: 런북, 인시던트 보고서, 인시던트 대응에 대한 DIY 가이드(SEC318-R1) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS 가상 워크숍 ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS Systems Manager로 스크립트 통합 ](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**관련 예시:**
+ [AWS 고객 플레이북 프레임워크 ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: 자동화 시연 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Jupyter Notebook 및 CloudTrail Lake를 사용하여 AWS 인시던트 대응 런북 구축 ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - Jupyter Notebook에서 런북을 구축하기 위한 Python 라이브러리 ](https://github.com/Nurtch/rubix)
+ [ Document Builder를 사용하여 사용자 지정 런북 만들기 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected 실습: 플레이북 및 런북으로 운영 자동화 ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected 실습: Jupyter를 사용한 인시던트 대응 플레이북 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**관련 서비스:**
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 정보에 입각하여 시스템 및 변경 사항 배포 결정
워크로드를 지원할 수 있는 팀의 능력과 워크로드의 거버넌스 준수 여부를 평가합니다. 배포의 이점을 기준으로 하여 이러한 평가를 수행해 시스템 또는 변경 사항을 프로덕션 환경으로 전환할지 여부를 결정합니다. 이점과 위험을 파악하면 정보에 입각한 결정을 내릴 수 있습니다.
사전 분석이란 팀이 완화 전략을 개발하기 위해 실패를 시뮬레이션하는 연습입니다. 사전 분석을 사용하여 실패를 예측하고 적절한 절차를 마련할 수 있습니다. 워크로드를 평가하는 데 사용하는 체크리스트를 변경할 때는 해당 변경으로 인해 더 이상 규정을 준수하지 않는 라이브 시스템에 대해 수행할 작업을 계획합니다.
**일반적인 안티 패턴:**
+ 워크로드의 보안 위험을 파악하지 않고 워크로드 배포를 결정합니다.
+ 워크로드가 거버넌스 및 표준을 준수하는지 여부를 파악하지 않고 워크로드 배포를 결정합니다.
+ 팀에서 지원할 수 있는지 여부를 파악하지 않고 워크로드 배포를 결정합니다.
+ 워크로드가 조직에 어떤 이점을 제공하는지 파악하지 않고 워크로드 배포를 결정합니다.
**이 모범 사례 수립의 이점:** 숙련된 팀원이 있으면 워크로드를 효과적으로 지원할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 정보에 입각하여 워크로드 및 변경 사항 배포 결정: 워크로드를 지원할 수 있는 팀의 능력과 워크로드의 거버넌스 준수 여부를 평가합니다. 배포의 이점을 기준으로 하여 이러한 평가를 수행해 시스템 또는 변경 사항을 프로덕션 환경으로 전환할지 여부를 결정합니다. 이점과 위험을 파악하고 정보에 입각한 결정을 내려야 합니다.