# 운영 우수성
**Topics**
+ [조직](a-organization.md)
+ [준비](a-prepare.md)
+ [운영](a-operate.md)
+ [개선](a-evolve.md)
# 조직
**Topics**
+ [OPS 1 귀사의 운영 우선순위를 결정하는 요인은 무엇입니까?](w2aac19b5b5b5.md)
+ [OPS 2 비즈니스 성과를 지원하기 위해 조직을 어떻게 구성합니까?](w2aac19b5b5b7.md)
+ [OPS 3 조직 문화는 비즈니스 성과를 어떻게 지원합니까?](w2aac19b5b5b9.md)
# OPS 1 귀사의 운영 우선순위를 결정하는 요인은 무엇입니까?
모든 직원이 효율적인 업무 수행을 위한 역할과 리소스 우선 순위 설정을 위한 공동의 목표를 파악하고 있어야 합니다. 그러면 운영 개선 작업의 이점을 극대화할 수 있습니다.
**Topics**
+ [OPS01-BP01 외부 고객 요구 평가](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 내부 고객 요구 평가](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 거버넌스 요구 사항 평가](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 규정 준수 요구 사항 평가](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 위협 환경 평가](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 장단점 평가](ops_priorities_eval_tradeoffs.md)
+ [OPS01-BP07 이점 및 위험 관리](ops_priorities_manage_risk_benefit.md)
# OPS01-BP01 외부 고객 요구 평가
실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 외부 고객 요구 충족을 위해 주력할 영역을 결정합니다. 이렇게 하면 원하는 비즈니스 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다.
**일반적인 안티 패턴:**
+ 핵심 업무 시간 이외에 고객 지원을 하기로 결정했지만 과거 지원 요청 데이터를 검토하지 않았습니다. 이것이 고객에게 영향을 미치는지 여부는 알 수 없습니다.
+ 새로운 기능을 개발 중이지만 고객이 원하는 기능이고 원하는 형태인지 확인하지 않았으며 요구 사항과 제공 방법을 확인하기 위한 실험도 진행하지 않습니다.
**이 모범 사례 정립의 이점:** 요구가 충족되는 경우 고객으로 남을 가능성이 훨씬 더 높습니다. 외부 고객 요구를 평가하고 이해하면 비즈니스 가치를 제공하기 위해 작업의 우선순위를 정하는 방법을 알 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 비즈니스 요구 사항 파악: 비즈니스의 성공은 실무 팀, 개발 팀, 운영 팀을 비롯한 모든 이해관계자가 서로 목표와 이해를 공유하면서 실현됩니다.
+ 외부 고객의 비즈니스 목표, 요구 사항 및 우선순위 검토: 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 외부 고객의 목표, 요구 사항 및 우선순위를 논의합니다. 이렇게 하면 비즈니스 및 고객 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다.
+ 공유된 이해 관계 수립: 워크로드의 비즈니스 기능과 워크로드 작동 과정에서 각 팀의 역할을 비롯하여 이러한 요소가 내외부 고객의 공동 비즈니스 목표를 지원하는 방식에 대한 공유된 이해 관계를 정립합니다.
## 리소스
**관련 문서:**
+ [AWS Well-Architected Framework 개념 – 피드백 루프](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html)
# OPS01-BP02 내부 고객 요구 평가
실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 내부 고객 요구 충족을 위한 주력할 영역을 결정합니다. 이렇게 하면 비즈니스 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다.
설정한 우선순위를 활용해 가장 영향력이 큰 개선 작업 부분부터 중점적으로 수행합니다. 팀 기술 개발, 워크로드 성능 개선, 비용 절감, 런북 자동화, 모니터링 기능 향상 등을 예로 들 수 있습니다. 요구 사항이 변경되면 우선 순위를 업데이트합니다.
**일반적인 안티 패턴:**
+ 네트워크를 보다 쉽게 관리할 수 있도록 제품 팀의 IP 주소 할당을 상의하지 않고 변경하기로 결정했습니다. 이것이 제품 팀에 어떤 영향을 미칠지 알 수 없습니다.
+ 새로운 개발 도구를 구현하고 있지만 내부 고객에게 이 도구가 필요한지 여부나 기존 사례와 호환되는지 여부를 확인하지 않았습니다.
+ 새 모니터링 시스템을 구현하고 있지만 고려해야 할 모니터링 또는 보고 요구 사항이 있는지 내부 고객에게 문의하지 않았습니다.
**이 모범 사례 수립의 이점:** 내부 고객 요구를 평가하고 이해하면 비즈니스 가치를 제공하기 위해 작업의 우선순위를 정하는 방법을 알 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 비즈니스 요구 사항 파악: 비즈니스의 성공은 실무 팀, 개발 팀, 운영 팀을 비롯한 모든 이해관계자가 서로 목표와 이해를 공유하면서 실현됩니다.
+ 내부 고객의 비즈니스 목표, 요구 사항 및 우선순위 검토: 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 내부 고객의 목표, 요구 사항 및 우선순위를 논의합니다. 이렇게 하면 비즈니스 및 고객 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다.
+ 공유된 이해 관계 수립: 워크로드의 비즈니스 기능과 워크로드 작동 과정에서 각 팀의 역할을 비롯하여 이러한 요소가 내외부 고객의 공동 비즈니스 목표를 지원하는 방식에 대한 공유된 이해 관계를 정립합니다.
## 리소스
**관련 문서:**
+ [AWS Well-Architected Framework 개념 – 피드백 루프](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html)
# OPS01-BP03 거버넌스 요구 사항 평가
조직에서 특정 사항을 준수하거나 강조하기 위해 정의한 지침이나 의무 사항을 알고 있어야 합니다. 조직 정책, 표준 및 요구 사항과 같은 내부 요인을 평가합니다. 거버넌스에 대한 변경 사항을 식별할 수 있는 메커니즘이 있는지 확인합니다. 거버넌스 요구 사항이 식별되지 않는 것으로 결론을 내릴 때에는 신중하게 판단하여 내린 결론인지 재차 확인해야 합니다.
**일반적인 안티 패턴:**
+ 감사를 받고 있으며 내부 거버넌스에 대한 규정 준수 증명을 제출해야 합니다. 규정 준수 요구 사항을 평가한 적이 없기 때문에 규정 준수 여부도 알 수 없습니다.
+ 재정적 손실을 초래하는 손상을 겪었습니다. 재정적 손실에 대한 보험이 거버넌스에서 요구하지만 마련되어 있지 않은 특정 보안 제어의 구현을 조건으로 함을 알게 됩니다.
+ 관리 계정이 손상되어 회사 웹 사이트와 고객 신뢰가 손상되었습니다. 내부 거버넌스는 다중 인증(MFA)을 사용하여 관리 계정을 보호하도록 요구합니다. MFA로 관리 계정을 보호하지 않았으며 징계 조치 대상입니다.
**이 모범 사례 정립의 이점:** 조직이 워크로드에 적용하는 거버넌스 요구 사항을 평가하고 이해하면 비즈니스 가치를 제공하기 위한 작업의 우선순위를 정하는 방법을 알 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 거버넌스 요구 사항 이해: 프로그램 또는 조직 정책, 프로그램 정책, 문제 또는 시스템별 정책, 표준, 절차, 기준 및 지침과 같은 내부 거버넌스 요소를 평가합니다. 거버넌스에 대한 변경 사항을 식별할 수 있는 메커니즘이 있는지 확인합니다. 거버넌스 요구 사항이 식별되지 않는 것으로 결론을 내릴 때에는 신중하게 판단하여 내린 결론인지 재차 확인해야 합니다.
## 리소스
**관련 문서:**
+ [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/)
# OPS01-BP04 규정 준수 요구 사항 평가
규정 준수 요구 사항 및 산업 표준과 같은 외부 요인을 평가하여 특정 작업을 반드시/집중적으로 수행해야 할 수 있는 의무 사항이나 지침을 파악해야 합니다. 규정 준수 요구 사항이 확인되지 않으면 적절한 판단에 따라 해당 요구 사항을 결정해야 합니다.
**일반적인 안티 패턴:**
+ 감사를 받고 있으며 산업 규정 준수 증명을 제출해야 합니다. 규정 준수 요구 사항을 평가한 적이 없기 때문에 규정 준수 여부도 알 수 없습니다.
+ 관리 계정이 손상되어 고객 데이터가 다운로드되고 고객 신뢰가 손상되었습니다. 업계 모범 사례는 MFA를 사용하여 관리 계정을 보호할 것을 요구합니다. MFA로 관리 계정을 보호하지 않았으며 고객의 소송 대상입니다.
**이 모범 사례 정립의 이점:** 워크로드에 적용되는 규정 준수 요구 사항을 평가하고 이해하면 비즈니스 가치를 제공하기 위한 작업의 우선순위를 정하는 방법을 알 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 규정 준수 요구 사항 이해: 규정 준수 요구 사항 및 산업 표준과 같은 외부 요인을 평가하여 구체적인 초점을 맞춰 반드시/집중적으로 수행해야 할 수 있는 의무 사항이나 지침을 숙지하고 있는지 확인합니다. 규정 준수 요구 사항이 확인되지 않으면 적절한 판단에 따라 해당 요구 사항을 결정했는지 확인합니다.
+ 규정 준수 요구 사항 이해: 법적 이행 의무가 있는 규정 준수 요구 사항을 파악합니다. 그리고 이러한 요구 사항을 충족할 수 있는 운영 작업을 중점적으로 수행합니다. 예를 들면 개인 정보 보호 및 데이터 보호 조항의 의무 사항이 여기에 해당합니다.
+ [AWS 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)
+ [AWS 규정 준수 최신 소식](https://aws.amazon.com/compliance/compliance-latest-news/)
+ 업계 표준 및 모범 사례 이해: Payment Card Industry Data Security Standard(PCI DSS)와 같이 워크로드에 적용되는 업계 표준과 모범 사례 요구 사항을 파악합니다. 그리고 이러한 요구 사항을 충족할 수 있는 운영 작업을 중점적으로 수행합니다.
+ [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)
+ 내부 규정 준수 요구 사항 파악: 조직에서 수립한 규정 준수 요구 사항 및 모범 사례를 파악합니다. 그리고 이러한 요구 사항을 충족할 수 있는 운영 작업을 중점적으로 수행합니다. 정보 보안 정책 및 데이터 분류 표준을 예로 들 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 규정 준수 최신 소식](https://aws.amazon.com/compliance/compliance-latest-news/)
+ [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)
# OPS01-BP05 위협 환경 평가
비즈니스에 대한 위협 요소(예: 경쟁, 비즈니스상의 위험 및 법적 책임, 운영상의 위험, 정보 보안 위협)를 평가하고 위험 목록에서 최신 정보를 관리합니다. 주력할 영역을 결정할 때 위험의 영향을 포함시킵니다.
유효 [Well-Architected 프레임워크](https://aws.amazon.com/architecture/well-architected/) 에서는 학습, 평가 및 개선을 강조합니다. 아키텍처를 평가하고 시간에 따라 확장 가능한 설계를 구현하는 일관된 접근 방식을 제공합니다. AWS에서 선보이는 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) 은 개발 전의 접근 방식, 프로덕션 환경에 적용하기 전의 워크로드 상태, 프로덕션 환경에서의 워크로드 상태를 검토합니다. 이를 최신 AWS 아키텍처 모범 사례와 비교하고, 워크로드의 전반적인 상태를 모니터링하며, 잠재적 위험에 대한 인사이트를 얻을 수 있습니다.
AWS 고객은 AWS 모범 사례를 기준으로 하여 [아키텍처를 평가하는](https://aws.amazon.com/premiumsupport/programs/) 미션 크리티컬 워크로드에 대한 안내형 AWS Well-Architected Review 서비스를 이용할 수 있습니다. Enterprise Support 고객이라면 [Operations Review](https://aws.amazon.com/premiumsupport/programs/)를 이용할 수도 있습니다.
여러 팀의 구성원이 이러한 검토에 참여하면 워크로드 자체, 그리고 팀에서 각 역할을 맡은 구성원이 효율적인 워크로드 처리에 기여할 수 있는 방법을 공통된 방식으로 파악할 수 있습니다. 검토를 통해 확인된 요구 사항을 참조하여 우선 순위를 결정할 수 있습니다.
[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 는 우선순위 결정에 도움이 될 수 있는 최적화 방안을 알려주는 핵심 검사 세트에 액세스할 수 있는 도구입니다. [Business 및 Enterprise Support 고객에게는](https://aws.amazon.com/premiumsupport/plans/) 우선순위를 더욱 자세히 결정하는 데 사용할 수 있는 추가 검사 기능이 제공됩니다. 이러한 기능을 사용하면 보안, 안정성, 성능 및 비용 최적화 영역을 중점적으로 확인할 수 있습니다.
**일반적인 안티 패턴:**
+ 제품에서 이전 버전의 소프트웨어 라이브러리를 사용하고 있습니다. 워크로드에 의도하지 않은 영향을 줄 수 있는 문제에 대한 라이브러리의 보안 업데이트에 대해 모릅니다.
+ 경쟁업체가 제품에 대한 많은 고객 불만 사항을 해결하는 제품 버전을 출시했습니다. 이러한 알려진 문제 해결에 우선순위를 지정하지 않았습니다.
+ 규제 기관이 법률 규정 준수 요구 사항을 준수하지 않는 귀사와 같은 회사를 추적하고 있습니다. 미해결 규정 준수 요구 사항 해결에 우선순위를 지정하지 않았습니다.
**이 모범 사례 수립의 이점:** 조직 및 워크로드에 대한 위협을 식별하고 이해하면 해결할 위협, 우선순위 및 이를 수행하는 데 필요한 리소스를 결정하는 데 도움이 됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 위협 환경 평가: 주력할 영역을 결정할 때 영향력을 고려할 수 있도록 업무상의 위협 요소(예: 경쟁, 업무상의 위험/책임, 운영상의 위험, 정보 보안 위협)를 평가합니다.
+ [최신 AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ 위협 모델 유지 관리: 잠재적 위협, 계획되어 실행 중인 완화 조치 및 각 우선순위를 식별하는 위협 모델을 수립하고 유지 관리합니다. 인시던트로 나타나는 위협의 가능성, 해당 인시던트로부터 복구하는 비용 및 예상되는 피해, 이러한 인시던트를 방지하는 비용을 검토합니다. 위협 모델의 내용이 변경됨에 따라 우선순위를 수정합니다.
## 리소스
**관련 문서:**
+ [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/)
+ [최신 AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
# OPS01-BP06 장단점 평가
주력할 영역을 결정하거나 수행할 조치를 선택할 때 정보를 토대로 결정을 내릴 수 있도록 상충하는 이해 관계나 대안 사이의 장단점을 평가합니다. 예를 들어, 비용 최적화보다 새로운 기능의 시장 출시를 앞당기는 데 더 역점을 둘 수 있습니다. 아니면 데이터 유형에 최적화된 데이터베이스로 마이그레이션하고 애플리케이션을 업데이트하는 대신, 시스템 마이그레이션 작업을 간소화하기 위해 비관계형 데이터용 솔루션으로 관계형 데이터베이스를 선택할 수도 있습니다.
AWS를 활용하면 선택한 방식이 워크로드에 미치는 영향을 효과적으로 파악하도록 팀에 AWS 및 해당 서비스 관련 정보를 제공할 수 있습니다. 팀에 관련 정보를 제공하는 데 [AWS Support](https://aws.amazon.com/premiumsupport/programs/) ([AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/), [AWS 토론 포럼](https://forums.aws.amazon.com/index.jspa)및 [AWS Support 센터](https://console.aws.amazon.com/support/home/)) 및 [AWS 설명서](https://docs.aws.amazon.com/) 를 이용해야 합니다. AWS 관련 문의 사항에 대해 지원을 받으려면 AWS Support 센터를 통해 AWS Support에 지원을 요청하십시오.
AWS는 다음에서 AWS의 운영을 통해 학습한 모범 사례와 패턴을 공유합니다. [Amazon Builders' Library](https://aws.amazon.com/builders-library/)참조. 다음에서도 기타 여러 가지 유용한 정보를 확인할 수 있습니다. [AWS 블로그](https://aws.amazon.com/blogs/) 및 [공식 AWS 팟캐스트](https://aws.amazon.com/podcasts/aws-podcast/).
**일반적인 안티 패턴:**
+ 관계형 데이터베이스를 사용하여 시계열 및 비관계형 데이터를 관리하고 있습니다. 사용 중인 데이터 형식을 지원하도록 최적화된 데이터베이스 옵션이 있지만 솔루션 간의 장단점을 평가하지 않아 이점을 모릅니다.
+ 투자자는 PCI DSS(Payment Card Industry Data Security Standards)를 준수함을 입증할 것을 요청합니다. 요청을 충족하는 것과 현재 개발 작업을 계속하는 것 사이의 장단점을 고려하지 않습니다. 대신 규정 준수를 입증하지 않고 개발 작업을 계속 진행합니다. 투자자는 플랫폼 보안과 투자에 대한 우려 사항으로 인해 회사의 지원을 중단합니다.
**이 모범 사례 수립의 이점:** 선택에 따른 영향과 결과를 이해하면 옵션의 우선순위를 정할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 장단점 평가: 주력할 영역을 결정할 때 정보를 토대로 적절한 결정을 내릴 수 있도록 상충하는 이해관계의 장단점을 평가합니다. 예를 들어 새로운 기능의 출시 기간을 단축하는 것이 비용 최적화보다 우선시될 수 있습니다.
+ AWS를 활용하면 선택한 방식이 워크로드에 미치는 영향을 효과적으로 파악하도록 팀에 AWS 및 해당 서비스 관련 정보를 제공할 수 있습니다. AWS Support(AWS 지식 센터, AWS 토론 포럼, AWS Support 센터) 및 AWS 설명서에 나와 있는 리소스를 사용해서 팀을 교육해야 합니다. AWS 관련 문의 사항에 대해 지원을 받으려면 AWS Support 센터를 통해 AWS Support에 지원을 요청하십시오.
+ 또한 AWS는 AWS의 운영을 통해 학습한 모범 사례와 패턴을 Amazon Builders' Library에서 공유합니다. AWS 블로그 및 공식 AWS 팟캐스트에서도 기타 여러 가지 유용한 정보를 확인할 수 있습니다.
## 리소스
**관련 문서:**
+ [AWS 블로그](https://aws.amazon.com/blogs/)
+ [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 토론 포럼](https://forums.aws.amazon.com/index.jspa)
+ [AWS 설명서](https://docs.aws.amazon.com/)
+ [AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/)
+ [AWS Support](https://aws.amazon.com/premiumsupport/)
+ [AWS Support 센터](https://console.aws.amazon.com/support/home/)
+ [Amazon Builders' Library](https://aws.amazon.com/builders-library/)
+ [공식 AWS 팟캐스트](https://aws.amazon.com/podcasts/aws-podcast/)
# OPS01-BP07 이점 및 위험 관리
주력할 영역을 결정할 때 정보를 토대로 적절한 결정을 내릴 수 있도록 이점과 위험을 관리합니다. 예를 들어 새 기능을 고객에게 제공하기 위해 해결되지 않은 문제가 남아 있는 워크로드를 배포하는 것이 이득일 수 있습니다. 관련 위험을 완화할 수도 있겠지만, 위험을 감수할 수 없는 경우에는 위험을 해결하기 위한 조치를 취해야 합니다.
특정 시점에 우선순위 중 일부를 중점적으로 처리해야 할 수도 있습니다. 필요한 기능을 개발하고 위험을 관리하려면 워크로드 우선순위를 장기적으로 적절하게 절충해야 합니다. 요구 사항이 변경되면 우선순위를 업데이트합니다.
**일반적인 안티 패턴:**
+ 한 개발자가 인터넷에서 찾은 필요한 모든 것을 수행하는 라이브러리를 포함하기로 했습니다. 출처를 알 수 없는 이 라이브러리의 도입에 따른 위험을 평가하지 않았으며 취약성 또는 악성 코드가 포함되어 있는지 알 수 없습니다.
+ 기존 문제를 해결하는 대신 새 기능을 개발하고 배포하기로 결정했습니다. 배포 전까지 이 기능에 남아 있는 문제의 위험을 평가하지 않았으며 고객에게 어떤 영향이 있을지 모릅니다.
+ 규정 준수 팀의 불특정 우려 때문에 고객이 자주 요청하는 기능을 배포하지 않기로 결정했습니다.
**이 모범 사례 수립의 이점:** 선택 시 얻을 수 있는 이점을 파악하고 조직의 위험을 인식하면 정보에 입각한 결정을 내릴 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 이점 및 위험 관리: 결정으로 인해 누릴 수 있는 이점과 수반되는 위험의 균형을 잡습니다.
+ 이점 파악: 비즈니스 목표, 필요 사항 및 우선순위에 따른 이점을 파악합니다. 출시 리드타임, 보안, 신뢰성, 성능 및 비용이 이에 해당합니다.
+ 위험 요소 파악: 비즈니스 목표, 필요 사항 및 우선순위에 따른 위험 요소를 파악합니다. 출시 리드타임, 보안, 신뢰성, 성능 및 비용이 이에 해당합니다.
+ 위험 대비 이점 평가 및 정보에 입각한 의사 결정: 실무/개발/운영 팀을 비롯한 주요 이해관계자의 목표, 필요 사항 및 우선순위를 기준으로 하여 이점과 위험의 영향을 파악합니다. 위험 발생 가능성 및 해당 위험이 주는 영향의 비용 대비 이점의 가치를 평가합니다. 예를 들어, 안정성보다 시장 진입 속도를 강조하면 경쟁 우위를 제공할 수 있습니다. 하지만 안정성 문제가 있는 경우 가동 시간이 단축될 수 있습니다.
# OPS 2 비즈니스 성과를 지원하기 위해 조직을 어떻게 구성합니까?
팀은 비즈니스 성과를 달성하기 위해 맡은 역할을 파악해야 합니다. 그리고 다른 팀의 성공을 위해 자신의 팀이 해야 할 역할과 해당 팀이 해야 할 역할을 파악하고, 목표를 공유해야 합니다. 맡은 책임, 소유권, 의사 결정 방식 및 의사 결정권자를 파악하면 역량을 집중하고 팀의 이점을 극대화할 수 있습니다.
**Topics**
+ [OPS02-BP01 리소스 소유자 식별](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 팀원이 담당해야 하는 업무 파악](ops_ops_model_know_my_job.md)
+ [OPS02-BP05 책임과 소유권을 식별하는 메커니즘](ops_ops_model_find_owner.md)
+ [OPS02-BP06 추가, 변경 및 예외를 요청하는 메커니즘](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 미리 정의되었거나 협상된 팀 간 책임](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 리소스 소유자 식별
각 애플리케이션, 워크로드, 플랫폼 및 인프라 구성 요소의 소유권, 해당 구성 요소가 제공하는 비즈니스 가치, 그리고 소유권이 존재하는 이유를 파악합니다. 이러한 개별 구성 요소의 비즈니스 가치를 파악하고 이들이 비즈니스 성과를 어떻게 지원하는지 파악하면 해당 구성 요소에 적용되는 프로세스와 절차를 알 수 있습니다.
**이 모범 사례 정립의 이점:** 소유권을 파악하면 누가 개선 사항 승인 또는 구현을 수행하거나 둘 다 수행할 수 있는지 알 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 리소스 소유자 식별: 환경의 리소스 사용 사례에 대한 소유권 의미를 정의합니다. 최소한 이름, 연락처 정보, 조직 및 팀을 포함하여 리소스 소유자를 지정하고 기록합니다. 태그 또는 리소스 그룹과 같은 메타데이터를 사용하여 리소스와 함께 리소스 소유권 정보를 저장합니다. AWS Organizations를 사용하여 계정을 구성하고 소유권 및 연락처 정보가 캡처되도록 정책을 구현합니다.
+ 소유권 형태 및 할당 방법 정의: 사용 사례가 서로 다른 조직에서는 소유권에 대한 정의가 다양할 수 있습니다. ‘워크로드 소유자’를 워크로드 운영의 위험을 부담하고 책임을 지며 궁극적으로 워크로드 관련 결정을 내릴 권한이 있는 개인으로 정의할 수 있습니다. 소유권이 상위 조직에 롤업되는 재무 또는 관리 책임의 관점에서 소유권을 정의할 수 있습니다. 개발자는 개발 환경의 소유자일 수 있으며 운영에 따른 인시던트에 대한 책임이 있습니다. 제품 책임자는 개발 환경의 운영과 관련된 재정적 비용에 대한 책임을 부담할 수 있습니다.
+ 조직, 계정, 리소스 모음 또는 개별 구성 요소의 소유자 정의: 검색을 지원하도록 구성된 적절하게 액세스 가능한 위치에서 소유권을 정의하고 기록합니다. 변경 시 정의와 소유권 세부 정보를 업데이트합니다.
+ 리소스에 대한 메타데이터에서 소유권 캡처: 태그 또는 리소스 그룹과 같은 메타데이터를 사용하고 소유권과 연락처 정보를 지정하여 리소스 소유권을 캡처합니다. AWS Organizations를 사용하여 계정을 구성하고 소유권 및 연락처 정보가 캡처되도록 합니다.
# OPS02-BP02 프로세스 및 절차의 소유자 식별
개별 프로세스와 절차의 정의에 대한 소유권이 있는 사람, 그러한 특정 프로세스와 절차가 사용되는 이유, 그리고 소유권이 존재하는 이유를 파악합니다. 특정 프로세스 및 절차가 사용되는 이유를 이해하면 개선 기회를 파악할 수 있습니다.
**이 모범 사례 수립의 이점:** 소유권을 파악하면 누가 개선 사항 승인 또는 구현을 수행하거나 둘 다 수행할 수 있는지 알 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 프로세스 및 절차에서 정의를 담당하는 소유자 식별: 환경에서 사용되는 프로세스 및 절차와 정의를 담당하는 개인 또는 팀을 캡처합니다.
+ 프로세스 및 절차 식별: 워크로드 지원을 위해 수행되는 운영 활동을 식별합니다. 검색 가능한 위치에 이러한 활동을 문서화합니다.
+ 프로세스 또는 절차 정의 소유자 지정: 활동 지정을 담당하는 개인 또는 팀을 고유하게 식별합니다. 이들은 올바른 권한, 액세스 및 도구와 적절한 기술을 갖춘 팀원이 활동을 성공적으로 수행할 수 있도록 할 책임이 있습니다. 해당 활동을 수행하는 데 문제가 있는 경우 활동을 수행하는 팀원은 활동 개선에 필요한 상세한 피드백을 제공할 책임이 있습니다.
+ 활동 아티팩트의 메타데이터에서 소유권 캡처: AWS Systems Manager, 문서 및 AWS Lambda와 같은 서비스에서 함수로 자동화된 절차를 사용하면 메타데이터 정보를 태그로 캡처할 수 있습니다. 태그 또는 리소스 그룹을 사용하여 리소스 소유권을 캡처하고 소유권 및 연락처 정보를 지정합니다. AWS Organizations를 사용하여 태그 지정 정책을 생성하고 소유권 및 연락처 정보가 캡처되도록 합니다.
# OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별
정의된 워크로드를 대상으로 하는 특정 활동 수행에 대한 책임 소재와 그러한 책임이 존재하는 이유를 파악합니다. 활동 수행에 대한 책임 소재를 파악하면 누가 작업을 수행하고, 누가 결과를 확인하며, 누가 활동 소유자에게 피드백을 제공할지 알 수 있습니다.
**이 모범 사례 정립의 이점:** 활동 수행에 대한 책임 소재를 파악하면 작업이 필요할 때 누구에게 알릴지, 누가 작업을 수행하고 결과를 확인하며 활동 소유자에게 피드백을 제공할지 알 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 운영 활동에서 성과를 담당하는 소유자 식별: 환경에서 사용되는 프로세스 및 절차 수행에 대한 책임 소재를 파악합니다.
+ 프로세스 및 절차 식별: 워크로드 지원을 위해 수행되는 운영 활동을 식별합니다. 검색 가능한 위치에 이러한 활동을 문서화합니다.
+ 각 활동 수행에 대한 책임 소재 정의: 활동을 담당하는 팀을 식별합니다. 활동 세부 정보, 활동 수행에 필요한 기술, 올바른 권한, 액세스 및 도구를 갖추고 있는지 확인합니다. 활동 수행 조건(예: 이벤트 또는 일정)을 파악해야 합니다. 조직의 구성원이 특정 요구 사항에 대해 연락할 팀이나 개인을 식별할 수 있도록 이 정보를 검색할 수 있게 설정합니다.
# OPS02-BP04 팀원이 담당해야 하는 업무 파악
역할의 책임과 비즈니스 성과에 기여하는 방법을 파악하면 작업의 우선순위와 역할이 중요한 이유를 알 수 있습니다. 이를 통해 팀원은 요구 사항을 인식하고 적절하게 대응할 수 있습니다.
**이 모범 사례 정립의 이점:** 책임을 파악하면 사용자가 내리는 결정, 취하는 조치, 적절한 소유자에게 활동 전달을 알 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 팀원의 역할 및 책임 파악: 팀원의 역할과 책임을 식별하고 맡은 역할에 대한 기대치를 이해하도록 합니다. 조직의 구성원이 특정 요구 사항에 대해 연락할 팀이나 개인을 식별할 수 있도록 이 정보를 검색할 수 있게 설정합니다.
# OPS02-BP05 책임과 소유권을 식별하는 메커니즘
개인이나 팀을 식별하지 못할 경우 소유권을 할당하거나 요구 사항 충족을 위한 계획을 수립할 권한이 있는 사람에게 정해진 경로를 통해 사안을 에스컬레이션할 수 있습니다.
**이 모범 사례 정립의 이점:** 책임 또는 소유권이 있는 사람을 파악하면 적절한 팀이나 팀원에게 연락하여 요청을 하거나 태스크를 전환할 수 있습니다. 책임 또는 소유권을 할당하거나 요구 사항 충족을 위한 계획을 수립할 권한이 있는 사람을 식별하면 휴지 및 요구 사항 미충족의 위험이 줄어듭니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 책임과 소유권을 식별하는 메커니즘: 조직 구성원에게 소유권과 책임을 발견하고 식별할 수 있는 액세스 가능한 메커니즘을 제공합니다. 이러한 메커니즘을 통해 조직 구성원은 특정 요구 사항에 대해 연락할 팀 또는 개인을 식별할 수 있습니다.
# OPS02-BP06 추가, 변경 및 예외를 요청하는 메커니즘
프로세스, 절차 및 리소스의 소유자에게 요청을 보낼 수 있습니다. 이점과 위험을 평가한 후 요청이 적절한지 판단하고 정보에 입각한 의사 결정을 통해 실현 가능한 경우에 요청을 승인해야 합니다.
**이 모범 사례 정립의 이점:** 팀의 활동을 지원하는 데 있어서는 추가, 변경 및 예외 처리를 요청하는 메커니즘을 갖추어야 합니다. 이 옵션이 없으면 현재 상태가 혁신의 제약 요인이 됩니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 추가, 변경 및 예외를 요청하는 메커니즘: 표준이 엄격하면 혁신은 제약을 받습니다. 비즈니스 요구 사항 지원을 위해 프로세스, 절차 및 리소스를 소유자에게 요청할 수 있는 메커니즘을 조직 구성원에게 제공합니다.
# OPS02-BP07 미리 정의되었거나 협상된 팀 간 책임
팀 간에 서로 협력하고 지원하는 방식에 관한 내용을 정의하거나 협상합니다(예: 응답 시간, 서비스 수준 목표 또는 서비스 수준 계약). 팀의 작업이 비즈니스 성과에 미치는 영향, 그리고 다른 팀과 조직의 성과에 미치는 영향을 이해하면 작업의 우선순위를 파악하고 적절하게 대응할 수 있습니다.
책임과 소유권을 정의하지 않았거나 알지 못하는 경우 필요한 활동을 적시에 처리하지 못하게 되며 해당 요구 사항을 해결하기 위한 작업이 중복되고 잠재적으로는 상충될 위험이 있습니다.
**이 모범 사례 정립의 이점:** 팀, 목표 및 요구 사항을 전달하는 방법 간의 책임을 확립하면 요청 흐름이 쉬어지고 필요한 정보가 반드시 제공됩니다. 이렇게 하면 팀 간 전환 태스크에서 발생하는 지연이 줄고 비즈니스 성과 달성에 도움이 됩니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 미리 정의되었거나 협상된 팀 간 책임: 팀이 상호작용하는 방법과 서로 지원하는 데 필요한 정보를 지정하면 요청을 반복적으로 검토하고 설명하게 되면서 지연이 발생하는 상황을 최소화할 수 있습니다. 기대치를 정의하는 특정 계약(예: 응답 시간 또는 이행 시간)을 사용하면 팀이 효과적인 계획과 리소스를 적절하게 작성할 수 있습니다.
# OPS 3 조직 문화는 비즈니스 성과를 어떻게 지원합니까?
팀원이 효과적으로 조치를 취하고 비즈니스 성과를 지원할 수 있도록 팀원에 대한 지원을 제공합니다.
**Topics**
+ [OPS03-BP01 경영진의 후원 확보](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여](ops_org_culture_team_emp_take_action.md)
+ [OPS03-BP03 에스컬레이션 장려](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 시기 적절하고 명확하며 실행 가능한 커뮤니케이션](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 실험 장려](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 팀원의 기술 유지와 증진 지원 및 장려](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 리소스 팀 적절히 관리](ops_org_culture_team_res_appro.md)
+ [OPS03-BP08 팀 내부 및 여러 팀 간에 의견의 다양성 추구 및 장려](ops_org_culture_diverse_inc_access.md)
# OPS03-BP01 경영진의 후원 확보
최고 경영진은 조직에 대한 기대치를 명확하게 설정하고 성공 여부를 평가합니다. 최고 경영진은 조직이 발전하고 모범 사례를 도입하도록 하는 동인이자 후원자이자 지지자입니다.
**이 모범 사례 수립의 이점:** 경영진의 참여, 명확하게 기대치 전달 및 목표 공유를 통해 팀원은 기대 사항을 파악할 수 있습니다. 성공 평가를 통해 후원자 또는 대리인의 개입을 통해 해결할 수 있도록 성공의 장벽을 파악할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 경영진의 후원 확보: 최고 경영진은 조직에 대한 기대치를 명확하게 설정하고 성공 여부를 평가합니다. 최고 경영진은 조직이 발전하고 모범 사례를 도입하도록 하는 동인이자 후원자이자 지지자입니다.
+ 기대치 설정: 측정 방법을 포함하여 조직의 목표를 정의하고 게시합니다.
+ 목표 달성 추적: 성과가 위태로운 상태일 경우 적절한 조치를 취할 수 있도록 목표의 점진적 달성을 정기적으로 측정하고 결과를 공유합니다.
+ 목표를 달성하는 데 필요한 리소스 제공: 리소스가 여전히 적절한지 또는 새로운 정보, 목표 변경, 책임 또는 비즈니스 환경에 따라 추가 리소스가 필요한지 정기적으로 검토합니다.
+ 팀 지지: 팀과 지속적으로 협력하여 팀의 업무 방식과 팀에 영향을 미치는 외부 요인을 파악합니다. 팀이 외부 요인의 영향을 받는 경우 목표를 재평가하고 적절하게 목표를 조정합니다. 팀 진행을 방해하는 장애물을 파악합니다. 팀을 대신해 장애물을 해결하고 불필요한 부담을 제거하는 데 도움을 줍니다.
+ 모범 사례 도입을 위한 동인: 수량화할 수 있는 이점을 제공하고 생산자와 채택자를 인지하는 모범 사례를 확인합니다. 추가적인 채택을 장려하여 달성된 이점을 확대합니다.
+ 팀의 진화를 이끄는 동력: 지속적으로 개선하는 문화를 조성합니다. 개인 및 조직의 성장과 개발을 장려합니다. 시간 경과에 따른 점진적 달성을 필요로 하는, 추구할 장기적 목표를 제공합니다. 이러한 비전을 조정하여 변화하는 요구 사항, 비즈니스 목표 및 비즈니스 환경을 보완합니다.
# OPS03-BP02 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여
워크로드 소유자는 성과가 위험한 상태일 때 팀원들이 응답할 수 있도록 지침과 범위를 정의했습니다. 에스컬레이션 메커니즘은 이벤트가 정의된 범위를 벗어날 경우 수행할 조치를 정할 때 사용됩니다.
**이 모범 사례 수립의 이점:** 변경 사항을 조기에 테스트하고 검증함으로써 최소화된 비용으로 문제를 해결하고 고객에게 미치는 영향을 제한할 수 있습니다. 배포 전에 테스트하면 오류 도입을 최소화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여: 팀원에게 효과적으로 대응하는 데 필요한 기술을 연습할 수 있는 권한, 도구 및 기회를 제공합니다.
+ 팀원에게 대응하는 데 필요한 기술을 연습할 기회 제공: 프로세스와 절차를 안전하게 테스트하고 교육할 수 있는 안전한 대체 환경을 제공합니다. 팀원들이 안전한 시뮬레이션 환경에서 실제 인시던트에 대응하는 경험을 쌓을 수 있도록 실전 연습을 수행합니다.
+ 팀원의 조치 수행 권한 정의 및 승인: 특히 팀원이 지원하는 워크로드 및 구성 요소에 대한 권한과 액세스를 할당하여 조치를 취할 수 있는 팀원 권한을 정의합니다. 성과가 위험한 상태일 때 조치를 취할 수 있는 권한이 팀원에게 있음을 확인합니다.
# OPS03-BP03 에스컬레이션 장려
성과 실현에 실패할 위험이 있는 경우 의사 결정권자와 이해관계자에게 문제를 에스컬레이션하는 메커니즘이 마련되어 있으며 팀원은 이를 적극적으로 활용해야 합니다. 위험을 식별하고 인시던트를 방지할 수 있도록 에스컬레이션을 조기에 자주 수행해야 합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 조기의 잦은 에스컬레이션 장려: 조직 차원에서 에스컬레이션을 조기에 자주 진행하는 게 모범 사례임을 받아들입니다. 에스컬레이션이 근거가 없는 것으로 판명될 수 있으며 에스컬레이션하지 않아 해당 기회를 놓치는 것보다 인시던트를 방지할 기회를 갖는 것이 낫다는 것을 조직 차원에서 인정하고 수락합니다.
+ 에스컬레이션을 위한 메커니즘 보유: 에스컬레이션이 발생하는 시점과 방법을 정의하는 문서화된 절차가 있어야 합니다. 조치를 취하거나 조치와 연락처 정보를 승인할 수 있는 높은 권한이 있는 사람들을 문서화합니다. 팀원이 위험 요소를 처리할 수 있는 사람에게 문제를 이관했거나 워크로드 운영에 대한 위험과 책임을 부담하는 사람에게 연락했다고 만족할 때까지 에스컬레이션이 계속되어야 합니다. 궁극적으로 워크로드와 관련된 모든 의사 결정을 소유하는 사람이 여기에 해당합니다. 에스컬레이션에는 위험의 특성, 워크로드의 중요성, 영향을 받는 사람, 영향의 종류, 긴급성, 즉 영향이 예상되는 시기가 포함되어야 합니다.
+ 에스컬레이션하는 직원 보호: 팀원이 부적절한 의사 결정권자나 이해관계자에게로 문제를 에스컬레이션하는 경우 받을 수 있는 불이익으로부터 팀원을 보호하는 정책을 마련합니다. 이러한 일이 발생하는지 여부를 식별하고 적절하게 대응할 수 있는 메커니즘이 마련되어 있습니다.
# OPS03-BP04 시기 적절하고 명확하며 실행 가능한 커뮤니케이션
알려진 위험과 예정된 이벤트를 팀원에게 적시에 알리는 데 사용되는 메커니즘이 마련되어 있습니다. 조치가 필요한지 여부와 어떤 조치가 필요한지 판단하고 적시에 조치를 취할 수 있도록 필요한 컨텍스트, 세부 정보 및 시간(가능한 경우)이 제공됩니다. 예를 들어 소프트웨어 취약성에 대한 알림을 제공하여 패치를 신속하게 적용하도록 하거나, 예정된 판매 프로모션에 대한 알림을 제공하여 서비스 중단의 위험을 방지하기 위한 변경 동결 기능을 구현하게 할 수 있습니다.
대기 중인 활동을 팀원이 식별할 수 있도록 예정된 이벤트를 변경 일정이나 유지 관리 일정에 기록할 수 있습니다.
AWS에서는 [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/ARG/latest/userguide/supported-resources.html#supported-resources-console) 에 대한 활동을 예약하여 활동을 자동화하고 해당 활동을 검색할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 시기 적절하고 명확하며 실행 가능한 커뮤니케이션: 적절한 대응을 가능하게 하는 충분한 정보와 함께 명확하고 실행 가능한 방식으로 위험 또는 계획된 이벤트를 알리는 메커니즘이 마련되어 있습니다.
+ 변경 일정에서 계획된 활동 문서화 및 알림 제공: 계획된 이벤트를 검색할 수 있는 액세스 가능한 정보 출처를 제공합니다. 동일한 시스템의 계획된 이벤트에 대한 알림을 제공합니다.
+ 워크로드에 영향을 줄 수 있는 이벤트 및 활동 추적: 취약성 알림과 패치 정보를 모니터링하여 워크로드 구성 요소와 관련된 잠재적 위험과 취약성을 파악합니다. 팀원에게 조치를 취할 수 있도록 알림을 제공합니다.
## 리소스
**관련 문서:**
+ [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)
# OPS03-BP05 실험 장려
실험은 학습을 가속화하고 팀원의 관심과 참여를 유지합니다. 원치 않는 결과가 나와도 성공하지 못하는 경로를 알게 되었으므로 실험에는 성공한 것입니다. 원치 않는 결과가 나온 성공한 실험에 대해 팀원에게 불이익을 가하지 않습니다. 혁신과 아이디어를 실현하려면 실험이 필요합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 실험 장려: 학습과 혁신을 지원하도록 실험을 장려하십시오.
+ 다양한 기술로 실험: 현재 또는 미래에 비즈니스 성과를 달성하는 데 적용할 수 있는 기술을 실험하도록 장려하십시오. 이러한 지식은 향후 혁신에 도움이 될 수 있습니다.
+ 목표를 염두에 두고 실험: 팀원이 도달할 특정 목표 또는 가까운 장래에 적용할 수 있는 기술을 사용한 실험을 장려하십시오. 이러한 지식은 혁신에 도움이 될 수 있습니다.
+ 체계적인 실험 시간 제공: 팀원이 실험에 집중할 수 있도록 통상적인 책임에서 벗어날 수 있는 구체적인 시간을 지원합니다.
+ 실험을 지원하는 리소스 제공: 실험을 수행하는 데 필요한 리소스(예: 소프트웨어 또는 클라우드 리소스)에 자금을 지원합니다.
+ 성공 인정: 실험으로 인해 창출되는 가치를 인식합니다. 원하는 결과가 나오지 않은 실험이라도 성공적이라고 생각해야 합니다. 이 실험을 통해 성공으로 이어지지 않는 경로를 알게 되었기 때문입니다. 실험에서 원하는 성과를 달성하지 못했다고 팀원이 처벌되지는 않습니다.
# OPS03-BP06 팀원의 기술 유지와 증진 지원 및 장려
팀은 새로운 기술을 도입하고 워크로드 지원 책임과 수요 변화를 지원하기 위해 기술 역량을 키워야 합니다. 새로운 기술 영역의 기술 증진은 팀원의 만족도를 높이고 혁신을 뒷받침합니다. 발전하는 기술을 검증하고 인증하는 업계 자격증을 획득하고 관리하도록 팀원을 독려합니다. 지식이 효과적으로 전달되도록 하고, 제도적 지식을 갖춘 경험 많고 숙련된 직원을 잃은 경우에 중대한 영향이 발생할 위험을 줄일 수 있도록 교차 교육을 실시합니다. 학습을 위해 체계적으로 정해진 교육 시간을 제공합니다.
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는 다음에서 AWS의 운영을 통해 학습한 모범 사례와 패턴을 공유합니다. [Amazon Builders' Library](https://aws.amazon.com/builders-library/) 또한 다음을 통해 도움이 되는 방대한 기타 교육 자료를 제공합니다. [AWS 블로그](https://aws.amazon.com/blogs/) 및 [공식 AWS 팟캐스트](https://aws.amazon.com/podcasts/aws-podcast/).
팀에 관련 정보를 제공하는 데 AWS에서 지원하는 교육 리소스, 즉 Well-Architected 실습과 [AWS Support](https://aws.amazon.com/premiumsupport/programs/) ([AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/), [AWS 토론 양식](https://forums.aws.amazon.com/index.jspa)및 [AWS Support 센터](https://console.aws.amazon.com/support/home/)) 및 [AWS 설명서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 를 이용해야 합니다. AWS 관련 문의 사항에 대해 지원을 받으려면 AWS Support 센터를 통해 AWS Support에 지원을 요청하십시오.
[AWS 교육 and Certification](https://aws.amazon.com/training/) 에서는 AWS 기초에 관한 자습형 디지털 과정을 통해 무료 교육을 제공합니다. 강사 주도형 교육에 등록하여 팀이 AWS 기술을 연마하도록 추가로 지원할 수도 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 팀원의 기술 유지와 증진 지원 및 장려: 새로운 기술을 도입하고, 혁신을 지원하고, 워크로드 지원 책임과 수요 변화를 뒷받침하려면 지속적인 교육이 필요합니다.
+ 교육 리소스 제공: 체계적인 시간, 교육 자료 이용, 실습 리소스 및 교사와 동료에게서 배울 수 있는 기회를 제공하는 컨퍼런스 및 전문 조직에 참석 지원을 제공합니다. 수습 팀원에게 선임 팀원의 지도와 조언을 받을 수 있는 기회를 제공하고 선임 팀원의 일과 방법 및 기술을 배울 수 있게 합니다. 보다 넓은 시야를 확보하기 위해 작업과 직접적으로 관련되지 않은 콘텐츠에 대해 학습하도록 장려합니다.
+ 팀 교육 및 팀 간 참여: 팀원의 지속적인 교육 요구 사항을 계획합니다. 팀원이 다른 팀(임시로 또는 영구적으로)에 합류하여 전체 조직에 도움이 되는 기술과 모범 사례를 공유할 수 있는 기회를 제공합니다.
+ 업계 자격증 획득 및 유지 지원: 팀원이 배운 내용을 확인하고 그 성과를 인정하는 업계 자격증을 획득하고 유지하도록 지원합니다.
## 리소스
**관련 문서:**
+ [AWS 시작하기 리소스 센터](https://aws.amazon.com/getting-started/)
+ [AWS 블로그](https://aws.amazon.com/blogs/)
+ [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 토론 양식](https://forums.aws.amazon.com/index.jspa)
+ [AWS 설명서](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Online Tech Talks](https://aws.amazon.com/getting-started/)
+ [AWS 이벤트 및 웨비나](https://aws.amazon.com/events/)
+ [AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/)
+ [AWS Support](https://aws.amazon.com/premiumsupport/programs/)
+ [AWS 교육 and Certification](https://aws.amazon.com/training/)
+ [AWS Well-Architected 실습](https://wellarchitectedlabs.com/),
+ [Amazon Builders' Library](https://aws.amazon.com/builders-library/)
+ [공식 AWS 팟캐스트](https://aws.amazon.com/podcasts/aws-podcast/).
# OPS03-BP07 리소스 팀 적절히 관리
워크로드 요구 사항을 지원할 수 있도록 팀원 역량을 유지하고 도구와 리소스를 제공합니다. 과중한 업무를 수행하는 팀원은 인적 오류로 인한 인시던트의 위험이 큽니다. 자주 수행하는 활동을 자동화하는 등 도구 및 리소스에 투자하면 팀의 효율성이 높아져 팀원이 더 많은 활동을 지원할 수 있게 됩니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 리소스 팀 적절히 관리: 팀의 성공을 깊이 있게 이해하고, 성공 또는 실패를 부른 요인을 파악해야 합니다. 적절한 리소스로 팀 지원 활동을 합니다.
+ 팀 성과 이해: 팀의 운영 성과 달성과 자산 개발을 측정합니다. 시간 경과에 따른 출력 및 오류 발생률의 변화를 추적합니다. 팀과 협력하여 업무에 영향을 미치는 문제(예: 책임 증가, 기술 변화, 인력 손실 또는 지원 고객 증가)를 파악합니다.
+ 팀 성과에 미치는 영향 파악: 팀과 지속적으로 협력하여 팀의 업무 방식과 팀에 영향을 미치는 외부 요인을 파악합니다. 팀이 외부 요인의 영향을 받는 경우 목표를 재평가하고 적절하게 목표를 조정합니다. 팀 진행을 방해하는 장애물을 파악합니다. 팀을 대신해 장애물을 해결하고 불필요한 부담을 제거하는 데 도움을 줍니다.
+ 팀의 성공에 필요한 리소스 제공: 리소스가 여전히 적절한지, 추가 리소스가 필요한지 정기적으로 검토하고 지원 팀을 적절히 조정합니다.
# OPS03-BP08 팀 내부 및 여러 팀 간에 의견의 다양성 추구 및 장려
조직 간의 다양성을 활용하여 여러 가지 고유한 관점을 모색합니다. 이러한 관점을 통해 혁신을 증진하고, 기존의 추정 사항에 의문을 제기하며, 확증 편향의 위험을 줄일 수 있습니다. 팀 내에서 포용성, 다양성 및 접근성을 높여 유익한 관점을 확보합니다.
조직 문화는 팀원의 업무 만족도와 팀원 이직률에 직접적인 영향을 미칩니다. 팀원의 참여와 역량을 통해 비즈니스의 성공을 뒷받침할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 다양한 의견과 관점 모색: 모든 사람이 기여하도록 장려합니다. 대표가 불분명한 소수 그룹의 의견을 경청합니다. 미팅에서 역할과 책임을 교대로 맡습니다.
+ 역할 및 책임 확대: 다른 상황에서는 맡을 수 없는 역할을 담당할 수 있는 기회를 팀원에게 제공합니다. 마찬가지로 팀원은 다른 상황에서는 불가능할 수 있는 새로운 팀원과의 상호 작용 및 역할에서 경험과 관점을 얻습니다. 팀원은 상호 작용하는 새로운 역할과 팀원에 자신의 경험과 관점을 적용합니다. 관점이 증가함에 따라 추가적인 비즈니스 기회가 나타나거나 새로운 개선 기회를 찾을 수 있습니다. 팀원들로 하여금 다른 구성원들이 수행하는 일반적인 작업을 번갈아 수행하도록 하여 해당 작업의 요구 사항과 영향에 대한 이해를 돕습니다.
+ 안전하고 환영받는 환경 제공: 조직 내 팀원의 정신적, 신체적 안전을 보호하는 정책과 규제 수단을 마련합니다. 팀원은 보복에 대한 두려움 없이 상호 작용할 수 있어야 합니다. 팀원들이 안전하고 환영 받는다고 느낄 때 참여와 생산성이 향상됩니다. 조직이 다양할수록 고객을 비롯하여 지원하는 인력을 더 잘 이해할 수 있습니다. 팀원들이 편하고 자유롭게 이야기할 수 있고 자신의 의견이 존중된다고 확신할 때 마케팅 기회, 접근성 요구 사항, 소외된 시장 부문, 환경에서 알려지지 않은 위험과 같은 귀중한 인사이트를 공유할 가능성이 더 높아집니다.
+ 팀원의 완전한 참여 지원: 직원이 모든 업무 관련 활동에 완전히 참여하는 데 필요한 리소스를 제공합니다. 일상적인 문제에 직면하는 팀원들은 이러한 문제를 해결할 수 있는 기술을 개발했습니다. 이러한 고유하게 개발된 기술은 조직에 상당한 이점을 가져올 수 있습니다. 팀원들에게 필요한 설비를 지원하면 그들의 조력을 통해 얻을 수 있는 혜택이 늘어납니다.
# 준비
**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 정보에 입각하여 시스템 및 변경 사항 배포 결정
워크로드를 지원할 수 있는 팀의 능력과 워크로드의 거버넌스 준수 여부를 평가합니다. 배포의 이점을 기준으로 하여 이러한 평가를 수행해 시스템 또는 변경 사항을 프로덕션 환경으로 전환할지 여부를 결정합니다. 이점과 위험을 파악하면 정보에 입각한 결정을 내릴 수 있습니다.
사전 분석이란 팀이 완화 전략을 개발하기 위해 실패를 시뮬레이션하는 연습입니다. 사전 분석을 사용하여 실패를 예측하고 적절한 절차를 마련할 수 있습니다. 워크로드를 평가하는 데 사용하는 체크리스트를 변경할 때는 해당 변경으로 인해 더 이상 규정을 준수하지 않는 라이브 시스템에 대해 수행할 작업을 계획합니다.
**일반적인 안티 패턴:**
+ 워크로드의 보안 위험을 파악하지 않고 워크로드 배포를 결정합니다.
+ 워크로드가 거버넌스 및 표준을 준수하는지 여부를 파악하지 않고 워크로드 배포를 결정합니다.
+ 팀에서 지원할 수 있는지 여부를 파악하지 않고 워크로드 배포를 결정합니다.
+ 워크로드가 조직에 어떤 이점을 제공하는지 파악하지 않고 워크로드 배포를 결정합니다.
**이 모범 사례 수립의 이점:** 숙련된 팀원이 있으면 워크로드를 효과적으로 지원할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 정보에 입각하여 워크로드 및 변경 사항 배포 결정: 워크로드를 지원할 수 있는 팀의 능력과 워크로드의 거버넌스 준수 여부를 평가합니다. 배포의 이점을 기준으로 하여 이러한 평가를 수행해 시스템 또는 변경 사항을 프로덕션 환경으로 전환할지 여부를 결정합니다. 이점과 위험을 파악하고 정보에 입각한 결정을 내려야 합니다.
# 운영
**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)
**관련 예시:**
# 개선
**Topics**
+ [OPS 11 귀사는 어떻게 운영을 지속적으로 개선하고 있습니까?](w2aac19b5c11b5.md)
# OPS 11 귀사는 어떻게 운영을 지속적으로 개선하고 있습니까?
시간과 리소스를 할애하여 점진적 개선을 지속적으로 수행하면 운영 효율성을 높일 수 있습니다.
**Topics**
+ [OPS11-BP01 지속적인 개선을 위한 프로세스 마련](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 피드백 루프 구현](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 지식 관리 수행](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 개선 추진 요인 정의](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 인사이트 검증](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 운영 지표 검토 수행](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 파악한 내용 문서화 및 공유](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 개선을 위한 시간 할애](ops_evolve_ops_allocate_time_for_imp.md)
# OPS11-BP01 지속적인 개선을 위한 프로세스 마련
개선 기회를 정기적으로 평가하고 우선순위를 지정해 가장 큰 이점을 얻을 수 있는 영역에서 작업을 집중적으로 수행합니다.
**일반적인 안티 패턴:**
+ 개발 또는 테스트 환경을 생성하는 데 필요한 절차를 문서화했습니다. CloudFormation을 사용하여 프로세스를 자동화할 수 있지만, 대신 콘솔에서 수동으로 프로세스를 수행합니다.
+ 테스트 결과, 애플리케이션 내 CPU 사용률의 대다수가 몇몇의 비효율적인 기능에 기인함을 확인했습니다. 이를 개선하고 비용을 절감하는 데 집중할 수 있지만 새로운 사용 가능성 기능을 만들 수 있는 임무가 주어졌습니다.
**이 모범 사례 수립의 이점:** 지속적인 개선은 개선 기회를 정기적으로 평가하고 우선순위를 지정하고, 가장 큰 이점을 얻을 수 있는 영역에서 작업을 집중적으로 수행하는 메커니즘을 제공합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 지속적 개선을 위한 프로세스 정의: 개선 기회를 정기적으로 평가하고 우선순위를 지정하여 가장 큰 이점을 얻을 수 있는 영역에 작업을 집중적으로 수행합니다. 변경 사항을 적용하여 성과를 개선하고, 평가를 통하여 성공 여부를 확정합니다. 성과가 목표에 미치지 못하지만 여전히 개선을 우선해야 한다면 다른 대안을 찾아서 해당 과정을 반복합니다. 개선 가능한 운영 프로세스를 지속적으로 개선하기 위해서는 전담 리소스와 시간을 할애해야 합니다.
# OPS11-BP02 인시던트 사후 분석 수행
고객에게 영향을 주는 이벤트를 검토하고 기여 요인과 예방 조치를 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다.
**일반적인 안티 패턴:**
+ 애플리케이션 서버를 관리합니다. 약 23시간 55분마다 모든 활성 세션이 종료됩니다. 애플리케이션 서버에서 무엇이 잘못되었는지 파악하려고 했습니다. 네트워크 문제일 수도 있다고 생각하지만 네트워크 팀이 너무 바쁜 관계로 지원을 받을 수 없습니다. 지원을 받고 진행 상황을 파악하는 데 필요한 정보를 수집하기 위해 따라야 할 사전 정의된 프로세스가 없습니다.
+ 워크로드 내에서 데이터가 손실되었습니다. 이런 일은 처음이며 그 원인이 명확하지 않습니다. 데이터를 다시 생성할 수 있으므로 대수롭지 않은 일로 생각합니다. 데이터 손실이 발생하면서 고객에게 영향을 미치는 빈도가 증가합니다. 또한 이로 인해 누락된 데이터를 복원할 때 운영 부담이 가중됩니다.
**이 모범 사례 정립의 이점:** 인시던트에 기여한 구성 요소, 조건, 작업 및 이벤트를 결정하기 위해 사전 정의된 프로세스를 사용하면 개선 기회를 파악할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 프로세스를 사용하여 기여 요인 확인: 고객에게 영향을 미치는 모든 인시던트를 검토합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 인시던트의 기여 요인을 식별하고 문서화하는 프로세스를 마련합니다. 적절한 경우 근본 원인을 알리고 목표 대상에게 맞춤화된 프로세스를 마련합니다.
# OPS11-BP03 피드백 루프 구현
피드백 루프는 의사 결정을 추진하는 실행 가능한 인사이트를 제공합니다. 절차와 워크로드에 피드백 루프를 구축하세요. 이를 통해 문제와 개선이 필요한 영역을 파악할 수 있습니다. 또한 개선에 대한 투자를 검증합니다. 이러한 피드백 루프는 워크로드를 지속적으로 향상하기 위한 기반입니다.
피드백 루프의 두 가지 카테고리: *즉각적 피드백* 및 *후행 분석*. 즉각적 피드백은 운영 활동의 성과 및 결과를 검토하여 수집합니다. 이 피드백은 팀원, 고객 또는 자동화된 활동 출력으로부터 제공됩니다. A/B 테스트 및 새로운 기능 전달과 같은 사항을 통해 즉각적 피드백을 수신하며, 빠른 실패에 필수입니다.
시간 경과에 따른 운영 결과 및 지표 검토 결과의 피드백을 얻을 수 있도록 후행 분석이 정기적으로 수행됩니다. 이러한 후행 분석은 스프린트 후반, 정기적인 주기, 또는 주요 릴리스나 이벤트 이후 수행합니다. 이러한 유형의 피드백 루프는 운영 또는 워크로드의 투자를 검증합니다. 이를 통해 성공 여부를 측정하고 결과를 검증할 수 있습니다.
**원하는 결과:** 즉각적 피드백 및 후행 분석을 사용하여 개선을 추진할 수 있습니다. 사용자 및 팀원의 피드백을 얻을 수 있는 메커니즘이 있습니다. 후행 분석은 개선을 추진하는 트렌드를 파악하는 데 사용됩니다.
**일반적인 안티 패턴:**
+ 새로운 기능을 출시했지만 이에 대한 고객 피드백을 받을 수 있는 방법이 없습니다.
+ 운영 개선에 투자한 후 이를 검증할만한 후행 분석을 수행하지 않습니다.
+ 고객 피드백을 수집하지만 이를 정기적으로 검토하지 않습니다.
+ 피드백 루프를 통해 제안된 조치 항목을 얻지만 소프트웨어 개발 프로세스에 포함되지 않습니다.
+ 고객이 제안한 개선 사항에 대한 피드백을 받지 못합니다.
**이 모범 사례 확립의 이점:**
+ 고객의 입장에서 시작한 역방향 작업을 통해 새로운 기능을 이끌어낼 수 있습니다.
+ 조직 문화가 변화에 빠르게 반응할 수 있습니다.
+ 트렌드를 사용하여 개선 기회를 파악할 수 있습니다.
+ 후행 분석을 통해 워크로드 및 운영에 대한 투자를 검증할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
이 모범 사례를 구현하면 즉각적인 피드백과 후행 분석을 모두 사용하게 됩니다. 이러한 피드백 루프를 통해 개선을 추진할 수 있습니다. 설문 조사, 고객 투표, 피드백 양식 등 즉각적 피드백을 위한 다양한 메커니즘이 있습니다. 조직에서는 후행 분석도 사용하여 개선 기회를 파악하고 이니셔티브를 검증합니다.
**고객 사례**
AnyCompany Retail은 고객이 피드백을 제공하고 문제를 보고할 수 있는 웹 양식을 만들었습니다. 주간 스크럼 기간 동안 소프트웨어 개발 팀이 사용자 피드백을 평가합니다. 피드백은 플랫폼의 평가를 추진하는 데 정기적으로 사용됩니다. 각 스프린트의 후반에는 후행 분석을 수행하여 개선하고자 하는 항목을 파악합니다.
## 구현 단계
1. 즉각적 피드백
+ 고객 및 팀원으로부터 피드백을 수신할 수 있는 메커니즘이 필요합니다. 또한 자동 피드백을 제공하도록 운영 활동을 구성할 수 있습니다.
+ 조직은 이 피드백을 검토하고, 개선할 점을 결정하며 개선 일정을 지정하는 프로세스가 필요합니다.
+ 피드백이 소프트웨어 개발 프로세스에 반드시 추가되어야 합니다.
+ 개선 사항이 있을 때 피드백 제출자에게 후속 조치를 취합니다.
+ 이때 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 를 사용하여 이러한 개선 사항을 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html)로 생성하고 추적할 수 있습니다.
1. 후행 분석
+ 개발 주기의 마지막, 정기적인 주기, 또는 주요 릴리스 이후에 후행 분석을 수행합니다.
+ 후행 분석 회의를 위해 워크로드에 관련된 이해 관계자를 모읍니다.
+ 화이트보드나 스프레드시트에 중지, 시작 및 유지라는 세 개의 열을 만듭니다.
+ *중지* 는 팀에서 수행을 중지하고자 하는 항목입니다.
+ *시작* 은 시작하고자 하는 아이디어입니다.
+ *유지* 는 계속 하고자 하는 항목입니다.
+ 회의실을 한 바퀴 돌며 이해 관계자들의 피드백을 수렴합니다.
+ 피드백의 우선순위를 정합니다. 모든 시작 또는 유지 항목에 대한 활동 및 이해 관계자를 할당합니다.
+ 소프트웨어 개발 프로세스에 해당 활동을 추가하고 개선 작업을 수행할 때 이해 관계자에게 상태 업데이트를 전달합니다.
**구현 계획의 작업 수준:** 보통. 이 모범 사례를 구현하려면 즉각적인 피드백을 수렴하고 이를 분석할 수 있는 방법이 필요합니다. 또한 후행 분석 프로세스를 확립해야 합니다.
## 리소스
**관련 모범 사례:**
+ [OPS01-BP01 외부 고객 요구 평가](ops_priorities_ext_cust_needs.md): 피드백 루프는 외부 고객의 요구를 수집할 수 있는 메커니즘입니다.
+ [OPS01-BP02 내부 고객 요구 평가](ops_priorities_int_cust_needs.md): 내부 이해 관계자는 피드백 루프를 사용하여 필요 및 요구 사항을 논의합니다.
+ [OPS11-BP02 인시던트 사후 분석 수행](ops_evolve_ops_perform_rca_process.md): 인시던트 사후 분석은 인시던트 후 수행하는 후행 분석의 중요한 양식입니다.
+ [OPS11-BP07 운영 지표 검토 수행](ops_evolve_ops_metrics_review.md): 운영 지표 검토는 개선을 위한 트렌드와 영역을 파악합니다.
**관련 문서:**
+ [CCOE 구축 시 피해야 할 7가지 위험](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [Atlassian Team 플레이북 - 후행 분석](https://www.atlassian.com/team-playbook/plays/retrospective)
+ [이메일 정의: 피드백 루프](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/)
+ [AWS Well-Architected 프레임워크 검토를 기반으로 피드백 루프 확립](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/)
+ [IBM Garage 방법론 - 후행 분석 진행](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/)
+ [Investopedia – PDCS 주기](https://www.investopedia.com/terms/p/pdca-cycle.asp)
+ [Tim Cochran의 개발자 효율성 극대화](https://martinfowler.com/articles/developer-effectiveness.html)
+ [ORR(운영 준비 상태 검토) 백서 - 반복](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
+ [TIL CSI - 지속적인 서비스 개선](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+ [Toyota가 전자 상거래를 만났을 때: Amazon으로부터 배우기](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon)
**관련 동영상:**
+ [효과적인 고객 피드백 루프 구축](https://www.youtube.com/watch?v=zz_VImJRZ3U)
**관련 예시: **
+ [Astuto - 오픈 소스 고객 피드백 도구](https://github.com/riggraz/astuto)
+ [AWS 솔루션 - AWS의 QnABot](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/)
+ [Fider - 고객 피드백 구성을 위한 플랫폼](https://github.com/getfider/fider)
**관련 서비스:**
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS11-BP04 지식 관리 수행
팀원이 적시에 원하는 정보를 검색하고 액세스하며, 최신 상태의 완전한 정보인지 식별하는 메커니즘을 제공합니다. 필요한 콘텐츠, 갱신이 필요한 콘텐츠, 더 이상 참조되지 않도록 보관해야 하는 콘텐츠를 식별하는 메커니즘도 제공합니다.
**일반적인 안티 패턴:**
+ 불만을 가진 한 고객이 인지한 문제를 해결하기 위해 새로운 제품 기능 요청에 대한 지원 사례를 개시합니다. 우선순위 개선 목록에 이 사례가 추가됩니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 지식 관리: 팀원이 적시에 원하는 정보를 검색하고 확인하며, 최신 상태의 완전한 정보인지 파악할 수 있는 메커니즘을 제공합니다. 필요한 콘텐츠, 갱신이 필요한 콘텐츠, 더 이상 참조되지 않도록 보관해야 하는 콘텐츠를 식별하는 메커니즘을 보유합니다.
# OPS11-BP05 개선 추진 요인 정의
개선 기회를 평가하고 우선순위를 지정할 수 있도록 개선 추진 요인을 파악합니다.
AWS에서는 모든 운영 활동, 워크로드 및 인프라의 로그를 집계하여 상세 활동 이력을 생성할 수 있습니다. 그런 후에는 AWS 도구를 통해 시간별 운영 및 워크로드 상태를 분석하여 추진 요인을 기반으로 개선 기회를 파악할 수 있습니다. 예를 들어, 추세를 파악하고, 이벤트/활동과 성과의 상관 관계를 지정하고, 여러 환경과 시스템을 비교/대조할 수 있습니다.
CloudTrail을 사용해 AWS Management Console, CLI, SDK 및 API를 통해 API 활동을 추적하여 모든 계정에서 수행되는 작업을 확인해야 합니다. CloudTrail 및 CloudWatch를 사용하여 AWS 개발자 도구 배포 활동을 추적합니다. 이렇게 하면 배포의 자세한 활동 이력과 해당 결과가 CloudWatch Logs 로그 데이터에 추가됩니다.
[장기간 저장을 위해 Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 작업을 수행합니다. 여러분은 [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)를 사용하여 분석을 위해 Amazon S3의 로그 데이터를 검색 및 준비할 수 있습니다. 또한 [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)를 사용하면 AWS Glue와의 기본 통합을 통해 로그 데이터를 분석할 수 있습니다. 여러분은 [Quick](https://aws.amazon.com/quicksight/) 와 같은 비즈니스 인텔리전스 도구를 사용하여 데이터를 시각화하고 탐색하며 분석할 수 있습니다.
**일반적인 안티 패턴:**
+ 작동하지만 부적절한 스크립트가 있습니다. 시간을 들여 재작성합니다. 이제 완벽합니다.
+ 스타트업이 벤처 투자자로부터 또 다른 자금 지원을 받으려고 합니다. 고객은 PCI DSS 규정 준수를 입증하기를 원합니다. 고객의 요구를 들어주고 싶지만 규정 준수를 문서화하고 고객의 배송 날짜를 놓치면 고객을 잃게 됩니다. 잘못된 일은 아니었지만 옳은 일이었는지 궁금합니다.
**이 모범 사례 수립의 이점:** 개선에 사용할 기준을 결정하면 이벤트 기반 동기 또는 감정적 투자의 영향을 최소화할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 개선 추진 요인 파악: 원하는 결과가 지원되는 경우에만 시스템을 변경해야 합니다.
+ 필요한 기능: 개선 기회를 평가할 때 필요한 기능을 평가합니다.
+ [AWS의 새로운 소식](https://aws.amazon.com/new/)
+ 반드시 수정해야 할 문제: 개선 기회를 평가할 때 반드시 수정해야 할 문제, 버그 및 취약점을 평가합니다.
+ [최신 AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ 규정 준수 요건: 개선 기회를 검토할 때 규정/정책 준수 상태를 유지하거나 타사의 지원을 계속 받으려는 데 필요한 업데이트와 변경 사항을 평가합니다.
+ [AWS 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)
+ [AWS 규정 준수 최신 소식](https://aws.amazon.com/compliance/compliance-latest-news/)
## 리소스
**관련 문서:**
+ [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS 규정 준수](https://aws.amazon.com/compliance/)
+ [AWS 규정 준수 최신 소식](https://aws.amazon.com/compliance/compliance-latest-news/)
+ [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/)
+ [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [최신 AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [장기간 저장을 위해 Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [AWS의 새로운 소식](https://aws.amazon.com/new/)
# OPS11-BP06 인사이트 검증
여러 부문의 팀 및 비즈니스 소유자와 함께 분석 결과와 응답을 검토합니다. 이러한 검토에서는 개선 가능성을 공통적으로 파악하고, 추가적인 영향을 확인하고, 조치 과정을 결정할 수 있습니다. 필요에 따라 대응 내용을 조정합니다.
**일반적인 안티 패턴:**
+ 시스템에서 CPU 사용률이 95%이며 시스템의 부하를 줄이는 방법을 찾기 위해 이를 최우선 과제로 삼습니다. 가장 좋은 조치는 확장하는 것입니다. 시스템은 트랜스코더이며 항상 95%의 CPU 사용률로 실행되도록 확장됩니다. 시스템 소유자에게 문의했다면 상황을 설명할 수 있었을 것입니다. 시간이 낭비되었습니다.
+ 시스템 소유자는 시스템이 미션 크리티컬하다고 주장합니다. 시스템이 보안 수준이 높은 환경에 배치되지 않았습니다. 보안을 강화하기 위해 미션 크리티컬 시스템에 필요한 탐지 및 예방 제어 기능을 추가로 구현합니다. 작업이 완료되고 추가 리소스에 대한 요금이 청구될 것임을 시스템 소유자에게 알립니다. 알림을 받고 진행한 논의에서 시스템 소유자는 시스템이 충족하지 못하는 미션 크리티컬 시스템에 대한 공식적인 정의가 있음을 알게 됩니다.
**이 모범 사례 정립의 이점:** 비즈니스 소유자 및 주제 전문가와 함께 인사이트를 확인하여 공통된 이해를 확립하고 개선 사항을 좀 더 효과적으로 안내할 수 있습니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 인사이트 검증: 비즈니스 소유자 및 주제별 전문가와 협력하여 수집한 데이터의 의미에 대한 공통된 이해와 동의가 있는지 확인합니다. 추가 우려 사항, 잠재적 영향을 식별하고 조치 과정을 결정합니다.
# OPS11-BP07 운영 지표 검토 수행
다양한 실무 영역의 여러 팀 구성원들과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. 이러한 검토에서는 개선 기회와 진행 가능한 조치 과정을 파악하고 배운 내용을 공유할 수 있습니다.
개발, 테스트, 프로덕션 등 모든 환경에서 향상 기회를 모색해야 합니다.
**일반적인 안티 패턴:**
+ 유지 관리 기간으로 인해 상당한 소매 프로모션이 중단되었습니다. 기업에서는 비즈니스에 영향을 미치는 다른 이벤트가 있는 경우 지연될 수 있는 표준 유지 관리 기간이 있음을 모릅니다.
+ 조직에서 일반적으로 사용되는 버그가 많은 라이브러리 사용으로 인해 장기간 가동이 중단되었습니다. 이후 신뢰할 수 있는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 정기적으로 만나고 이 인시던트를 검토했다면 이들도 위험을 알았을 것입니다.
+ 트랜스코더의 성능이 지속적으로 저하되어 미디어 팀에 영향을 미치고 있습니다. 아직 심각하지는 않습니다. 인시던트를 발생시키기에 충분히 나쁜 상태가 될 때까지 알 수 없습니다. 미디어 팀과 운영 지표를 검토했다면 지표의 변화와 그 경험을 인식하고 문제를 해결할 기회가 있었을 것입니다.
+ 고객 SLA 만족도를 검토하고 있지 않습니다. 고객 SLA를 충족하지 못하는 추세입니다. 고객 SLA를 충족하지 못할 경우 재정적 징벌이 부과될 수 있습니다. 이러한 SLA의 지표를 정기적으로 검토했다면 문제를 파악하고 해결할 수 있는 기회가 있었을 것입니다.
**이 모범 사례 정립의 이점:** 운영 지표, 이벤트 및 인시던트를 검토하기 위해 정기적으로 회의를 진행하여 팀 전체에서 공통된 이해를 유지하고, 배운 내용을 공유하고, 개선 사항의 우선순위와 대상을 정합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 운영 지표 검토: 다양한 실무 영역의 여러 팀 구성원들과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. 실무 팀, 개발 팀, 운영 팀 등의 이해 관계자와 함께 즉각적인 피드백 및 후행 분석에서 발견된 사항을 확인하고 파악한 내용을 공유합니다. 그리고 이러한 인사이트를 활용하여 개선 기회와 진행 가능한 조치 과정을 확인합니다.
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 지표 및 차원 참조](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [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)
+ [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS11-BP08 파악한 내용 문서화 및 공유
운영 활동 과정에서 파악한 내용을 문서화하고 공유하여 내부적으로, 그리고 여러 팀 간에 사용할 수 있도록 하십시오.
조직 전체에서 관련 이점을 더욱 효율적으로 활용하려면 팀에서 파악한 내용을 공유해야 합니다. 피할 수 있는 오류를 방지하고 개발 작업을 쉽게 수행하기 위해 정보와 리소스를 공유할 수 있습니다. 이렇게 하면 원하는 기능을 제공하는 데 집중할 수 있습니다.
AWS Identity and Access Management(IAM)를 사용하여 계정 내/계정 간에 공유할 리소스 액세스를 제어할 수 있는 권한을 정의합니다. 그런 다음 버전 제어 AWS CodeCommit 리포지토리를 사용하여 애플리케이션 라이브러리, 스크립팅된 절차, 절차 설명서 및 기타 시스템 설명서를 공유해야 합니다. 여러 계정에 Lambda 함수 사용 권한을 부여하고 AMI 액세스를 공유하는 방식을 통해 컴퓨팅 표준을 공유합니다. 인프라 표준도 AWS CloudFormation 템플릿으로 공유해야 합니다.
AWS API 및 SDK를 사용하면 GitHub, BitBucket, SourceForge 등의 외부 및 타사 도구와 리포지토리를 통합할 수 있습니다. 파악한 내용과 개발한 기능을 공유할 때는 공유 리포지토리 무결성을 유지할 수 있도록 권한의 구조를 지정해야 합니다.
**일반적인 안티 패턴:**
+ 조직에서 일반적으로 사용되는 버그가 많은 라이브러리 사용으로 인해 장기간 가동이 중단되었습니다. 이후 신뢰할 수 있는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들도 위험에 대해 알았을 것입니다.
+ 내부적으로 공유된 마이크로서비스에서 세션 중단을 일으키는 엣지 사례를 발견했습니다. 이 엣지 사례를 방지하기 위해 서비스에 대한 호출을 업데이트했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들도 위험에 대해 알았을 것입니다.
+ 마이크로서비스 중 하나에 대한 CPU 사용률 요구 사항을 크게 줄일 수 있는 방법을 찾았습니다. 다른 팀에서 이 기술을 활용할 수 있는지 여부는 알 수 없습니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들에게도 그렇게 할 기회가 있었을 것입니다.
**이 모범 사례 수립의 이점:** 개선을 지원하고 경험의 이점을 극대화하기 위해 파악한 내용을 공유합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 파악한 내용 문서화 및 공유: 운영 활동을 실행하면서 파악한 내용과 후행 분석 결과를 문서화하는 절차를 마련하여 다른 팀에서도 사용할 수 있도록 합니다.
+ 파악한 내용 공유: 파악한 내용 및 관련 작업 결과를 팀 간에 공유할 수 있는 절차를 마련합니다. 예를 들어, 접속 가능한 위키를 통해 새로워진 절차, 지침, 거버넌스 및 모범 사례를 공유하십시오. 스크립트, 코드 및 라이브러리는 공동 리포지토리를 통해 공유할 수 있습니다.
+ [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로 템플릿 공유 속도 향상](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로 템플릿 공유 속도 향상](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)
# OPS11-BP09 개선을 위한 시간 할애
프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다.
AWS에서는 실험과 테스트의 위험, 작업량 및 비용을 줄일 수 있는 환경의 임시 복제본을 생성할 수 있습니다. 이렇게 복제된 환경을 사용하여 분석의 결론을 테스트하고, 실험을 진행하고, 계획된 향상 내용을 개발/테스트할 수 있습니다.
**일반적인 안티 패턴:**
+ 애플리케이션 서버에 알려진 성능 문제가 있습니다. 이는 계획된 모든 기능 구현 뒤의 백로그에 추가됩니다. 추가 예정인 계획된 기능의 비율이 일정하게 유지되는 경우 성능 문제는 해결되지 않습니다.
+ 지속적인 개선 지원을 위해 관리자 및 개발자가 개선 사항을 선택하고 구현하는 데 여분의 시간을 모두 할애하는 것을 승인합니다. 개선이 완료되지 않습니다.
**이 모범 사례 정립의 이점:** 프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다.
**이 모범 사례를 정립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
+ 개선을 위한 시간 할애: 프로세스에 리소스와 시간을 투자하여 가능한 범위 내에서 점진적이고 지속적인 개선을 수행합니다. 변경 사항을 적용하여 결과를 개선하고, 평가를 통하여 성공 여부를 확정합니다. 결과가 목표에 미치지 못하지만 여전히 개선을 우선해야 한다면 다른 대안을 찾아서 진행합니다.