OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별 - 운영 우수성 원칙
구현 지침리소스

OPS02-BP03 운영 활동에서 성능을 담당하는 소유자 식별

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

원하는 성과:

조직은 정의된 워크로드에서 특정 활동을 수행하고 워크로드에서 생성된 이벤트에 대응해야 할 책임을 명확하게 정의합니다. 조직은 프로세스 및 이행의 소유권을 문서화하고 이 정보를 검색할 수 있게 합니다. 조직 변경이 발생하면 책임을 검토 및 업데이트하고 팀은 결함 및 비효율성 식별 활동의 성과를 추적하고 측정합니다. 피드백 메커니즘을 구현하여 결함과 개선 사항을 추적하고 지속적인 개선을 지원합니다.

일반적인 안티 패턴:

  • 책임을 문서화하지 않습니다.

  • 단편화된 스크립트가 고립된 운영자 워크스테이션에 존재합니다. 이를 사용하는 방법을 알고 있거나 비공식적으로 팀 지식이라고 부르는 사람은 소수에 불과합니다.

  • 기존 프로세스를 업데이트할 예정이지만 프로세스 담당자가 누구인지 알 수 없으며 원래 작성자도 더 이상 조직의 일원이 아닙니다.

  • 프로세스와 스크립트를 검색할 수 없어 필요할 때(예: 인시던트 대응) 즉시 사용할 수 없습니다.

이 모범 사례 확립의 이점:

  • 누가 활동 수행을 담당하는지, 조치가 필요한 경우 누구에게 알릴 것인지, 누가 작업을 수행하고 결과를 검증하고 활동 소유자에게 피드백을 제공하는지 이해할 수 있습니다.

  • 프로세스와 절차를 통해 워크로드 운영 작업을 강화할 수 있습니다.

  • 새로운 팀원들은 더 빠르게 역량을 발휘할 수 있습니다.

  • 인시던트를 완화하는 데 걸리는 시간을 줄일 수 있습니다.

  • 팀마다 동일한 프로세스와 절차를 사용하여 일관된 방식으로 작업을 수행합니다.

  • 팀이 반복 가능한 프로세스를 통해 프로세스 규모를 조정할 수 있습니다.

  • 표준화된 프로세스와 절차는 팀 간에 워크로드 책임을 이전하는 데 따르는 영향을 완화하는 데 도움이 됩니다.

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

구현 가이드

책임을 정의하려면 먼저 책임 매트릭스, 프로세스 및 절차, 역할 및 책임, 도구 및 자동화와 같은 기존 문서부터 시작해야 합니다. 문서화된 프로세스의 책임을 검토하고 토론을 주최하세요. 팀과 함께 검토하여 문서의 책임과 프로세스 간의 불일치를 파악합니다. 팀 간의 기대치 차이를 파악하기 위해 해당 팀의 내부 고객과 함께 제공되는 서비스에 대해 논의하세요.

불일치를 분석하고 해결합니다. 개선 기회를 파악하고, 자주 요청되고 리소스를 많이 사용하는 활동(일반적으로 개선이 필요한 활동)을 찾아보세요. 개선을 간소화하고 표준화하기 위한 모범 사례, 패턴 및 권장 가이드를 살펴보세요. 개선 기회를 기록하고 개선이 완료될 때까지 추적하세요.

시간이 지남에 따라 이러한 절차를 코드로 실행할 수 있도록 발전시켜 사람이 개입할 필요가 줄어들어야 합니다. 예를 들어 프로시저는 AWS Lambda 함수, AWS 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. 최신 상태인지 검토하고 확인합니다.

    2. 각 프로세스 또는 프로시저에 소유자가 있는지 확인합니다.

    3. 프로시저의 버전을 관리하세요.

    4. 가능하면 아키텍처 설계를 공유하는 워크로드 및 환경 전반에서 프로세스와 절차를 공유합니다.

  2. 피드백 및 개선을 위한 메커니즘을 수립합니다.

    1. 프로세스를 검토해야 하는 빈도에 대한 정책을 정의합니다.

    2. 검토자와 승인자를 위한 프로세스를 정의합니다.

    3. 문제 또는 티켓팅 대기열을 구현하여 피드백을 제공하고 추적합니다.

    4. 가능하면 프로세스 및 절차에는 변경 승인 위원회(CAB)의 사전 승인 및 위험 분류가 있어야 합니다.

  3. 프로세스 및 프로시저를 실행해야 하는 사용자가 이를 액세스하고 검색할 수 있도록 합니다.

    1. 태그를 사용하여 워크로드의 프로세스 및 절차에 액세스할 수 있는 위치를 지정합니다.

    2. 의미 있는 오류 및 이벤트 메시지를 사용하여 문제를 해결하기 위한 적절한 프로세스나 절차를 지정합니다.

    3. Wiki 또는 문서 관리를 사용하여 조직 전체에서 프로세스와 절차를 일관되게 검색할 수 있습니다.

  4. 필요할 때 자동화하세요.

    1. 서비스와 기술이 API를 제공하는 경우 자동화를 개발합니다.

    2. 프로세스를 제대로 이해하고 있는지 확인하고 해당 프로세스를 자동화하기 위한 사용자 스토리와 요구 사항을 개발합니다.

    3. 반복적 개선을 지원하는 문제 추적을 통해 프로세스 및 절차의 성공적인 사용을 측정합니다.

구현 계획의 작업 수준: 중간

리소스

관련 모범 사례:

관련 문서:

관련 비디오:

관련 예제: