# 모범 사례 4.3 - 정기적으로 비즈니스 연속성 계획 및 장애 복구 테스트 SAP 시스템은 일반적으로 주요 고객 대면 트랜잭션에 사용되는 비즈니스 중요 시스템입니다. 장애 또는 재해 상황에서 IT 운영을 신속하게 재개하고 데이터 손실을 최소화하는 것은 운영 우수성을 유지하는 데 매우 중요합니다. 비즈니스 연속성 계획(BCP) 및 장애 복구 절차는 장애 발생 시 운영 팀 및 시스템이 무엇을 언제 해야 하는지 숙지하고 워크로드 서비스를 즉각적으로 재개할 수 있도록 하는 데 필요합니다. 시스템 및 지원 팀이 발전함에 따라 정기적으로 BCP 절차 및 장애 복구 계획을 테스트, 개선 및 구체화하는 것이 서비스를 성공적으로 재개하는 데 중요합니다. 실제 위기 상황이 아닐 때 BCP 및 복구 계획을 테스트하면 실제 시스템 장애 또는 재해가 발생할 경우 서비스를 성공적으로 재개할 수 있는 능력을 확신할 수 있고 복구 시간 목표(RTO) 및 복구 시점 목표(RPO)를 달성할 수 있습니다. **제안 사항 4.3.1 - BCP 및 장애 복구 테스트 캘린더를 작성** SAP 워크로드에 대한 정기(최소 1년) BCP 및 장애 복구 테스트를 예약하는 캘린더를 만듭니다. 절차를 숙지하고 일치된 예상을 할 수 있도록 기술 운영 팀, 지원 담당자 및 비즈니스 이해 관계자를 이 테스트에 참여시킵니다. 가능한 한 실제 상황에서 시스템을 테스트하는 것을 목표로 합니다. 다음 시나리오를 테스트하고 각 시나리오에 대한 복구 지표를 검증하는 것을 고려합니다. + SAP 애플리케이션 서비스 장애 *(예: SAP 애플리케이션 서비스가 구성 변경으로 인해 시작되지 않음)* + 단일 인스턴스 호스트 장애 *(예: SAP 애플리케이션 서버 EC2 인스턴스에 연결할 수 없음)* + 단일 스토리지 볼륨 장애 *(예: 단일 EBS 볼륨에 연결할 수 없음)* + 네트워크 장애 및 이중화 연결로 전환 *(예: 온프레미스 Direct Connect 연결이 끊어짐)* + 클러스터링된 기본 구성 요소와 보조 구성 요소 간에 자동 장애 조치 *(예: SUSE HAE 클러스터가 강제로 프라이머리 HANA 데이터베이스를 대체 가용 영역의 세컨더리 데이터베이스로 이동)* + 기본 구성 요소와 보조 구성 요소 간의 수동 장애 조치 *(예: 수동으로 Oracle DataGuard를 대체 가용 영역의 세컨더리 데이터베이스로 전환)* + 여러 이중화 구성 요소 간의 로드 밸런싱 *(예: 가용 영역 간 고가용성 페어의 기본 웹 디스패처에서 장애가 발생)* + 대체 AWS 리전에서 SAP 애플리케이션 복구(필요한 경우) + 랜섬웨어 발생 시 백업에서 복구 *(예: Amazon S3 WORM 백업에서 전체 SAP ERP 시스템을 복구)* **제안 사항 4.3.2 - 워크로드 변경의 일부로 정기적으로 BCP 및 장애 복구 절차를 검토 및 업데이트** 시간이 흐르면서 워크로드가 발전하고 변경되는 과정에서 BCP 및 복구 절차를 고려해야 합니다. 코드 또는 인프라 변경이 RTO 또는 RPO에 영향을 줄 수 있는 경우 설명서 및 구성을 업데이트하고 릴리스 프로세스 또는 정기 테스트 일정의 일부로 새 BCP 및 복구 절차를 테스트해야 합니다. + AWS 설명서: [비즈니스 연속성 계획(BCP) 정의](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html) + AWS 설명서: [Architecture Guidance for Availability and Reliability of SAP on AWS(SAP on AWS의 가용성 및 안정성을 위한 아키텍처 지침)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) + SAP Lens [안정성]: [모범 사례 11.4 - 주기적으로 복원력 테스트 수행](best-practice-11-4.md)