# 조직
<a name="a-organization"></a>

**Topics**
+ [OPS 1  귀사의 운영 우선순위를 결정하는 요인은 무엇입니까?](w2aac19b5b5b5.md)
+ [OPS 2  비즈니스 성과를 지원하기 위해 조직을 어떻게 구성합니까?](w2aac19b5b5b7.md)
+ [OPS 3  조직 문화는 비즈니스 성과를 어떻게 지원합니까?](w2aac19b5b5b9.md)

# OPS 1  귀사의 운영 우선순위를 결정하는 요인은 무엇입니까?
<a name="w2aac19b5b5b5"></a>

 모든 직원이 효율적인 업무 수행을 위한 역할과 리소스 우선 순위 설정을 위한 공동의 목표를 파악하고 있어야 합니다. 그러면 운영 개선 작업의 이점을 극대화할 수 있습니다. 

**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 외부 고객 요구 평가
<a name="ops_priorities_ext_cust_needs"></a>

 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 외부 고객 요구 충족을 위해 주력할 영역을 결정합니다. 이렇게 하면 원하는 비즈니스 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  핵심 업무 시간 이외에 고객 지원을 하기로 결정했지만 과거 지원 요청 데이터를 검토하지 않았습니다. 이것이 고객에게 영향을 미치는지 여부는 알 수 없습니다. 
+  새로운 기능을 개발 중이지만 고객이 원하는 기능이고 원하는 형태인지 확인하지 않았으며 요구 사항과 제공 방법을 확인하기 위한 실험도 진행하지 않습니다. 

 **이 모범 사례 정립의 이점:** 요구가 충족되는 경우 고객으로 남을 가능성이 훨씬 더 높습니다. 외부 고객 요구를 평가하고 이해하면 비즈니스 가치를 제공하기 위해 작업의 우선순위를 정하는 방법을 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  비즈니스 요구 사항 파악: 비즈니스의 성공은 실무 팀, 개발 팀, 운영 팀을 비롯한 모든 이해관계자가 서로 목표와 이해를 공유하면서 실현됩니다. 
  +  외부 고객의 비즈니스 목표, 요구 사항 및 우선순위 검토: 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 외부 고객의 목표, 요구 사항 및 우선순위를 논의합니다. 이렇게 하면 비즈니스 및 고객 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다. 
  +  공유된 이해 관계 수립: 워크로드의 비즈니스 기능과 워크로드 작동 과정에서 각 팀의 역할을 비롯하여 이러한 요소가 내외부 고객의 공동 비즈니스 목표를 지원하는 방식에 대한 공유된 이해 관계를 정립합니다. 

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

 **관련 문서:** 
+  [AWS Well-Architected Framework 개념 – 피드백 루프](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP02 내부 고객 요구 평가
<a name="ops_priorities_int_cust_needs"></a>

 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 내부 고객 요구 충족을 위한 주력할 영역을 결정합니다. 이렇게 하면 비즈니스 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다. 

 설정한 우선순위를 활용해 가장 영향력이 큰 개선 작업 부분부터 중점적으로 수행합니다. 팀 기술 개발, 워크로드 성능 개선, 비용 절감, 런북 자동화, 모니터링 기능 향상 등을 예로 들 수 있습니다. 요구 사항이 변경되면 우선 순위를 업데이트합니다. 

 **일반적인 안티 패턴:** 
+  네트워크를 보다 쉽게 관리할 수 있도록 제품 팀의 IP 주소 할당을 상의하지 않고 변경하기로 결정했습니다. 이것이 제품 팀에 어떤 영향을 미칠지 알 수 없습니다. 
+  새로운 개발 도구를 구현하고 있지만 내부 고객에게 이 도구가 필요한지 여부나 기존 사례와 호환되는지 여부를 확인하지 않았습니다. 
+  새 모니터링 시스템을 구현하고 있지만 고려해야 할 모니터링 또는 보고 요구 사항이 있는지 내부 고객에게 문의하지 않았습니다. 

 **이 모범 사례 수립의 이점:** 내부 고객 요구를 평가하고 이해하면 비즈니스 가치를 제공하기 위해 작업의 우선순위를 정하는 방법을 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  비즈니스 요구 사항 파악: 비즈니스의 성공은 실무 팀, 개발 팀, 운영 팀을 비롯한 모든 이해관계자가 서로 목표와 이해를 공유하면서 실현됩니다. 
  +  내부 고객의 비즈니스 목표, 요구 사항 및 우선순위 검토: 실무 팀, 개발 팀, 운영 팀 등의 주요 이해관계자와 함께 내부 고객의 목표, 요구 사항 및 우선순위를 논의합니다. 이렇게 하면 비즈니스 및 고객 성과 달성에 필요한 운영 지원을 철저하게 파악할 수 있습니다. 
  +  공유된 이해 관계 수립: 워크로드의 비즈니스 기능과 워크로드 작동 과정에서 각 팀의 역할을 비롯하여 이러한 요소가 내외부 고객의 공동 비즈니스 목표를 지원하는 방식에 대한 공유된 이해 관계를 정립합니다. 

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

 **관련 문서:** 
+  [AWS Well-Architected Framework 개념 – 피드백 루프](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP03 거버넌스 요구 사항 평가
<a name="ops_priorities_governance_reqs"></a>

 조직에서 특정 사항을 준수하거나 강조하기 위해 정의한 지침이나 의무 사항을 알고 있어야 합니다. 조직 정책, 표준 및 요구 사항과 같은 내부 요인을 평가합니다. 거버넌스에 대한 변경 사항을 식별할 수 있는 메커니즘이 있는지 확인합니다. 거버넌스 요구 사항이 식별되지 않는 것으로 결론을 내릴 때에는 신중하게 판단하여 내린 결론인지 재차 확인해야 합니다. 

 **일반적인 안티 패턴:** 
+  감사를 받고 있으며 내부 거버넌스에 대한 규정 준수 증명을 제출해야 합니다. 규정 준수 요구 사항을 평가한 적이 없기 때문에 규정 준수 여부도 알 수 없습니다. 
+  재정적 손실을 초래하는 손상을 겪었습니다. 재정적 손실에 대한 보험이 거버넌스에서 요구하지만 마련되어 있지 않은 특정 보안 제어의 구현을 조건으로 함을 알게 됩니다. 
+  관리 계정이 손상되어 회사 웹 사이트와 고객 신뢰가 손상되었습니다. 내부 거버넌스는 다중 인증(MFA)을 사용하여 관리 계정을 보호하도록 요구합니다. MFA로 관리 계정을 보호하지 않았으며 징계 조치 대상입니다. 

 **이 모범 사례 정립의 이점:** 조직이 워크로드에 적용하는 거버넌스 요구 사항을 평가하고 이해하면 비즈니스 가치를 제공하기 위한 작업의 우선순위를 정하는 방법을 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  거버넌스 요구 사항 이해: 프로그램 또는 조직 정책, 프로그램 정책, 문제 또는 시스템별 정책, 표준, 절차, 기준 및 지침과 같은 내부 거버넌스 요소를 평가합니다. 거버넌스에 대한 변경 사항을 식별할 수 있는 메커니즘이 있는지 확인합니다. 거버넌스 요구 사항이 식별되지 않는 것으로 결론을 내릴 때에는 신중하게 판단하여 내린 결론인지 재차 확인해야 합니다. 

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

 **관련 문서:** 
+  [AWS 클라우드 규정 준수](https://aws.amazon.com/compliance/) 

# OPS01-BP04 규정 준수 요구 사항 평가
<a name="ops_priorities_compliance_reqs"></a>

 규정 준수 요구 사항 및 산업 표준과 같은 외부 요인을 평가하여 특정 작업을 반드시/집중적으로 수행해야 할 수 있는 의무 사항이나 지침을 파악해야 합니다. 규정 준수 요구 사항이 확인되지 않으면 적절한 판단에 따라 해당 요구 사항을 결정해야 합니다. 

 **일반적인 안티 패턴:** 
+  감사를 받고 있으며 산업 규정 준수 증명을 제출해야 합니다. 규정 준수 요구 사항을 평가한 적이 없기 때문에 규정 준수 여부도 알 수 없습니다. 
+  관리 계정이 손상되어 고객 데이터가 다운로드되고 고객 신뢰가 손상되었습니다. 업계 모범 사례는 MFA를 사용하여 관리 계정을 보호할 것을 요구합니다. MFA로 관리 계정을 보호하지 않았으며 고객의 소송 대상입니다. 

 **이 모범 사례 정립의 이점:** 워크로드에 적용되는 규정 준수 요구 사항을 평가하고 이해하면 비즈니스 가치를 제공하기 위한 작업의 우선순위를 정하는 방법을 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  규정 준수 요구 사항 이해: 규정 준수 요구 사항 및 산업 표준과 같은 외부 요인을 평가하여 구체적인 초점을 맞춰 반드시/집중적으로 수행해야 할 수 있는 의무 사항이나 지침을 숙지하고 있는지 확인합니다. 규정 준수 요구 사항이 확인되지 않으면 적절한 판단에 따라 해당 요구 사항을 결정했는지 확인합니다. 
  +  규정 준수 요구 사항 이해: 법적 이행 의무가 있는 규정 준수 요구 사항을 파악합니다. 그리고 이러한 요구 사항을 충족할 수 있는 운영 작업을 중점적으로 수행합니다. 예를 들면 개인 정보 보호 및 데이터 보호 조항의 의무 사항이 여기에 해당합니다. 
    +  [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/) 
  +  내부 규정 준수 요구 사항 파악: 조직에서 수립한 규정 준수 요구 사항 및 모범 사례를 파악합니다. 그리고 이러한 요구 사항을 충족할 수 있는 운영 작업을 중점적으로 수행합니다. 정보 보안 정책 및 데이터 분류 표준을 예로 들 수 있습니다. 

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

 **관련 문서:** 
+  [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 위협 환경 평가
<a name="ops_priorities_eval_threat_landscape"></a>

 비즈니스에 대한 위협 요소(예: 경쟁, 비즈니스상의 위험 및 법적 책임, 운영상의 위험, 정보 보안 위협)를 평가하고 위험 목록에서 최신 정보를 관리합니다. 주력할 영역을 결정할 때 위험의 영향을 포함시킵니다. 

 유효 [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/) 우선순위를 더욱 자세히 결정하는 데 사용할 수 있는 추가 검사 기능이 제공됩니다. 이러한 기능을 사용하면 보안, 안정성, 성능 및 비용 최적화 영역을 중점적으로 확인할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  제품에서 이전 버전의 소프트웨어 라이브러리를 사용하고 있습니다. 워크로드에 의도하지 않은 영향을 줄 수 있는 문제에 대한 라이브러리의 보안 업데이트에 대해 모릅니다. 
+  경쟁업체가 제품에 대한 많은 고객 불만 사항을 해결하는 제품 버전을 출시했습니다. 이러한 알려진 문제 해결에 우선순위를 지정하지 않았습니다. 
+  규제 기관이 법률 규정 준수 요구 사항을 준수하지 않는 귀사와 같은 회사를 추적하고 있습니다. 미해결 규정 준수 요구 사항 해결에 우선순위를 지정하지 않았습니다. 

 **이 모범 사례 수립의 이점:** 조직 및 워크로드에 대한 위협을 식별하고 이해하면 해결할 위협, 우선순위 및 이를 수행하는 데 필요한 리소스를 결정하는 데 도움이 됩니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  위협 환경 평가: 주력할 영역을 결정할 때 영향력을 고려할 수 있도록 업무상의 위협 요소(예: 경쟁, 업무상의 위험/책임, 운영상의 위험, 정보 보안 위협)를 평가합니다. 
  +  [최신 AWS 보안 공지](https://aws.amazon.com/security/security-bulletins/) 
  +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  위협 모델 유지 관리: 잠재적 위협, 계획되어 실행 중인 완화 조치 및 각 우선순위를 식별하는 위협 모델을 수립하고 유지 관리합니다. 인시던트로 나타나는 위협의 가능성, 해당 인시던트로부터 복구하는 비용 및 예상되는 피해, 이러한 인시던트를 방지하는 비용을 검토합니다. 위협 모델의 내용이 변경됨에 따라 우선순위를 수정합니다. 

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

 **관련 문서:** 
+  [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 장단점 평가
<a name="ops_priorities_eval_tradeoffs"></a>

 주력할 영역을 결정하거나 수행할 조치를 선택할 때 정보를 토대로 결정을 내릴 수 있도록 상충하는 이해 관계나 대안 사이의 장단점을 평가합니다. 예를 들어, 비용 최적화보다 새로운 기능의 시장 출시를 앞당기는 데 더 역점을 둘 수 있습니다. 아니면 데이터 유형에 최적화된 데이터베이스로 마이그레이션하고 애플리케이션을 업데이트하는 대신, 시스템 마이그레이션 작업을 간소화하기 위해 비관계형 데이터용 솔루션으로 관계형 데이터베이스를 선택할 수도 있습니다. 

 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)를 준수함을 입증할 것을 요청합니다. 요청을 충족하는 것과 현재 개발 작업을 계속하는 것 사이의 장단점을 고려하지 않습니다. 대신 규정 준수를 입증하지 않고 개발 작업을 계속 진행합니다. 투자자는 플랫폼 보안과 투자에 대한 우려 사항으로 인해 회사의 지원을 중단합니다. 

 **이 모범 사례 수립의 이점:** 선택에 따른 영향과 결과를 이해하면 옵션의 우선순위를 정할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  장단점 평가: 주력할 영역을 결정할 때 정보를 토대로 적절한 결정을 내릴 수 있도록 상충하는 이해관계의 장단점을 평가합니다. 예를 들어 새로운 기능의 출시 기간을 단축하는 것이 비용 최적화보다 우선시될 수 있습니다. 
+  AWS를 활용하면 선택한 방식이 워크로드에 미치는 영향을 효과적으로 파악하도록 팀에 AWS 및 해당 서비스 관련 정보를 제공할 수 있습니다. AWS Support(AWS 지식 센터, AWS 토론 포럼, AWS Support 센터) 및 AWS 설명서에 나와 있는 리소스를 사용해서 팀을 교육해야 합니다. AWS 관련 문의 사항에 대해 지원을 받으려면 AWS Support 센터를 통해 AWS Support에 지원을 요청하십시오. 
+  또한 AWS는 AWS의 운영을 통해 학습한 모범 사례와 패턴을 Amazon Builders' Library에서 공유합니다. AWS 블로그 및 공식 AWS 팟캐스트에서도 기타 여러 가지 유용한 정보를 확인할 수 있습니다. 

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

 **관련 문서:** 
+  [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 이점 및 위험 관리
<a name="ops_priorities_manage_risk_benefit"></a>

 주력할 영역을 결정할 때 정보를 토대로 적절한 결정을 내릴 수 있도록 이점과 위험을 관리합니다. 예를 들어 새 기능을 고객에게 제공하기 위해 해결되지 않은 문제가 남아 있는 워크로드를 배포하는 것이 이득일 수 있습니다. 관련 위험을 완화할 수도 있겠지만, 위험을 감수할 수 없는 경우에는 위험을 해결하기 위한 조치를 취해야 합니다. 

 특정 시점에 우선순위 중 일부를 중점적으로 처리해야 할 수도 있습니다. 필요한 기능을 개발하고 위험을 관리하려면 워크로드 우선순위를 장기적으로 적절하게 절충해야 합니다. 요구 사항이 변경되면 우선순위를 업데이트합니다. 

 **일반적인 안티 패턴:** 
+  한 개발자가 인터넷에서 찾은 필요한 모든 것을 수행하는 라이브러리를 포함하기로 했습니다. 출처를 알 수 없는 이 라이브러리의 도입에 따른 위험을 평가하지 않았으며 취약성 또는 악성 코드가 포함되어 있는지 알 수 없습니다. 
+  기존 문제를 해결하는 대신 새 기능을 개발하고 배포하기로 결정했습니다. 배포 전까지 이 기능에 남아 있는 문제의 위험을 평가하지 않았으며 고객에게 어떤 영향이 있을지 모릅니다. 
+  규정 준수 팀의 불특정 우려 때문에 고객이 자주 요청하는 기능을 배포하지 않기로 결정했습니다. 

 **이 모범 사례 수립의 이점:** 선택 시 얻을 수 있는 이점을 파악하고 조직의 위험을 인식하면 정보에 입각한 결정을 내릴 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  이점 및 위험 관리: 결정으로 인해 누릴 수 있는 이점과 수반되는 위험의 균형을 잡습니다. 
  +  이점 파악: 비즈니스 목표, 필요 사항 및 우선순위에 따른 이점을 파악합니다. 출시 리드타임, 보안, 신뢰성, 성능 및 비용이 이에 해당합니다. 
  +  위험 요소 파악: 비즈니스 목표, 필요 사항 및 우선순위에 따른 위험 요소를 파악합니다. 출시 리드타임, 보안, 신뢰성, 성능 및 비용이 이에 해당합니다. 
  +  위험 대비 이점 평가 및 정보에 입각한 의사 결정: 실무/개발/운영 팀을 비롯한 주요 이해관계자의 목표, 필요 사항 및 우선순위를 기준으로 하여 이점과 위험의 영향을 파악합니다. 위험 발생 가능성 및 해당 위험이 주는 영향의 비용 대비 이점의 가치를 평가합니다. 예를 들어, 안정성보다 시장 진입 속도를 강조하면 경쟁 우위를 제공할 수 있습니다. 하지만 안정성 문제가 있는 경우 가동 시간이 단축될 수 있습니다. 

# OPS 2  비즈니스 성과를 지원하기 위해 조직을 어떻게 구성합니까?
<a name="w2aac19b5b5b7"></a>

 팀은 비즈니스 성과를 달성하기 위해 맡은 역할을 파악해야 합니다. 그리고 다른 팀의 성공을 위해 자신의 팀이 해야 할 역할과 해당 팀이 해야 할 역할을 파악하고, 목표를 공유해야 합니다. 맡은 책임, 소유권, 의사 결정 방식 및 의사 결정권자를 파악하면 역량을 집중하고 팀의 이점을 극대화할 수 있습니다. 

**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 리소스 소유자 식별
<a name="ops_ops_model_def_resource_owners"></a>

 각 애플리케이션, 워크로드, 플랫폼 및 인프라 구성 요소의 소유권, 해당 구성 요소가 제공하는 비즈니스 가치, 그리고 소유권이 존재하는 이유를 파악합니다. 이러한 개별 구성 요소의 비즈니스 가치를 파악하고 이들이 비즈니스 성과를 어떻게 지원하는지 파악하면 해당 구성 요소에 적용되는 프로세스와 절차를 알 수 있습니다. 

 **이 모범 사례 정립의 이점:** 소유권을 파악하면 누가 개선 사항 승인 또는 구현을 수행하거나 둘 다 수행할 수 있는지 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  리소스 소유자 식별: 환경의 리소스 사용 사례에 대한 소유권 의미를 정의합니다. 최소한 이름, 연락처 정보, 조직 및 팀을 포함하여 리소스 소유자를 지정하고 기록합니다. 태그 또는 리소스 그룹과 같은 메타데이터를 사용하여 리소스와 함께 리소스 소유권 정보를 저장합니다. AWS Organizations를 사용하여 계정을 구성하고 소유권 및 연락처 정보가 캡처되도록 정책을 구현합니다. 
  +  소유권 형태 및 할당 방법 정의: 사용 사례가 서로 다른 조직에서는 소유권에 대한 정의가 다양할 수 있습니다. ‘워크로드 소유자’를 워크로드 운영의 위험을 부담하고 책임을 지며 궁극적으로 워크로드 관련 결정을 내릴 권한이 있는 개인으로 정의할 수 있습니다. 소유권이 상위 조직에 롤업되는 재무 또는 관리 책임의 관점에서 소유권을 정의할 수 있습니다. 개발자는 개발 환경의 소유자일 수 있으며 운영에 따른 인시던트에 대한 책임이 있습니다. 제품 책임자는 개발 환경의 운영과 관련된 재정적 비용에 대한 책임을 부담할 수 있습니다. 
  +  조직, 계정, 리소스 모음 또는 개별 구성 요소의 소유자 정의: 검색을 지원하도록 구성된 적절하게 액세스 가능한 위치에서 소유권을 정의하고 기록합니다. 변경 시 정의와 소유권 세부 정보를 업데이트합니다. 
  +  리소스에 대한 메타데이터에서 소유권 캡처: 태그 또는 리소스 그룹과 같은 메타데이터를 사용하고 소유권과 연락처 정보를 지정하여 리소스 소유권을 캡처합니다. AWS Organizations를 사용하여 계정을 구성하고 소유권 및 연락처 정보가 캡처되도록 합니다. 

# OPS02-BP02 프로세스 및 절차의 소유자 식별
<a name="ops_ops_model_def_proc_owners"></a>

 개별 프로세스와 절차의 정의에 대한 소유권이 있는 사람, 그러한 특정 프로세스와 절차가 사용되는 이유, 그리고 소유권이 존재하는 이유를 파악합니다. 특정 프로세스 및 절차가 사용되는 이유를 이해하면 개선 기회를 파악할 수 있습니다. 

 **이 모범 사례 수립의 이점:** 소유권을 파악하면 누가 개선 사항 승인 또는 구현을 수행하거나 둘 다 수행할 수 있는지 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  프로세스 및 절차에서 정의를 담당하는 소유자 식별: 환경에서 사용되는 프로세스 및 절차와 정의를 담당하는 개인 또는 팀을 캡처합니다. 
  +  프로세스 및 절차 식별: 워크로드 지원을 위해 수행되는 운영 활동을 식별합니다. 검색 가능한 위치에 이러한 활동을 문서화합니다. 
  +  프로세스 또는 절차 정의 소유자 지정: 활동 지정을 담당하는 개인 또는 팀을 고유하게 식별합니다. 이들은 올바른 권한, 액세스 및 도구와 적절한 기술을 갖춘 팀원이 활동을 성공적으로 수행할 수 있도록 할 책임이 있습니다. 해당 활동을 수행하는 데 문제가 있는 경우 활동을 수행하는 팀원은 활동 개선에 필요한 상세한 피드백을 제공할 책임이 있습니다. 
  +  활동 아티팩트의 메타데이터에서 소유권 캡처: AWS Systems Manager, 문서 및 AWS Lambda와 같은 서비스에서 함수로 자동화된 절차를 사용하면 메타데이터 정보를 태그로 캡처할 수 있습니다. 태그 또는 리소스 그룹을 사용하여 리소스 소유권을 캡처하고 소유권 및 연락처 정보를 지정합니다. AWS Organizations를 사용하여 태그 지정 정책을 생성하고 소유권 및 연락처 정보가 캡처되도록 합니다. 

# OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별
<a name="ops_ops_model_def_activity_owners"></a>

 정의된 워크로드를 대상으로 하는 특정 활동 수행에 대한 책임 소재와 그러한 책임이 존재하는 이유를 파악합니다. 활동 수행에 대한 책임 소재를 파악하면 누가 작업을 수행하고, 누가 결과를 확인하며, 누가 활동 소유자에게 피드백을 제공할지 알 수 있습니다. 

 **이 모범 사례 정립의 이점:** 활동 수행에 대한 책임 소재를 파악하면 작업이 필요할 때 누구에게 알릴지, 누가 작업을 수행하고 결과를 확인하며 활동 소유자에게 피드백을 제공할지 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  운영 활동에서 성과를 담당하는 소유자 식별: 환경에서 사용되는 프로세스 및 절차 수행에 대한 책임 소재를 파악합니다. 
  +  프로세스 및 절차 식별: 워크로드 지원을 위해 수행되는 운영 활동을 식별합니다. 검색 가능한 위치에 이러한 활동을 문서화합니다. 
  +  각 활동 수행에 대한 책임 소재 정의: 활동을 담당하는 팀을 식별합니다. 활동 세부 정보, 활동 수행에 필요한 기술, 올바른 권한, 액세스 및 도구를 갖추고 있는지 확인합니다. 활동 수행 조건(예: 이벤트 또는 일정)을 파악해야 합니다. 조직의 구성원이 특정 요구 사항에 대해 연락할 팀이나 개인을 식별할 수 있도록 이 정보를 검색할 수 있게 설정합니다. 

# OPS02-BP04 팀원이 담당해야 하는 업무 파악
<a name="ops_ops_model_know_my_job"></a>

 역할의 책임과 비즈니스 성과에 기여하는 방법을 파악하면 작업의 우선순위와 역할이 중요한 이유를 알 수 있습니다. 이를 통해 팀원은 요구 사항을 인식하고 적절하게 대응할 수 있습니다. 

 **이 모범 사례 정립의 이점:** 책임을 파악하면 사용자가 내리는 결정, 취하는 조치, 적절한 소유자에게 활동 전달을 알 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  팀원의 역할 및 책임 파악: 팀원의 역할과 책임을 식별하고 맡은 역할에 대한 기대치를 이해하도록 합니다. 조직의 구성원이 특정 요구 사항에 대해 연락할 팀이나 개인을 식별할 수 있도록 이 정보를 검색할 수 있게 설정합니다. 

# OPS02-BP05 책임과 소유권을 식별하는 메커니즘
<a name="ops_ops_model_find_owner"></a>

 개인이나 팀을 식별하지 못할 경우 소유권을 할당하거나 요구 사항 충족을 위한 계획을 수립할 권한이 있는 사람에게 정해진 경로를 통해 사안을 에스컬레이션할 수 있습니다. 

 **이 모범 사례 정립의 이점:** 책임 또는 소유권이 있는 사람을 파악하면 적절한 팀이나 팀원에게 연락하여 요청을 하거나 태스크를 전환할 수 있습니다. 책임 또는 소유권을 할당하거나 요구 사항 충족을 위한 계획을 수립할 권한이 있는 사람을 식별하면 휴지 및 요구 사항 미충족의 위험이 줄어듭니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  책임과 소유권을 식별하는 메커니즘: 조직 구성원에게 소유권과 책임을 발견하고 식별할 수 있는 액세스 가능한 메커니즘을 제공합니다. 이러한 메커니즘을 통해 조직 구성원은 특정 요구 사항에 대해 연락할 팀 또는 개인을 식별할 수 있습니다. 

# OPS02-BP06 추가, 변경 및 예외를 요청하는 메커니즘
<a name="ops_ops_model_req_add_chg_exception"></a>

 프로세스, 절차 및 리소스의 소유자에게 요청을 보낼 수 있습니다. 이점과 위험을 평가한 후 요청이 적절한지 판단하고 정보에 입각한 의사 결정을 통해 실현 가능한 경우에 요청을 승인해야 합니다. 

 **이 모범 사례 정립의 이점:** 팀의 활동을 지원하는 데 있어서는 추가, 변경 및 예외 처리를 요청하는 메커니즘을 갖추어야 합니다. 이 옵션이 없으면 현재 상태가 혁신의 제약 요인이 됩니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  추가, 변경 및 예외를 요청하는 메커니즘: 표준이 엄격하면 혁신은 제약을 받습니다. 비즈니스 요구 사항 지원을 위해 프로세스, 절차 및 리소스를 소유자에게 요청할 수 있는 메커니즘을 조직 구성원에게 제공합니다. 

# OPS02-BP07 미리 정의되었거나 협상된 팀 간 책임
<a name="ops_ops_model_def_neg_team_agreements"></a>

 팀 간에 서로 협력하고 지원하는 방식에 관한 내용을 정의하거나 협상합니다(예: 응답 시간, 서비스 수준 목표 또는 서비스 수준 계약). 팀의 작업이 비즈니스 성과에 미치는 영향, 그리고 다른 팀과 조직의 성과에 미치는 영향을 이해하면 작업의 우선순위를 파악하고 적절하게 대응할 수 있습니다. 

 책임과 소유권을 정의하지 않았거나 알지 못하는 경우 필요한 활동을 적시에 처리하지 못하게 되며 해당 요구 사항을 해결하기 위한 작업이 중복되고 잠재적으로는 상충될 위험이 있습니다. 

 **이 모범 사례 정립의 이점:** 팀, 목표 및 요구 사항을 전달하는 방법 간의 책임을 확립하면 요청 흐름이 쉬어지고 필요한 정보가 반드시 제공됩니다. 이렇게 하면 팀 간 전환 태스크에서 발생하는 지연이 줄고 비즈니스 성과 달성에 도움이 됩니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  미리 정의되었거나 협상된 팀 간 책임: 팀이 상호작용하는 방법과 서로 지원하는 데 필요한 정보를 지정하면 요청을 반복적으로 검토하고 설명하게 되면서 지연이 발생하는 상황을 최소화할 수 있습니다. 기대치를 정의하는 특정 계약(예: 응답 시간 또는 이행 시간)을 사용하면 팀이 효과적인 계획과 리소스를 적절하게 작성할 수 있습니다. 

# OPS 3  조직 문화는 비즈니스 성과를 어떻게 지원합니까?
<a name="w2aac19b5b5b9"></a>

 팀원이 효과적으로 조치를 취하고 비즈니스 성과를 지원할 수 있도록 팀원에 대한 지원을 제공합니다. 

**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 경영진의 후원 확보
<a name="ops_org_culture_executive_sponsor"></a>

 최고 경영진은 조직에 대한 기대치를 명확하게 설정하고 성공 여부를 평가합니다. 최고 경영진은 조직이 발전하고 모범 사례를 도입하도록 하는 동인이자 후원자이자 지지자입니다. 

 **이 모범 사례 수립의 이점:** 경영진의 참여, 명확하게 기대치 전달 및 목표 공유를 통해 팀원은 기대 사항을 파악할 수 있습니다. 성공 평가를 통해 후원자 또는 대리인의 개입을 통해 해결할 수 있도록 성공의 장벽을 파악할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  경영진의 후원 확보: 최고 경영진은 조직에 대한 기대치를 명확하게 설정하고 성공 여부를 평가합니다. 최고 경영진은 조직이 발전하고 모범 사례를 도입하도록 하는 동인이자 후원자이자 지지자입니다. 
  +  기대치 설정: 측정 방법을 포함하여 조직의 목표를 정의하고 게시합니다. 
  +  목표 달성 추적: 성과가 위태로운 상태일 경우 적절한 조치를 취할 수 있도록 목표의 점진적 달성을 정기적으로 측정하고 결과를 공유합니다. 
  +  목표를 달성하는 데 필요한 리소스 제공: 리소스가 여전히 적절한지 또는 새로운 정보, 목표 변경, 책임 또는 비즈니스 환경에 따라 추가 리소스가 필요한지 정기적으로 검토합니다. 
  +  팀 지지: 팀과 지속적으로 협력하여 팀의 업무 방식과 팀에 영향을 미치는 외부 요인을 파악합니다. 팀이 외부 요인의 영향을 받는 경우 목표를 재평가하고 적절하게 목표를 조정합니다. 팀 진행을 방해하는 장애물을 파악합니다. 팀을 대신해 장애물을 해결하고 불필요한 부담을 제거하는 데 도움을 줍니다. 
  +  모범 사례 도입을 위한 동인: 수량화할 수 있는 이점을 제공하고 생산자와 채택자를 인지하는 모범 사례를 확인합니다. 추가적인 채택을 장려하여 달성된 이점을 확대합니다. 
  +  팀의 진화를 이끄는 동력: 지속적으로 개선하는 문화를 조성합니다. 개인 및 조직의 성장과 개발을 장려합니다. 시간 경과에 따른 점진적 달성을 필요로 하는, 추구할 장기적 목표를 제공합니다. 이러한 비전을 조정하여 변화하는 요구 사항, 비즈니스 목표 및 비즈니스 환경을 보완합니다. 

# OPS03-BP02 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여
<a name="ops_org_culture_team_emp_take_action"></a>

 워크로드 소유자는 성과가 위험한 상태일 때 팀원들이 응답할 수 있도록 지침과 범위를 정의했습니다. 에스컬레이션 메커니즘은 이벤트가 정의된 범위를 벗어날 경우 수행할 조치를 정할 때 사용됩니다. 

 **이 모범 사례 수립의 이점:** 변경 사항을 조기에 테스트하고 검증함으로써 최소화된 비용으로 문제를 해결하고 고객에게 미치는 영향을 제한할 수 있습니다. 배포 전에 테스트하면 오류 도입을 최소화할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여: 팀원에게 효과적으로 대응하는 데 필요한 기술을 연습할 수 있는 권한, 도구 및 기회를 제공합니다. 
  +  팀원에게 대응하는 데 필요한 기술을 연습할 기회 제공: 프로세스와 절차를 안전하게 테스트하고 교육할 수 있는 안전한 대체 환경을 제공합니다. 팀원들이 안전한 시뮬레이션 환경에서 실제 인시던트에 대응하는 경험을 쌓을 수 있도록 실전 연습을 수행합니다. 
  +  팀원의 조치 수행 권한 정의 및 승인: 특히 팀원이 지원하는 워크로드 및 구성 요소에 대한 권한과 액세스를 할당하여 조치를 취할 수 있는 팀원 권한을 정의합니다. 성과가 위험한 상태일 때 조치를 취할 수 있는 권한이 팀원에게 있음을 확인합니다. 

# OPS03-BP03 에스컬레이션 장려
<a name="ops_org_culture_team_enc_escalation"></a>

 성과 실현에 실패할 위험이 있는 경우 의사 결정권자와 이해관계자에게 문제를 에스컬레이션하는 메커니즘이 마련되어 있으며 팀원은 이를 적극적으로 활용해야 합니다. 위험을 식별하고 인시던트를 방지할 수 있도록 에스컬레이션을 조기에 자주 수행해야 합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  조기의 잦은 에스컬레이션 장려: 조직 차원에서 에스컬레이션을 조기에 자주 진행하는 게 모범 사례임을 받아들입니다. 에스컬레이션이 근거가 없는 것으로 판명될 수 있으며 에스컬레이션하지 않아 해당 기회를 놓치는 것보다 인시던트를 방지할 기회를 갖는 것이 낫다는 것을 조직 차원에서 인정하고 수락합니다. 
  +  에스컬레이션을 위한 메커니즘 보유: 에스컬레이션이 발생하는 시점과 방법을 정의하는 문서화된 절차가 있어야 합니다. 조치를 취하거나 조치와 연락처 정보를 승인할 수 있는 높은 권한이 있는 사람들을 문서화합니다. 팀원이 위험 요소를 처리할 수 있는 사람에게 문제를 이관했거나 워크로드 운영에 대한 위험과 책임을 부담하는 사람에게 연락했다고 만족할 때까지 에스컬레이션이 계속되어야 합니다. 궁극적으로 워크로드와 관련된 모든 의사 결정을 소유하는 사람이 여기에 해당합니다. 에스컬레이션에는 위험의 특성, 워크로드의 중요성, 영향을 받는 사람, 영향의 종류, 긴급성, 즉 영향이 예상되는 시기가 포함되어야 합니다. 
  +  에스컬레이션하는 직원 보호: 팀원이 부적절한 의사 결정권자나 이해관계자에게로 문제를 에스컬레이션하는 경우 받을 수 있는 불이익으로부터 팀원을 보호하는 정책을 마련합니다. 이러한 일이 발생하는지 여부를 식별하고 적절하게 대응할 수 있는 메커니즘이 마련되어 있습니다. 

# OPS03-BP04 시기 적절하고 명확하며 실행 가능한 커뮤니케이션
<a name="ops_org_culture_effective_comms"></a>

 알려진 위험과 예정된 이벤트를 팀원에게 적시에 알리는 데 사용되는 메커니즘이 마련되어 있습니다. 조치가 필요한지 여부와 어떤 조치가 필요한지 판단하고 적시에 조치를 취할 수 있도록 필요한 컨텍스트, 세부 정보 및 시간(가능한 경우)이 제공됩니다. 예를 들어 소프트웨어 취약성에 대한 알림을 제공하여 패치를 신속하게 적용하도록 하거나, 예정된 판매 프로모션에 대한 알림을 제공하여 서비스 중단의 위험을 방지하기 위한 변경 동결 기능을 구현하게 할 수 있습니다. 

 대기 중인 활동을 팀원이 식별할 수 있도록 예정된 이벤트를 변경 일정이나 유지 관리 일정에 기록할 수 있습니다. 

 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) 에 대한 활동을 예약하여 활동을 자동화하고 해당 활동을 검색할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  시기 적절하고 명확하며 실행 가능한 커뮤니케이션: 적절한 대응을 가능하게 하는 충분한 정보와 함께 명확하고 실행 가능한 방식으로 위험 또는 계획된 이벤트를 알리는 메커니즘이 마련되어 있습니다. 
  +  변경 일정에서 계획된 활동 문서화 및 알림 제공: 계획된 이벤트를 검색할 수 있는 액세스 가능한 정보 출처를 제공합니다. 동일한 시스템의 계획된 이벤트에 대한 알림을 제공합니다. 
  +  워크로드에 영향을 줄 수 있는 이벤트 및 활동 추적: 취약성 알림과 패치 정보를 모니터링하여 워크로드 구성 요소와 관련된 잠재적 위험과 취약성을 파악합니다. 팀원에게 조치를 취할 수 있도록 알림을 제공합니다. 

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

 **관련 문서:** 
+  [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 실험 장려
<a name="ops_org_culture_team_enc_experiment"></a>

 실험은 학습을 가속화하고 팀원의 관심과 참여를 유지합니다. 원치 않는 결과가 나와도 성공하지 못하는 경로를 알게 되었으므로 실험에는 성공한 것입니다. 원치 않는 결과가 나온 성공한 실험에 대해 팀원에게 불이익을 가하지 않습니다. 혁신과 아이디어를 실현하려면 실험이 필요합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  실험 장려: 학습과 혁신을 지원하도록 실험을 장려하십시오. 
  +  다양한 기술로 실험: 현재 또는 미래에 비즈니스 성과를 달성하는 데 적용할 수 있는 기술을 실험하도록 장려하십시오. 이러한 지식은 향후 혁신에 도움이 될 수 있습니다. 
  +  목표를 염두에 두고 실험: 팀원이 도달할 특정 목표 또는 가까운 장래에 적용할 수 있는 기술을 사용한 실험을 장려하십시오. 이러한 지식은 혁신에 도움이 될 수 있습니다. 
  +  체계적인 실험 시간 제공: 팀원이 실험에 집중할 수 있도록 통상적인 책임에서 벗어날 수 있는 구체적인 시간을 지원합니다. 
  +  실험을 지원하는 리소스 제공: 실험을 수행하는 데 필요한 리소스(예: 소프트웨어 또는 클라우드 리소스)에 자금을 지원합니다. 
  +  성공 인정: 실험으로 인해 창출되는 가치를 인식합니다. 원하는 결과가 나오지 않은 실험이라도 성공적이라고 생각해야 합니다. 이 실험을 통해 성공으로 이어지지 않는 경로를 알게 되었기 때문입니다. 실험에서 원하는 성과를 달성하지 못했다고 팀원이 처벌되지는 않습니다. 

# OPS03-BP06 팀원의 기술 유지와 증진 지원 및 장려
<a name="ops_org_culture_team_enc_learn"></a>

 팀은 새로운 기술을 도입하고 워크로드 지원 책임과 수요 변화를 지원하기 위해 기술 역량을 키워야 합니다. 새로운 기술 영역의 기술 증진은 팀원의 만족도를 높이고 혁신을 뒷받침합니다. 발전하는 기술을 검증하고 인증하는 업계 자격증을 획득하고 관리하도록 팀원을 독려합니다. 지식이 효과적으로 전달되도록 하고, 제도적 지식을 갖춘 경험 많고 숙련된 직원을 잃은 경우에 중대한 영향이 발생할 위험을 줄일 수 있도록 교차 교육을 실시합니다. 학습을 위해 체계적으로 정해진 교육 시간을 제공합니다. 

 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 기술을 연마하도록 추가로 지원할 수도 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  팀원의 기술 유지와 증진 지원 및 장려: 새로운 기술을 도입하고, 혁신을 지원하고, 워크로드 지원 책임과 수요 변화를 뒷받침하려면 지속적인 교육이 필요합니다. 
  +  교육 리소스 제공: 체계적인 시간, 교육 자료 이용, 실습 리소스 및 교사와 동료에게서 배울 수 있는 기회를 제공하는 컨퍼런스 및 전문 조직에 참석 지원을 제공합니다. 수습 팀원에게 선임 팀원의 지도와 조언을 받을 수 있는 기회를 제공하고 선임 팀원의 일과 방법 및 기술을 배울 수 있게 합니다. 보다 넓은 시야를 확보하기 위해 작업과 직접적으로 관련되지 않은 콘텐츠에 대해 학습하도록 장려합니다. 
  +  팀 교육 및 팀 간 참여: 팀원의 지속적인 교육 요구 사항을 계획합니다. 팀원이 다른 팀(임시로 또는 영구적으로)에 합류하여 전체 조직에 도움이 되는 기술과 모범 사례를 공유할 수 있는 기회를 제공합니다. 
  +  업계 자격증 획득 및 유지 지원: 팀원이 배운 내용을 확인하고 그 성과를 인정하는 업계 자격증을 획득하고 유지하도록 지원합니다. 

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

 **관련 문서:** 
+  [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 리소스 팀 적절히 관리
<a name="ops_org_culture_team_res_appro"></a>

 워크로드 요구 사항을 지원할 수 있도록 팀원 역량을 유지하고 도구와 리소스를 제공합니다. 과중한 업무를 수행하는 팀원은 인적 오류로 인한 인시던트의 위험이 큽니다. 자주 수행하는 활동을 자동화하는 등 도구 및 리소스에 투자하면 팀의 효율성이 높아져 팀원이 더 많은 활동을 지원할 수 있게 됩니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  리소스 팀 적절히 관리: 팀의 성공을 깊이 있게 이해하고, 성공 또는 실패를 부른 요인을 파악해야 합니다. 적절한 리소스로 팀 지원 활동을 합니다. 
  +  팀 성과 이해: 팀의 운영 성과 달성과 자산 개발을 측정합니다. 시간 경과에 따른 출력 및 오류 발생률의 변화를 추적합니다. 팀과 협력하여 업무에 영향을 미치는 문제(예: 책임 증가, 기술 변화, 인력 손실 또는 지원 고객 증가)를 파악합니다. 
  +  팀 성과에 미치는 영향 파악: 팀과 지속적으로 협력하여 팀의 업무 방식과 팀에 영향을 미치는 외부 요인을 파악합니다. 팀이 외부 요인의 영향을 받는 경우 목표를 재평가하고 적절하게 목표를 조정합니다. 팀 진행을 방해하는 장애물을 파악합니다. 팀을 대신해 장애물을 해결하고 불필요한 부담을 제거하는 데 도움을 줍니다. 
  +  팀의 성공에 필요한 리소스 제공: 리소스가 여전히 적절한지, 추가 리소스가 필요한지 정기적으로 검토하고 지원 팀을 적절히 조정합니다. 

# OPS03-BP08 팀 내부 및 여러 팀 간에 의견의 다양성 추구 및 장려
<a name="ops_org_culture_diverse_inc_access"></a>

 조직 간의 다양성을 활용하여 여러 가지 고유한 관점을 모색합니다. 이러한 관점을 통해 혁신을 증진하고, 기존의 추정 사항에 의문을 제기하며, 확증 편향의 위험을 줄일 수 있습니다. 팀 내에서 포용성, 다양성 및 접근성을 높여 유익한 관점을 확보합니다. 

 조직 문화는 팀원의 업무 만족도와 팀원 이직률에 직접적인 영향을 미칩니다. 팀원의 참여와 역량을 통해 비즈니스의 성공을 뒷받침할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  다양한 의견과 관점 모색: 모든 사람이 기여하도록 장려합니다. 대표가 불분명한 소수 그룹의 의견을 경청합니다. 미팅에서 역할과 책임을 교대로 맡습니다. 
  +  역할 및 책임 확대: 다른 상황에서는 맡을 수 없는 역할을 담당할 수 있는 기회를 팀원에게 제공합니다. 마찬가지로 팀원은 다른 상황에서는 불가능할 수 있는 새로운 팀원과의 상호 작용 및 역할에서 경험과 관점을 얻습니다. 팀원은 상호 작용하는 새로운 역할과 팀원에 자신의 경험과 관점을 적용합니다. 관점이 증가함에 따라 추가적인 비즈니스 기회가 나타나거나 새로운 개선 기회를 찾을 수 있습니다. 팀원들로 하여금 다른 구성원들이 수행하는 일반적인 작업을 번갈아 수행하도록 하여 해당 작업의 요구 사항과 영향에 대한 이해를 돕습니다. 
  +  안전하고 환영받는 환경 제공: 조직 내 팀원의 정신적, 신체적 안전을 보호하는 정책과 규제 수단을 마련합니다. 팀원은 보복에 대한 두려움 없이 상호 작용할 수 있어야 합니다. 팀원들이 안전하고 환영 받는다고 느낄 때 참여와 생산성이 향상됩니다. 조직이 다양할수록 고객을 비롯하여 지원하는 인력을 더 잘 이해할 수 있습니다. 팀원들이 편하고 자유롭게 이야기할 수 있고 자신의 의견이 존중된다고 확신할 때 마케팅 기회, 접근성 요구 사항, 소외된 시장 부문, 환경에서 알려지지 않은 위험과 같은 귀중한 인사이트를 공유할 가능성이 더 높아집니다. 
  +  팀원의 완전한 참여 지원: 직원이 모든 업무 관련 활동에 완전히 참여하는 데 필요한 리소스를 제공합니다. 일상적인 문제에 직면하는 팀원들은 이러한 문제를 해결할 수 있는 기술을 개발했습니다. 이러한 고유하게 개발된 기술은 조직에 상당한 이점을 가져올 수 있습니다. 팀원들에게 필요한 설비를 지원하면 그들의 조력을 통해 얻을 수 있는 혜택이 늘어납니다.