开发 BCP 时最常见的 11 个错误

开发 BCP 时最常见的 11 个错误

大家好,我叫 Igor Tyukachev,是一名业务连续性顾问。 在今天的帖子中,我们将就常见真理进行漫长而乏味的讨论,我想分享我的经验,并谈谈公司在制定业务连续性计划时犯的主要错误。

1.RTO和RPO随机

我见过的最重要的错误是凭空获取恢复时间(RTO)。 嗯,凭空而来 - 例如,有人从以前的工作地点带来了两年前的 SLA 中的一些数字。 他们为什么这样做呢? 毕竟,根据所有方法,您必须首先分析对业务流程的后果,并基于此分析计算目标恢复时间和可接受的数据丢失。 但进行这样的分析有时需要很长时间,有时成本高昂,有时不太清楚如何进行——强调需要做什么。 很多人首先想到的是: “我们都是成年人,都知道商业是如何运作的。 我们不要浪费时间和金钱! 让我们按应有的方式加上或减去。 用无产阶级的聪明才智,从你的头脑中出来! 让 RTO 为两个小时。”

这会导致什么? 当您向管理层寻求资金开展活动以确保达到一定数量的 RTO/RPO 时,总是需要理由。 如果没有正当理由,那么问题就来了:你从哪里得到它? 并且没有什么可以回答的。 结果,你对工作失去了信心。

此外,有时这两个小时的恢复成本就高达一百万美元。 证明 RTO 持续时间的合理性是一个金钱问题,而且是一个非常大的问题。

最后,当你把你的 BCP 和/或 DR 计划带给表演者(他们在事故发生时实际上正在跑步并挥舞着手臂)时,他们会问一个类似的问题:这两个小时是从哪里来的? 如果你不能清楚地解释这一点,那么他们将不会对你或你的文件有信心。

结果是为了一张纸而一张纸,取消订阅。 顺便说一句,有些人故意这样做,只是为了满足监管机构的要求。

开发 BCP 时最常见的 11 个错误
嗯,你理解

2.治愈一切

有些人认为,制定 BCP 计划是为了保护所有业务流程免受任何威胁。 最近,“我们要保护自己免受什么侵害?”这个问题。 我听到的答案是:“一切,甚至更多。”

开发 BCP 时最常见的 11 个错误

但事实是该计划的目的只是为了保护 具体 公司的关键业务流程来自 具体 威胁。 因此,在制定计划之前,有必要评估风险的发生并分析其对业务的影响。 为了了解公司害怕哪些威胁,需要进行风险评估。 如果建筑物被毁,将有一个连续性计划,如果有制裁压力,则有另一个连续性计划,如果发生洪水,则有第三个连续性计划。 即使是不同城市的两个相同地点也可能有截然不同的规划。

仅用一个 BCP 来保护整个公司是不可能的,尤其是大型 BCP。 例如,庞大的 X5 Retail Group 开始确保两个关键业务流程的连续性(我们写过这个 这里)。 而将整个公司包含在一个计划中是不现实的;这属于“集体责任”的范畴,每个人都有责任,而没有人负责。

ISO 22301 标准包含政策的概念,实际上,公司的连续性流程就是从该概念开始的。 它描述了我们将保护什么以及免受什么侵害。 如果人们跑过来要求添加这个那个,例如:

— 让我们在 BCP 中添加被黑客攻击的风险吗?

— 最近下雨,我们的顶楼被水淹了,我们来添加一个场景,如果发生水灾怎么办?

然后立即向他们推荐这项政策,并说我们保护特定的公司资产,并且仅免受特定的、预先商定的威胁,因为它们是现在的首要任务。

即使更改建议确实合适,也要在下一版本的政策中考虑这些建议。 因为保护一家公司需要花费很多钱。 因此BCP计划的所有变更都必须经过预算委员会和规划。 我们建议每年一次或在公司结构或外部条件发生重大变化后立即审查公司的业务连续性政策(请读者原谅我这样说)。

3. 幻想与现实

在制定 BCP 计划时,作者经常会描述一些理想的世界图景。 例如,“我们没有第二个数据中心,但我们会像有第二个数据中心一样编写计划。” 或者企业还没有某些基础设施,但员工仍然会将其添加到计划中,希望它将来会出现。 然后公司将把现实延伸到计划中:建立第二个数据中心,描述其他变化。

开发 BCP 时最常见的 11 个错误
左边是BCP对应的基础设施,右边是真正的基础设施

这都是一个错误。 写BCP计划就意味着要花钱。 如果你写的计划目前不起作用,你将支付非常昂贵的纸张费用。 不可能从中恢复,也不可能对其进行测试。 事实证明,这是为了工作而工作。
您可以很快地制定计划,但构建备份基础设施并在所有保护解决方案上花钱是漫长且昂贵的。 这可能需要一年多的时间。 事实可能是你已经有了一个计划,并且它的基础设施将在两年内出现。 为什么需要这样一个计划? 它会保护你免受什么侵害?

当 BCP 开发团队开始为专家弄清楚他们应该做什么以及在什么时间做什么时,这也是一个幻想。 它来自这样的类别:“当你在针叶林中看到熊时,你需要转向与熊相反的方向,并以超过熊的速度奔跑。 在冬季,你需要掩盖自己的踪迹。”

4. 顶部和根部

第四个最重要的错误是计划要么太肤浅,要么太详细。 我们需要一个中庸之道。 对于白痴来说,计划不应该太详细,但也不应该太笼统,以免出现这样的结果:

开发 BCP 时最常见的 11 个错误
总的来说很容易

5. 对于凯撒来说,什么是凯撒的,对于机械师来说,什么是机械师的。

下一个错误源于上一个错误:一个计划无法容纳各级管理层的所有行动。 BCP计划通常是为资金流量大的大公司制定的(顺便说一句,根据我们的数据) 研究平均而言,48%的俄罗斯大型企业遇到了导致重大财务损失的紧急情况)和多级管理体系。 对于这样的公司来说,不值得尝试将所有内容都放入一份文档中。 如果公司规模庞大且结构合理,那么该计划应该分为三个不同的层次:

  • 战略层面——高级管理层;
  • 战术层面——针对中层管理人员;
  • 以及操作层面——对于那些直接参与该领域的人。

例如,如果我们正在谈论恢复故障的基础设施,那么在战略层面上会做出激活恢复计划的决定,在战术层面上可能会描述过程程序,而在操作层面上会有调试特定的说明。设备件。

开发 BCP 时最常见的 11 个错误
无预算的 BCP

每个人都看到自己的职责范围以及与其他员工的联系。 事故发生的那一刻,每个人都制定了计划,迅速找到自己的部分并执行。 理想情况下,您需要记住要打开哪些页面,因为有时分钟很重要。

6. 角色扮演

制定BCP计划时的另一个错误是:计划中不需要包含具体的姓名、邮件地址和其他联系信息。 在文件本身的文本中,仅应指出非个人角色,并且应为这些角色分配负责特定任务的人员的姓名,并且应在计划的附件中列出他们的联系方式。

为什么呢?

如今,大多数人每两到三年就会换一次工作。 如果你在计划的文本中写下所有责任人和他们的联系方式,那么它就必须不断地改变。 在大公司,尤其是政府公司,对任何文件的每次更改都需要大量批准。

更不用说,如果发生紧急情况,你必须疯狂地翻阅计划并寻找合适的联系人,你将浪费宝贵的时间。

生活窍门:当您更改应用程序时,通常甚至不需要批准它。 另一个提示:您可以使用计划更新自动化系统。

7. 缺乏版本控制

通常他们会创建一个计划版本 1.0,然后在不进行编辑模式的情况下进行所有更改,并且不更改文件名。 同时,与以前的版本相比,通常不清楚发生了什么变化。 在没有版本控制的情况下,计划有自己的生命周期,不会以任何方式进行跟踪。 任何 BCP 计划的第二页都应标明版本、更改的作者以及更改本身的列表。

开发 BCP 时最常见的 11 个错误
没有人能再弄清楚

8. 我应该问谁?

公司通常没有专人负责 BCP 计划,也没有单独的部门负责业务连续性。 这个光荣的责任被分配给CIO,他的副手,或者按照“你处理信息安全,所以这里还有BCP”的原则。 因此,该计划是从上到下制定、商定和批准的。

谁负责存储计划、更新和修改其中的信息? 这可能没有规定。 为此雇用一名单独的员工是浪费的,但是当然可以让现有的一名员工承担额外的职责,因为现在每个人都在努力提高效率:“让我们在他身上挂一盏灯笼,这样他就可以在晚上割草了,”但是有必要吗?
开发 BCP 时最常见的 11 个错误
BCP 创建两年后,我们正在寻找负责人

因此,经常会发生这样的情况:制定了一个计划,放在一个长盒子里,变得布满灰尘。 没有人测试它或维持其相关性。 找客户最常听到的一句话就是:“有方案,但是很久以前制定的,是否测试过未知,有行不通的嫌疑。”

9、水太多

有些计划的介绍长达五页,包括对先决条件的描述、对项目所有参与者的感谢,以及有关公司业务的信息。 当你向下滚动到第十页时,那里有有用的信息,你的数据中心已经被淹没了。

开发 BCP 时最常见的 11 个错误
当您尝试阅读最新信息时,如果您的数据中心被淹没,您该怎么办?

将所有公司“水”放在单独的文档中。 计划本身必须非常具体:负责这项任务的人执行此操作,等等。

10. 宴会费用由谁承担?

通常,计划制定者得不到公司高层管理人员的支持。 但中层管理人员提供支持,他们不管理或没有必要的预算和资源来管理业务连续性。 例如,IT 部门在其预算范围内制定了 BCP 计划,但 CIO 却看不到公司的整体情况。 我最喜欢的例子是视频会议。 当CEO的视频会议不起作用时,他会剔除谁? “没有提供”的 CIO。 因此,从CIO的角度来看,公司最重要的事情是什么? 人们总是“喜欢”他的原因:视频会议,它立即变成一个关键业务系统。 从商业角度来看 - 好吧,没有 VKS,想想看,我们会通过电话交谈,就像勃列日涅夫领导下的那样......

此外,IT部门通常认为发生灾难时其主要任务是恢复企业IT系统的运行。 但有时你不需要这样做! 如果有一个业务流程是在非常昂贵的打印机上打印纸张,那么您不应该购买第二台这样的打印机作为备用,并将其放在旁边以防发生故障。 暂时用手给纸片上色可能就足够了。

如果我们要在 IT 内部构建持续的保护,我们必须争取高级管理层和业务代表的支持。 否则,在 IT 部门内部化身后,您可以解决一定范围的问题,但不能解决所有必要的问题。

开发 BCP 时最常见的 11 个错误
这就是只有 IT 部门有灾难恢复计划时的情况

10. 没有测试

如果有计划,就需要进行测试。 对于那些不熟悉标准的人来说,这一点并不明显。 例如,到处都挂着“紧急出口”标志。 但请告诉我,你的消防桶、钩子和铲子在哪里? 消防栓在哪里? 灭火器应该安装在哪里? 但每个人都应该知道这一点。 对我们来说,进入办公室时找到灭火器似乎根本不合逻辑。

也许计划本身应该提到测试计划的必要性,但这是一个有争议的决定。 无论如何,一个计划只有经过至少一次测试才能被认为是有效的。 正如上面提到的,我经常听到:“有一个计划,所有的基础设施都准备好了,但事实并非一切都会按照计划中所写的那样进行。 因为他们没有测试过。 绝不”。

总之

一些公司可以分析他们的历史记录,以了解可能发生什么样的麻烦以及发生的可能性有多大。 研究和经验表明,我们无法保护自己免受一切侵害。 狗屎,任何公司迟早都会发生。 另一件事是您将如何应对这种或类似的情况,以及您是否能够及时恢复业务。

有些人认为连续性就是如何消除各种风险,使其不至于出现。 不,关键是风险将会成为现实,而我们将为此做好准备。 士兵们接受的训练不是在战斗中思考,而是行动。 BCP 计划也是如此:它可以让您尽快恢复业务。

开发 BCP 时最常见的 11 个错误
唯一不需要BCP的设备

伊戈尔·秋卡乔夫,
业务连续性顾问
计算系统设计中心
“喷气信息系统”


来源: habr.com

添加评论