BCP 개발 시 TOP 11 실수

안녕하세요 여러분, 제 이름은 Igor Tyukachev이고 비즈니스 연속성 컨설턴트입니다. 오늘 포스팅에서는 일반적인 진실에 대해 길고 지루한 토론을 하게 될 것입니다. 저는 제 경험을 공유하고 기업이 비즈니스 연속성 계획을 개발할 때 저지르는 주요 실수에 대해 이야기하고 싶습니다.

1. 무작위로 RTO와 RPO

내가 본 가장 중요한 실수는 복구 시간(RTO)이 허공에서 빼앗긴다는 것입니다. 글쎄요, 예를 들어 누군가가 이전 직장에서 가져온 SLA의 XNUMX년 전 수치가 있습니다. 그들은 왜 이런 일을 하는가? 결국 모든 방법에 따라 먼저 비즈니스 프로세스에 대한 결과를 분석하고 이 분석을 기반으로 목표 복구 시간과 허용 가능한 데이터 손실을 계산해야 합니다. 그러나 그러한 분석을 수행하는 데는 시간이 오래 걸리고, 비용이 많이 들며, 수행 방법이 명확하지 않은 경우도 있습니다. 무엇을 해야 하는지 강조하십시오. 그리고 많은 사람들이 가장 먼저 생각하는 것은 다음과 같습니다. “우리는 모두 성인이며 비즈니스가 어떻게 작동하는지 이해합니다. 시간과 돈을 낭비하지 말자! 플러스나 마이너스를 그대로 취해보자. 프롤레타리아의 독창성을 사용하여 머리 밖으로! RTO를 XNUMX시간으로 설정하세요.”

이것이 무엇으로 이어지는가? 특정 수치로 필요한 RTO/RPO를 보장하기 위한 활동에 대한 비용을 관리할 때는 항상 정당성이 필요합니다. 정당성이 없으면 질문이 생깁니다. 어디서 얻었습니까? 그리고 대답할 것이 없습니다. 결과적으로 업무에 대한 자신감이 상실됩니다.

게다가 때로는 그 XNUMX시간의 회복에 백만 달러가 드는 경우도 있습니다. 그리고 RTO 기간을 정당화하는 것은 돈 문제이고 그 점에서는 매우 큰 문제입니다.

그리고 마지막으로 BCP 및/또는 DR 계획을 공연자(실제로 사고 순간에 달리며 팔을 흔들고 있는)에게 가져오면 그들은 비슷한 질문을 할 것입니다. 이 두 시간은 어디서 왔습니까? 그리고 이것을 명확하게 설명할 수 없다면 그들은 귀하나 귀하의 문서에 대해 신뢰를 갖지 않을 것입니다.

종이 한 장, 구독 취소를 위한 종이 한 장으로 밝혀졌습니다. 그런데 일부는 단순히 규제 기관의 요구 사항을 충족시키기 위해 의도적으로 이 작업을 수행합니다.

음, 너 이해해.

2. 모든 것에 대한 치료법

어떤 사람들은 모든 비즈니스 프로세스를 위협으로부터 보호하기 위해 BCP 계획이 개발되었다고 믿습니다. 최근 “우리는 무엇으로부터 자신을 보호하고 싶은가?”라는 질문이 제기됩니다. 나는 “모든 것, 그 이상”이라는 대답을 들었습니다.

그러나 사실은 이 계획은 오직 보호만을 위한 것입니다. 특정의 회사의 주요 비즈니스 프로세스부터 특정의 위협. 따라서 계획을 수립하기 전에 위험 발생을 평가하고 그것이 비즈니스에 미치는 영향을 분석하는 것이 필요합니다. 회사가 두려워하는 위협이 무엇인지 이해하려면 위험 평가가 필요합니다. 건물이 파괴되는 경우 제재 압력이 가해질 경우, 홍수가 발생하는 경우에는 세 번째 연속성 계획이 적용됩니다. 서로 다른 도시에 있는 두 개의 동일한 사이트라도 상당히 다른 계획을 가질 수 있습니다.

하나의 BCP, 특히 대규모 BCP로 회사 전체를 보호하는 것은 불가능합니다. 예를 들어, 대규모 X5 Retail Group은 두 가지 핵심 비즈니스 프로세스의 연속성을 보장하기 시작했습니다. 여기에). 그리고 회사 전체를 하나의 계획으로 묶는 것은 단순히 비현실적입니다. 이는 모든 사람이 책임을 지고 누구도 책임을 지지 않는 "집단 책임" 범주에 속합니다.

ISO 22301 표준에는 실제로 회사의 연속성 프로세스가 시작되는 정책 개념이 포함되어 있습니다. 이는 우리가 무엇을 보호할 것인지, 무엇으로부터 보호할 것인지를 설명합니다. 사람들이 달려와서 이것저것 추가해 달라고 요청한다면, 예를 들면 다음과 같습니다.

— BCP에 해킹당할 위험을 추가해 볼까요?

또는

— 최근 비가 내리는 동안 꼭대기 층이 침수되었습니다. 침수 시 대처 방법에 대한 시나리오를 추가해 보겠습니다.

그런 다음 즉시 이 정책을 언급하고 우리는 특정 회사 자산을 보호하고 사전 합의된 특정 위협으로부터만 보호한다고 말합니다. 왜냐하면 이것이 현재 우선순위이기 때문입니다.

그리고 변경 제안이 실제로 적절하더라도 정책의 다음 버전에서 이를 고려하겠다고 제안하십시오. 회사를 보호하는 데에는 많은 비용이 들기 때문입니다. 따라서 BCP 계획에 대한 모든 변경 사항은 예산 위원회와 계획을 거쳐야 합니다. 회사의 비즈니스 연속성 정책은 XNUMX년에 한 번 또는 회사의 구조나 외부 상황에 중대한 변화가 발생한 직후에 검토하는 것이 좋습니다(독자들의 양해를 바랍니다).

3. 환상과 현실

BCP 계획을 작성할 때 저자가 세계의 이상적인 그림을 설명하는 경우가 종종 있습니다. 예를 들어, “우리는 두 번째 데이터 센터가 없지만, 마치 있는 것처럼 계획을 작성하겠습니다.” 또는 비즈니스에 아직 인프라의 일부가 없지만 직원은 향후 해당 인프라가 나타날 것이라는 희망으로 이를 계획에 추가할 것입니다. 그런 다음 회사는 두 번째 데이터 센터를 구축하고 다른 변경 사항을 설명하는 계획에 현실을 적용할 것입니다.

왼쪽은 BCP에 해당하는 인프라, 오른쪽은 실제 인프라

이것은 모두 실수입니다. BCP 계획을 작성한다는 것은 돈을 쓰는 것을 의미합니다. 지금 당장 효과가 없는 계획서를 작성한다면 매우 비싼 종이를 지불하게 될 것입니다. 복구도 불가능하고 테스트도 불가능합니다. 그것은 일을 위한 일임이 밝혀졌습니다.
매우 빠르게 계획을 작성할 수 있지만 백업 인프라를 구축하고 모든 보호 솔루션에 비용을 지출하는 데는 시간이 오래 걸리고 비용이 많이 듭니다. XNUMX년 이상이 걸릴 수도 있습니다. 그리고 이미 계획이 있고 이를 위한 인프라가 XNUMX년 안에 나타날 것입니다. 왜 그러한 계획이 필요한가? 그것은 무엇으로부터 당신을 보호할 것인가?

BCP 개발팀이 전문가를 위해 무엇을 언제 해야 할지 파악하기 시작하는 것도 환상입니다. “타이가에서 곰을 보면 곰과 반대 방향으로 방향을 틀고 곰의 속도를 초과하는 속도로 달려야 합니다. 겨울철에는 흔적을 덮어야 합니다.”

4. 꼭대기와 뿌리

네 번째로 중요한 실수는 계획을 너무 피상적이거나 너무 상세하게 만드는 것입니다. 우리에게는 황금률이 ​​필요합니다. 계획은 바보가 보기에는 너무 자세하지 않아야 하지만, 다음과 같은 결과가 나올 정도로 너무 일반적이어서는 안 됩니다.

일반적으로 쉬움

5. 카이사르에게 – 카이사르의 것은 무엇이며, 기계공에게 – 기계공의 것은 무엇입니까?

다음 실수는 이전 실수에서 비롯됩니다. 하나의 계획이 모든 수준의 관리에 대한 모든 조치를 수용할 수는 없습니다. BCP 계획은 일반적으로 자금 흐름이 큰 대기업을 위해 개발됩니다. 연구, 평균적으로 러시아 대기업의 48%는 상당한 재정적 손실을 수반하는 긴급 상황에 직면했으며 다단계 관리 시스템을 갖추고 있습니다. 그러한 회사의 경우 모든 것을 하나의 문서에 맞추려고 노력할 가치가 없습니다. 회사 규모가 크고 구조화되어 있는 경우 계획에는 세 가지 별도의 수준이 있어야 합니다.

• 전략적 수준 - 고위 경영진을 위한 것입니다.
• 전술적 수준 - 중간 관리자용
• 및 운영 수준 - 현장에 직접 관련된 사람들을 위한 것입니다.

예를 들어, 실패한 인프라 복원에 대해 이야기하는 경우 전략적 수준에서는 복구 계획을 활성화하기로 결정하고, 전술적 수준에서는 프로세스 절차를 설명할 수 있으며, 운영 수준에서는 특정 시운전에 대한 지침이 있습니다. 장비 조각.

예산이 없는 BCP

모든 사람은 자신의 책임 영역과 다른 직원과의 관계를 봅니다. 사고가 발생하는 순간, 모두가 계획을 세우고 빠르게 자신의 역할을 찾아 이를 따릅니다. 이상적으로는 어떤 페이지를 열어야 하는지 기억해야 합니다. 때로는 시간이 중요하기 때문입니다.

6. 역할극

BCP 계획을 세울 때의 또 다른 실수는 계획에 특정 이름, 이메일 주소 및 기타 연락처 정보를 포함할 필요가 없다는 것입니다. 문서 자체의 텍스트에는 비인격적인 역할만 표시되어야 하며 이러한 역할에는 특정 작업을 담당하는 사람의 이름이 할당되어야 하며 해당 연락처는 계획의 부록에 나열되어야 합니다.

이유는 무엇입니까?

오늘날 대부분의 사람들은 XNUMX~XNUMX년마다 직장을 바꿉니다. 그리고 계획 텍스트에 모든 책임자와 연락처를 적어두면 지속적으로 변경되어야 합니다. 대기업, 특히 정부 기관에서는 문서를 변경할 때마다 수많은 승인이 필요합니다.

긴급 상황이 발생하여 필사적으로 계획을 검토하고 올바른 연락처를 찾아야 하는 경우 귀중한 시간을 낭비하게 될 것이라는 점은 말할 것도 없습니다.

인생 꿀팁: 애플리케이션을 변경할 때 승인할 필요조차 없는 경우가 많습니다. 또 다른 팁: 계획 업데이트 자동화 시스템을 사용할 수 있습니다.

7. 버전 관리 부족

일반적으로 그들은 계획 버전 1.0을 만든 다음 편집 모드나 파일 이름을 변경하지 않고 모든 변경을 수행합니다. 동시에, 이전 버전에 비해 무엇이 변경되었는지 명확하지 않은 경우가 많습니다. 버전 관리가 없으면 계획은 자체적으로 유지되며 어떤 방식으로도 추적되지 않습니다. BCP 계획의 두 번째 페이지에는 버전, 변경 내용 작성자 및 변경 내용 자체 목록이 표시되어야 합니다.

더 이상 누구도 알아낼 수 없어

8. 누구에게 물어봐야 합니까?

기업에는 BCP 계획을 담당하는 사람이 없고 비즈니스 연속성을 담당하는 별도의 부서가 없는 경우가 많습니다. 이 명예로운 책임은 CIO, 그의 대리인 또는 "정보 보안을 다루므로 여기에 BCP가 추가됩니다"라는 원칙에 따라 할당됩니다. 결과적으로 계획은 처음부터 끝까지 개발, 합의 및 승인됩니다.

계획을 저장하고, 계획에 포함된 정보를 업데이트 및 수정하는 책임은 누구에게 있습니까? 이것은 처방되지 않을 수도 있습니다. 이를 위해 별도의 직원을 고용하는 것은 낭비이지만 기존 직원 중 하나에 추가 업무를 추가하는 것은 물론 가능합니다. 이제 모두가 효율성을 위해 노력하고 있기 때문입니다. "그가 밤에 깎을 수 있도록 랜턴을 걸어 놓자" 그게 필요 할까?

BCP 창립 XNUMX년 후 책임자를 찾습니다.

따라서 종종 다음과 같은 일이 발생합니다. 계획을 개발하여 긴 상자에 넣어 먼지로 덮었습니다. 아무도 그것을 테스트하거나 관련성을 유지하지 않습니다. 제가 고객을 만나면 가장 많이 듣는 말은 “계획은 있지만 오래 전에 개발한 것인지, 테스트를 했는지는 알 수 없고, 안 되는 게 아닌가 하는 의혹이 있다”는 것이다.

9. 물이 너무 많다

전제 조건에 대한 설명과 프로젝트의 모든 참가자에 대한 감사, 회사가 하는 일에 대한 정보를 포함하여 XNUMX페이지 길이의 소개 계획이 있습니다. 유용한 정보가 있는 XNUMX번째 페이지까지 아래로 스크롤할 때쯤에는 귀하의 데이터 센터가 이미 물바다가 된 것입니다.

현재까지 읽으려고 할 때 데이터 센터가 침수되면 어떻게 해야 합니까?

모든 기업의 "물"을 별도의 문서에 보관하십시오. 계획 자체는 매우 구체적이어야 합니다. 이 작업을 담당하는 사람이 이 작업을 수행하는 식입니다.

10. 잔치는 누구의 비용으로 합니까?

계획 작성자가 회사 최고 경영진의 지원을 받지 못하는 경우가 많습니다. 그러나 비즈니스 연속성을 관리하는 데 필요한 예산과 자원을 관리하지 않거나 보유하지 않은 중간 경영진의 지원이 있습니다. 예를 들어, IT 부서는 예산 내에서 BCP 계획을 수립하지만 CIO는 회사 전체 그림을 볼 수 없습니다. 제가 가장 좋아하는 예는 화상 회의입니다. CEO의 화상회의가 작동하지 않으면 그는 누구를 제거할 것인가? “제공하지 않은” CIO. 그렇다면 CIO의 관점에서 회사에서 가장 중요한 것은 무엇인가? 사람들이 항상 그를 "좋아하는" 이유는 바로 비즈니스에 중요한 시스템으로 변하는 화상 회의입니다. 그리고 비즈니스 관점에서 보면 VKS는 없습니다. 브레즈네프 밑에서처럼 전화로 통화하겠습니다...

또한, IT 부서는 일반적으로 재해 발생 시 주요 업무가 기업 IT 시스템의 운영을 복원하는 것이라고 생각합니다. 하지만 때로는 이렇게 할 필요가 없습니다! 엄청나게 비싼 프린터에서 종이 조각을 인쇄하는 형태의 비즈니스 프로세스가 있는 경우 이러한 프린터를 예비용으로 구입하여 고장이 발생할 경우 옆에 놓아서는 안됩니다. 손으로 종이 조각을 일시적으로 색칠하는 것만으로도 충분할 수 있습니다.

IT 내에서 지속적인 보호를 구축하려면 고위 경영진과 비즈니스 담당자의 지원을 받아야 합니다. 그렇지 않으면 IT 부서 내부에서 번성하면 특정 범위의 문제를 해결할 수 있지만 필요한 모든 문제를 해결할 수는 없습니다.

IT 부서만이 DR 계획을 갖고 있는 경우의 상황은 다음과 같습니다.

10. 테스트 없음

계획이 있다면 테스트를 거쳐야 합니다. 표준에 익숙하지 않은 사람들에게는 이것이 전혀 명확하지 않습니다. 예를 들어, "비상구" 표지판이 곳곳에 걸려 있습니다. 하지만 말해 보세요. 소방용 양동이, 갈고리, 삽은 어디에 있나요? 소화전은 어디에 있나요? 소화기는 어디에 설치해야 합니까? 하지만 이건 모두가 알아야 해요. 사무실에 들어갈 때 소화기를 찾는 것은 전혀 논리적이지 않은 것 같습니다.

아마도 계획 자체에서 계획을 테스트해야 할 필요성이 언급되어야 할 것 같지만 이는 논란의 여지가 있는 결정입니다. 어쨌든 계획은 적어도 한 번 테스트된 경우에만 작동하는 것으로 간주될 수 있습니다. 위에서 언급했듯이 저는 다음과 같은 말을 자주 듣습니다. “계획이 있고 모든 인프라가 준비되어 있지만 모든 것이 계획대로 진행될 것이라는 것은 사실이 아닙니다. 왜냐하면 그들은 그것을 테스트하지 않았기 때문입니다. 절대".

결론적으로

일부 회사에서는 어떤 종류의 문제가 발생할 가능성이 있는지, 발생할 가능성이 얼마나 되는지 이해하기 위해 이력을 분석할 수 있습니다. 연구와 경험에 따르면 우리는 모든 것으로부터 자신을 보호할 수는 없습니다. 조만간 어느 회사에나 이런 일이 일어납니다. 또 다른 것은 이 상황이나 유사한 상황에 대해 얼마나 준비할 것인지, 그리고 시간 내에 비즈니스를 복원할 수 있는지 여부입니다.

어떤 사람들은 연속성이 모든 종류의 위험이 실현되지 않도록 제거하는 방법이라고 생각합니다. 아니요, 요점은 위험이 현실화된다는 것입니다. 우리는 이에 대비할 것입니다. 군인들은 전투에서 생각하는 것이 아니라 행동하도록 훈련받습니다. BCP 계획도 마찬가지입니다. 이를 통해 가능한 한 빨리 비즈니스를 복원할 수 있습니다.

BCP가 필요하지 않은 유일한 장비

이고르 튜카체프,
비즈니스 연속성 컨설턴트
컴퓨팅 시스템 설계 센터
"제트 인포시스템즈"

출처 : habr.com