9.5 재해 복구와 비즈니스 연속성

개요와 동기

조만간 계획하지 않은 무언가가 시스템을 내릴 것입니다. 리전 전체의 클라우드 장애, 실수로 친 DROP TABLE, 데이터 센터의 홍수, 랜섬웨어의 폭발, 하룻밤 사이에 사라지는 공급자입니다. 질문은 결코 중단이 오는지가 아니라 얼마나 빨리 복구하고 그 과정에서 얼마를 잃는지입니다. 이 장은 나쁜 날이 오기 전에 대비하는 것에 관한 것입니다.

두 규율이 그 준비에 답하며, 둘은 같은 것이 아닙니다. 비즈니스 연속성 계획(BCP)은 중단을 거치며 조직 전체가 기능하도록 유지합니다. 사람, 사무실, 소통, 급여, 고객이 의존하는 핵심 비즈니스 프로세스입니다. 재해 복구(DR)는 IT 시스템과 데이터가 실패한 뒤 복원하는 더 좁은 기술적 일입니다. 연속성이 목표이고 복구는 수단의 하나입니다. 모든 서버를 복원하고도 누가 재해를 선언할 권한이 있는지, 그들에게 어떻게 닿는지 아무도 몰랐다면 고객을 실패시킬 수 있습니다. 이 장은 DR을 엔지니어링 실천으로, BCP를 그것이 봉사하는 비즈니스 틀로 다룹니다.

큰 팀에게 판돈은 여러분과 함께 커집니다. 기업은 규제상의 복구 의무, 다중 리전 영역, 소수 공급자에 대한 집중 위험을 집니다. 정부는 시민을 위해 필수 기능을 유지할 법적 의무를 지며, 이는 업무 연속성으로 법제화되어 있습니다. 둘 다 테스트되지 않은 계획이 최악의 순간에 발견하게 될 부채인 정밀 검토 아래서 운영됩니다. 복구는 신뢰성(9.1장)과 인시던트 대응(9.3장)이 설계로 없앨 수 없는 실패를 살아남는다는 더 어려운 질문을 만나는 곳입니다.

핵심 원칙

연속성은 복구보다 넓습니다. 서버를 복원하는 것은 비즈니스를 계속 돌리는 것과 같지 않습니다.
두 숫자가 모든 것을 이끕니다. 비즈니스 영향에서 정해지는 복구 시간 목표(RTO)와 복구 시점 목표(RPO)가 모든 결정의 크기를 정합니다.
테스트되지 않은 백업은 백업이 아닙니다. 한 번도 수행해 본 적 없는 복원은 역량이 아니라 희망입니다.
백업이 표적이라고 가정하십시오. 랜섬웨어는 백업을 먼저 노리므로 사본을 불변이고 오프라인으로 유지하십시오.
기억이 아니라 코드로 다시 만드십시오. 소스에서 인프라를 다시 만들 수 없다면 믿을 만하게 복구할 수 없습니다.
의존하는 것을 지도화하십시오. 가장 느린 상류 의존성만큼만 빨리 복구합니다.
복구를 다른 시스템처럼 측정하십시오. 슬라이드에 쓴 숫자가 아니라 실제 훈련에서 나온 실제 RTO와 RPO입니다.

권장 사항

비즈니스 영향 분석에서 RTO와 RPO를 정한다

모든 복구 결정은 두 숫자에서 내려오므로 먼저 제대로 정하십시오. 복구 시간 목표(RTO)는 피해가 받아들일 수 없게 되기 전에 시스템이 내려가 있을 수 있는 시간입니다. 복구 시점 목표(RPO)는 복원할 수 있는 마지막 좋은 사본의 나이로 측정한, 잃어도 되는 데이터의 양입니다. 결제 원장은 몇 분의 RTO와 0에 가까운 RPO를 요구할 수 있고, 내부 분석 대시보드는 각각 하루를 견딜 수 있습니다. 이것을 엔지니어링에서 정할 수는 없습니다. 비즈니스 프로세스를 중단 비용으로 순위 매기고 각각을 필요한 시스템과 데이터까지 추적하는 비즈니스 영향 분석(BIA)에서 도출하십시오. 더 엄격한 목표는 더 많은 비용이 들므로, BIA가 사소한 서비스를 도금하고 핵심 서비스를 과소 보호하는 것을 막아 줍니다.

백업을 제대로 한다: 3-2-1 규칙, 불변성, 테스트

백업은 모든 복구 전략 아래의 바닥이며, 대부분의 조직이 생각보다 서투르게 합니다. 3-2-1 규칙으로 알려진 백업 규율을 따르십시오. 적어도 세 개의 데이터 사본을, 두 가지 다른 매체나 시스템에, 하나는 오프사이트에 보관합니다. 현대의 위협은 두 가지 요건을 더합니다. 랜섬웨어가 이제 자신을 알리기 전에 닿을 수 있는 백업을 의도적으로 암호화하거나 삭제하므로, 적어도 하나의 사본을 불변(쓰기 한 번, 보존 기간 동안 삭제 불가)으로, 이상적으로는 오프라인이나 에어 갭으로 유지하십시오. 무엇보다 복원을 일정에 따라 테스트하십시오. 테스트되지 않은 백업은 백업이 아니라 테스트되지 않은 가정입니다. 훈련에서 찾는 실패, 곧 손상된 아카이브, 빠진 암호화 키, 잘못된 볼륨의 백업이 실제 사건에서 여러분을 끝냈을 바로 그것들입니다.

비용 대 속도의 스펙트럼을 따라 DR 전략을 고른다

DR 전략은 돈을 복구 속도와 맞바꾸며, 모든 것에 하나의 등급을 사는 대신 시스템별로 RTO와 RPO에 근거해 골라야 합니다. 네 가지 패턴이 스펙트럼을 이룹니다. 백업과 복원은 가장 싸고 가장 느립니다. 재해가 닥치면 백업에서 다시 구축하며, RTO는 몇 시간에서 며칠입니다. 파일럿 라이트는 최소한의 핵심(복제 중인 데이터베이스, 제자리의 핵심 구성)을 축소된 채 데워 두고 확장할 준비를 합니다. 웜 스탠바이는 전체 스택의 더 작은 상시 사본을 돌려 장애 조치 시 확장하며, RTO를 몇 분으로 줄입니다. 다중 사이트 액티브-액티브는 둘 이상의 위치에서 라이브 트래픽을 서비스하며 전체 용량을 돌려, 가장 높은 비용과 복잡성으로 0에 가까운 RTO를 줍니다. 등급을 비즈니스가 서명한 숫자에 맞추고, 파일럿 라이트를 견디는 시스템에 액티브-액티브 가격을 치르지 마십시오.

일관성 트레이드오프를 염두에 두고 데이터를 복제한다

복구 속도는 스탠바이 데이터가 얼마나 최신인지에 달려 있으며, 여기서 분산 시스템(3.3장)의 어려운 문제를 물려받습니다. 동기 복제는 모든 쓰기를 확인하기 전에 두 번째 위치에서 확인해, 쓰기 지연과 거리의 엄격한 한계를 대가로 0에 가까운 RPO를 줍니다. 비동기 복제는 로컬에서 확인한 뒤 변경을 보내므로 빠르고 지리적으로 유연하지만, 장애 조치 시 잃게 될 복제 지연 구간을 남깁니다. 공짜 선택은 없습니다. 더 강한 일관성은 지연을, 더 약한 일관성은 데이터를 치릅니다. 데이터 저장소별로 RPO에서 결정하고 전형적인 복제 지연을 아십시오. 그 지연이 설계 문서의 숫자가 아니라 나쁜 날의 실제 RPO이기 때문입니다.

코드형 인프라로 코드에서 다시 구축한다

손으로 프로비저닝한 환경은 아무도 모든 클릭을 기억하지 못하므로 믿을 만하게 복구할 수 없습니다. 전체 스택을 알려진 좋은 상태의 버전 관리되는 소스에서 다시 만들 수 있도록 환경을 코드형 인프라(8.2장)로 정의하십시오. 이는 복구를 고고학 프로젝트에서 반복 가능한 파이프라인 실행으로 바꾸고, 스탠바이 리전을 정직하게 유지하며(둘이 같은 코드로 빌드되면 덜 드리프트함), 침해 후 새 계정이나 리전에 복구 인프라를 세우는 깨끗한 방법을 줍니다. 코드, 비밀 참조, 런북을 주 환경의 손실을 살아남는 곳에 저장하십시오.

필요하기 전에 의존성을 지도화한다

시스템은 고립되어 실패하지 않고 그물로 실패하며, 복구는 잊은 의존성에서 멈춥니다. 각 핵심 시스템이 기능하는 데 필요한 것을 지도화하십시오. 상류 서비스, DNS, 신원과 인증, 인증 기관, 메시지 큐, 제3자 API와 SaaS 제공자입니다. 애플리케이션을 그 데이터베이스나 신원 제공자보다 먼저 올리면 두 번째 장애만 만들므로 복구 순서를 기록하십시오. 외부 공급자에 특별히 주의하십시오. 여러분의 복구는 그들의 복구에 의해 한계가 정해지고 그것에 대한 가시성이 없을 수 있기 때문입니다. 이 지도화는 복원력과 우아한 성능 저하(3.5장)에 직접 묶입니다. 시스템에 하드 의존성이 적을수록 더 빨리 돌아옵니다.

복구 테스트를 사건이 아니라 실천으로 한다

연습한 적 없는 DR 계획은 허구입니다. 테스트의 사다리를 쌓으십시오. 테이블탑 연습은 팀이 종이 위에서 시나리오를 훑어 역할, 결정, 소통의 간극을 찾습니다. 게임 데이는 라이브와 비슷한 환경에 실제 통제된 실패를 주입합니다. 전체 장애 조치 훈련은 실제로 복구 사이트로 전환해 그 위에서 돕니다. 이를 주기에 따라 돌리고, 시나리오를 순환시키고(핵심 인물이나 공급자의 손실 포함), 결과를 측정하십시오. 달성한 실제 RTO와 RPO를 포착해 목표와 비교합니다. 측정된 복구와 약속된 복구 사이의 간극이 가진 가장 정직한 신뢰성 지표이며, 그것을 닫는 것이 훈련의 요점 전체입니다.

사이버 복구를 별도의 시나리오로 계획한다

랜섬웨어와 파괴적 사이버 공격은 일반 DR의 가정을 깨뜨리므로 따로 다루십시오. 자연 재해에서는 데이터가 다른 곳에 온전하지만, 랜섬웨어 사건에서는 데이터와 흔히 백업이 무기이고 복구 환경 자체가 침해되었을 수 있습니다. 클린룸 복구를 계획하십시오. 불변 사본에서 복원하고, 침입을 스캔하고, 무엇이든 다시 연결하기 전에 신원과 자격 증명을 다시 만드는 격리된 신뢰할 수 있는 환경입니다. 어느 백업이 마지막으로 알려진 깨끗한 시점인지 알고, 그것을 찾는 데 일반 RTO가 예산에 잡지 않은 포렌식 시간이 든다고 예상하십시오. 여기서 불변이고 오프라인인 사본이 비용만큼 값을 하며, 인시던트 관리(9.3장)와 침해 처리에 대한 컴플라이언스 및 거버넌스 의무(4.6장)에 긴밀히 연결됩니다.

장단점

DR 전략	장점	단점
백업과 복원	가장 싸고 단순. 낮은 지속 비용	느린 RTO (몇 시간에서 며칠). 더 큰 RPO
파일럿 라이트	낮은 비용. 핵심 데이터가 데워져 준비됨	수동 확장. 복구에 여전히 실제 시간이 듦
웜 스탠바이	빠른 RTO (몇 분). 전체 스택이 입증됨	실행 중인 두 번째 환경의 지속 비용
다중 사이트 액티브-액티브	0에 가까운 RTO. 단일 사이트 실패 없음	가장 높은 비용과 복잡성. 일관성이 어려움
동기 복제	0에 가까운 RPO	쓰기 지연. 거리 제한. 더 단단한 결합
비동기 복제	빠르고, 유연하고, 지리적으로 자유	복제 지연만큼의 데이터 손실 구간

중심 긴장은 복구 속도와 데이터 최신성이 모두 돈과 복잡성이 들며, 어느 등급에서도 공짜가 아니라는 것입니다. 조직별이 아니라 시스템별로 해결하십시오. 비즈니스 영향 분석이 각 핵심 시스템에 RTO와 RPO를 배정하게 하고, 그것을 충족하는 전략을 정확히 사십시오. 보고 도구에 액티브-액티브 돈을 쓰면 정말 그것이 필요했던 원장을 굶기고, 그 반대는 태만입니다. 규율은 지출을 비즈니스가 소유한 숫자에 맞추고, 시스템의 중요도가 바뀜에 따라 그 일치를 다시 살피는 것입니다.

팀과 논의할 질문

각 핵심 시스템의 RTO와 RPO는 무엇이며, 비즈니스의 누가 그것에 서명했습니까? 엔지니어링이 혼자 이 숫자를 지어냈다면 그것은 짐작이고, 짐작은 너무 후하게 자금을 받거나 전혀 받지 못합니다. 복구 시간과 복구 시점 목표는 비즈니스 프로세스를 중단 비용으로 순위 매기는 비즈니스 영향 분석에서 나와야 하며, 그래야 원장은 몇 분을, 내부 위키는 하루를 얻습니다. 현재 등급화를 가져와 각 비즈니스 프로세스에 책임지는 사람이 설계한 데이터 손실과 다운타임을 실제로 받아들일지 물으십시오. 큰 조직에서 이 대화가 모든 것을 똑같이 보호하는 비싼 실수를 막으며, 이는 아무것도 잘 보호하지 못합니다. 엔지니어링 밖의 누구도 숫자의 이름을 댈 수 없다면, 아직 목표가 없고 희망만 있는 것입니다.
마지막으로 실제 복원을 수행한 것은 언제이며, 달성한 실제 RTO와 RPO를 측정했습니까? 한 번도 복원해 본 적 없는 백업은 테스트되지 않은 가정이며, 여러분을 죽이는 실패 모드(손상된 아카이브, 잃어버린 암호화 키, 잘못된 볼륨의 스냅샷, 올라오지 않는 의존성)는 시도할 때에만 드러납니다. 마지막 테이블탑이 아니라 마지막 전체 장애 조치 훈련의 날짜와 결과, 달성한 복구와 약속한 복구 사이의 간극을 가져오십시오. 큰 팀에서 한 시스템의 한 번의 성공적인 복원은 다른 시스템들을 증명하지 못하므로, 지난 1년 동안 핵심 시스템의 몇 퍼센트가 끝에서 끝까지 복구되었는지 물으십시오. 측정된 간극이 가장 정직한 신뢰성 숫자이며, 그것을 진술할 수 없다면 계획은 입증될 때까지 허구입니다.
오늘 밤 랜섬웨어가 프로덕션을 암호화하고 백업에 닿았다면, 마지막으로 알려진 깨끗한 사본은 무엇이며 어디서 다시 구축하겠습니까? 일반 재해 복구는 데이터가 다른 곳에 안전하다고 가정하고, 파괴적 사이버 공격은 데이터와 백업을 무기로 만들어 정확히 그 가정을 깨뜨립니다. 적어도 하나의 백업 사본이 불변이고 오프라인인지, 마지막 깨끗한 복원 시점을 어떻게 식별할지, 프로덕션 자체가 침해되었을 때 신뢰할 수 있는 클린룸 환경이 어디서 올지 물으십시오. 이 시나리오는 일반 RTO가 예산에 잡지 않은 포렌식 시간을 필요로 하므로, 깨끗한 시점을 찾는 데 실제로 얼마나 걸리는지의 정직한 추정을 가져오십시오. 기업과 정부 팀에게 이것은 침해 통지 시계가 병렬로 돌아가는 컴플라이언스 사건(4.6장)이기도 합니다. 답이 “가장 최근 백업을 복원하겠다”라면, 이 시나리오를 전혀 계획하지 않은 것입니다.
어떤 시스템이 비즈니스 영향 분석이 정당화하지 않는 복구 등급에 값을 치르고 있으며, 어떤 것이 위험하게 과소 보호되어 있습니까? 복구 속도와 데이터 최신성은 모든 등급에서 돈이 들므로, 일괄 정책은 보고 도구에 액티브-액티브 예산을 낭비하거나 정말 그것이 필요했던 원장을 굶깁니다. 경쟁하는 끌림은 실제입니다. 하나의 표준 등급은 많은 팀이 운영하기 훨씬 단순한 반면, 시스템별 등급화는 지출을 가치에 맞추지만 시스템의 중요도가 이동함에 따라 지속적인 선별을 요구합니다. 각 핵심 시스템의 현재 DR 전략, 그것이 겨냥하는 RTO와 RPO, 스탠바이와 복제의 월 비용, 등급화가 새 영향 분석에 대해 마지막으로 다시 검토된 날짜를 가져오십시오. 기업이나 정부 환경에서 맞지 않는 등급은 리전에 걸쳐 곱해지고 감사는 쓰는 돈과 받아들이는 노출을 모두 정당화하라고 요구할 것이므로, 설명되지 않는 액티브-액티브 청구서와 보호되지 않는 핵심 서비스는 똑같이 방어하기 어렵습니다.
핵심 시스템의 복구 순서를 실제로 알며, 복구가 테스트할 수 없는 공급자에 얼마나 의존하는지 압니까? 시스템은 고립되어 실패하지 않고 그물로 실패하며, 복구는 아무도 지도화하지 않은 의존성에서 멈춥니다. 애플리케이션을 그 데이터베이스, 신원 제공자, DNS보다 먼저 올리면 그냥 두 번째 장애를 만듭니다. 의존성 지도화는 지루하고 지도는 낡지만, 대안은 장애 조치 중에 복구 순서를 라이브로 발견하는 것이며, 소수의 SaaS 제공자에 대한 집중 위험은 그들이 함께 실패해 복구를 그들의 것으로 한정할 때까지 보이지 않습니다. 현재 의존성 지도, 문서화된 복구 순서, 외부 공급자와 그들이 밝힌 복구 약속, 그중 어느 것이든 검증한 적이 있는지의 목록을 가져오십시오. 크거나 공공 조직에서 공급자 연속성과 집중 위험은 점점 조달과 규제의 관심사이므로, 그 복구 의무는 벤더의 마케팅이 아니라 감사할 수 있는 형태로 계약에 속합니다.
오늘 밤 모든 서버를 복원한다면 비즈니스가 실제로 계속 돌아가겠으며, 누가 재해를 선언할 권한이 있습니까? 재해 복구는 IT를 복원하지만, 비즈니스 연속성은 조직이 기능하도록 유지합니다. 사람, 소통, 급여, 결정을 내릴 권한이 누군가에게 있는지에 달린 결정입니다. 모든 시스템을 복구하고도 누가 재해를 선언할 수 있는지, 정상 채널도 내려갔을 때 직원에게 어떻게 닿는지 아무도 몰랐다면 고객을 실패시킬 수 있습니다. 엔지니어링이 복구를 소유하지만 연속성은 시설, 인사, 소통, 리더십 승계에 걸치며, 부서 사이의 그 이음새가 바로 계획이 조용히 썩는 곳입니다. 선언 권한과 에스컬레이션 체인, 대체 소통 계획, 지명된 후임자와 대체 시설, 비즈니스 쪽(IT만이 아니라)이 계획을 마지막으로 연습한 날짜를 가져오십시오. 정부는 지명된 후임자와 필수 기능이 있는 법적 업무 연속성 의무를 지고 기업은 규제상의 연속성 의무에 직면하므로, 둘 다 서버만이 아니라 비즈니스가 나쁜 날을 살아남는지로 판단됩니다.

분야별 관점

스타트업. 팀이 아주 작고 런웨이가 짧으면 뜨거운 두 번째 리전을 감당할 수 없으니, 그래도 여러분을 구하는 싼 부분에 대해 의도적이십시오. 하나의 정직한 복구 등급을 정하고, 자동화된 스냅샷과 자기 관리자가 삭제할 수 없는 적어도 하나의 불변 사본으로 3-2-1 규칙을 따르고, 소스에서 다시 구축할 수 있도록 전체 환경을 코드형 인프라로 유지하십시오. 정교한 계획은 건너뛰고 분기마다 스크래치 환경으로 실제 복원을 하나 돌리십시오. 시간을 잰 훈련 한 번이 아무도 읽지 않는 바인더보다 더 많이 가르쳐 주기 때문입니다.

소기업. 전담 연속성 전문가도 빠듯한 예산도 없으니 복구를 만드는 것이 아니라 사는 것으로 다루십시오. 맞춤 DR 인프라를 세우는 대신 클라우드 제공자의 관리형 백업, 스냅샷, 리전 간 복제에 기대고, 백업이 불변이고 복원 과정을 직접 실행할 수 있는 벤더를 고르십시오. 전체 작업을 전문가 없이도 답할 수 있는 두 질문을 중심으로 구성하십시오. 얼마의 데이터를 잃어도 되는가, 얼마나 오래 내려가 있어도 되는가. 그리고 신뢰하기 전에 복원 하나가 동작함을 증명하십시오.

대기업. 규모에서 문제는 많은 팀에 걸친 포트폴리오 거버넌스입니다. 모든 서비스에 RTO와 RPO를 배정하는 비즈니스 영향 분석, 백업과 복원에서 액티브-액티브까지 등급화된 복구 전략, 집중 위험을 포함한 상류와 공급자 의존성의 중앙 뷰입니다. 스탠바이, 복제, 불변 사본의 비용을 명시적으로 예산에 잡고, 주기에 따라 규제 기관이 참관하는 전체 장애 조치를 돌리고, 목표 대비 실제 복구를 추적되는 신뢰성 지표로 측정하십시오. 사이버 복구를 불변 보관소 사본과 클린룸 런북이 있는 별도의 프로그램으로 유지하고, 자연 재해 훈련과 독립적으로 테스트하십시오.

정부. 조달 규칙, 투명성, 공적 책임이 모든 선택을 형성하며, 연속성은 선호가 아니라 법적 의무인 경우가 많습니다. 필수 기능을 식별하고, 복구 순서를 정하고, 권한 있는 사람이 없어 결정이 멈추지 않도록 후임자와 대체 시설을 지명하는 업무 연속성 프로그램을 구축하고, FISMA 의무를 뒷받침하는 NIST SP 800-34 같은 인정된 지침에 맞추십시오. 에어 갭 백업 사본을 유지하고, 대체 리전에서의 재구축을 위해 인프라를 코드로 정의하고, 필수 서비스가 살아남는다는 증거로 감독 기관에 보고하는 측정된 결과와 함께 연 1회 전체 연습과 랜섬웨어 테이블탑 훈련을 돌리십시오.

사례

스타트업. 열두 명의 SaaS 회사는 뜨거운 두 번째 리전을 감당할 수 없으므로 싼 부분에 대해 의도적입니다. 고객 데이터베이스에 대해 하나의 정직한 등급을 정합니다. RTO는 네 시간, RPO는 15분입니다. 자동화된 스냅샷으로 3-2-1 규칙을 따르는데, 하나는 두 번째 클라우드 리전으로 복제되고 하나는 자기 관리자가 삭제할 수 없는 잠긴 보존 기간이 있는 불변 사본입니다. 전체 환경이 코드형 인프라(8.2장)이므로 소스에서 새 스택을 세울 수 있습니다. 분기마다 금요일 오후에 스크래치 환경으로 실제 복원을 하고, 시간을 재고, 짧은 메모를 남깁니다. 첫 훈련은 아홉 시간이 걸렸고 빠진 마이그레이션 단계를 찾아냈으며, 그 수정이 다음 훈련이 세 시간 걸린 이유입니다.

기업. 한 다국적 은행이 핵심 서비스에 테스트된 연속성을 의무화하는 규제 복구 요건 아래 운영됩니다. 핵심 뱅킹 플랫폼에 대해 두 번째 리전에서 웜 스탠바이를 운영하며, 0에 가까운 RPO를 위해 메트로 쌍 안에서는 동기 복제를, 지역 재해 생존을 위해 먼 리전으로는 비동기 복제를 씁니다. 비즈니스 영향 분석이 모든 서비스에 RTO와 RPO를 배정하고, 중앙 팀이 집중 위험으로 표시된 두 SaaS 제공자를 포함한 상류 의존성을 지도화합니다. 1년에 두 번 규제 기관이 참관하는 전체 장애 조치를 수행하고, 목표 대비 실제를 측정하고, 간극을 다음 주기에 공급합니다. 별도의 사이버 복구 프로그램이 불변 보관소 사본과 클린룸 런북을 유지하며, 자연 재해 훈련과 독립적으로 테스트됩니다.

정부. 급여를 전달하는 한 국가 기관이 어떤 중단 중에도 필수 기능을 유지하도록 만들어진 업무 연속성(COOP) 프로그램을 유지합니다. 업무 연속성 실천과 FISMA 의무를 뒷받침하는 NIST SP 800-34 비상 계획 지침을 따라, 필수 기능을 식별하고, 복구 순서를 정하고, 권한 있는 사람이 없어 결정이 멈추지 않도록 후임자와 대체 시설을 지명합니다. 시민 대면 시스템에는 문서화된 RTO와 RPO가 있고, 백업은 에어 갭 사본과 함께 3-2-1 규칙을 따르며, 인프라는 대체 리전에서의 재구축을 위해 코드로 정의됩니다. 연 1회의 전체 연습과 랜섬웨어 시나리오의 테이블탑 훈련이 측정된 복구에 대해 계획을 시험하고, 결과는 필수 서비스가 나쁜 날을 살아남는다는 증거로 감독 기관에 보고됩니다.

비즈니스 사례: 동기, ROI, TCO

DR과 연속성의 수익은 피한 재앙이며, 필요하기 전에는 가치를 매기기 정말 어렵고 필요할 때는 고통스럽게 구체적입니다. 위험 관리로 구성하십시오. 중단의 기대 비용은 그 가능성 곱하기 영향이며, 큰 조직의 영향은 다운타임 시간당 잃은 매출에서 규제 과징금, 침해 통지 비용, 장애보다 오래가는 평판 손상까지 이릅니다. 복구할 수 없는 랜섬웨어 사건 하나가 회사를 끝냈고, 공공 부문에서는 필수 시민 서비스를 몇 주 동안 내린 적이 있습니다. 그에 비해 테스트된 복구 역량의 비용은 소박하고 알 수 있습니다.

총소유비용(TCO)은 실제이며 지속됩니다. 스탠바이 인프라, 복제 대역폭, 백업 저장(불변 및 오프라인 사본으로 곱해짐), 자동화를 만들고 훈련을 돌리는 엔지니어링 시간입니다. 바로 그래서 어디서나 액티브-액티브를 사는 대신 RTO와 RPO로 등급화하여, 지출이 일괄 정책이 아니라 각 시스템의 가치를 따르게 합니다. 리더십을 설득하려면 계획을 그들의 언어로 옮기십시오. 오늘 우리가 살아남을 수 있는 다운타임과 데이터 손실은 이것이고, 목표와의 간극은 이것이며, 그것을 닫는 데 이만큼 들고, 그러지 않으면 노출은 이것입니다. 가장 설득력 있는 산출물은 측정된 훈련입니다. 입증된 복구는 리더십이 신뢰할 수 있는 숫자이고, 테스트되지 않은 계획은 자산으로 위장한 부채이기 때문입니다.

안티패턴과 함정

테스트되지 않은 백업. 한 번도 수행해 본 적 없는 복원은 희망입니다. 훈련이 손상, 빠진 키, 잘못된 볼륨을 찾는 곳입니다.
프로덕션에서 닿을 수 있는 백업. 랜섬웨어가 백업을 암호화하거나 삭제할 수 있다면 사본이 셋이 아니라 하나입니다. 하나는 불변이고 오프라인으로 두십시오.
모든 것에 하나의 RTO와 RPO. 일괄 등급은 사소한 것을 과보호하고 핵심을 과소 보호합니다. 비즈니스 영향 분석에서 등급화하십시오.
DR과 BCP의 혼동. 아무도 누가 재해를 선언하는지, 직원에게 어떻게 닿는지 모르는 채 모든 서버를 복원하는 것은 복구된 시스템과 실패한 비즈니스입니다.
손으로 만든 복구 환경. 코드에서 다시 만들 수 없는 인프라는 드리프트하며, 드리프트는 장애 조치 중에 발견됩니다.
무시된 의존성. 애플리케이션을 그 데이터베이스, 신원 제공자, DNS보다 먼저 복구하면 그냥 두 번째 장애를 만듭니다.
계획의 부패. 한 번 쓰고 연습한 적 없는 바인더는 더 이상 존재하지 않는 시스템을 기술합니다.
공급자 사각지대. 복구는 핵심 공급자의 복구에 의해 한계가 정해지고, 집중 위험은 그들이 함께 실패할 때까지 보이지 않습니다.

성숙도 모델

1단계, 시작: 복구가 즉흥적이고 반응적입니다. 백업이 돌 수 있지만 복원은 테스트되지 않습니다. 합의된 RTO나 RPO도, 비즈니스 영향 분석도 없고, 복구는 인시던트 중에 즉흥적으로 이루어집니다. 심각한 데이터 손실이나 랜섬웨어 사건은 복구할 수 없을 가능성이 큽니다.
2단계, 발전: 기본 실천이 있지만 팀마다 일관되지 않습니다. 일부 핵심 시스템에 3-2-1 규칙을 따르는 백업과 가장 중요한 서비스에 문서화된 RTO와 RPO가 있고, 기본 DR 계획이 있어 복원이 가끔 테스트됩니다. 커버리지는 부분적이고, 의존성은 지도화되지 않았으며, 훈련은 즉흥적이고, 한 팀의 규율이 다음 팀의 규율을 뜻하지 않습니다.
3단계, 표준화: 복구 실천이 문서화되어 조직 전체에 시행됩니다. 비즈니스 영향 분석이 시스템 전반에 등급화된 RTO와 RPO를 이끌고, 복구 전략이 그 등급에 맞춰지며, 환경이 코드형 인프라이고, 의존성과 복구 순서가 지도화되며, 예약된 훈련(테이블탑, 게임 데이, 장애 조치)이 정의된 주기로 돕니다. 불변이고 오프라인인 사본이 있는 사이버 복구 계획이 문서화되어 개별 팀에 맡겨지지 않고 일관되게 적용됩니다.
4단계, 관리: 복구가 기준선에 대해 측정되고 통제됩니다. 모든 훈련이 달성한 실제 RTO와 RPO를 포착해 목표와의 간극을 추적하고, 복원 성공률, 지난 1년 안에 끝에서 끝까지 복구된 핵심 시스템의 비율, 백업 커버리지와 불변성, 실제 RPO로서 모니터링되는 복제 지연 같은 지표가 대시보드에 보고됩니다. 이탈은 행동을 촉발하고, 등급화는 시스템이 실제로 쓰이는 방식에 대한 데이터로 다시 도출되며, 진행 또는 중단 결정은 슬라이드에 쓴 숫자가 아니라 증거에 근거합니다.
5단계, 오케스트레이션: 복구가 조직 전체에서 지속적으로 개선되고, 통합되고, 적응적입니다. 장애 조치와 사이버 복구 클린룸 복원이 일상으로 예행연습되고, 공급자와 집중 위험이 적극적으로 관리되며, 연속성이 신뢰성(9.1장) 및 인시던트 대응(9.3장)과 통합되어, 조직은 본 적 없는 실패로부터 예측 가능하게 복구하고 시스템 지형과 위협 상황이 이동함에 따라 복구 태세의 범위를 다시 정합니다.

논의를 위한 아이디어

핵심 시스템 중 끝에서 끝까지 복원된 적이 없는 것은 어느 것이며, 가능함을 증명하려면 무엇이 필요합니까?
주 클라우드 리전을 하루 종일 잃는다면 어떤 비즈니스 프로세스가 멈추며, 어떤 순서로 시스템을 복구하겠습니까?
복구의 얼마가 복구를 볼 수도 테스트할 수도 없는 공급자에 의존합니까?
비즈니스 영향 분석이 정당화하지 않는 복구 등급에 어디서 값을 치르고 있으며, 어디를 과소 보호하고 있습니까?
오늘 밤 백업이 닿을 수 있고 암호화되었다면, 진짜 마지막으로 알려진 깨끗한 복원 시점은 어디입니까?
약속한 RTO와 RPO와 마지막 훈련이 실제로 달성한 것 사이의 정직한 간극은 얼마입니까?

핵심 요점

연속성이 목표이고 복구는 수단입니다. 비즈니스 연속성 계획은 조직이 돌아가게 하고, 재해 복구는 그것이 의존하는 IT 시스템을 복원합니다.
RTO와 RPO가 모든 것을 이끌며, 둘 다 엔지니어링의 짐작이 아니라 비즈니스 영향 분석에서 나옵니다. 모두를 똑같이 보호하는 대신 시스템을 등급화하십시오.
테스트되지 않은 백업은 백업이 아닙니다. 3-2-1 규칙을 따르고, 랜섬웨어에 대비해 적어도 하나의 불변이고 오프라인인 사본을 유지하고, 복원을 일정에 따라 테스트하십시오.
DR 전략을 숫자에 맞추십시오. 백업과 복원, 파일럿 라이트, 웜 스탠바이, 액티브-액티브 중에서 각 시스템의 RTO와 RPO로 고릅니다.
복제는 일관성을 최신성과 맞바꿉니다(3.3장). 실제 RPO는 설계 문서가 아니라 복제 지연입니다.
코드에서 다시 구축하고(코드형 인프라, 8.2장), 필요하기 전에 의존성을 지도화하십시오.
테이블탑 연습, 게임 데이, 전체 장애 조치 훈련으로 테스트하고, 목표 대비 실제 RTO와 RPO를 측정하십시오.
사이버 복구를 클린룸 복원으로 따로 계획하고, 전체 실천을 신뢰성(9.1장), 인시던트 대응(9.3장), 컴플라이언스(4.6장)에 연결하십시오.

참고 문헌과 더 읽을거리

ISO 22301, Security and resilience: Business continuity management systems: Requirements (the international standard for BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, and recovery strategies for government systems).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (incident and cyber-recovery handling).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular and federal COOP guidance (essential functions and continuity of operations).
Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management booklet (regulatory recovery expectations for financial institutions).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (reliability and disaster testing).
Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (deliberately exercising failure and recovery).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (ransomware prevention and recovery practice).