# 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_def_responsibilities_ownership.md)
+ [OPS02-BP05 추가, 변경 및 예외를 요청하는 메커니즘](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 미리 정의되었거나 협상된 팀 간 책임](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 리소스 소유자 식별
워크로드의 리소스에는 변경 제어, 문제 해결 및 기타 기능에 대한 소유자가 식별되어 있어야 합니다. 소유자는 워크로드, 계정, 인프라, 플랫폼 및 애플리케이션에 대해 할당됩니다. 소유권은 중앙 레지스터 또는 리소스에 첨부된 메타데이터와 같은 도구를 사용하여 기록됩니다. 구성 요소의 비즈니스 가치는 구성 요소에 적용되는 프로세스와 절차를 알려 줍니다.
**원하는 성과:**
+ 리소스는 메타데이터 또는 중앙 레지스터를 사용하여 소유자를 식별했습니다.
+ 팀원은 누가 리소스를 소유하는지 식별할 수 있습니다.
+ 계정에는 가능한 경우 단일 소유자가 있습니다.
**일반적인 안티 패턴**:
+ AWS 계정의 대체 연락처가 입력되지 않았습니다.
+ 리소스에는 소유한 팀을 식별하는 태그가 없습니다.
+ 이메일 매핑이 없는 ITSM 대기열이 있습니다.
+ 두 팀이 중요한 인프라의 소유권을 중복으로 보유하고 있습니다.
**이 모범 사례 확립의 이점:**
+ 소유권이 할당되어 리소스에 대한 변경 제어가 간단해집니다.
+ 문제를 해결할 때 올바른 소유자를 참여시킬 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
환경의 리소스 사용 사례에 대한 소유권 의미를 정의합니다. 소유권이란 리소스의 변경 사항을 감독하거나, 문제 해결 중에 리소스를 지원하거나, 재정적으로 책임을 지는 사람을 의미할 수 있습니다. 이름, 연락처 정보, 조직 및 팀을 포함하여 리소스 소유자를 지정하고 기록합니다.
**고객 사례**
AnyCompany Retail은 소유권을 리소스에 대한 변경 및 지원 권한이 있는 팀 또는 개인으로 정의합니다. 이들은 AWS Organizations를 사용하여 AWS 계정을 관리합니다. 대체 계정 연락처는 그룹 받은 편지함을 사용하여 구성되고 있습니다. 각 ITSM 대기열은 이메일 별칭에 매핑됩니다. 태그는 AWS 리소스를 소유하는 사용자를 식별합니다. 다른 플랫폼 및 인프라의 경우 소유권 및 연락처 정보를 식별하는 Wiki 페이지가 있습니다.
### 구현 단계
1. 먼저 조직의 소유권을 정의합니다. 소유권은 리소스에 대한 위험을 부담하거나, 리소스를 변경하거나, 문제 해결 시 리소스를 지원하는 사람을 의미할 수 있습니다. 소유권은 리소스의 재정적 또는 관리적 소유권을 의미할 수도 있습니다.
1. [AWS Organizations](https://aws.amazon.com/organizations/)를 사용하여 계정을 관리합니다. 계정의 대체 연락처를 중앙에서 관리할 수 있습니다.
1. 연락처 정보에 회사 소유의 이메일 주소와 전화번호를 사용하면 상급자가 조직을 퇴사한 경우에도 액세스할 수 있습니다. 예를 들어 청구, 운영 및 보안에 대한 별도의 이메일 배포 목록을 생성하고, 각 활성 AWS 계정에서 이를 청구, 보안 및 운영 연락처로 구성합니다. 누군가 휴가 중이거나 역할이 변경되거나 퇴사하더라도 여러 사람이 AWS 알림을 수신하고 응답할 수 있게 됩니다.
1. 계정이 [AWS Organizations](https://aws.amazon.com/organizations/)에서 관리되지 않는 경우 대체 계정 연락처를 사용하면 AWS가 필요에 따라 적절한 담당자와 연락할 수 있습니다. 계정의 대체 연락처가 개인이 아닌 그룹으로 설정되도록 구성합니다.
1. 태그를 사용하여 AWS 리소스 소유자를 식별합니다. 소유자와 해당 연락처 정보를 별도의 태그로 지정할 수 있습니다.
1. [AWS Config](https://aws.amazon.com/config/) 규칙을 사용하여 리소스에 필수 소유권 태그가 포함되도록 할 수 있습니다.
1. 조직의 태그 지정 전략을 개발하는 방법에 대한 자세한 지침은 [AWS Tagging Best Practices 백서](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)를 참조하세요.
1. 생성형 AI를 사용하여 기업 시스템의 정보를 기반으로 직원 생산성을 높이고, 질문에 답하며, 작업을 완료하는 대화형 어시스턴트인 [Amazon Q Business](https://aws.amazon.com/q/business/)를 사용합니다.
1. Amazon Q Business를 회사의 데이터 소스에 연결합니다. Amazon Q Business는 Amazon Simple Storage Service(S3), Microsoft SharePoint, Salesforce, Atlassian Confluence를 포함하여 40개가 넘는 지원되는 데이터 소스에 대한 사전 구축된 커넥터를 제공합니다. 자자세한 내용은 [Amazon Q Business 커넥터](https://aws.amazon.com/q/business/connectors/)를 참조하세요.
1. 다른 리소스, 플랫폼 및 인프라의 경우 소유권을 식별하는 문서를 생성합니다. 모든 팀원이 여기에 액세스할 수 있어야 합니다.
**구현 계획의 작업 수준:** 낮음. 계정 연락처 정보 및 태그를 활용하여 AWS 리소스 소유권을 할당합니다. 다른 리소스의 경우 Wiki의 표와 같이 간단한 방식을 사용하여 소유권 및 연락처 정보를 기록하거나 ITSM 도구를 사용하여 소유권을 매핑할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 책임과 소유권을 관리하는 메커니즘 확보](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**관련 문서**:
+ [AWS Account Management - Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Updating alternative contacts in your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [AWS Tagging Best Practices 백서](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Build private and secure enterprise generative AI apps with Amazon Q Business and AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, now generally available, helps boost workforce productivity with generative AI](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS 클라우드 Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**관련 워크숍:**
+ [AWS 워크숍 - Tagging](https://catalog.workshops.aws/tagging/)
**관련 예제:**
+ [AWS Config 규칙 - Amazon EC2 with required tags and valid values](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**관련 서비스:**
+ [AWS Config 규칙 - required-tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 프로세스 및 절차의 소유자 식별
개별 프로세스와 절차의 정의에 대한 소유권이 있는 사람, 그러한 특정 프로세스와 절차가 사용되는 이유 그리고 소유권이 존재하는 이유를 파악합니다. 특정 프로세스 및 절차가 사용되는 이유를 이해하면 개선 기회를 파악할 수 있습니다.
**원하는 성과:** 운영 작업에 대한 일련의 프로세스와 절차가 효율적으로 정의 및 관리되고 있습니다. 프로세스와 절차는 중앙 위치에 저장되며 팀원이 사용할 수 있습니다. 프로세스 및 절차는 소유권을 명확하게 할당하여 자주 업데이트됩니다. 가능한 경우 스크립트, 템플릿 및 자동화 문서가 코드로 구현됩니다.
**일반적인 안티 패턴**:
+ 프로세스를 문서화하지 않습니다. 단편화된 스크립트가 격리된 운영자 워크스테이션에 존재할 수 있습니다.
+ 스크립트 사용 방법에 대한 지식은 소수의 개인이 보유하거나 팀 지식으로 비공식적으로 유지됩니다.
+ 업데이트에는 기존 프로세스가 필요하지만 업데이트의 소유권이 불분명하고 원래 작성자가 더 이상 조직의 일원이 아닙니다.
+ 프로세스와 스크립트를 검색할 수 없어 필요할 때(예: 인시던트 대응) 즉시 사용할 수 없습니다.
**이 모범 사례 확립의 이점:**
+ 프로세스와 절차를 통해 워크로드 운영 작업을 강화할 수 있습니다.
+ 새로운 팀원들은 더 빠르게 역량을 발휘할 수 있습니다.
+ 인시던트 완화 시간이 단축됩니다.
+ 여러 팀원(및 팀)이 동일한 프로세스와 절차를 일관되게 사용할 수 있습니다.
+ 팀이 반복 가능한 프로세스를 통해 프로세스 규모를 조정할 수 있습니다.
+ 표준화된 프로세스와 절차는 팀 간에 워크로드 책임을 이전하는 데 따른 영향을 완화하는 데 도움이 됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
+ 프로세스 및 절차에서 정의를 담당하는 소유자를 식별했습니다.
+ 워크로드 지원을 위해 수행되는 운영 활동을 식별합니다. 검색 가능한 위치에 이러한 활동을 문서화합니다.
+ 활동 지정을 담당하는 개인 또는 팀을 고유하게 식별합니다. 이들은 올바른 권한, 액세스 및 도구와 적절한 기술을 갖춘 팀원이 활동을 성공적으로 수행할 수 있도록 할 책임이 있습니다. 해당 활동을 수행하는 데 문제가 있는 경우 활동을 수행하는 팀원은 활동 개선에 필요한 상세한 피드백을 제공할 책임이 있습니다.
+ AWS Systems Manager와 같은 서비스, 문서, AWS Lambda를 통해 활동 아티팩트의 메타데이터에 대한 소유권을 파악합니다. 태그 또는 리소스 그룹을 사용하여 리소스 소유권을 캡처하고 소유권 및 연락처 정보를 지정합니다. AWS Organizations를 사용하여 태그 지정 정책을 생성하고 소유권 및 연락처 정보를 파악합니다.
+ 시간이 지남에 따라 이러한 절차를 코드로 실행할 수 있도록 발전시켜 사람이 개입할 필요가 줄어들어야 합니다.
+ AWS Lambda 함수, CloudFormation 템플릿 또는 AWS Systems Manager Automation 문서를 예로 들어 보겠습니다.
+ 적절한 리포지토리에서 버전 관리를 수행합니다.
+ 소유자와 문서를 쉽게 식별할 수 있도록 적절한 리소스 태그 지정을 포함합니다.
**고객 사례**
AnyCompany Retail은 소유권을 애플리케이션 또는 애플리케이션 그룹(공통 아키텍처 관행과 기술을 공유)에 대한 프로세스를 소유하는 팀 또는 개인으로 정의합니다. 처음에는 프로세스 및 절차가 문서 관리 시스템에 단계별 가이드로 문서화되며, 애플리케이션을 호스팅하는 AWS 계정과 계정 내 특정 리소스 그룹에서 태그를 사용하여 검색할 수 있습니다. 이들은 AWS Organizations를 사용하여 AWS 계정을 관리합니다. 시간이 지남에 따라 이러한 프로세스는 코드로 변환되고 리소스는 코드형 인프라(예: CloudFormation 또는 AWS Cloud Development Kit (AWS CDK) 템플릿)를 사용하여 정의됩니다. 운영 프로세스는 AWS Systems Manager 또는 AWS Lambda 함수의 자동화 문서가 됩니다. 그러면 AWS CloudWatch 경보 또는 AWS EventBridge 이벤트와 같은 이벤트에 대응하여 예약된 작업으로 시작되거나 IT 서비스 관리(ITSM) 플랫폼 내의 요청에 의해 시작될 수 있습니다. 모든 프로세스에는 소유권을 식별하는 태그가 있습니다. 자동화 및 프로세스에 대한 문서는 프로세스의 코드 저장소에서 생성한 Wiki 페이지 내에서 유지 관리됩니다.
### 구현 단계
1. 기존 프로세스 및 절차를 문서화합니다.
1. 이를 검토하고 최신 상태로 유지합니다.
1. 각 프로세스 또는 절차의 소유자를 식별합니다.
1. 이에 대한 버전을 관리합니다.
1. 가능하면 아키텍처 설계를 공유하는 워크로드 및 환경 전반에서 프로세스와 절차를 공유합니다.
1. 피드백 및 개선을 위한 메커니즘을 수립합니다.
1. 프로세스를 검토해야 하는 빈도에 대한 정책을 정의합니다.
1. 검토자와 승인자를 위한 프로세스를 정의합니다.
1. 피드백을 제공하고 추적할 수 있도록 문제 또는 티켓팅 대기열을 구현합니다.
1. 가능하면 프로세스 및 절차에는 변경 승인 위원회(CAB)의 사전 승인 및 위험 분류가 있어야 합니다.
1. 프로세스와 절차를 실행해야 하는 담당자가 프로세스와 절차에 액세스하고 검색할 수 있는지 확인합니다.
1. 태그를 사용하여 워크로드의 프로세스 및 절차에 액세스할 수 있는 위치를 지정합니다.
1. 의미 있는 오류 및 이벤트 메시지를 사용하여 문제를 해결하기 위한 적절한 프로세스나 절차를 지정합니다.
1. Wiki 및 문서 관리를 사용하여 프로세스 및 절차를 조직 전체에서 일관되게 검색할 수 있도록 합니다.
1. 생성형 AI를 사용하여 기업 시스템의 정보를 기반으로 직원 생산성을 높이고, 질문에 답하며, 작업을 완료하는 대화형 어시스턴트인 [Amazon Q Business](https://aws.amazon.com/q/business/)를 사용합니다.
1. Amazon Q Business를 회사의 데이터 소스에 연결합니다. Amazon Q Business는 Amazon S3, Microsoft SharePoint, Salesforce, Atlassian Confluence를 포함하여 40개가 넘는 지원되는 데이터 소스에 대한 사전 구축된 커넥터를 제공합니다. 자세한 내용은 [Amazon Q 커넥터](https://aws.amazon.com/q/business/connectors/)를 참조하세요.
1. 필요한 경우 자동화합니다.
1. 서비스 및 기술 팀에서 API를 제공할 경우 자동화를 개발해야 합니다.
1. 프로세스에 대해 적절하게 교육합니다. 사용자 스토리와 요구 사항을 개발하여 이러한 프로세스를 자동화합니다.
1. 프로세스와 절차의 사용을 성공적으로 측정하고, 지속적인 개선을 지원하기 위한 이슈 또는 티켓을 생성합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS02-BP01 리소스 소유자 식별](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 책임과 소유권을 관리하는 메커니즘 확보](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 지식 관리 수행](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**관련 문서:**
+ [AWS 백서 - AWS의 DevOps 소개](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 백서 - Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 백서 - Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 클라우드 Operations and Migrations Blog - Using Amazon Q Business to streamline your operations ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS 클라우드 Operations & Migrations Blog - Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 클라우드 Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**관련 워크숍:**
+ [AWS Well-Architected Operational Excellence 워크숍](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS 워크숍 - Tagging](https://catalog.workshops.aws/tagging/)
**관련 비디오:**
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [지원s You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**관련 서비스:**
+ [AWS Systems Manager - 자동화](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별
정의된 워크로드를 대상으로 하는 특정 활동 수행에 대한 책임 소재와 그러한 책임이 존재하는 이유를 파악합니다. 활동 수행에 대한 책임 소재를 파악하면 누가 작업을 수행하고, 누가 결과를 확인하며, 누가 활동 소유자에게 피드백을 제공할지 알 수 있습니다.
**원하는 성과:**
조직은 정의된 워크로드에서 특정 활동을 수행하고 워크로드에서 생성된 이벤트에 대응해야 할 책임을 명확하게 정의합니다. 조직은 프로세스 및 이행의 소유권을 문서화하고 이 정보를 검색할 수 있게 합니다. 조직 변경이 발생하면 책임을 검토 및 업데이트하고 팀은 결함 및 비효율성 식별 활동의 성과를 추적하고 측정합니다. 피드백 메커니즘을 구현하여 결함과 개선 사항을 추적하고 지속적인 개선을 지원합니다.
**일반적인 안티 패턴**:
+ 책임을 문서화하지 않습니다.
+ 단편화된 스크립트가 격리된 운영자 워크스테이션에 존재합니다. 이를 사용하는 방법을 알고 있거나 비공식적으로 *팀 지식*이라고 부르는 사람은 소수에 불과합니다.
+ 기존 프로세스를 업데이트할 예정이지만 프로세스 담당자가 누구인지 알 수 없으며 원래 작성자도 더 이상 조직의 일원이 아닙니다.
+ 프로세스와 스크립트를 검색할 수 없어 필요할 때(예: 인시던트 대응) 즉시 사용할 수 없습니다.
**이 모범 사례 확립의 이점:**
+ 누가 활동 수행을 담당하는지, 조치가 필요한 경우 누구에게 알릴 것인지, 누가 작업을 수행하고 결과를 검증하고 활동 소유자에게 피드백을 제공하는지 이해할 수 있습니다.
+ 프로세스와 절차를 통해 워크로드 운영 작업을 강화할 수 있습니다.
+ 새로운 팀원들은 더 빠르게 역량을 발휘할 수 있습니다.
+ 인시던트를 완화하는 데 걸리는 시간을 줄일 수 있습니다.
+ 팀마다 동일한 프로세스와 절차를 사용하여 일관된 방식으로 작업을 수행합니다.
+ 팀이 반복 가능한 프로세스를 통해 프로세스 규모를 조정할 수 있습니다.
+ 표준화된 프로세스와 절차는 팀 간에 워크로드 책임을 이전하는 데 따르는 영향을 완화하는 데 도움이 됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
책임을 정의하려면 먼저 책임 매트릭스, 프로세스 및 절차, 역할 및 책임, 도구 및 자동화와 같은 기존 문서부터 시작해야 합니다. 문서화된 프로세스의 책임을 검토하고 토론을 주최하세요. 팀과 함께 검토하여 문서의 책임과 프로세스 간의 불일치를 파악합니다. 팀 간의 기대치 차이를 파악하기 위해 해당 팀의 내부 고객과 함께 제공되는 서비스에 대해 논의하세요.
불일치를 분석하고 해결합니다. 개선 기회를 파악하고, 자주 요청되고 리소스를 많이 사용하는 활동(일반적으로 개선이 필요한 활동)을 찾아보세요. 개선을 간소화하고 표준화하기 위한 모범 사례, 패턴 및 권장 가이드를 살펴보세요. 개선 기회를 기록하고 개선이 완료될 때까지 추적하세요.
시간이 지남에 따라 이러한 절차를 코드로 실행할 수 있도록 발전시켜 사람이 개입할 필요가 줄어들어야 합니다. 예를 들어 프로시저는 AWS Lambda 함수, CloudFormation 템플릿 또는 AWS Systems Manager Automation 문서로 시작할 수 있습니다. 이러한 절차가 적절한 리포지토리에서 버전 관리되는지 확인하고 팀에서 소유자와 문서를 쉽게 식별할 수 있도록 적절한 리소스 태그 지정을 포함하세요. 활동 수행에 대한 책임을 문서화한 다음 성공적인 시작 및 운영과 원하는 성과의 성능을 위한 자동화를 모니터링합니다.
**고객 사례**
AnyCompany Retail은 소유권을 공통 아키텍처 관행과 기술을 공유하는 애플리케이션 또는 애플리케이션 그룹에 대한 프로세스를 소유하는 팀 또는 개인으로 정의합니다. 처음에 회사는 문서 관리 시스템의 단계별 지침으로 프로세스와 절차를 문서화합니다. AWS 계정을 관리하는 AWS Organizations를 통해, 애플리케이션을 호스팅하는 AWS 계정 태그와 계정 내 특정 리소스 그룹의 태그를 사용하여 프로시저를 검색할 수 있도록 합니다. AnyCompany Retail은 시간이 지남에 따라 이러한 프로세스를 코드로 변환하고 CloudFormation 또는 AWS Cloud Development Kit (AWS CDK) 템플릿과 같은 서비스를 통해 코드형 인프라를 사용하여 리소스를 정의합니다. 운영 프로세스는 AWS Systems Manager 또는 AWS Lambda 함수의 자동화 문서가 됩니다. 그러면 Amazon CloudWatch 경보 또는 Amazon EventBridge 이벤트와 같은 이벤트에 대응하여 예약된 작업으로 시작되거나 IT 서비스 관리(ITSM) 플랫폼 내의 요청에 의해 시작될 수 있습니다. 모든 프로세스에는 소유자를 식별하는 태그가 있습니다. 팀은 자동화 및 프로세스에 대한 문서를 프로세스의 코드 저장소에서 생성한 Wiki 페이지 내에서 관리합니다.
### 구현 단계
1. 기존 프로세스 및 절차를 문서화합니다.
1. 최신 상태인지 검토하고 확인합니다.
1. 각 프로세스 또는 프로시저에 소유자가 있는지 확인합니다.
1. 프로시저의 버전을 관리하세요.
1. 가능하면 아키텍처 설계를 공유하는 워크로드 및 환경 전반에서 프로세스와 절차를 공유합니다.
1. 피드백 및 개선을 위한 메커니즘을 수립합니다.
1. 프로세스를 검토해야 하는 빈도에 대한 정책을 정의합니다.
1. 검토자와 승인자를 위한 프로세스를 정의합니다.
1. 문제 또는 티켓팅 대기열을 구현하여 피드백을 제공하고 추적합니다.
1. 가능하면 프로세스 및 절차에는 변경 승인 위원회(CAB)의 사전 승인 및 위험 분류가 있어야 합니다.
1. 프로세스 및 프로시저를 실행해야 하는 사용자가 이를 액세스하고 검색할 수 있도록 합니다.
1. 태그를 사용하여 워크로드의 프로세스 및 절차에 액세스할 수 있는 위치를 지정합니다.
1. 의미 있는 오류 및 이벤트 메시지를 사용하여 문제를 해결하기 위한 적절한 프로세스나 절차를 지정합니다.
1. Wiki 또는 문서 관리를 사용하여 조직 전체에서 프로세스와 절차를 일관되게 검색할 수 있습니다.
1. 필요할 때 자동화하세요.
1. 서비스와 기술이 API를 제공하는 경우 자동화를 개발합니다.
1. 프로세스를 제대로 이해하고 있는지 확인하고 해당 프로세스를 자동화하기 위한 사용자 스토리와 요구 사항을 개발합니다.
1. 반복적 개선을 지원하는 문제 추적을 통해 프로세스 및 절차의 성공적인 사용을 측정합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS02-BP01 리소스 소유자 식별](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 책임과 소유권을 관리하는 메커니즘 확보](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 책임과 소유권을 식별하는 메커니즘](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 지식 관리 수행](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**관련 문서**:
+ [AWS 백서 \$1 AWS의 DevOps 소개](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 백서 \$1 Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 백서 \$1 Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 클라우드 Operations & Migrations Blog \$1 Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 워크숍 - Tagging](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**관련 비디오:**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [지원s You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 책임과 소유권을 관리하는 메커니즘 확보
역할의 책임과 비즈니스 성과에 기여하는 방법을 파악합니다. 이를 통해 작업의 우선순위와 역할이 중요한 이유를 알 수 있습니다. 그 결과 팀원들은 요구 사항을 인식하고 적절하게 대응할 수 있습니다. 팀원이 자신의 역할을 알게 되면 소유권을 확립하고 개선 기회를 식별하며 영향을 미치거나 적절한 변경을 수행하는 방법을 이해할 수 있습니다.
경우에 따라 책임의 소유자가 명확하지 않을 수 있습니다. 이러한 상황에서는 격차를 해소하는 메커니즘을 설계해야 합니다. 소유권을 할당하거나 필요 사항을 해결할 계획을 세울 권한이 있는 사람에게 이를 알릴 수 있도록 잘 정의된 에스컬레이션 경로를 만드세요.
**원하는 성과:** 조직 내 여러 팀이 리소스, 수행할 작업, 프로세스 및 절차와 관련된 방식을 포함하여 명확하게 정의된 책임을 갖고 있습니다. 이러한 책임은 팀의 책임과 목표는 물론 다른 팀의 책임과도 일치합니다. 일관되고 검색 가능한 방식으로 에스컬레이션 경로를 문서화하고 이러한 결정을 책임 매트릭스, 팀 정의 또는 Wiki 페이지와 같은 문서 아티팩트에 입력합니다.
**일반적인 안티 패턴**:
+ 팀의 책임은 모호하거나 잘못 정의되어 있습니다.
+ 팀은 역할과 책임을 연계하지 않습니다.
+ 팀은 목표와 목적, 책임을 조정하지 않으므로 성공을 측정하기가 어렵습니다.
+ 팀원의 책임이 팀 및 상위 조직에 적합하지 않습니다.
+ 팀은 책임을 최신 상태로 유지하지 않으므로 팀에서 수행하는 작업과 일치하지 않습니다.
+ 책임 결정을 위한 에스컬레이션 경로가 정의되어 있지 않거나 명확하지 않습니다.
+ 에스컬레이션 경로에는 시기적절한 응답을 보장하는 단일 스레드 소유자가 없습니다.
+ 역할, 책임 및 에스컬레이션 경로는 검색할 수 없으며 필요할 때(예: 인시던트 대응) 즉시 사용할 수 없습니다.
**이 모범 사례 확립의 이점:**
+ 책임이나 소유권을 가진 사람이 누구인지 알게 되면 적절한 팀이나 팀원에게 연락하여 요청을 하거나 작업을 전환할 수 있습니다.
+ 조치를 취하지 않거나 해결되지 않은 요구 사항이 발생할 위험을 줄이기 위해 책임 또는 소유권을 할당할 권한이 있는 사람을 지정하게 됩니다.
+ 책임 범위를 명확하게 정의하면 팀원이 자율성과 소유권을 얻게 됩니다.
+ 책임 범위 정의를 통해 사용자가 내리는 결정, 취하는 조치, 적절한 소유자에 대한 활동 전달을 알 수 있습니다.
+ 팀의 책임 범위를 벗어나는 것이 무엇인지 명확하게 이해할 수 있기 때문에 포기한 책임을 쉽게 식별할 수 있으며, 이를 통해 명확하게 에스컬레이션할 수 있습니다.
+ 팀은 혼란과 긴장을 피하고 워크로드와 리소스를 더 적절하게 관리할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
팀원의 역할과 책임을 식별하고 맡은 역할에 대한 기대치를 이해하도록 합니다. 조직의 구성원이 특정 요구 사항에 대해 연락할 팀이나 개인을 식별할 수 있도록 이 정보를 검색할 수 있게 설정합니다. 조직이 AWS에서 마이그레이션 및 현대화 기회를 활용하고자 함에 따라 역할과 책임도 달라질 수 있습니다. 팀과 팀원이 각자의 책임을 인식하도록 하고 이러한 변경 기간에 작업을 수행할 수 있도록 적절하게 교육하세요.
에스컬레이션을 받아야 하는 역할 또는 팀을 결정하여 책임과 소유권을 식별합니다. 이 팀은 다양한 이해관계자와 협력하여 결정을 내릴 수 있습니다. 그러나 이들은 의사 결정 프로세스의 관리를 담당해야 합니다.
조직 구성원에게 소유권과 책임을 발견하고 식별할 수 있는 액세스 가능한 메커니즘을 제공합니다. 이러한 메커니즘은 특정 요구 사항에 대해 누구에게 연락해야 하는지 알려줍니다.
**고객 사례**
AnyCompany Retail은 최근 리프트 앤 시프트 방식으로 온프레미스 환경에서 AWS 랜딩 존으로 워크로드를 마이그레이션하는 작업을 완료했습니다. 이들은 운영 검토를 수행하여 일반적인 운영 작업을 어떻게 수행하는지 되돌아보고 기존의 책임 매트릭스가 새로운 환경에서의 운영을 반영하는지 확인했습니다. 온프레미스에서 AWS로 마이그레이션하면서 하드웨어 및 물리적 인프라와 관련된 인프라 팀의 책임이 줄어들었습니다. 또한 이에 따라 워크로드의 운영 모델을 발전시킬 수 있는 새로운 기회가 드러났습니다.
이들은 대부분의 책임을 식별, 해결 및 문서화하는 동시에 운영 관행이 발전함에 따라 놓쳤거나 변경해야 할 수 있는 책임에 대한 에스컬레이션 경로도 정의했습니다. 워크로드 전반을 표준화하고 효율성을 개선할 수 있는 새로운 기회를 모색하려면 AWS Systems Manager와 같은 운영 도구와 AWS Security Hub CSPM 및 Amazon GuardDuty와 같은 보안 도구에 대한 액세스를 제공하세요. AnyCompany Retail은 가장 먼저 해결하고자 하는 개선 사항을 바탕으로 책임과 전략을 검토합니다. 회사는 새로운 업무 방식과 기술 패턴을 도입함에 따라 이에 맞게 책임 매트릭스를 업데이트합니다.
### 구현 단계
1. 기존 문서부터 시작하세요. 일반적인 소스 문서에는 다음이 포함될 수 있습니다.
1. 책임 또는 Responsible, Accountable, Consulted, and Informed(RACI) 매트릭스
1. 팀 정의 또는 Wiki 페이지
1. 서비스 정의 및 오퍼링
1. 역할 또는 직무 설명
1. 문서화된 책임을 검토하고 토론을 주최하세요.
1. 팀과 함께 검토하여 문서화된 책임과 팀이 일반적으로 수행하는 책임 간의 불일치 사항을 파악하세요.
1. 내부 고객이 제공하는 잠재적 서비스에 대해 논의하여 팀 간의 기대치 차이를 파악하세요.
1. 불일치를 분석하고 해결합니다.
1. 몇 가지 개선 기회를 파악합니다.
1. 자주 요구되고 리소스를 많이 사용하는 요청(일반적으로 강력한 개선 대상)을 식별합니다.
1. 모범 사례를 찾아보고, 패턴을 파악하고, 권장 가이드를 따라 개선을 간소화하고 표준화합니다.
1. 개선 기회를 기록하고 완료될 때까지 추적합니다.
1. 팀에 아직 책임 할당을 관리하고 추적할 책임이 없다면 팀에서 이 책임을 맡을 사람을 정합니다.
1. 팀의 책임 명시 요청 프로세스를 정의합니다.
1. 프로세스를 검토하고 명확하고 사용하기 쉬운지 확인합니다.
1. 누군가가 에스컬레이션을 담당하고 추적하여 결론에 도달하도록 하세요.
1. 운영 지표를 수립하여 효과를 측정합니다.
1. 피드백 메커니즘을 만들어 팀이 개선 기회를 강조할 수 있는지 확인하세요.
1. 주기적 검토를 위한 메커니즘을 구현합니다.
1. 검색 가능하고 액세스 가능한 위치에 문서화하세요.
1. 일반적으로는 Wiki 또는 문서 포털을 사용합니다.
**구현 계획의 작업 수준:** 중간
## 리소스
**관련 모범 사례:**
+ [OPS01-BP06 장단점 평가](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 팀원에게 성과 달성이 위태로울 때 조치를 취할 수 있는 권한 부여](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 에스컬레이션 장려](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 팀에 적절한 리소스 제공](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 지표를 통한 운영 목표 및 KPI 측정](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 운영 지표 검토 및 개선 우선순위 지정](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 지속적인 개선을 위한 프로세스 마련](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**관련 문서**:
+ [AWS 백서 - AWS의 DevOps 소개](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS 백서 - AWS 클라우드 Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [AWS Well-Architected Framework 운영 우수성 - 워크로드 수준 운영 모델 토폴로지](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS Prescriptive Guidance - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS Prescriptive Guidance - Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [AWS 클라우드 Operations & Migrations Blog - Delivering Business Value with Cloud Platform Teams](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [AWS 클라우드 Operations & Migrations Blog - Why a Cloud Operating Model?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps Blog - How organizations are modernizing for cloud operations](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**관련 비디오:**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 추가, 변경 및 예외를 요청하는 메커니즘
프로세스, 절차 및 리소스의 소유자에게 요청을 보낼 수 있습니다. 요청에는 추가, 변경 및 예외가 포함됩니다. 이러한 요청은 변경 관리 프로세스를 거칩니다. 이점과 위험을 평가한 후 요청이 적절한지 판단하고 정보에 입각한 의사 결정을 통해 실현 가능한 경우에 요청을 승인해야 합니다.
**원하는 성과:**
+ 할당된 소유권에 따라 프로세스, 절차 및 리소스 변경을 요청할 수 있습니다.
+ 변경은 이점과 위험을 저울질하면서 의도적으로 이루어집니다.
**일반적인 안티 패턴**:
+ 애플리케이션 배포 방법을 업데이트해야 하지만, 운영 팀의 배포 프로세스 변경을 요청할 수 있는 방법이 없습니다.
+ 재해 복구 계획을 업데이트해야 하지만, 변경을 요청할 식별된 소유자가 없습니다.
**이 모범 사례 확립의 이점:**
+ 프로세스, 절차 및 리소스는 요구 사항의 변화에 따라 달라질 수 있습니다.
+ 소유자는 정보에 입각하여 변경 시점을 결정할 수 있습니다.
+ 변경은 의도적인 방식으로 이루어집니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
이 모범 사례를 구현하려면 프로세스, 절차 및 리소스에 대한 변경을 요청할 수 있어야 합니다. 변경 관리 프로세스는 간단할 수 있습니다. 변경 관리 프로세스를 문서화합니다.
**고객 사례**
AnyCompany Retail은 책임 할당(RACI) 매트릭스를 사용하여 프로세스, 절차 및 리소스에 대한 변경 사항을 책임지는 소유자를 식별합니다. 문서화된 변경 관리 프로세스가 있어 간편하고 쉽게 변경 작업을 수행할 수 있습니다. RACI 매트릭스와 프로세스를 바탕으로 누구나 변경 요청을 제출할 수 있습니다.
**구현 단계**
1. 워크로드 및 각 워크로드의 소유자에 대한 프로세스, 절차 및 리소스를 식별합니다. 지식 관리 시스템에서 문서화합니다.
1. [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) 작업을 구현하지 않았다면 해당 작업부터 시작합니다.
1. 조직의 이해관계자와 협력하여 변경 관리 프로세스를 개발합니다. 프로세스에는 리소스, 프로세스 및 절차에 대한 추가, 변경 및 예외가 포함되어야 합니다.
1. [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)를 워크로드 리소스의 변경 관리 플랫폼으로 사용할 수 있습니다.
1. 지식 관리 시스템에서 변경 관리 프로세스를 문서화합니다.
**구현 계획의 작업 수준:** 중간. 변경 관리 프로세스를 개발하려면 조직 전체의 여러 이해관계자와 의견을 조율해야 합니다.
## 리소스
**관련 모범 사례:**
+ [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) - 변경 관리 프로세스를 구축하기 전에 운영 활동에 식별된 소유자가 있어야 합니다.
**관련 문서**:
+ [AWS Prescriptive Guidance - Foundation palybook for AWS large migrations: Creating RACI matrices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Change Management in the Cloud Whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**관련 서비스:**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 미리 정의되었거나 협상된 팀 간 책임
팀 간에 서로 협력하고 지원하는 방식에 관한 내용을 정의하거나 협상합니다(예: 응답 시간, 서비스 수준 목표 또는 서비스 수준에 관한 계약). 팀 간 통신 채널이 문서화되어 있습니다. 팀의 작업이 비즈니스 성과에 미치는 영향 그리고 다른 팀과 조직의 성과에 미치는 영향을 이해하면 작업의 우선순위를 파악하고 적절하게 대응할 수 있습니다.
책임과 소유권을 정의하지 않았거나 알지 못하는 경우 필요한 활동을 적시에 처리하지 못하게 되며 해당 요구 사항을 해결하기 위한 작업이 중복되고 잠재적으로는 상충될 위험이 있습니다.
**원하는 성과:**
+ 팀 간 작업 또는 지원 계약에 동의하고 문서화합니다.
+ 서로 지원하거나 협력하는 팀은 통신 채널과 대응 기대치를 정의합니다.
**일반적인 안티 패턴**:
+ 프로덕션에서 문제가 발생하고 2개의 개별 팀이 서로 독립적으로 문제 해결을 시작합니다. 이렇게 서로 분리되어 작업하면 운영 중단이 길어집니다.
+ 운영 팀은 개발 팀의 도움이 필요하지만, 응답 시간에 대해서는 합의된 바가 없습니다. 요청이 백로그에 쌓여 있습니다.
**이 모범 사례 확립의 이점:**
+ 팀이 서로 상호 작용하고 지원하는 방법을 알게 됩니다.
+ 응답성에 대한 기대치를 알게 됩니다.
+ 통신 채널이 명확하게 정의됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
이 모범 사례를 구현한다면 팀이 서로 협력하는 방식에 모호함이 사라집니다. 공식적인 합의에서는 팀이 협력하거나 서로를 지원하는 방식을 규정합니다. 팀 간 통신 채널이 문서화되어 있습니다.
**고객 사례**
AnyCompany Retail의 SRE 팀은 개발 팀과 서비스 수준에 관한 계약을 체결합니다. 개발 팀이 티켓팅 시스템에서 요청할 때마다 15분 안에 응답받기를 기대할 수 있습니다. 사이트 운영 중단이 발생하면 SRE 팀이 개발 팀의 지원을 받아 조사를 주도합니다.
**구현 단계**
1. 조직 전체의 이해관계자와 협력하여 프로세스 및 절차를 기반으로 팀 간의 계약을 개발합니다.
1. 프로세스 또는 절차를 두 팀 간에 공유하는 경우 각 팀이 협력할 방식에 대한 런북을 작성합니다.
1. 팀 간에 종속성이 있는 경우 요청에 대한 응답 SLA에 동의합니다.
1. 지식 관리 시스템에 책임을 문서화합니다.
**구현 계획의 작업 수준:** 중간. 기존에 팀 간 합의가 이루어지지 않은 경우 조직 전체의 이해관계자와 합의하는 데 노력이 필요할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [OPS02-BP02 프로세스 및 절차의 소유자 식별](ops_ops_model_def_proc_owners.md) - 팀 간 계약을 설정하기 전에 프로세스 소유권을 식별해야 합니다.
+ [OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별](ops_ops_model_def_activity_owners.md) - 팀 간 계약을 설정하기 전에 운영 활동 소유권을 식별해야 합니다.
**관련 문서**:
+ [AWS Executive Insights - 2-피자 팀을 통해 더 많이 빠르게 혁신](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [AWS에서 DevOps 소개 - 피자 두 판 팀 ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)