# 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 지속적인 개선을 위한 프로세스 마련 OPS11-BP01 지속적인 개선을 위한 프로세스 마련 내부 및 외부 아키텍처 모범 사례를 기준으로 워크로드를 평가하세요. 의도적인 워크로드 검토를 자주 실시하세요. 소프트웨어 개발 단계에서 개선 기회의 우선순위를 지정하세요. **원하는 성과:** + 아키텍처 모범 사례를 기준으로 워크로드를 자주 분석합니다. + 소프트웨어 개발 프로세스의 기능과 개선 기회에 동등한 우선순위를 부여합니다. **일반적인 안티 패턴**: + 몇 년 전에 배포된 이후 워크로드에 대한 아키텍처 검토를 수행한 적이 없습니다. + 개선 기회에 더 낮은 우선순위를 부여합니다. 새로운 기능에 비해 개선 기회를 계속 뒷전으로 두고 있습니다. + 조직에 맞춰 모범 사례를 수정하기 위한 표준이 없습니다. **이 모범 사례 확립의 이점:** + 워크로드가 최신 아키텍처 모범 사례에 맞춰 유지됩니다. + 의도적인 방식으로 워크로드를 발전시킵니다. + 조직의 모범 사례를 활용하여 모든 워크로드를 개선할 수 있습니다. + 개별적으로는 작지만 모이면 큰 영향을 미치는 이익을 얻을 수 있어 효율성의 심도가 향상됩니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 ## 구현 지침 구현 지침 워크로드에 대한 아키텍처 검토를 자주 수행하세요. 내부 및 외부 모범 사례를 사용하여 워크로드를 평가하고 개선 기회를 식별하세요. 소프트웨어 개발 단계에서 개선 기회의 우선순위를 지정하세요. ### 구현 단계 구현 단계 1. 합의된 빈도로 프로덕션 워크로드에 대한 정기적인 아키텍처 검토를 수행합니다. AWS 관련 모범 사례를 포함한 문서화된 아키텍처 표준을 사용합니다. 1. 이러한 검토에는 내부적으로 정의된 표준을 사용합니다. 내부 표준이 없는 경우에는 AWS Well-Architected Framework를 사용합니다. 1. AWS Well-Architected Tool을 사용하여 내부 모범 사례의 사용자 지정 렌즈를 생성하고 아키텍처 검토를 수행합니다. 1. AWS Solution Architect 또는 Technical Account Manager에게 문의하여 워크로드에 대한 가이드식 Well-Architected Framework 검토를 수행합니다. 1. 소프트웨어 개발 프로세스 중 검토 과정에서 식별된 개선 기회를 우선시합니다. **구현 계획의 작업 수준:** 낮음. AWS Well-Architected Framework를 사용하여 연간 아키텍처 검토를 수행할 수 있습니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS11-BP02 인시던트 사후 분석 수행](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html) + [OPS11-BP08 파악한 내용 문서화 및 공유](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_share_lessons_learned.html) + [OPS04 - 관찰성 구현](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html) **관련 문서**: + [AWS Well-Architected Tool - Custom lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) + [AWS Well-Architected 백서 - 검토 프로세스](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html) + [Customize Well-Architected Reviews using Custom Lenses and the AWS Well-Architected Tool](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/) + [Implementing the AWS Well-Architected Custom Lens lifecycle in your organization](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/) **관련 비디오:** + [AWS re:Invent 2023 - Scaling AWS Well-Architected best practices across your organization](https://youtu.be/UXtZCoE9qfQ?si=OPATCOY2YAwiF2TS) **관련 예제:** + [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) # OPS11-BP02 인시던트 사후 분석 수행 OPS11-BP02 인시던트 사후 분석 수행 고객에게 영향을 주는 이벤트를 검토하고 기여 요인과 예방 조치를 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. **원하는 성과:** + 인시던트 사후 분석을 포함하는 인시던트 관리 프로세스를 수립했습니다. + 이벤트에 대한 데이터를 수집하기 위한 관찰성 계획이 마련되어 있습니다. + 이 데이터를 통해 인시던트 사후 분석 프로세스를 지원하는 지표를 이해하고 수집할 수 있습니다. + 인시던트로부터 교훈을 얻어 미래의 결과를 개선합니다. **일반적인 안티 패턴**: + 애플리케이션 서버를 관리합니다. 약 23시간 55분마다 모든 활성 세션이 종료됩니다. 애플리케이션 서버에서 무엇이 잘못되었는지 파악하려고 했습니다. 네트워크 문제일 수도 있다고 생각하지만 네트워크 팀이 너무 바쁜 관계로 지원을 받을 수 없습니다. 지원을 받고 진행 상황을 파악하는 데 필요한 정보를 수집하기 위해 따라야 할 사전 정의된 프로세스가 없습니다. + 워크로드 내에서 데이터가 손실되었습니다. 이런 일은 처음이며 그 원인이 명확하지 않습니다. 데이터를 다시 생성할 수 있으므로 대수롭지 않은 일로 생각합니다. 데이터 손실이 발생하면서 고객에게 영향을 미치는 빈도가 증가합니다. 또한 이로 인해 누락된 데이터를 복원할 때 운영 부담이 가중됩니다. **이 모범 사례 확립의 이점:** + 인시던트에 기여한 구성 요소, 조건, 작업 및 이벤트를 결정하기 위해 사전 정의된 프로세스를 사용하면 개선 기회를 파악할 수 있습니다. + 인시던트 사후 분석에서 얻은 데이터를 사용하여 개선합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 ## 구현 가이드 구현 지침 발생 요인을 확인하는 프로세스를 사용합니다. 고객에게 영향을 미치는 모든 인시던트를 검토합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 인시던트의 기여 요인을 식별하고 문서화하는 프로세스를 마련합니다. 인시던트의 근본 원인을 적절하게 전달하고 대상 고객에 맞게 커뮤니케이션을 조정합니다. 조직 내에서 학습한 내용을 공개적으로 공유합니다. ### 구현 단계 구현 단계 1. 배포 변경, 구성 변경, 인시던트 시작 시간, 경보 시간, 참여 시간, 완화 시작 시간, 인시던트 해결 시간과 같은 지표를 수집합니다. 1. 인시던트 발생 상황을 파악하기 위해 타임라인에 주요 시점을 표시합니다. 1. 다음과 같이 질문하세요. 1. 감지 시간을 단축할 수 있나요? 1. 인시던트를 더 빨리 감지할 수 있는 지표 및 경보 업데이트가 있습니까? 1. 진단 시간을 개선할 수 있나요? 1. 대응 계획이나 에스컬레이션 계획에 올바른 대응 담당자를 더 빨리 투입할 수 있는 업데이트가 있습니까? 1. 완화 시간을 단축할 수 있나요? 1. 추가하거나 개선할 수 있는 런북 또는 플레이북 단계가 있나요? 1. 향후 인시던트 발생을 방지할 수 있나요? 1. 체크리스트와 작업을 생성합니다. 모든 작업을 추적하고 전달합니다. **구현 계획의 작업 수준:** 중간 ## 리소스 리소스 **관련 모범 사례:** + [OPS11-BP01 지속적인 개선을 위한 프로세스 마련](ops_evolve_ops_process_cont_imp.md) + [ OPS 4 - 관찰성 구현 ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html) **관련 문서**: + [Performing a post-incident analysis in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/analysis.html) + [운영 준비 상태 검토](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) # OPS11-BP03 피드백 루프 구현 OPS11-BP03 피드백 루프 구현 피드백 루프는 의사 결정을 추진하는 실행 가능한 인사이트를 제공합니다. 절차와 워크로드에 피드백 루프를 구축하세요. 이를 통해 문제와 개선이 필요한 영역을 파악할 수 있습니다. 또한 개선에 대한 투자를 검증합니다. 이러한 피드백 루프는 워크로드를 지속적으로 향상하기 위한 기반입니다. 피드백 루프는 *즉각적 피드백* 및 *후행 분석*과 같은 두 가지 범주로 구분됩니다. 즉각적 피드백은 운영 활동의 성과 및 결과를 검토하여 수집합니다. 이 피드백은 팀원, 고객 또는 자동화된 활동 출력으로부터 제공됩니다. A/B 테스트 및 새로운 기능 전달과 같은 사항을 통해 즉각적 피드백을 수신하며, 빠른 실패에 필수입니다. 시간 경과에 따른 운영 결과 및 지표 검토 결과의 피드백을 얻을 수 있도록 후행 분석이 정기적으로 수행됩니다. 이러한 후행 분석은 스프린트 후반, 정기적인 주기 또는 주요 릴리스나 이벤트 이후 수행합니다. 이러한 유형의 피드백 루프는 운영 또는 워크로드의 투자를 검증합니다. 이를 통해 성공 여부를 측정하고 결과를 검증할 수 있습니다. **원하는 성과:** 즉각적 피드백 및 후행 분석을 사용하여 개선을 추진할 수 있습니다. 사용자 및 팀원의 피드백을 얻을 수 있는 메커니즘이 있습니다. 후행 분석은 개선을 추진하는 추세를 파악하는 데 사용됩니다. **일반적인 안티 패턴**: + 새로운 기능을 출시했지만 이에 대한 고객 피드백을 받을 수 있는 방법이 없습니다. + 운영 개선에 투자한 후 이를 검증할만한 후행 분석을 수행하지 않습니다. + 고객 피드백을 수집하지만 이를 정기적으로 검토하지 않습니다. + 피드백 루프를 통해 제안된 조치 항목을 얻지만 소프트웨어 개발 프로세스에 포함되지 않습니다. + 고객이 제안한 개선 사항에 대한 피드백을 받지 못합니다. **이 모범 사례 확립의 이점:** + 고객의 입장에서 시작한 역방향 작업을 통해 새로운 기능을 이끌어낼 수 있습니다. + 조직 문화가 변화에 빠르게 반응할 수 있습니다. + 추세를 사용하여 개선 기회를 파악할 수 있습니다. + 후행 분석을 통해 워크로드 및 운영에 대한 투자를 검증할 수 있습니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 ## 구현 가이드 구현 지침 이 모범 사례를 구현하면 즉각적인 피드백과 후행 분석을 모두 사용하게 됩니다. 이러한 피드백 루프를 통해 개선을 추진할 수 있습니다. 설문 조사, 고객 투표, 피드백 양식 등 즉각적 피드백을 위한 다양한 메커니즘이 있습니다. 조직에서는 후행 분석도 사용하여 개선 기회를 파악하고 이니셔티브를 검증합니다. **고객 사례** AnyCompany Retail은 고객이 피드백을 제공하고 문제를 보고할 수 있는 웹 양식을 만들었습니다. 주간 스크럼 기간에 소프트웨어 개발 팀이 사용자 피드백을 평가합니다. 피드백은 플랫폼의 평가를 추진하는 데 정기적으로 사용됩니다. 각 스프린트의 후반에는 후행 분석을 수행하여 개선하고자 하는 항목을 파악합니다. ## 구현 단계 구현 단계 1. 즉각적 피드백 + 고객 및 팀원으로부터 피드백을 수신할 수 있는 메커니즘이 필요합니다. 또한 자동 피드백을 제공하도록 운영 활동을 구성할 수 있습니다. + 조직은 이 피드백을 검토하고 개선할 점을 결정하며 개선 일정을 지정하는 프로세스가 필요합니다. + 피드백이 소프트웨어 개발 프로세스에 반드시 추가되어야 합니다. + 개선 사항이 있을 때 피드백 제출자에게 후속 조치를 취합니다. + [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)를 사용하여 이러한 개선 사항을 [OpsIms](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): 운영 지표 검토는 개선을 위한 추세와 영역을 파악합니다. **관련 문서**: + [7 Pitfalls to Avoid When Building a CCOE](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) + [Atlassian Team Playbook - Retrospectives](https://www.atlassian.com/team-playbook/plays/retrospective) + [Email Definitions: Feedback Loops](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/) + [Establishing Feedback Loops Based on the AWS Well-Architected Framework Review](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/) + [IBM Garage Methodology - Hold a retrospective](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/) + [Investopedia – The PDCS Cycle](https://www.investopedia.com/terms/p/pdca-cycle.asp) + [Maximizing Developer Effectiveness by Tim Cochran](https://martinfowler.com/articles/developer-effectiveness.html) + [Operations Readiness Reviews (ORR) Whitepaper - Iteration](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html) + [ITIL CSI - Continual Service Improvement](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement) + [When Toyota met e-commerce: Lean at Amazon](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon) **관련 비디오:** + [Building Effective Customer Feedback Loops](https://www.youtube.com/watch?v=zz_VImJRZ3U) **관련 예제: ** + [Astuto - Open source customer feedback tool](https://github.com/riggraz/astuto) + [AWS 솔루션 - QnABot on AWS](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/) + [Fider - A platform to organize customer feedback](https://github.com/getfider/fider) **관련 서비스:** + [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) # OPS11-BP04 지식 관리 수행 OPS11-BP04 지식 관리 수행 지식 관리는 팀원이 업무 수행에 필요한 정보를 찾는 데 도움이 됩니다. 학습하는 조직에서는 개인에게 유용한 정보가 자유롭게 공유됩니다. 정보가 찾거나 검색할 수 있습니다. 정보가 정확하며 최신 상태입니다. 새로운 정보를 생성하고, 기존 정보를 업데이트하며, 오래된 정보를 보관하는 메커니즘이 있습니다. 지식 관리 플랫폼의 가장 일반적인 예로는 Wiki와 같은 콘텐츠 관리 시스템을 들 수 있습니다. **원하는 성과:** + 팀원이 적시에 정확한 정보에 액세스할 수 있습니다. + 정보 검색이 가능합니다. + 정보를 추가, 업데이트 및 보관하는 메커니즘이 있습니다. **일반적인 안티 패턴**: + 중앙 집중식 지식 스토리지가 없습니다. 팀원은 로컬 컴퓨터에서 자신의 메모를 관리합니다. + 셀프 호스팅된 Wiki가 있지만 정보를 관리하는 메커니즘이 없어 정보가 최신 상태가 아닙니다. + 누군가 누락된 정보를 식별하지만 팀 Wiki에 추가하도록 요청할 프로세스가 없습니다. 이를 직접 추가하지만 중요한 단계를 놓쳐 중단으로 이어집니다. **이 모범 사례 확립의 이점:** + 정보가 자유롭게 공유되기 때문에 팀원의 역량이 강화됩니다. + 문서가 최신 상태이고 검색 가능하기 때문에 새로운 팀원이 더 빨리 온보딩됩니다. + 정보는 시의적절하고 정확하며 실행 가능합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음 ## 구현 가이드 구현 지침 지식 관리는 학습하는 조직의 중요한 측면입니다. 시작하려면 지식을 저장할 중앙 리포지토리가 필요합니다(일반적인 예: 셀프 호스팅된 Wiki). 지식을 추가, 업데이트 및 보관하는 프로세스를 마련해야 합니다. 문서화해야 하는 항목에 대한 표준을 개발하고 모든 사람이 기여하도록 합니다. **고객 사례** AnyCompany Retail은 모든 지식이 저장되는 내부 Wiki를 호스팅합니다. 팀원은 일상 업무를 수행하면서 지식 베이스에 추가하도록 권장됩니다. 다기능 팀은 분기별로 가장 적게 업데이트된 페이지를 평가하고 아카이브할지 또는 업데이트할지 결정합니다. **구현 단계** 1. 먼저 지식이 저장될 콘텐츠 관리 시스템을 식별합니다. 조직 전체의 이해관계자로부터 동의를 얻습니다. 1. 기존 콘텐츠 관리 시스템이 없는 경우 셀프 호스팅된 Wiki를 실행하거나 버전 관리 리포지토리에서 시작하는 것이 좋습니다. 1. 정보를 추가, 업데이트 및 보관하기 위한 런북을 개발합니다. 팀에 이러한 프로세스를 알려줍니다. 1. 콘텐츠 관리 시스템에 어떤 지식을 저장해야 하는지 식별합니다. 팀원이 수행하는 일상 업무(런북 및 플레이북)부터 시작합니다. 이해관계자와 협력하여 추가되는 지식의 우선순위를 정합니다. 1. 주기적으로 이해관계자와 협력하여 오래된 정보를 식별하여 아카이브하거나 최신 정보를 가져옵니다. **구현 계획의 작업 수준:** 중간. 기존 콘텐츠 관리 시스템이 없는 경우 셀프 호스팅된 Wiki 또는 버전 관리 문서 리포지토리를 설정할 수 있습니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS11-BP08 학습한 내용 문서화 및 공유](ops_evolve_ops_share_lessons_learned.md) - 지식 관리는 학습한 내용에 대한 정보 공유를 용이하게 합니다. **관련 문서**: + [ Atlassian - Knowledge Management ](https://www.atlassian.com/itsm/knowledge-management) **관련 예제:** + [ DokuWiki ](https://www.dokuwiki.org/dokuwiki) + [ Gollum ](https://github.com/gollum/gollum) + [ MediaWiki ](https://www.mediawiki.org/wiki/MediaWiki) + [ Wiki.js ](https://github.com/Requarks/wiki) # OPS11-BP05 개선 추진 요인 정의 OPS11-BP05 개선 추진 요인 정의 개선 기회를 평가하고 우선순위를 지정할 수 있도록 데이터와 피드백 루프를 바탕으로 개선 추진 요인을 파악합니다. 시스템과 프로세스의 개선 기회를 탐색하고 적절한 경우 자동화합니다. **원하는 성과:** + 환경 전반에서 데이터를 추적합니다. + 이벤트 및 활동과 비즈니스 성과의 상관관계를 파악합니다. + 환경과 시스템을 비교하고 대조할 수 있습니다. + 배포 및 결과에 대한 자세한 활동 기록을 유지 관리합니다. + 보안 태세를 뒷받침하기 위해 데이터를 수집합니다. **일반적인 안티 패턴**: + 전체 환경에서 데이터를 수집하지만 이벤트와 활동의 상관관계를 파악하지는 않습니다. + 환경 전체에서 상세한 데이터를 수집하여 Amazon CloudWatch 및 AWS CloudTrail 활동과 비용이 많이 발생합니다. 그러나 이 데이터를 의미 있게 사용하지는 않습니다. + 개선 추진 요인을 정의할 때 비즈니스 성과를 고려하지 않습니다. + 새 기능의 효과를 평가하지 않습니다. **이 모범 사례 확립의 이점:** + 개선 기준을 결정하여 이벤트 기반 동기 또는 감정적 에너지 소모의 영향을 최소화합니다. + 기술 이벤트뿐만 아니라 비즈니스 이벤트에도 대응합니다. + 환경을 평가하여 개선이 필요한 영역을 식별합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간 ## 구현 지침 구현 지침 + 개선 추진 요인 파악: 원하는 성과가 지원되는 경우에만 시스템을 변경해야 합니다. + 필요한 기능: 개선 기회를 평가할 때 필요한 기능을 평가합니다. + [AWS의 새로운 소식](https://aws.amazon.com/new/) + 반드시 수정해야 할 문제: 개선 기회를 평가할 때 반드시 수정해야 할 문제, 버그 및 취약성을 평가합니다. 규모 조정 옵션을 추적하고 최적화 기회를 모색합니다. + [AWS 최신 보안 공지](https://aws.amazon.com/security/security-bulletins/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) + [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cloud-intelligence-dashboards/) + 규정 준수 요건: 개선 기회를 검토할 때 규정과 정책 준수 상태를 유지하거나 서드파티의 지원을 계속 받으려는 데 필요한 업데이트와 변경 사항을 평가합니다. + [AWS 규정 준수](https://aws.amazon.com/compliance/) + [AWS 규정 준수 프로그램](https://aws.amazon.com/compliance/programs/) + [AWS 규정 준수 최신 뉴스](https://aws.amazon.com/compliance/compliance-latest-news/) ## 리소스 리소스 **관련 모범 사례:** + [OPS01 조직 우선순위](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/organization-priorities.html) + [OPS02 관계 및 소유권](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/relationships-and-ownership.html) + [OPS04-BP01 핵심 성과 지표 파악](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html) + [OPS08 워크로드 관찰성 활용](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html) + [OPS09 운영 상태 파악](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-operational-health.html) + [OPS11-BP03 피드백 루프 구현](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) **관련 문서**: + [ 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/) + [Export your log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) + [AWS의 새로운 소식](https://aws.amazon.com/new/) + [고객 중심 혁신의 필요성](https://aws.amazon.com/executive-insights/content/the-imperatives-of-customer-centric-innovation/) + [Digital Transformation: Hype or a Strategic Necessity?](https://aws.amazon.com/blogs/enterprise-strategy/digital-transformation-hype-or-a-strategic-necessity/) **관련 비디오** + [AWS re:Invent 2023 - Improve operational efficiency and resilience with 지원 (SUP310)](https://youtu.be/jaehZYBNG0Y?si=UNEaLZsXDrxcBgYo) # OPS11-BP06 인사이트 검증 OPS11-BP06 인사이트 검증 여러 부문의 팀 및 비즈니스 소유자와 함께 분석 결과와 응답을 검토합니다. 이러한 검토에서는 개선 가능성을 공통적으로 파악하고, 추가적인 영향을 확인하며, 조치 과정을 결정할 수 있습니다. 필요에 따라 대응 내용을 조정합니다. **원하는 성과:** + 정기적으로 비즈니스 소유자와 함께 인사이트를 검토합니다. 비즈니스 소유자는 새로 얻은 인사이트에 대한 추가 컨텍스트를 제공합니다. + 인사이트를 검토하고 기술 부문의 동료에게 피드백을 요청하며 팀 간에 학습한 내용을 공유합니다. + 다른 기술 및 비즈니스 팀이 검토할 수 있도록 데이터와 인사이트를 게시합니다. 학습한 내용을 다른 부서의 새로운 업무 방식에 반영합니다. + 시니어 리더와 함께 새로운 인사이트를 요약하고 검토합니다. 시니어 리더는 새로운 인사이트를 사용하여 전략을 정의합니다. **일반적인 안티 패턴**: + 새 기능을 릴리스합니다. 이 기능은 고객 행동 중 일부를 변화시킵니다. 관찰성에 이러한 변경 사항을 고려하지 않습니다. 이러한 변경으로 인한 이점을 수량화하지 않습니다. + 새 업데이트를 푸시하고 CDN 새로 고침을 소홀히 합니다. CDN 캐시가 최신 릴리스와 더 이상 호환되지 않습니다. 오류가 있는 요청의 비율을 측정합니다. 모든 사용자가 백엔드 서버와 통신할 때 HTTP 400 오류를 보고합니다. 클라이언트 오류를 조사한 결과 차원을 잘못 측정했기 때문에 시간이 낭비되었다는 것을 알게 됩니다. + 서비스 수준에 관한 계약(SLA)에는 가동 시간이 99.9%라고 명시되어 있으며 Recovery Point Objective는 4시간입니다. 서비스 소유자는 시스템 가동 중지 시간이 전혀 없다고 주장합니다. 비용이 많이 들고 복잡한 복제 솔루션을 구축하여 시간과 비용이 낭비됩니다. **이 모범 사례 확립의 이점: ** + 비즈니스 소유자 및 주제 전문가와 함께 인사이트를 검증하면 공통된 이해를 확립하고 개선에 더 효과적으로 반영할 수 있습니다. + 숨겨진 문제를 발견하고 이를 향후 의사 결정에 반영합니다. + 기술적 성과에서 비즈니스 성과로 초점이 옮겨집니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간 ## 구현 가이드 구현 지침 + **인사이트 검증:** 비즈니스 소유자 및 주제별 전문가와 협력하여 수집한 데이터의 의미에 대한 공통된 이해와 동의가 있는지 확인합니다. 추가 우려 사항, 잠재적 영향을 식별하고 조치 과정을 결정합니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS01-BP06 이점과 위험을 관리하면서 장단점 평가](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html) + [OPS02-BP06 미리 정의되었거나 협상된 팀 간 책임](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html) + [OPS11-BP03 피드백 루프 구현](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) **관련 문서**: + [Designing a Cloud Center of Excellence (CCOE)](https://aws.amazon.com/blogs/enterprise-strategy/designing-a-cloud-center-of-excellence-ccoe/) **관련 비디오:** + [Building observability to increase resiliency](https://youtu.be/6bJkYtrMMPI?si=yu8tVMz4a6ax9f34&t=2695) # OPS11-BP07 운영 지표 검토 수행 OPS11-BP07 운영 지표 검토 수행 다양한 실무 영역의 여러 팀원과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. 이러한 검토에서는 개선 기회와 진행 가능한 조치 과정을 파악하고 배운 내용을 공유할 수 있습니다. 개발, 테스트, 프로덕션 등 모든 환경에서 개선 기회를 모색해야 합니다. **원하는 성과:** + 비즈니스에 영향을 미치는 지표 자주 검토 + 관찰성 기능을 통해 이상 징후 감지 및 검토 + 데이터를 사용하여 비즈니스 성과 및 목표 지원 **일반적인 안티 패턴**: + 유지 관리 기간으로 인해 중요한 소매 프로모션이 중단됩니다. 기업에서는 비즈니스에 영향을 미치는 다른 이벤트가 있는 경우 지연될 수 있는 표준 유지 관리 기간이 있음을 모릅니다. + 조직에서 오래된 라이브러리를 일반적으로 사용하기 때문에 운영 중단이 오래 지속되었습니다. 이후 지원되는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀은 위험에 처해 있다는 것을 알지 못합니다. + 고객 SLA 달성을 정기적으로 검토하지 않습니다. 고객 SLA를 충족하지 못하는 추세입니다. 고객 SLA를 충족하지 못할 경우 재정적 징벌이 부과될 수 있습니다. **이 모범 사례 확립의 이점:** + 정기적으로 만나 운영 지표, 이벤트 및 인시던트를 검토하면 팀 간에 공통된 이해를 유지할 수 있습니다. + 팀은 정기적으로 회의를 통해 지표와 인시던트를 검토하며, 이를 통해 위험에 대한 조치를 취하고 고객 SLA를 인식할 수 있습니다. + 파악한 내용을 공유하여 비즈니스 성과에 대한 우선순위 지정 및 목표 개선을 위한 데이터를 제공합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간 ## 구현 가이드 구현 지침 + 다양한 실무 영역의 여러 팀원과 함께 운영 지표 후행 분석을 정기적으로 수행합니다. + 실무 팀, 개발 팀, 운영 팀 등의 이해관계자와 함께 즉각적인 피드백 및 후행 분석에서 발견된 사항을 확인하고 파악한 내용을 공유합니다. + 그리고 이러한 인사이트를 활용하여 개선 기회와 진행 가능한 조치 과정을 확인합니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS08-BP05 대시보드 만들기](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_dashboards.html) + [OPS09-BP03 운영 지표 검토 및 개선 우선순위 지정](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html) + [OPS10-BP01 이벤트, 인시던트 및 문제 관리 프로세스 사용](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.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) + [Dashboards and visualizations with CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-dashboards-visualizations.html) # OPS11-BP08 학습한 내용 문서화 및 공유 OPS11-BP08 학습한 내용 문서화 및 공유 운영 활동 과정에서 파악한 내용을 문서화하고 공유하여 내부적으로 그리고 여러 팀 간에 사용할 수 있도록 합니다. 조직 전체에서 관련 이점을 더욱 효율적으로 활용하려면 팀에서 학습한 내용을 공유해야 합니다. 피할 수 있는 오류를 방지하고 개발 작업을 쉽게 수행하기 위해 정보와 리소스를 공유하고 원하는 기능을 제공하는 데 집중하세요. AWS Identity and Access Management(IAM)를 사용하여 계정 내에서와 계정 간에 공유할 리소스 액세스를 제어할 수 있는 권한을 정의합니다. **원하는 성과:** + 버전 관리 리포지토리를 사용하여 애플리케이션 라이브러리, 스크립팅된 절차, 절차 설명서 및 기타 시스템 설명서를 공유합니다. + 인프라 표준을 AWS CloudFormation 템플릿(버전 관리됨)으로 공유합니다. + 팀 전체에서 학습한 내용을 검토합니다. **일반적인 안티 패턴**: + 조직에서 일반적으로 버그가 있는 라이브러리를 사용하기 때문에 운영 중단이 오래 지속되었습니다. 이후 신뢰할 수 있는 라이브러리로 마이그레이션했습니다. 조직의 다른 팀들은 그들이 위험에 처해 있다는 것을 알지 못합니다. 아무도 이 라이브러리에 대한 경험을 문서화하고 공유하지 않으며 위험을 인식하지 못합니다. + 내부적으로 공유된 마이크로서비스에서 세션 중단을 일으키는 엣지 사례를 발견했습니다. 이 엣지 사례를 방지하기 위해 서비스에 대한 직접 호출을 업데이트했습니다. 조직의 다른 팀은 위험에 처해 있다는 것을 알지 못합니다. + 마이크로서비스 중 하나에 대한 CPU 사용률 요구 사항을 크게 줄일 수 있는 방법을 찾았습니다. 다른 팀에서 이 기술을 활용할 수 있는지 여부는 알 수 없습니다. **이 모범 사례 확립의 이점:** 개선을 지원하고 경험의 이점을 극대화하기 위해 학습한 교훈을 공유합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음 ## 구현 가이드 구현 지침 + **학습한 내용 문서화 및 공유:** 운영 활동을 통해 파악한 내용과 후행 분석 결과를 문서화하는 절차를 마련하여 다른 팀에서도 사용할 수 있도록 합니다. + **학습한 내용 공유:** 학습한 내용 및 관련 아티팩트를 여러 팀에서 공유하는 절차를 마련합니다. 예를 들어, 접속 가능한 Wiki를 통해 새로워진 절차, 지침, 거버넌스 및 모범 사례를 공유합니다. 스크립트, 코드 및 라이브러리는 공동 리포지토리를 통해 공유할 수 있습니다. + [AWS re:Post Private](https://aws.amazon.com/repost-private/)을 지식 서비스로 활용하여 조직 내 협업 및 지식 공유를 간소화합니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS02-BP06 미리 정의되었거나 협상된 팀 간 책임](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html) + [OPS05-BP01 버전 관리 사용](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html) + [OPS05-BP06 설계 표준 공유](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html) + [OPS11-BP03 피드백 루프 구현](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html) + [OPS11-BP07 운영 지표 검토 수행](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_metrics_review.html) **관련 문서:** + [AWS re:Post Private을 사용하여 협업을 강화하고 클라우드 관련 지식을 안전하게 공유](https://aws.amazon.com/blogs/aws/increase-collaboration-and-securely-share-cloud-knowledge-with-aws-repost-private/) + [ Reduce project delays with a docs-as-code solution ](https://aws.amazon.com/blogs/infrastructure-and-automation/reduce-project-delays-with-docs-as-code-solution/) **관련 비디오:** + [AWS re:Invent 2,023 - Collaborate within your company and with AWS using AWS re:Post Private ](https://www.youtube.com/watch?v=HNq_kU2QJLU) + [지원s You \$1 Exploring the Incident Management Tabletop Exercise](https://www.youtube.com/watch?v=0m8sGDx-pRM) # OPS11-BP09 개선을 위한 시간 할애 OPS11-BP09 개선을 위한 시간 할애 프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다. **원하는 성과:** + 실험과 테스트의 위험, 작업량 및 비용을 줄일 수 있도록 환경의 임시 복제본을 생성합니다. + 이렇게 복제된 환경을 사용하여 분석의 결론을 테스트하고, 실험을 진행하며, 계획된 향상 내용을 개발 및 테스트할 수 있습니다. + 게임 데이를 운영하고 결함 주입 서비스(FIS)를 통해 팀이 프로덕션과 유사한 환경에서 실험을 실행하는 데 필요한 제어 및 가드레일을 제공합니다. **일반적인 안티 패턴**: + 애플리케이션 서버에 알려진 성능 문제가 있습니다. 이는 계획된 모든 기능 구현 뒤의 백로그에 추가됩니다. 추가되는 계획된 기능의 비율이 일정하게 유지되는 경우 성능 문제는 해결되지 않습니다. + 지속적인 개선 지원을 위해 관리자 및 개발자가 개선 사항을 선택하고 구현하는 데 여분의 시간을 모두 할애하는 것을 승인합니다. 개선이 완료되지 않습니다. + 운영 승인이 완료되었으며 운영 사례를 다시 테스트하지 않습니다. **이 모범 사례 확립의 이점:** 프로세스 내에서 전담 리소스와 시간을 할애하여 가능한 범위 내에서 점진적 개선을 지속적으로 수행합니다. **이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음 ## 구현 가이드 구현 지침 + 개선을 위한 시간 할애: 프로세스 내에서 전담 리소스와 시간을 할애하여 점진적 개선을 지속적으로 수행합니다. + 변경 사항을 적용하여 결과를 개선하고, 평가를 통하여 성공 여부를 확정합니다. + 결과가 목표에 미치지 못하지만 여전히 개선을 우선해야 한다면 다른 대안을 찾아서 진행합니다. + 게임 데이 내내 프로덕션 워크로드를 시뮬레이션하고 이러한 시뮬레이션에서 파악한 내용을 활용하여 개선합니다. ## 리소스 리소스 **관련 모범 사례:** + [OPS05-BP08 여러 환경 사용](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_multi_env.html) **관련 비디오:** + [AWS re:Invent 2023 - Improve application resilience with AWS Fault Injection Service](https://youtu.be/N0aZZVVZiUw?si=ivYa9ScBfHcj-IAq)