나는 오래되고 다소 일방적 인 재난 복구 계획을 업데이트하는 것과 관련된 프로젝트를 이끌었습니다. 지금은 DR의 IT 측면을 정리하는 중입니다. 마지막으로이 작업을 수행 할 때 단일 재난 (데이터 센터가 플러딩 됨)을 구성하고 다른 모든 재난 유형을 배제하도록 계획하여 범위를 설정했습니다. 좀 더 잘 다듬어보고 싶습니다. 나는 이것이 해결 된 문제라는 것을 알고 다른 조직은 DR 계획을 작성했습니다.
우리의 계획은 IT DR 계획을 세우고 계속 진행하여 "이것은 우리가 IT를위한 DR 계획에서 원하는 것입니다. 다른 대학의 활동과 맞물려 있습니까? 복원 된 서비스 우선 순위가 있습니까? '변경 하시겠습니까? " 우리는 계획의 나머지 부분이 무엇인지 잘 알고 있으며 이것이 잘 될 것으로 기대하고 있습니다.
내가 찾고있는 것은 DR 계획의 범위를 정하는 방법과 내가 고려해야 할 질문에 대한 지침입니다. DR 계획 개발과 관련된 즐겨 찾는 리소스, 서적, 교육이 있습니까?
답변:
훌륭한 정보원은 Disaster Recovery Journal ( 약 )입니다.
사용 가능한 커뮤니티 리소스에는 일반적인 비즈니스 연속성 계획 및 프로세스를 구성하는 프로세스 및 결과물에 대한 훌륭한 개요를 제공하는 GAP (Generally Accepted Practices) 문서 의 현재 초안이 포함 됩니다. 또한 사용할 수있는 몇 가지 있습니다 백서 다양한 DR / BC의 주제를 다루는.
프로세스가 어려워 보이지만 DRJ GAP 문서와 같이 종료하려는 위치에 대한 개요가 체계적으로 접근하면 투자 시간을 최적화하고 최종 제품의 가치를 극대화 할 수 있습니다.
나는 그들의 분기 별 간행물이 흥미롭고 유익한 정보가된다고 생각한다 ( 구독 ).
비상 연락 명단이 있는지 확인하십시오. 일명 리콜 명단
나무처럼 보이고 누가 누구에게 연락하는지 보여줍니다. 지점 끝에서 마지막 사람은 첫 번째 사람에게 연락하여 연락 할 수없는 사람을보고해야합니다.
(이는 HR을 통해 조정할 수 있으며 모든 유형의 재해에 사용될 수 있습니다)
아이디어를 추가하면 모든 사람이 자신의 아이디어를 추가 한 후에이 게시물에서 멋진 위키를 만들 수 있습니다. 나는 거기에 따라야 할 무리가 있음을 이해하지만, 우리 중 일부는 회복과 관련하여 특정 우선 순위가 있습니다. 시작하려면 여기 내 것이 있습니다 :
DR의 기본 사항은 RTO (Recovery Time Objectives) 및 RPO (Recovery Point Objectives)입니다. 이는 "복구하는 데 시간이 얼마나 걸리고, 데이터를 얼마나 잃을 수 있는지"로 대략적으로 해석됩니다. 이상적인 세상에서 답은 "아무것도 없습니다"이지만 DR 시나리오는 예외적 인 상황입니다. 이는 실제로 고객이 주도해야하지만 IT 각도에서 시작한 이후 최상의 추측을 할 수 있지만 필요에 따라 위 또는 아래로 조정할 수 있습니다. 합리적으로 얻을 수있는만큼 "없음과 없음"에 가까운 것을 목표로하는 것이 좋지만 수익이 감소하는 시점을 파악할 수 있어야합니다.
이 두 가지 요소는 연중 다른 시간과 시스템마다 다를 수 있습니다.
나는 다재다능한 접근법을 좋아한다. DR 시나리오로 이어질 수있는 이벤트를 나열하려고하지만 실제로는 위험 분석 / 완화 실습에 더 속합니다. DR을 통해 사건이 이미 발생했으며 관련성이 덜한 사항 (DR 시설의 가용성에 영향을 미치는 경우 제외)이 구체적으로 설명되었습니다. 서버를 잃어버린 경우 번개, 우발적 인 형식 등으로 인해 서버에 충돌이 발생했는지 여부에 관계없이 서버를 다시 가져와야합니다. 재난의 규모와 확산에 중점을 둔 접근 방식이 결과를 산출 할 가능성이 높습니다.
고객이 참여하기를 꺼려하는 경우 고객에게 사용하는 한 가지 방법은 비 IT 각도에서 DR 질문을하는 것입니다. 모든 종이 파일이 화염에 휩싸 일지에 대한 계획을 묻는 것이 여기의 예입니다. 이를 통해 더 넓은 DR에 더 많이 참여하고 유용한 정보를 자신의 계획에 제공 할 수 있습니다.
마지막으로 계획을 정기적으로 테스트하는 것이 성공에 중요합니다. 종이에는 멋지게 보이지만 목표에 부합하지 않는 아름다운 DR 계획을 갖는 것은 좋지 않습니다.
실제로 "단일 사고"개발 모델은 첫 번째 단계로서 좋은 생각입니다. 한 가지 이유는 계획 연습을보다 현실적이고 집중적으로 만드는 것입니다. 홍수를 계획하십시오. 그런 다음 다른 사고 (예 : 장기 정전)를 가정하고 해당 계획을 적용하고 중단되는 부분을 수정하십시오. 몇 번의 반복 후에는 계획이 비교적 견고해야합니다.
몇 가지 생각 ...-사용할 수없는 사람들을 고려해야합니다. 홍수가 발생하면 모든 관련 직원을 이용할 수 있다고 가정 할 수 없습니다. 누군가 휴가 중이거나 부상을 입거나 가족을 대할 수 있습니다.
-의사 소통 문제와 약점에 대한 계획. 여러 숫자와 여러 모드가 있습니다.
-DR 계획에는 일련의 명령이 필요합니다. 누가 결정을 내리는 지 아는 것이 중요합니다.
-계획은 오프 사이트 및 그리드 외부를 포함하여 광범위하게 분산되어야합니다. 재난 중에 액세스 할 수 있어야합니다!
일하는 곳에서 지난 2 년 동안 대규모 DR 테스트를 수행하는 데 참여했습니다. "현실적인"상황에서 서비스, 사람 및 프로세스를 테스트하는 것이 유용하다는 것을 알게되었습니다. 유용한 교훈을 얻기 위해 몇 가지 교훈을 얻었을 것입니다.
내가 얻는 것은 DR 계획 프로세스에 대한 모든 것을 이론적으로 만들지 말아야한다는 것입니다. 실제로 문제를 해결하여 조직의 준비에 대한 하드 데이터를 얻을 수있는 권한을 얻으십시오. 물론 경영진의 진지한 지원이 필요하지만 기업이 며칠 동안 실제로 최악의 상황을 연습하는 데 초점을 맞출 수 있습니다.
시안
영국 표준 협회 (BSi)는 연속성 관리 및 재해 복구에 중점을 둔 몇 가지 표준이 있습니다 .
명백한 것처럼 보이지만 위의 오프 사이트 문서와 함께 진행하려면 오프 사이트 (바람직하게는 리전 외부) 백업이 있는지 확인하십시오. 이것은 온라인 스토리지 서비스이거나 테이프를 가져갈 장소 일 수 있습니다.
매년 많은 자연 재해가 발생하지 않는 지역에서 왔기 때문에 지역 밖으로 나가는 것이 바람직하지만, 대규모 재난 (지진, 화산)이있는 지역 규모에 해당합니다. 은행이 액체 핫 마그마 (/ Dr. Evil Voice) 상태가 될 때까지 은행의 안전 금고에 백업 해 두는 것이 좋습니다.
내가 읽은 것은 큰 사이트가 방문했을 때 핫 사이트를 유지 관리하는 비용을 공유하는 대행사입니다. 이들은 가상화 등을 사용하여 핫 사이트에 중요한 두 회사의 사명을 복원하려는 계획을 제정 한 다음 깜박이는 수준에서 직원을 공유합니다. 그냥 생각이야
로라,
다음은 DR의 기본을 제공하는 SQLServerPedia의 링크입니다.
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/