DR 시범 테스트

드라이 테스트는 DR 계획의 종이 기반 연습 실행입니다. 드라이 테스트를 실행할 때는 복구를 수행하지 않지만 계획에 명백한 구멍이 없는지 확인합니다. 예를 들어 드라이 테스트는 이를 보장하는 데 도움이 됩니다:

• 적합한 인력을 보유하고 있는지 확인합니다
• 백업이 존재하고 사용 가능합니다
• 직원 간 커뮤니케이션 채널이 작동 중입니다
• dR 런북에 누락된 단계가 없습니다
• 팀 간의 효율적인 핸드오프 작업

DR 드라이 테스트는 다른 테스트와 마찬가지로 기술과 인력 측면에서 동일한 노력이 필요합니다. 실제 복구 작업이 수행되지 않기 때문에 이 유형의 테스트는 더 빠르므로 일반적으로 다른 테스트 유형에 비해 더 높은 빈도로 실행됩니다. 요금제 전체를 실행할지 아니면 요금제 내의 개별 부분과 서비스를 테스트할지 선택할 수 있습니다.

DR 시뮬레이션

DR 시뮬레이션은 실제 비상 상황을 시뮬레이션하여 데이터를 복구함으로써 비상 런북을 검증 또는 감사하고 솔루션에서 제공하는 복구 시간 목표재해 복구 계획에서, 재해 발생 후 비즈니스 프로세스를 복구하는 데 걸리는 시간입니다. (RTO) 및 복구 지점 목표재해 복구 계획에서 데이터 복구 시간은 복구된 시점부터 재해 발생 시점까지 걸린 시간(초, 분, 시간)으로 측정됩니다. (RPO)를 확인하는 방법입니다.

DR 시뮬레이션은 프로덕션 워크로드에 영향을 주지 않으면서 기본 리전에서 데이터 복제에 잠재적인 중단을 도입하는 것이므로 신중한 계획이 필요합니다. DR 환경을 테스트하는 동안에는 실제 재해 복구 목적으로 일시적으로 사용할 수 없을 수도 있습니다. 이러한 위험은 특정 클라우드 서비스와 배포 방식에 따라 달라집니다. 일부 서비스는 테스트와 가용성을 동시에 허용할 수 있지만, 그렇지 않은 서비스도 있습니다.

DR 시뮬레이션은 테스트 및 검증을 위해 지정된 DR 지역에 프로덕션 환경의 임시 복사본을 생성합니다. 시뮬레이션이 종료되면 테스트 환경이 삭제되거나 초기화되며, 기본 프로덕션 환경이 계속 정상적으로 작동하므로 테스트 중에 변경된 내용은 모두 폐기됩니다.

전환

전환에는 프로덕션 환경을 한 지역에서 다른 지역으로 전환하는 작업이 포함됩니다. 이 방법은 대체 지역에서 장기간 생산 운영을 실행하고 유지할 수 있는 능력을 검증하고 감사하는 데 도움이 됩니다. 프로덕션 작업은 첫 번째 지역에서 정상적으로 중단되고 두 번째 지역으로 전환되며, 필요한 데이터 복구가 완료된 후 다시 시작됩니다.

두 번째 리전이 예상대로 작동하는지 확인한 후에는 프로덕션 활동을 재개하고 데이터 복제를 구성하여 원래 리전을 새 보조 리전으로 만들 수 있습니다. 프로덕션 환경은 다시 전환하기로 결정할 때까지 이 사이트에서 계속 실행됩니다.

DR 테스트 빈도

DR 계획을 얼마나 자주 테스트하는지는 규정 준수 표준에서 요구하는 사항을 비롯한 여러 요인에 따라 달라집니다. 규정 준수가 문제가 되지 않는다면 적어도 1년에 한 번 전체 DR 테스트를 수행하고 감사자의 검토를 위해 결과를 문서화하는 것을 목표로 하세요. 준비 상태를 확인하기 위해 일 년 내내 소규모 테스트를 실행하는 것이 좋습니다.

다음 질문을 고려하여 시험 빈도를 조정하세요:

내 워크로드는 얼마나 동적인가요?

워크로드가 더 많이 변경될수록 어떤 형태의 DR 테스트를 더 자주 수행해야 합니다. 이렇게 하면 변경 사항이 복구 기능에 영향을 미치지 않는지 확인할 수 있습니다. 변경 사항에는 새로운 종속성, 기타 클라우드 서비스, 인프라 변경 등이 포함될 수 있습니다. 데이터 세트가 증가하면 복구하는 데 시간이 오래 걸리므로 특정 RTO를 충족하는 데 영향을 미칠 수 있습니다.

내 인력은 얼마나 역동적인가요?

테스트 주기에 직원 이직률도 고려할 수 있습니다. 복구를 수행하는 직원이 변경되는 경우, 새로운 팀원이 DR의 작동 방식과 DR 계획에서 자신의 역할을 이해하도록 하세요. 확실하지 않거나 DR 테스트에 익숙하지 않은 새로운 팀원이 여러 명 있는 경우 복구 계획에 위험이 추가됩니다.

그 밖에 어떤 테스트에 중점을 두어야 하나요?

재해 복구 테스트의 주요 목표는 워크로드를 성공적으로 복구할 수 있는지 확인하는 것입니다. 그러나 다음 사항도 제대로 작동하는지 확인하세요:

• 핵심 인력: DR 계획에는 성공적인 복구를 위해 필요한 인력과 각 인력의 역할에 대한 개요가 포함되어야 합니다. 테스트 중에 더 많은 인원이나 역할이 필요한지, 아니면 일부 인원이 요구 사항에 비해 초과되었는지, 사람들이 자신의 역할을 얼마나 잘 수행할 수 있었는지 고려하세요.
• 커뮤니케이션: DR 계획에는 재해 발생 시 커뮤니케이션 방법을 명확하게 설명해야 합니다. 테스트 중에 사용된 커뮤니케이션 채널을 포함하여 참가자 간의 커뮤니케이션이 얼마나 잘 이루어졌는지 고려하세요.
• 문서화된 종속성: DR 계획에 종속성이 설명되어 있을 가능성이 높습니다. 이러한 정보가 유효한지, 복구 프로세스를 방해하지 않는지 확인하세요. 동시에 새로운 종속성이 기록되어 있는지 확인하세요.
• 기타 문서: 런북은 복구를 구현하는 데 사용될 수 있으므로 얼마나 정확하고 효과적인지 이해하는 것이 중요합니다. 단계를 과소 문서화하면 지연이 발생할 수 있으며, 너무 자세하거나 관련성이 없는 세부 정보를 제공하는 것도 같은 결과를 초래할 수 있습니다. 작성자가 아닌 다른 사람이 단계를 테스트하여 명확한지 확인하도록 합니다. 이렇게 하면 재해가 발생하여 작성자가 부재 중일 때에도 프로세스를 사용할 수 있습니다.

테스트 후

테스트가 완료되면 다음 테스트를 위한 벤치마크로 결과를 기록합니다. 나중에 테스트 절차를 변경하면 결과를 쉽게 비교할 수 있습니다.

각 재해 복구 테스트 후에는 결과에 따라 계획 및 관련 문서를 업데이트합니다. DR 계획은 효과를 유지하기 위해 정기적으로 조정해야 하는 살아있는 문서입니다. 참가자의 피드백을 통해 무엇이 효과가 있었고 무엇이 효과가 없었는지 파악하고 이러한 인사이트를 향후 테스트에 반영하세요. 또한 역할 명확화, 의사소통 개선, 기술 역량 강화 등 필요한 경우 더 많은 교육을 제공하는 것도 고려하세요.