Akashic Records

DRP 재해 복구 계획(Disaster Recovery Planning) 본문

Infrastructure

DRP 재해 복구 계획(Disaster Recovery Planning)

Andrew's Akashic Records 2018. 4. 18. 14:23
728x90

재해 복구 계획(Disaster Recovery Planning)

재해 복구 계획(Disaster Recovery Planning) 정보 시스템 자원의 중대한 손실을 유발할수 있는 파괴적 사건이 발생하기 전과 진행 중일 그리고 사후에 취해져야 일관적인 작업을 포괄적으로 설명하는 것이다. 재해 복구 계획은 중단 상황에서 확장된 백업 운영을 제공하고 사후 복구와 구조 작업을 관리하며, 조직이 실제적인 프로세싱 기능의 손실을 겪는 비상상황에 대처하는 프로시저이다.


재해 복구 계획의 주요한 목적은 대체 사이트에 핵심 기능을 구현하고 신속한 복구 프로시저를 수행하여, 조직의 손실을 최소화시키는 시간 프레임 내에 사이트와 정상 프로세싱 상태로 되돌아가기 위한 능력을 제공하는 것이다.

DRP 목표와 목적

DRP 목표 : 파괴적 사건이 발생하는 경우 결정해야 조직화된 방법을 제공하는 것이다.재해 복구 계획의 취지는 혼란을 줄이고 위기상황에 대처하기 위한 조직의 능력을 확장시키는것이다.


파괴적 사건 발생시 조직이 즉시 복구 계획을 수립하고 수행시키는 놀라운 능력을 발휘하지못할 것임은 확실하다. 그러므로 충분한 계획과 테스트를 미리 해보는 것이 재해에 지탱하는조직의 능력을 결정해줄 것이다. DRP 목적은 여러 가지가 있으며 하나하나가 모두 중요하다. 여기에는 다음 사항들이 포함된다.

  • 주요한 컴퓨터 서비스 장애로부터 조직을 보호하는

  • 서비스 제공 지연으로 인해 조직에 부과되는 위험 최소화

  • 테스트와 시뮬레이션을 통해 스탠바이 시스템의 안전성 보장

  • 재해중에 직원이 담당해야 의사결정 기회 최소화

이어서 DRP 다음과 같은 영역을 살펴보자

1.     재해 복구 계획 프로세스

2.     재해 복구 계획 테스트

3.     재해 복구 프로시저

재해 복구 계획 프로세스

재해 복구 계획 프로세스에서 다루는 단계는 다음과 같다.

1.  데이터 처리 지속 계획(Data Processing Continuity Planning) : 재해를 예측하고그에 대처하기 위한 계획 수립

2.  데이터 복구 계획 유지보수(Data Recovery Plan Maintenance) : 계획이 항상 적절하게 최신 버전을 반영하도록 유지

데이터 처리 지속 계획

백업 서비스를 처리하는 다양한 방법들은 재해 복구 계획에서 가장 중요한 요소이다. 여기서가장 많이 사용되는 대체 처리 사이트를 살펴보겠다.

상호 지원 계약

상호 지원 계약은 유사한 컴퓨팅 요구를 가지는 다른 회사와 계약하는 것이다. 다른 회사는비슷한 하드웨어나 소프트웨어의 구성을 가지고 있거나 해당 조직과 동일한 네트워크 데이터통신이나 인터넷 접근을 요구할 것이다. 이러한 유형의 계약은 파괴적 사건 발생시 양쪽이 서로 지원해 주는 것에 동의한다. 협정은 조직의 운영 영역이 필요 상대방을 지원해줄수 있을 만큼 충분한 여력을 가지고 있다는 전제하에 결성된다.

  • 장점 : 매우 적은 비용

  • 단점 : 조직의 인프라 구조가 사고 발생시 타사의 전체 운영 프로세스를 지원해줄정도로 충분한 여유 공간을 가지고 있지 못할 가능성이 크다.

가입 서비스

대체 처리 시나리오의 다른 유형은 가입 서비스로 표현된다. 시나리오에서 3 사용서비스는 대체 수단으로서의 백업과 처리 설비를 제공한다. 가입 서비스는 아마도 가장 많이사용되는 대체 처리 사이트 구현 방법일 것이다. 가입 서비스에는 다음과 같은 가지 기본적인 형식과 약간의 변형들이 있다.

  • 사이트(Hot site)

  • 사이트(Warm site)

  • 콜드 사이트(Cold site)

사이트

전원이나 난방, 통풍, 공기 청정기와 기능성 파일/프린터 서버와 워크스테이션까지 모든 컴퓨터 설비를 완전히 갖추고 있다. 원격 트랜잭션 프로세싱을 유지하기 위해 필요한 애플리케이션이 서버와 워크스테이션에 설치되고 운영 환경과 동일한 상태로 관리된다. 이론적으로 직원이나 운영자가 걸어가서 최근 백업으로부터 수정된 파일의 데이터를 리스토어하고, 매우 짧은 시간 안에 전체 운영을 시작하게 해야 한다. 만약 사이트가 원격 저널링을사용한다면, 초고속 데이터 라인을 통해 사이트로 트랜잭션 프로세싱 내역을 미러링하고 있다면, 백업 시간도 감소하거나 제거될 것이다.


  • 장점 : 24시간, 7 내내 서비스 가용성과 독점적 사용이 보장된다는 것이다. 파괴적 사고 발생 즉시(혹은 허용 가능한 시간 이내에) 사이트가 정상가동 된다는것이다. 사이트는 단기간의 중단뿐만 아니라 장기간에 걸친 서비스 중단 상황도지원할 있다.

  • 단점

    • 가장 고가의 대체 사이트 방안, 모든 고객이 동시에 설비를 요구하지는 않을 것이므로 서비스 제공자는 처리 능력보다 훨씬 많은 고객을 유치하는 것이일반적이다.

    • 애플리케이션이 실제 운영 데이터의 미러된 사본을 보유하게 되므로 사이트에도 보안 이슈가 존재하게 된다.

    • 사이트는 관리적으로 자원집약적이므로 데이터를 항상 최신 버전으로 맞추고 소프트웨어를 패치하는 통제가 구현되어야 한다.

사이트

사이트와 콜드 사이트의 절충안으로 가장 설명된다. 사이트처럼, 사이트도 전원이나 HVAC 컴퓨터 등이 갖추어진 컴퓨터 설비이지만 애플리케이션은 설치되거나 구성되어 있지 않다. 파일/프린터 서버는 있을 수도 있지만 전체 워크스테이션은 설치되거나 구성되어 있지 않다. 파일/프린터 서버는 있을 수도 있지만 전체 워크스테이션을 보충할 정도는 아니다. 그러나 보통 주문과 설치에 오랜 시간이 소요되는 외부 통신선과 기타 데이터요소는 준비될 것이다. 이러한 유형의 사이트에서 원격 프로세싱을 활성화시키기 위해, 워크스테이션이 신속하게 배달되어야 것이고, 애플리케이션과 데이터가 백업 미디어로부터 리스토어될 필요가 있다. 이러한 유형의 사이트의 장점은 사이트와는 반대로 다음과같다.

  • 비용 : 구성은 사이트보다 훨씬 경제적이다.

  • 위치 : 이러한 유형의 사이트가 그다지 광범위하지 않은 통제와 구성을 요구하기 대문에 사이트 선정시 유연성이 있다.

  • 자원 : 사이트의 유지보수보다 관리 자원 낭비가 적다.

사이트의 주요 단점은 사이트와 비교할 , 신규 사이트에서 운영 처리를 개시하는 소요되는 시간과 노력이 양이 다르다. 만약 극단적으로 긴급한 트랜잭션 처리가 요구되는 경우가 아니라면 방법도 대안으로 수용 가능하다.

콜드 사이트

콜드 사이트는 가지 가장 미비한 사이트이지만 중에 가장 많이 사용되는 방안이기도 하다. 콜드 사이트는 비상시 장비를 가져올 준비만 어떤 컴퓨터 하드웨어도 사이트에 존재하지 않는다 점에서 다른 가지와 다르다. 콜드 사이트는 전원과 HVAC 설치되어 있고 컴퓨터는 필요시 운반해야 하며 통신 링크는 준비될 수도 수도 있다. 파일과 프린터 서버도 가져와야 하고 모든 워크스테이션도 마찬가지이며 애플리케이션을 설치하고 현재 데이터를 백업으로부터 리스토어해야 한다.

콜드 사이트는 파괴적인 사고를 무마시키고 모든 상황이 가동되게 하기까지 상당한 시간이소요되기 때문에 재해 복구에 적합한 자원으로는 고려되지 않는다. 실제로 콜드 사이트를이용하면 효율적인 복구는 불가능할 것이다. 콜드 사이트에서는 심도 있는 재해 복구 테스트를 수행한다거나 병행 트랜잭션 처리가 거의 불가능하고, 재해 복구 노력의 성공을 예견하기는 어렵다.

  • 장점 : 비용과 장소선정

  • 단점 : 보안에 대한 잘못된 인식, 복구 불능


다중 센터

처리가 여러 운영 센터로 나누어지고, 가용한 자원의 공유와 중복성에 대한 분산 접근이 도입된다. 이러한 다중 센터는 동일한 조직에 의해 소유, 관리되거나 또는 일종의 상호 협정과함께 이용될 수도 있다.

  • 장점 : 비용이 내포되기 때문에 주로 경제적인 측면이다. 또한 이러한 유형의 사이트는 다중 사이트간에 자원의 지원 공유를 허용할 것이다.

  • 단점 : 상호 협정과 같다. 대규모 재해가 사이트의 처리 용량을 초과할 있다. 또한다중 형상을 관리하기도 어렵다.

서비스 업체

드물기는 하지만 모든 대체 백업 처리 서비스를 전적으로 제공하는 서비스 업체와 계약하는조직도 있다.

  • 장점 : 서비스 업체의 신속한 대응과 가용성이며 테스트가 가능하고 서비스 업체가 백업 이상의 것을 제공한다.

  • 단점 : 비용문제와 대규모 비상상황 발생시 자원의 경합


기타 데이터 센터 백업 대안

이동 백업 사이트(Rolling/mobile backup sites)

이동 백업 사이트를 제공하는 벤더와 계약. 이것은 필요한 대체 처리를 수행하기에 충분한전원과 HVAC 갖춘 이동식 건물이나 평반형 트럭 형태이다. 이것은 콜드 사이트의 변형으로 간주된다.


  • 하드웨어 교환을 위한 내부 혹은 외부 지원(In-house or External supply of hardware replacements)  : 벤더가 필요한 하드웨어를 다시 지원해주거나 핵심컴포넌트 인벤토리의 내부 비축. 조직은 하룻밤 사이에 식별된 핵심 컴포넌트를 보내주도록 벤더와 가입 서비스 계약을 하게 된다. 사이트에는 사용될 있지만핫 사이트에서는 수용하기 곤란하다.

  • 조립식 간이 빌딩(Prefabricated buildings) : 재해가 발생하면 대체 처리 기능을수용할 조립식 간이 빌딩을 구축하기 위해 회사가 서비스 조직을 채용하는 것은 이상한 일이 아니다. 이동 백업 사이트와 그다지 다르지 않은 콜드 사이트라 수있다.


트랜잭션 중복 구현

장애방지(Fault tolerance) 수준과 트랜잭션 프로세싱의 중복성을 유지하기 위해 사용되는세 가지 개념을 알아야 한다. 이러한 프로세스는 재해 복구만을 위해 단독으로 사용되지는 않으며 재해 복구 계획의 요소가 되기도 한다. 만약 이러한 프로세스 하나 이상이 채용되면 온라인으로 되돌아가기 위한 회사의 능력은 매우 향상될 것이다.

  • l전자 볼팅(Electronic Vaulting) : 전자 볼팅은 오프 사이트 위치로 백업 데이터를 전송하는 것을 가리킨다. 이것은 주로 대체 사이트에 있는 서버로 통신 라인을 통하여데이터를 덤프하는 배치 프로세스이다.

  • 원격 저널링(Remote journaling) : 원격 저널링은 대체 사이트로 보내는 트랜잭션의병렬 프로세싱을 가리키는데, 전자 볼팅 같은 배치 덤프 프로세스와는 상반된다. 통신선은 데이터가 발생하는대로 그것을 전송하는 사용된다. 이것은 대체 사이트가 항상 완전히 운영 가능하며 고차원적인 장애방지 상황을 도입하게 해준다.

  • 데이터베이스 쉐도우잉(Database shadowing) : 데이터베이스 쉐도우잉은 원격 저널링의 실제 프로세싱을 사용하는 것인데, 데이터베이스 집합을 다중 서버에 이중화시키는 방식으로 완전한 중복성을 구현한다.


재해 복구 계획 유지보수

재해 복구 계획은 가끔 현재 버전에서 뒤쳐지게 된다. 모든 복구 계획에 있어서 공통적인 유사성이 많은 다양한 이유로 인해 계획이 빠른 속도로 퇴화한다는 것이다. 회사는 조직도개편할 것이고 핵심 사업 단위도 계획이 처음 수립되던 시점과 달라질 있다. 네트워크나컴퓨팅 인프라 구조에서의 변화는 가장 빈번하게 하드웨어나 소프트웨어, 다른 컴포넌트의 위치나 구성을 변경시킬 것이다. 이유는 관리적일 수도 있다. 복잡한 재해 복구 계획은 쉽게갱신되지 않을 것이고, 직원이 프로세스에 흥미를 잃을 수도 있으며, 직원이 조직 개편으로 인해 참여에 영향을 수도 있다. 계획의 유지보수 기술은 계획이 항상 현재 상황을 반영하고 유용하도록 유지된다는 것을 보장하기 위해 초기부터 채용되어야 한다. 업데이트 책임에집중하는 업무 지정으로 조직에 유지보수 프로시저를 구축하는 것은 중요하다. 또한 계획의상태를 주기적으로 보고할 있는 감사 프로시저를 만드는 것이 좋다. 비상시 혼란을 유발할 있기 때문에 계획의 다중 버전이 존재하지 않도록 보장하는 것도 역시 중요하다. 계획이 변경되거나 대체될 항상 전사적으로 기존 버전을 업데이트된 버전으로 교체하라.


재해 복구 계획 테스트

재해 복구 계획을 테스트하는 것은 매우 중요하다(테이프 백업 시스템은 전체 복구 테스트가완료될 때까지는 정상 작동한다고 간주할 없다). 재해 복구 계획은 실제적으로 테스트해보고 검증 받을 때까지는 단지 이론적인 많은 요소를 내포하고 있을 뿐이다. 테스트 계획이 생성되고 테스팅이 순서대로, 표준화된 방법으로, 주기적으로 실행되어야 한다.

테스트가 필요한 이유

  • 테스트는 복구 프로시저의 정확성을 검증하고 결함 부분을 식별한다.

  • 테스트는 직원들이 비상시 자신의 의무사항을 수행하도록 준비하고 훈련시킨다.

  • 테스트는 대체 백업 사이트의 처리 역량을 검증한다.

테스트 문서 작성

테스트부터 최대 이익과 기능 조율을 얻기 위해서는, 테스트 필요성, 테스트의 목적, 집행되는 테스트의 유형을 포함해서 테스트 시나리오 문서의 윤곽을 잡아야 한다. 또한 문서는다음 내용을 포함하여 테스트 발생할 세부적 상세사항까지 내포해야 한다.

  • 테스트 스케줄과 타이밍

  • 테스트 소요 시간

  • 명확한 테스트 단계

  • 테스트에 참여할 참석자

  • 테스트 참가자에게 작업 할당 내역

  • 필요한 자원과 서비스(보급품, 하드웨어, 소프트웨어, 문서 )


가장 기본적인 조건으로, 테스트는 정상 사업 기능을 방해해서는 안된다. 또한 테스트는 간단한 테스트 유형으로부터 시작해서 복구팀이 테스팅 기술을 획득한 후에 점차 중요한 시뮬레이션으로 확장시켜 나갈 있게 해야 한다. 테스트하는 이유가 계획에서 취약한 측면을 발견해내는 것이라는 점을 기억하는 것이 중요하다. 만약 문제점이 발견되지 않으면 아마도 정확한테스트가 실시되지 않은 것이다. 테스트는 복구 계획이나 직원이 계획을 얼마나 수행하는지 등급을 매기는 대화가 아니다. 오류가 발생할 수도 있지만, 테스트 시간이야말로 실수를해봐야 하는 단계이다. 테스트 와중에 부딪힌 문제점을 문서화하고 필요하다면 계획을 업데이트한 다시 테스트한다.

다섯 가지 재해 복구 테스트 유형

체크리스트

재해 복구 계획의 체크리스트 테스트를 수행하는 동안 계획의 사본이 사업 단위 관리자에게 배포된다. 그리고 나서 계획이 조직의 모든 프로시저와 핵심 영역을 언급하는지 확인하기 위해 검토한다. 실제로 이것은 테스트의 사전 단계로 고려되며 자체로 만족할만한 테스트는 아니다.

구조적 점검 테스트

유형의 테스트에서는 사업 단위 관리자의 대표가 계획을 철저히 점검하기 위해 모인다.목적은 계획이 정확하게 조직의 복구 능력을 성공적으로(최소한 서류상으로라도) 반영하는지 확인하는 것이다. 계획의 단계가 회의에서 철저히 점검되며 수행 표시된다. 계획에서 눈에 띄는 중요한 오류는 점검하는 동안 명백하게 밝혀져야 한다.

시뮬레이션 테스트

모든 운영자

병렬 테스트

모든 직원을 활용하여 복구 계획에 대해 완전하게 테스트하는 것이다. 테스트와 다음에설명할 전체 서비스 중단 테스트와의 차이점은 사업의 기본적인 운영 프로세싱을 멈추지 않는다 것이다. 테스트 프로세싱은 실제 프로세싱과 병렬적으로 운영된다. 이러한 유형의테스트 목적은 핵심적 시스템이 대체 처리 백업 사이트에서 정말 수행되는지 보장하는 것이다. 시스템은 대체 사이트에 재배치되고 병렬 프로세싱이 초기화되고 트랜잭션의 결과와 다른 요소들이 비교된다. 이것은 가장 많이 사용되는 재해 복구 계획 테스트 방법이다.

전체 시스템 중단 테스트

정상적인 운영을 중단시킬 정도의 재해가 가상된다. 마치 실제 재해상황처럼 비상 서비스가호출되고 계획이 전체적으로 실행된다(중대한 테스트이니만큼 지역 당국은 미리 보고받고조정을 도와야 한다). 이것은 자체로 재해를 유발시킬 수도 있기 때문에 극히 드문 형태의 테스트이다. 어쨌든, 이것은 동작하거나 하거나 하나이기 때문에 재해 복구 계획을 테스트하기에는 절대적으로 최선의 방법이다.

재해 복구 프로시저

계획에서 부분은 다양한 직원이 담당하는 역할이 무엇인지, 사이트를 복구하고 구조하기위해 구현해야 하는 작업이 무엇인지, 회사가 많은 외부 그룹과 어떻게 인터페이스 해야 하는지. 그리고 경제적 고려사항에 관해 상세하게 보여준다.

재해 복구 프로세스의 기본적인 요소는 다음과 같이 구분할 있다.

  • 복구팀(Recovery team)

  • 구조팀(Salvage team)

  • 정상 운영 재개(Normal operations resume)

  • 기타 복구 이슈

복구팀

복구팀은 재해 선언시 복구 프로시저를 구현하기 위해서 명령으로 확실하게 정의된다. 복구팀의 주요한 작업은 대체 백업 사이트에서 미리 정의된 핵심적 사업 기능 운영을 담당하는 것이다.


복구팀이 해야 많은 작업 하나는 오프사이트 스토리지, 백업 테이프나 미디어, 워크스테이션 등으로부터 필요한 자료를 검색해오는 것이다. 자료를 찾으면, 복구팀이 필요한장비와 통신을 설치할 것이다. 팀은 또한 작업을 재개할 핵심 사업 단위에 필요한 핵심 시스템과 애플리케이션, 데이터를 설치하게 된다.

구조팀

구조팀은 복구팀과는 달리 사이트를 정상 처리 환경 조건으로 되돌리기 위해 급파된다. 이팀은 복구팀과는 다른 지시를 받기 때문에 분리된 팀을 구성하는 것이 바람직하다. 이들은 운영 처리를 생성하거나 데이터의 중요성을 결정하는 것처럼 복구팀이 관여하는 것과 동일한 이슈에 참여하지는 않는다. 구조팀은 직접적인 재해상황이 끝난 , 신속하고 중요하게, 안전하게 정리하고 수리하고 구조하고 프라이머리 프로세싱 인프라 구조의 실행 가능성을 결정해야 임무를 가진다.

정상운영 회복

이것은 일반적으로 복구팀에 할당되는 작업이거나 다른 구분된 회복팀이 결성된다. 여기서의 계획은 어떻게 회사가 최소한의 파괴와 위험만을 감수하며 대체 사이트에서 사이트로운영 프로세싱을 반환시킬 것인가에 대해 완전한 프로시저를 가진다. 정상 운영 처리 상태로회복하는 단계는 복구 단계와는 다르다. , 가장 중요하지 않은 업무를 먼저 사이트로 되돌려야 한다. 모든 운영이 사이트의 전체 운영 모드로 되돌아갈 때까지 비상사태가 끝나지않는다는 사실은 중요하다.


여기서 논의된 가지 구현 요소는 모두 매우 조율된 병참학적 계획과 자원을 포함한다.복구팀, 구조팀, 그리고 아마도 존재할 회복팀을 관리하고 급파시키는 것은 중요한 노력의 결과이며, 여기서 짧게 설명했다고 해서 별로 중요한 업무가 아니라는 인상을 가져서는 된다.

재해상황은 언제 종료되는가?

재해상황이 언제 끝나는가? 답은 매우 중요하다. 재해상황은 모든 운영이 그들의 정상위치와 기능으로 되돌아갈 때까지는 끝나지 않는다. 트랜잭션 프로세싱이 대체 백업 사이트로부터 오리저널 운영 사이트로 되돌아갈 매우 거대한 취약성의 구성이 존재하게 된다. 기업의 모든 영역이 오리지널 홈으로 돌아가 정상작동 , 그리고 모든 데이터가 정확하다고 증명되고 나서야 비로소 재해상황은 공식적으로 종료된다.


기타 복구 이슈

여러 가지 기타 이슈들도 재해 시나리오의 중요한 요소로서 논의되어야 한다.

  • 외부 그룹과의 인터페이스

  • 직원과의 관계

  • 사기와 범죄

  • 재정적 부담

  • 미디어와의 관계

외부 그룹과의 인터페이스

조직은 자체 직원들과의 관계에 있어서는 재해에 대응하기 위해 갖추어져 있다. 그러나외부 그룹과의 관계는 흔히 간과된다. 외부 그룹이란 경찰, 소방서, EMS, 의료진, 병원 스탭처럼 시의 비상기관이 있다. 그들은 공무원이나 유틸리티 제공자, 보도기관, 고객이나 주주일 수도 있다. 고위 관리자로부터 말단 까지 모든 직원이 이런 그룹과 상호작용하는 방법이 재해 복구 노력의 결과에 영향을 미칠 것이다. 복구 계획은 이런 외부 그룹과통신하기 위한 단계와 단계적 확대를 분명하게 정의해야 한다.

직원과의 관계

재해 복구 계획의 다른 중요한 국면은 조직이 어떻게 직원과 가족들에 대한 관계를관리하는가 하는 문제이다. 인명이나 안전을 위협하는 사고 발생시 조직은 직원들에 대해고유의 책임을 지닌다. 조직은 사업 운영이 정지될지라도 월급을 지속적으로 지급할 있는 준비를 해야 한다. 이런 급여의 존속성은 장기간 동안 유지되어야 하며, 필요시 회사는보험이 비용을 부담하도록 해야 한다. 또한 직원과 가족이 지진이나 홍수 등의 자연재해로 인한 다양한 종류의 비상 사태에 대해 이동하거나 장기간의 생계지원을 위한 자금을필요로 수도 있다.

사기와 범죄 행위

사고와 관련된 다른 문제도 발생할 있다. 보안 관심사나 사기의 기회를 악용하여 재해를경제적으로 이용하고자 하는 개인이나 조직을 조심해야 한다. 대규모 물리적 재해시, 만행이나 약탈행위가 흔히 발생한다. 계획은 이러한 우발성도 고려해야 한다.

재정적 부담

재해에서 흔히 간과되는 측면은 비용의 지출이다. 결제되고 허가된 수표를 오프사이트로 저장하는 프로시저는 재정적 상환을 촉진하기 위해 고려해야 한다. 또한 사고 도중에 발생한비용이 비상 관리자의 권한을 초과할 가능성도 언급해야 한다.

보도기관과의 관계

어떤 재해 복구 시나리오든 보도기관을 수반한다. 계획의 중요한 부분은 보도기관과 공무원을 다루도록 언급되어야 한다. 조직이 신뢰할 있고 훈련되고 지식이 넓은 대변인에 의해 입안된, 미리 확립되고 정련된 조직적 대응을 준비하는 것은 중요하다. 회사는보도기관이 다른 소스에게로 가지 않도록 보도기관에 접근 가능해야 한다. 회사의 결점을감추려는 것처럼 보이지 않게 보도하는 것이 좋다. 의심이나 소문을 피할 있도록 신속하고 개방적으로 정직하게 있는 그대로 말하라. 재해에 앞서 계획의 일부로서 보도기관에 대한 적절한 보안 등급과 승인 프로세스를 결정하라. 사고의 추이에 따라 신속하고 빠르게 기사의 유포를 통제하는 것이 중요하다.


728x90

'Infrastructure' 카테고리의 다른 글

ebXML [e-business Extensible Markup Language]  (0) 2018.04.18
e-Learning  (0) 2018.04.18
DMB(Digital Multimedia Broadcasting)  (0) 2018.04.18
Data Warehouse  (0) 2018.04.18
Data Roaming  (0) 2018.04.18
Comments