Close

더 나은 인시던트 관리를 위한 길은 여기에서 시작됩니다

IT 운영 및 DevOps 전문가를 위한 재해 복구 계획

IT 서비스 팀이 보이지 않는 곳에서 비용을 잡아먹는 부서에서 핵심 비즈니스 가치를 창출하는 부분으로 변화하면서, 효과적인 IT 재해 복구 관행은 그 어느 때보다 중요해졌습니다.

애플리케이션 가동 중지 시간, 데이터 손실 또는 심지어는 온프레미스 화재 등 어떤 것이든, 재해 발생 시 대응은 간단하게 할 수 있는 경우가 거의 없습니다.

소규모 기업의 경우 복구로 인해 상당한 타격을 받을 수 있습니다. FEMA에 따르면 소규모 기업의 약 40~60%는 재해 이후에 다시 영업을 하지 못합니다.

재해 복구 계획이란 무엇입니까?

재해 복구 계획은 재해 발생 시 조직과 조직의 IT 자산을 보호하기 위해 문서화된 관행과 절차입니다. 일반적으로 계획에는 비즈니스 및 IT 서비스 운영을 위한 시나리오, 런북, 백업 및 안내가 포함됩니다. 특히 시스템 장애, 가동 중지 시간, 보안 침해 또는 데이터 손실과 같은 이벤트와 관련이 있습니다.

IBM에 따르면 다음과 같습니다.

"1970년대 이전에 대부분의 조직은 종이로 된 기록의 복사본을 만들기만 하면 되었습니다. 1970년대에 기업이 컴퓨터 기반 운영에 더 의존하기 시작하면서 재해 복구 계획의 중요성이 대두되었습니다. 그 당시 대부분의 시스템은 배치 중심의 메인프레임이었습니다. 기본 사이트가 복구될 때까지 기다리는 동안 백업 테이프에서 또다른 오프사이트 메인프레임을 로드할 수 있었습니다."

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

재해 복구 계획은 비즈니스 연속성 계획의 하위 집합입니다. 재해 복구 계획은 영향을 받는 서비스를 최대한 빠르게 다시 가동하는 데 초점을 맞추는 한편, 비즈니스 연속성 계획은 재해 발생 시 중단 없이 비즈니스를 운영하는 데 중점을 둡니다.

IT 팀은 재해 복구 및 비즈니스 연속성 두 가지 관행 모두에서 중심적인 역할을 합니다.

재해 복구와 비즈니스 연속성을 혼동하거나 서로 대체 가능한 것으로 취급하기 쉽습니다. 재해 복구 계획은 인시던트 발생 후 서비스를 복원하는 것을 목표로 합니다. 재해 복구는 전체 비즈니스 연속성 계획의 작은 부분입니다. 비즈니스 연속성 계획은 인시던트 전후와 그 도중에 조직의 기능을 유지하도록 설계되었습니다. 재해 복구가 “인시던트를 종료하는 방법”에 대한 문제라면 비즈니스 연속성은 “인시던트 발생 시에도 비즈니스를 계속 운영할 수 있는 방법”에 관한 것입니다.

재해 복구 계획 및 인시던트 관리 비교

DevOps 및 IT 운영 팀의 경우, 인시던트 관리는 예기치 않은 이벤트 또는 서비스 중단에 대응하고 서비스를 운영 상태로 복원하는 데 사용되는 프로세스입니다.

인시던트 관리와 재해 복구는 팀과 조직에 따라 서로 대체 가능한 방식으로 사용되는 경우가 많습니다. 인시던트 관리 역시 실시간으로 인시던트를 해결하고 인시던트 중에 서비스를 다시 가동하고 실행하는 데 중점을 둡니다.

Atlassian에서는 인시던트를 서비스 중단 또는 서비스 품질 저하를 야기하여 즉각적인 대응이 필요한 이벤트로 정의하고 있습니다.

또는 사이트 신뢰성 엔지니어링에 대한 Google의 책에서는 다음과 같이 정의합니다.

"효과적인 인시던트 관리는 인시던트로 인한 중단을 제한하고 최대한 빠르게 정상적인 비즈니스 운영을 복원하는 데 중요합니다. 잠재적 인시던트에 대한 대응을 미리 계획하지 않았다면 실제 상황에서 원칙적인 인시던트 관리가 이루어지지 못할 수 있습니다."

또한 Google은 조직의 재해 복구 테스트 프로세스의 일부로 인시던트 관리를 포함할 것을 권장합니다. 인시던트 대응 프로세스를 통해 대응자의 조치와 커뮤니케이션을 기록하여 향후의 관련 인시던트 또는 서비스 중단에 대한 리소스로 사용할 수 있는 풍부한 인시던트 타임라인을 만드는 것이 이상적입니다. 팀이 운영에 대한 완전한 컨텍스트를 가지게 되므로, 재해 복구 테스트를 수행하는 조직에 유용합니다.

복구 시간 목표란 무엇입니까?

복구 시간 목표는 서비스 중단 후 비즈니스 기능이 정상적인 서비스를 다시 시작하는 데 허용되는 복구 시간입니다. DevOps 메트릭에 나오는 평균 복구 시간과 밀접한 관련이 있습니다.

DevOps 환경에서의 재해 복구 계획

지속적 제공, 자동화된 테스트 및 하루에도 여러 번 배포하는 환경에서 재해 복구 계획은 어떻게 관련성을 유지할 수 있습니까?

즉, DevOps를 실행하는 조직에서 재해 복구 계획은 어떤 역할을 합니까?

다행히 두 가지 관행은 함께 존재하면서 서로에게 도움이 될 수 있습니다. 코드를 개발에서 테스트, 프로덕션으로 푸시하는 데 사용하는 똑같은 도구 및 프로세스가 재해 복구에도 중요한 역할을 할 수 있습니다. 예를 들어, 배포를 테스트하는 데 사용되는 프로덕션 환경의 백업은 재해 시뮬레이션을 실행하는 데도 사용될 수 있습니다. 또한 CI/CD 파이프라인에서 추적된 코드 커밋은 재해 복구 시나리오의 최근 변경 사항을 드러내는 데 유용한 도구가 될 수 있습니다.

DevOps가 회사의 모든 IT 의사 결정의 속도를 점점 더 빠르게 만들고 있다는 것은 모두가 아는 사실입니다. 그렇다고 해서 복구 계획과 리소스에 투입된 노력이 낭비된 것이거나 재해 복구 계획이 오랫동안 사용되지 않아 방치될 것이라는 의미는 아닙니다.

Atlassian의 인시던트 관리 솔루션인 Jira Service Management에 대해 자세히 알아보고 이 솔루션이 개발 및 운영 팀이 인시던트를 해결하든, 재해 복구 모드에 있든 공동 작업할 수 있는 유연성을 제공하는 방법을 살펴보세요.