

# 개선
<a name="a-evolve"></a>

**Topics**
+ [

# OPS 11  귀사는 어떻게 운영을 지속적으로 개선하고 있습니까?
](w2aac19b5c11b5.md)

# OPS 11  귀사는 어떻게 운영을 지속적으로 개선하고 있습니까?
<a name="w2aac19b5c11b5"></a>

 시간과 리소스를 할애하여 점진적 개선을 지속적으로 수행하면 운영 효율성을 높일 수 있습니다. 

**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 지속적인 개선을 위한 프로세스 마련
<a name="ops_evolve_ops_process_cont_imp"></a>

 개선 기회를 정기적으로 평가하고 우선순위를 지정해 가장 큰 이점을 얻을 수 있는 영역에서 작업을 집중적으로 수행합니다. 

 **일반적인 안티 패턴:** 
+  개발 또는 테스트 환경을 생성하는 데 필요한 절차를 문서화했습니다. CloudFormation을 사용하여 프로세스를 자동화할 수 있지만, 대신 콘솔에서 수동으로 프로세스를 수행합니다. 
+  테스트 결과, 애플리케이션 내 CPU 사용률의 대다수가 몇몇의 비효율적인 기능에 기인함을 확인했습니다. 이를 개선하고 비용을 절감하는 데 집중할 수 있지만 새로운 사용 가능성 기능을 만들 수 있는 임무가 주어졌습니다. 

 **이 모범 사례 수립의 이점:** 지속적인 개선은 개선 기회를 정기적으로 평가하고 우선순위를 지정하고, 가장 큰 이점을 얻을 수 있는 영역에서 작업을 집중적으로 수행하는 메커니즘을 제공합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  지속적 개선을 위한 프로세스 정의: 개선 기회를 정기적으로 평가하고 우선순위를 지정하여 가장 큰 이점을 얻을 수 있는 영역에 작업을 집중적으로 수행합니다. 변경 사항을 적용하여 성과를 개선하고, 평가를 통하여 성공 여부를 확정합니다. 성과가 목표에 미치지 못하지만 여전히 개선을 우선해야 한다면 다른 대안을 찾아서 해당 과정을 반복합니다. 개선 가능한 운영 프로세스를 지속적으로 개선하기 위해서는 전담 리소스와 시간을 할애해야 합니다. 

# OPS11-BP02 인시던트 사후 분석 수행
<a name="ops_evolve_ops_perform_rca_process"></a>

 고객에게 영향을 주는 이벤트를 검토하고 기여 요인과 예방 조치를 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. 

 **일반적인 안티 패턴:** 
+  애플리케이션 서버를 관리합니다. 약 23시간 55분마다 모든 활성 세션이 종료됩니다. 애플리케이션 서버에서 무엇이 잘못되었는지 파악하려고 했습니다. 네트워크 문제일 수도 있다고 생각하지만 네트워크 팀이 너무 바쁜 관계로 지원을 받을 수 없습니다. 지원을 받고 진행 상황을 파악하는 데 필요한 정보를 수집하기 위해 따라야 할 사전 정의된 프로세스가 없습니다. 
+  워크로드 내에서 데이터가 손실되었습니다. 이런 일은 처음이며 그 원인이 명확하지 않습니다. 데이터를 다시 생성할 수 있으므로 대수롭지 않은 일로 생각합니다. 데이터 손실이 발생하면서 고객에게 영향을 미치는 빈도가 증가합니다. 또한 이로 인해 누락된 데이터를 복원할 때 운영 부담이 가중됩니다. 

 **이 모범 사례 정립의 이점:** 인시던트에 기여한 구성 요소, 조건, 작업 및 이벤트를 결정하기 위해 사전 정의된 프로세스를 사용하면 개선 기회를 파악할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  프로세스를 사용하여 기여 요인 확인: 고객에게 영향을 미치는 모든 인시던트를 검토합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 인시던트의 기여 요인을 식별하고 문서화하는 프로세스를 마련합니다. 적절한 경우 근본 원인을 알리고 목표 대상에게 맞춤화된 프로세스를 마련합니다. 

# OPS11-BP03 피드백 루프 구현
<a name="ops_evolve_ops_feedback_loops"></a>

피드백 루프는 의사 결정을 추진하는 실행 가능한 인사이트를 제공합니다. 절차와 워크로드에 피드백 루프를 구축하세요. 이를 통해 문제와 개선이 필요한 영역을 파악할 수 있습니다. 또한 개선에 대한 투자를 검증합니다. 이러한 피드백 루프는 워크로드를 지속적으로 향상하기 위한 기반입니다.

 피드백 루프의 두 가지 카테고리: *즉각적 피드백* 및 *후행 분석*. 즉각적 피드백은 운영 활동의 성과 및 결과를 검토하여 수집합니다. 이 피드백은 팀원, 고객 또는 자동화된 활동 출력으로부터 제공됩니다. A/B 테스트 및 새로운 기능 전달과 같은 사항을 통해 즉각적 피드백을 수신하며, 빠른 실패에 필수입니다. 

 시간 경과에 따른 운영 결과 및 지표 검토 결과의 피드백을 얻을 수 있도록 후행 분석이 정기적으로 수행됩니다. 이러한 후행 분석은 스프린트 후반, 정기적인 주기, 또는 주요 릴리스나 이벤트 이후 수행합니다. 이러한 유형의 피드백 루프는 운영 또는 워크로드의 투자를 검증합니다. 이를 통해 성공 여부를 측정하고 결과를 검증할 수 있습니다. 

 **원하는 결과:** 즉각적 피드백 및 후행 분석을 사용하여 개선을 추진할 수 있습니다. 사용자 및 팀원의 피드백을 얻을 수 있는 메커니즘이 있습니다. 후행 분석은 개선을 추진하는 트렌드를 파악하는 데 사용됩니다. 

 **일반적인 안티 패턴:** 
+ 새로운 기능을 출시했지만 이에 대한 고객 피드백을 받을 수 있는 방법이 없습니다.
+ 운영 개선에 투자한 후 이를 검증할만한 후행 분석을 수행하지 않습니다.
+ 고객 피드백을 수집하지만 이를 정기적으로 검토하지 않습니다.
+ 피드백 루프를 통해 제안된 조치 항목을 얻지만 소프트웨어 개발 프로세스에 포함되지 않습니다.
+  고객이 제안한 개선 사항에 대한 피드백을 받지 못합니다. 

 **이 모범 사례 확립의 이점:** 
+  고객의 입장에서 시작한 역방향 작업을 통해 새로운 기능을 이끌어낼 수 있습니다. 
+  조직 문화가 변화에 빠르게 반응할 수 있습니다. 
+  트렌드를 사용하여 개선 기회를 파악할 수 있습니다. 
+  후행 분석을 통해 워크로드 및 운영에 대한 투자를 검증할 수 있습니다. 

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

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

 이 모범 사례를 구현하면 즉각적인 피드백과 후행 분석을 모두 사용하게 됩니다. 이러한 피드백 루프를 통해 개선을 추진할 수 있습니다. 설문 조사, 고객 투표, 피드백 양식 등 즉각적 피드백을 위한 다양한 메커니즘이 있습니다. 조직에서는 후행 분석도 사용하여 개선 기회를 파악하고 이니셔티브를 검증합니다. 

 **고객 사례** 

 AnyCompany Retail은 고객이 피드백을 제공하고 문제를 보고할 수 있는 웹 양식을 만들었습니다. 주간 스크럼 기간 동안 소프트웨어 개발 팀이 사용자 피드백을 평가합니다. 피드백은 플랫폼의 평가를 추진하는 데 정기적으로 사용됩니다. 각 스프린트의 후반에는 후행 분석을 수행하여 개선하고자 하는 항목을 파악합니다. 

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

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.  후행 분석 
   +  개발 주기의 마지막, 정기적인 주기, 또는 주요 릴리스 이후에 후행 분석을 수행합니다. 
   +  후행 분석 회의를 위해 워크로드에 관련된 이해 관계자를 모읍니다. 
   +  화이트보드나 스프레드시트에 중지, 시작 및 유지라는 세 개의 열을 만듭니다. 
     +  *중지* 는 팀에서 수행을 중지하고자 하는 항목입니다. 
     +  *시작* 은 시작하고자 하는 아이디어입니다. 
     +  *유지* 는 계속 하고자 하는 항목입니다. 
   +  회의실을 한 바퀴 돌며 이해 관계자들의 피드백을 수렴합니다. 
   +  피드백의 우선순위를 정합니다. 모든 시작 또는 유지 항목에 대한 활동 및 이해 관계자를 할당합니다. 
   +  소프트웨어 개발 프로세스에 해당 활동을 추가하고 개선 작업을 수행할 때 이해 관계자에게 상태 업데이트를 전달합니다. 

 **구현 계획의 작업 수준:** 보통. 이 모범 사례를 구현하려면 즉각적인 피드백을 수렴하고 이를 분석할 수 있는 방법이 필요합니다. 또한 후행 분석 프로세스를 확립해야 합니다. 

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

 **관련 모범 사례:** 
+  [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 지식 관리 수행
<a name="ops_evolve_ops_knowledge_management"></a>

 팀원이 적시에 원하는 정보를 검색하고 액세스하며, 최신 상태의 완전한 정보인지 식별하는 메커니즘을 제공합니다. 필요한 콘텐츠, 갱신이 필요한 콘텐츠, 더 이상 참조되지 않도록 보관해야 하는 콘텐츠를 식별하는 메커니즘도 제공합니다. 

 **일반적인 안티 패턴:** 
+  불만을 가진 한 고객이 인지한 문제를 해결하기 위해 새로운 제품 기능 요청에 대한 지원 사례를 개시합니다. 우선순위 개선 목록에 이 사례가 추가됩니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  지식 관리: 팀원이 적시에 원하는 정보를 검색하고 확인하며, 최신 상태의 완전한 정보인지 파악할 수 있는 메커니즘을 제공합니다. 필요한 콘텐츠, 갱신이 필요한 콘텐츠, 더 이상 참조되지 않도록 보관해야 하는 콘텐츠를 식별하는 메커니즘을 보유합니다. 

# OPS11-BP05 개선 추진 요인 정의
<a name="ops_evolve_ops_drivers_for_imp"></a>

 개선 기회를 평가하고 우선순위를 지정할 수 있도록 개선 추진 요인을 파악합니다. 

 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 규정 준수를 입증하기를 원합니다. 고객의 요구를 들어주고 싶지만 규정 준수를 문서화하고 고객의 배송 날짜를 놓치면 고객을 잃게 됩니다. 잘못된 일은 아니었지만 옳은 일이었는지 궁금합니다. 

 **이 모범 사례 수립의 이점:** 개선에 사용할 기준을 결정하면 이벤트 기반 동기 또는 감정적 투자의 영향을 최소화할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  개선 추진 요인 파악: 원하는 결과가 지원되는 경우에만 시스템을 변경해야 합니다. 
  +  필요한 기능: 개선 기회를 평가할 때 필요한 기능을 평가합니다. 
    +  [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/) 

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

 **관련 문서:** 
+  [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 인사이트 검증
<a name="ops_evolve_ops_validate_insights"></a>

 여러 부문의 팀 및 비즈니스 소유자와 함께 분석 결과와 응답을 검토합니다. 이러한 검토에서는 개선 가능성을 공통적으로 파악하고, 추가적인 영향을 확인하고, 조치 과정을 결정할 수 있습니다. 필요에 따라 대응 내용을 조정합니다. 

 **일반적인 안티 패턴:** 
+  시스템에서 CPU 사용률이 95%이며 시스템의 부하를 줄이는 방법을 찾기 위해 이를 최우선 과제로 삼습니다. 가장 좋은 조치는 확장하는 것입니다. 시스템은 트랜스코더이며 항상 95%의 CPU 사용률로 실행되도록 확장됩니다. 시스템 소유자에게 문의했다면 상황을 설명할 수 있었을 것입니다. 시간이 낭비되었습니다. 
+  시스템 소유자는 시스템이 미션 크리티컬하다고 주장합니다. 시스템이 보안 수준이 높은 환경에 배치되지 않았습니다. 보안을 강화하기 위해 미션 크리티컬 시스템에 필요한 탐지 및 예방 제어 기능을 추가로 구현합니다. 작업이 완료되고 추가 리소스에 대한 요금이 청구될 것임을 시스템 소유자에게 알립니다. 알림을 받고 진행한 논의에서 시스템 소유자는 시스템이 충족하지 못하는 미션 크리티컬 시스템에 대한 공식적인 정의가 있음을 알게 됩니다. 

 **이 모범 사례 정립의 이점:** 비즈니스 소유자 및 주제 전문가와 함께 인사이트를 확인하여 공통된 이해를 확립하고 개선 사항을 좀 더 효과적으로 안내할 수 있습니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  인사이트 검증: 비즈니스 소유자 및 주제별 전문가와 협력하여 수집한 데이터의 의미에 대한 공통된 이해와 동의가 있는지 확인합니다. 추가 우려 사항, 잠재적 영향을 식별하고 조치 과정을 결정합니다. 

# OPS11-BP07 운영 지표 검토 수행
<a name="ops_evolve_ops_metrics_review"></a>

 다양한 실무 영역의 여러 팀 구성원들과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. 이러한 검토에서는 개선 기회와 진행 가능한 조치 과정을 파악하고 배운 내용을 공유할 수 있습니다. 

 개발, 테스트, 프로덕션 등 모든 환경에서 향상 기회를 모색해야 합니다. 

 **일반적인 안티 패턴:** 
+  유지 관리 기간으로 인해 상당한 소매 프로모션이 중단되었습니다. 기업에서는 비즈니스에 영향을 미치는 다른 이벤트가 있는 경우 지연될 수 있는 표준 유지 관리 기간이 있음을 모릅니다. 
+  조직에서 일반적으로 사용되는 버그가 많은 라이브러리 사용으로 인해 장기간 가동이 중단되었습니다. 이후 신뢰할 수 있는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 정기적으로 만나고 이 인시던트를 검토했다면 이들도 위험을 알았을 것입니다. 
+  트랜스코더의 성능이 지속적으로 저하되어 미디어 팀에 영향을 미치고 있습니다. 아직 심각하지는 않습니다. 인시던트를 발생시키기에 충분히 나쁜 상태가 될 때까지 알 수 없습니다. 미디어 팀과 운영 지표를 검토했다면 지표의 변화와 그 경험을 인식하고 문제를 해결할 기회가 있었을 것입니다. 
+  고객 SLA 만족도를 검토하고 있지 않습니다. 고객 SLA를 충족하지 못하는 추세입니다. 고객 SLA를 충족하지 못할 경우 재정적 징벌이 부과될 수 있습니다. 이러한 SLA의 지표를 정기적으로 검토했다면 문제를 파악하고 해결할 수 있는 기회가 있었을 것입니다. 

 **이 모범 사례 정립의 이점:** 운영 지표, 이벤트 및 인시던트를 검토하기 위해 정기적으로 회의를 진행하여 팀 전체에서 공통된 이해를 유지하고, 배운 내용을 공유하고, 개선 사항의 우선순위와 대상을 정합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  운영 지표 검토: 다양한 실무 영역의 여러 팀 구성원들과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. 실무 팀, 개발 팀, 운영 팀 등의 이해 관계자와 함께 즉각적인 피드백 및 후행 분석에서 발견된 사항을 확인하고 파악한 내용을 공유합니다. 그리고 이러한 인사이트를 활용하여 개선 기회와 진행 가능한 조치 과정을 확인합니다. 
  +  [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) 

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

 **관련 문서:** 
+  [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 파악한 내용 문서화 및 공유
<a name="ops_evolve_ops_share_lessons_learned"></a>

 운영 활동 과정에서 파악한 내용을 문서화하고 공유하여 내부적으로, 그리고 여러 팀 간에 사용할 수 있도록 하십시오. 

 조직 전체에서 관련 이점을 더욱 효율적으로 활용하려면 팀에서 파악한 내용을 공유해야 합니다. 피할 수 있는 오류를 방지하고 개발 작업을 쉽게 수행하기 위해 정보와 리소스를 공유할 수 있습니다. 이렇게 하면 원하는 기능을 제공하는 데 집중할 수 있습니다. 

 AWS Identity and Access Management(IAM)를 사용하여 계정 내/계정 간에 공유할 리소스 액세스를 제어할 수 있는 권한을 정의합니다. 그런 다음 버전 제어 AWS CodeCommit 리포지토리를 사용하여 애플리케이션 라이브러리, 스크립팅된 절차, 절차 설명서 및 기타 시스템 설명서를 공유해야 합니다. 여러 계정에 Lambda 함수 사용 권한을 부여하고 AMI 액세스를 공유하는 방식을 통해 컴퓨팅 표준을 공유합니다. 인프라 표준도 AWS CloudFormation 템플릿으로 공유해야 합니다. 

 AWS API 및 SDK를 사용하면 GitHub, BitBucket, SourceForge 등의 외부 및 타사 도구와 리포지토리를 통합할 수 있습니다. 파악한 내용과 개발한 기능을 공유할 때는 공유 리포지토리 무결성을 유지할 수 있도록 권한의 구조를 지정해야 합니다. 

 **일반적인 안티 패턴:** 
+  조직에서 일반적으로 사용되는 버그가 많은 라이브러리 사용으로 인해 장기간 가동이 중단되었습니다. 이후 신뢰할 수 있는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들도 위험에 대해 알았을 것입니다. 
+  내부적으로 공유된 마이크로서비스에서 세션 중단을 일으키는 엣지 사례를 발견했습니다. 이 엣지 사례를 방지하기 위해 서비스에 대한 호출을 업데이트했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들도 위험에 대해 알았을 것입니다. 
+  마이크로서비스 중 하나에 대한 CPU 사용률 요구 사항을 크게 줄일 수 있는 방법을 찾았습니다. 다른 팀에서 이 기술을 활용할 수 있는지 여부는 알 수 없습니다. 이 라이브러리에 대한 경험을 문서화하고 공유했다면 그들에게도 그렇게 할 기회가 있었을 것입니다. 

 **이 모범 사례 수립의 이점:** 개선을 지원하고 경험의 이점을 극대화하기 위해 파악한 내용을 공유합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  파악한 내용 문서화 및 공유: 운영 활동을 실행하면서 파악한 내용과 후행 분석 결과를 문서화하는 절차를 마련하여 다른 팀에서도 사용할 수 있도록 합니다. 
  +  파악한 내용 공유: 파악한 내용 및 관련 작업 결과를 팀 간에 공유할 수 있는 절차를 마련합니다. 예를 들어, 접속 가능한 위키를 통해 새로워진 절차, 지침, 거버넌스 및 모범 사례를 공유하십시오. 스크립트, 코드 및 라이브러리는 공동 리포지토리를 통해 공유할 수 있습니다. 
    +  [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) 

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

 **관련 문서:** 
+  [간편한 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 개선을 위한 시간 할애
<a name="ops_evolve_ops_allocate_time_for_imp"></a>

 프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다. 

 AWS에서는 실험과 테스트의 위험, 작업량 및 비용을 줄일 수 있는 환경의 임시 복제본을 생성할 수 있습니다. 이렇게 복제된 환경을 사용하여 분석의 결론을 테스트하고, 실험을 진행하고, 계획된 향상 내용을 개발/테스트할 수 있습니다. 

 **일반적인 안티 패턴:** 
+  애플리케이션 서버에 알려진 성능 문제가 있습니다. 이는 계획된 모든 기능 구현 뒤의 백로그에 추가됩니다. 추가 예정인 계획된 기능의 비율이 일정하게 유지되는 경우 성능 문제는 해결되지 않습니다. 
+  지속적인 개선 지원을 위해 관리자 및 개발자가 개선 사항을 선택하고 구현하는 데 여분의 시간을 모두 할애하는 것을 승인합니다. 개선이 완료되지 않습니다. 

 **이 모범 사례 정립의 이점:** 프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다. 

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

## 구현 가이드
<a name="implementation-guidance"></a>
+  개선을 위한 시간 할애: 프로세스에 리소스와 시간을 투자하여 가능한 범위 내에서 점진적이고 지속적인 개선을 수행합니다. 변경 사항을 적용하여 결과를 개선하고, 평가를 통하여 성공 여부를 확정합니다. 결과가 목표에 미치지 못하지만 여전히 개선을 우선해야 한다면 다른 대안을 찾아서 진행합니다. 