Atlassian Data Center 제품의 재해 복구

재해 복구 전략은 모든 비즈니스 연속성 계획의 핵심입니다. 재해 발생 시 비즈니스를 복구하고 계속 운영하기 위해 따라야 할 프로세스를 개략적으로 알아보세요.

재해 복구란 무엇입니까?

Atlassian Data Center 제품에서 재해 복구란 기본 인스턴스를 사용할 수 없는 경우에도 가용성을 보장한다는 의미입니다. Data Center 제품 전반에서 재해 복구에는 일반적으로 수동 대기 전략 수립이 포함됩니다. 쇼는 계속되어야 한다는 말처럼, 장애 조치 전략은 고가용성 및 재해 복구 계획을 달성하는 데 필수적인 부분입니다.

완전히 똑같은 재해 복구 계획은 없습니다.

Atlassian Data Center 제품의 재해 복구를 사용하면 재해 복구 계획의 특정 요구사항을 준수하도록 인덱스 복제, 첨부 파일 업데이트 및 데이터베이스 동기화를 구성할 수 있습니다.

재해 복구 계획 유형

IT 인시던트는 자연적인 상황이나 사이버 위협, 인적 오류, 잘못된 계획, 하드웨어 또는 소프트웨어 결함 등 사람이 야기한 상황으로 인해 발생할 수 있습니다. 재해가 어떻게 발생했는지 관계없이 가동 중지 시간은 생산성과 수익 손실로 이어집니다. 조직이 성장할수록 더 많은 팀이 재해 복구 계획의 결과에 의존하게 됩니다.

조직이 사용하는 모든 도구에 대해 재해 복구 계획을 세워야 합니다. 여기에는 자체 관리 제품(예: Atlassian의 Data Center 제품) 또는 Cloud 호스팅 제품이 포함됩니다. 최근에는 타사 복제 및 호스팅 서비스를 제공하여 다른 위치로 장애 조치를 넘기는 DRaaS(Disaster Recovery as a Service) 도구의 인기가 높아졌습니다.

조직에서 사용하는 인프라에 따라 IT 인프라, 조직 네트워크 인프라 및 사용되는 가상 컴퓨터의 물리적 측면을 아우르는 재해 복구 계획이 필요할 수 있습니다.

재해 복구 계획의 이점

재해 복구 계획은 재해 발생 후 미션 크리티컬 비즈니스 애플리케이션을 빠르게 복구하기 위한 문서화된 프로세스입니다. 그러나 재해가 발생할 때까지는 재해 계획이 대부분 이론에 불과합니다.

재해 복구 계획을 세우면 복구 시간을 단축하고 재해에 직면했을 때 가동 중지 시간이나 데이터 손실 가능성을 최소화할 수 있다는 이점이 있습니다.

재해 복구 계획에 영향을 주는 세 가지 요소는 RPO(복구 지점 목표), RTO(복구 목표 시간) 및 RCO(복구 비용 목표)입니다.

복구 지점 목표

RPO는 장애 발생 후 시스템이 얼마나 최신 상태여야 하는지, 또는 장애 발생 시 얼마나 많은 데이터를 손실해도 되는지를 나타냅니다.

복구 시간 목표

RTO는 장애 발생 후 대기 시스템을 얼마나 빨리 사용할 수 있어야 하는지를 나타냅니다.

복구 비용 목표

RCO는 재해 복구 솔루션 또는 계획에 얼마나 지출할 계획인지를 나타냅니다.

재해 복구 전략을 구현하기 위한 Data Center 제품 구성

재해 복구 전략을 구현하도록 Atlassian Data Center 제품을 구성하여 전체 시스템 또는 특정 위치에 장애가 발생해도 비즈니스 연속성을 보장하고 복구 시간 목표를 준수하세요. Jira, Confluence 및 Bitbucket의 Data Center 버전을 이용하면 재해 발생 시 수동 대기 인스턴스를 설정할 수 있습니다.

가장 먼저, 팀이 시작하지 않고도 대기 시스템을 만들도록 지원할 수 있습니다. 그런 다음 데이터 복제 전략을 구현해야 합니다. 데이터를 대기 위치로 복제하는 것은 수동 대기 전략에서 매우 중요합니다. 즉, 대기 인스턴스로 장애 조치를 하여 오래된 인스턴스나 데이터베이스를 다시 인덱싱하는 데 시간이 오래 걸리는 일을 방지할 수 있습니다.

활성 Data Center 라이선스가 있는 경우 수동 대기 인스턴스에서 Jira, Confluence 또는 Bitbucket을 시작하기 위해 라이선스를 추가 또는 별도로 구매할 필요가 없습니다.

재해 복구 테스트

소방관 및 의료진 같은 응급 서비스 팀은 정기적으로 구조 스킬을 연습하는데, 팀이 그렇게 못할 이유가 있을까요? 팀은 연습을 통해 압박감이 심한 상황에서도 익숙하고 편안한 자세로 더 빠르고 만족스럽게 문제를 해결할 수 있습니다.

Jira, Confluence 및 Bitbucket의 경우 재해 복구 테스트를 수행하기 전에 프로덕션 데이터를 분리하는 것이 좋습니다. 그런 다음 장애 조치 시스템이 준비되었는지 확인하고 애플리케이션을 시작합니다. 로그 파일을 모니터링하고 일관성 이슈를 확인하는 것도 잊지 마세요. 테스트 후에는 대기 컴포넌트 복제가 발생할 수 있는 상태로 복원하여 재해 복구 배포를 다시 설정합니다. 대부분의 경우 대기 인프라를 다시 설정하는 게 더 쉬울 수 있습니다.

비즈니스 연속성 및 재해 복구 비교

비즈니스 연속성과 재해 복구는 종종 같은 의미로 사용되지만 용어의 개념은 서로 다릅니다.

비즈니스 연속성

비즈니스 연속성 계획은 조직이 가동 중지 시간 최소화하면서 비즈니스를 운영할 수 있도록 지원하는 전략을 말합니다.

비즈니스 연속성 계획의 첫 번째 단계는 비즈니스 영향 분석을 개발하는 것입니다. 여기에는 비즈니스 기능의 평가 및 우선 순위 지정, IT 재해의 잠재적 영향 식별이 포함되어야 합니다. 비즈니스 영향 분석에는 또한 허용 가능한 최대 가동 중지 시간 및 복구 시간 목표의 추정치도 포함할 수 있습니다. 잠재적 종속성을 식별하려면 비즈니스 영향 분석을 수행하는 것이 중요합니다.

비즈니스 연속성 계획을 수립하는 데 있어 그다음 단계는 위험 평가입니다. 조직은 비즈니스 영향 분석을 사용하여 위협을 분석하고 잠재적인 재해의 가능성과 심각도를 고려해야 합니다. 그런 다음 조직은 비즈니스 프로세스의 우선 순위를 지정하고 기존 정책과의 격차 분석을 수행할 수 있습니다. 위험 평가는 더 나은 결과를 달성하기 위한 조직의 지출 계획에 영향을 미칠 수도 있습니다.