业务连续性流程图：从启动预案到解除响应

什么是业务连续性流程图：从启动预案到解除响应流程

业务连续性流程让组织在某样东西已经瘫痪时，仍然能继续交付它的关键职能。它不等于 IT 灾难恢复。灾难恢复是恢复系统与数据的技术工作——故障转移、备份、恢复点目标——它是连续性的一项输入，而不是连续性的全部。许多次启动根本与 IT 故障无关：一栋建筑无法进入、一家独家供应商停摆、恶劣天气或罢工让一个班次的大部分人无法到岗。这个流程要回答的问题不是“系统什么时候恢复？”，而是“在它恢复之前，我们怎样继续服务客户？”。

把与相邻流程的边界说清楚是值得的，因为把边界画糊的图，在真正的中断中会被无视。一次落在正常容忍范围内的单一服务中断属于事件管理，由它按 SLA 恢复服务。一次已确认的网络攻击属于安全事件响应，由它负责遏制、证据保全与违规通报。重建或切换到备用技术环境属于灾难恢复运行手册。业务连续性位于这三者之上：它判定这次中断已经越过了阈值，决定优先保护哪些业务活动，并运行那些在技术团队工作期间把业务撑住的人工与变通安排。

连续性流程通常在四个可以预见的地方失效，下面这张图就是为了堵住它们而画的。启动被拖延，因为没有人事先约定谁有权启动、依据什么标准启动。优先级由喊得最响的人决定，而不是由业务影响分析（BIA）里早已记录的恢复时间目标决定。变通方案停留在纸面上，但它们所假定的纸质表单、离线数据和人工审批权限从来没有准备好。而恢复正常运营时没有约定的判定标准，于是业务回到日常，却留下一堆无人认领的积压。五条泳道——事件管理团队、业务部门负责人、业务连续性协调人、沟通与高管层——承载了横跨五个阶段的流程，其中有两个决策：是否启动计划，以及是否可以恢复正常运营。

本流程图涵盖的内容

本模板包含

• 五条泳道，每一步都有具名的负责人——事件管理团队、业务部门负责人、业务连续性协调人、沟通与高管层——分布在五个阶段：评估与启动、动员、连续性运行、监控与检视，以及恢复与复盘。
• 一个可度量的入口：“中断已上报值班经理”接入“确认受影响的场地与职能”，再到“对照连续性阈值评估影响”，让触发条件被拿去与业务影响分析比对，而不是凭感觉判断。
• “是否启动业务连续性计划？”这一决策，其低于阈值的分支运行“在正常运营中处理”，并在中断升级时回到重新评估——让一次未遂事件被持续监控，而不是被遗忘。
• 计划启动之后的动员：“召集事件管理团队”“依据业务影响分析确定关键职能的优先顺序”，沟通泳道中的“通知员工并清点人员”，以及高管层泳道中的“批准应急预算与授权”。
• 连续性运行本身：“启用变通方案与人工流程”“安排备用场地与远程办公”以及“向客户和关键利益相关方通报”——正是这些步骤把连续性与技术恢复区分开来。
• 一个状态循环和一次受控的收尾：“按约定间隔检视状态”接入“是否恢复正常运营？”，其中“暂不”走向“延长连续性安排”并回到下一次检视，而“恢复”则依次执行恢复运行与清理积压、解除响应、确认恢复正常服务、事后评审，最后落在“更新业务影响分析与连续性计划”。

何时使用本模板

• 你们要编写或更新一份业务连续性计划，需要用一页纸说明谁决定什么、按什么顺序决定——在这份计划真的要在压力下被翻开之前。
• 你们要事先约定启动权限与连续性阈值，包括非工作时间由谁代行，好让第一个小时不用花在争论这件事算不算得上中断。
• 你们想把业务连续性计划与 IT 灾难恢复运行手册分开，让每一份文件各自覆盖自己的范围，并把两者之间的交接写明。
• 你们要做一次桌面推演：两个决策、状态循环和跨泳道的交接，给了你们具体可测、也可以被压垮的东西。
• 你们要向业务部门负责人说明中断期间对他们的期望，尤其是人工变通方案，以及随后必须完成的对账工作。
• 你们在准备一次业务连续性审核，或回答客户的韧性问卷，需要拿得出一个有负责人的成文流程。

运作方式

1. 把泳道改成你们真实的应急组织

   把事件管理团队、业务部门负责人、业务连续性协调人、沟通与高管层，换成你们实际拥有的角色——危机管理团队、战略层与战术层指挥、场地负责人、韧性经理、值班高管。规模较小的组织常把业务连续性协调人并入事件管理团队的泳道；宁可删掉一条泳道，也不要让它空着无人负责。

2. 把启动标准与启动权限写下来

   打开“是否启动业务连续性计划？”，填入你们自己的判定条件：预计中断时长超过某项关键职能的恢复时间目标，或者某个场地、某家供应商的不可用超过约定期限。写明谁有权启动，写明代行人，并给出一条非工作时间的联络路径。一条需要开会才能解释清楚的启动标准，在凌晨三点是不会被用上的。

3. 把业务影响分析挂到优先级排序这一步上

   “依据业务影响分析确定关键职能的优先顺序”，其质量不会高于它背后的那份分析。按恢复时间目标的顺序列出你们的关键活动，并记录每一项依赖什么：人员、场地、系统、数据与供应商。如果某项职能的依赖关系不清楚，那正是下一次演练应当瞄准的缺口。

4. 让变通方案具体、可核查

   把“启用变通方案与人工流程”换成每一项关键职能的具名变通方案，写明它的产能上限、能维持多久，以及需要事先准备什么——纸质表单、关键数据的离线副本、一个人工审批限额。再加上系统恢复后由谁负责核对这些人工记录，因为连续性的问题通常正是在积压那里暴露出来。

5. 确定状态检视的节奏与恢复正常的判定标准

   决定“按约定间隔检视状态”多久触发一次——起初每小时一次，随着局面稳定逐步拉长——以及“是否恢复正常运营？”需要什么证据：产能已恢复、员工与场地安全、积压量已核算且有人认领。没有判定标准就宣布恢复正常，正是第二次中断的经典开端。

6. 先演练这张图，再发布一个经审批的版本

   和每一条泳道一起走一遍，把步骤改成人们实际会做的事；然后用一个与 IT 完全无关的情景做桌面推演——一处场地关闭，或一家供应商崩盘。记录演练带来的改动，把它接进“更新业务影响分析与连续性计划”，并发布这个达成一致的版本，让所有人都能看到当前生效的是哪一版。

常见问题

业务连续性与 IT 灾难恢复有什么区别？

业务连续性让业务活动在中断期间继续交付——人员、场地、供应商、客户、人工变通方案。灾难恢复恢复的是技术：系统、应用与数据，用恢复时间目标和恢复点目标来衡量。灾难恢复是支撑连续性的一项能力，而不是它的替代品。业务连续性计划也会因为完全没有技术原因的事件而启动，例如某栋建筑无法使用，或一家关键供应商崩盘；即便是在 IT 故障期间，连续性要回答的仍然是：在灾难恢复团队工作的同时，业务如何继续做生意。在这张图里，这个区别就落在“启用变通方案与人工流程”上：技术恢复发生在别处，按它自己的运行手册进行。

由谁决定启动业务连续性计划？

一个获得授权的具名角色，再加上一位负责非工作时间的代行人。在这张图里，这个决策由业务连续性协调人依据成文标准作出，高管层泳道紧接着批准应急预算与授权；许多组织则把启动权交给值班高管或危机负责人。比职务名称更重要的是：标准在事件发生前就已经写下来，并且客观到一个人在夜里也能据以判断。启动是一个有成本的业务决策，但更常见的失误是启动得太晚，把最初几个小时耗在争论上。

什么是连续性阈值，它从哪里来？

它来自业务影响分析（BIA）。对每一项关键活动，BIA 记录它可以被中断多久，后果才会变得不可接受——即最大可容忍中断时长，也称最大可接受停机时间——以及在这个上限之内的一个恢复时间目标。连续性阈值把这些数字变成一个触发条件：如果预计中断时长将超过某项关键活动的恢复时间目标，就启动计划。受监管的机构可能会有一套由外部设定的对应要求；例如英国金融服务业的运营韧性规则，就要求机构识别重要业务服务并为其设定影响容忍度。

连续性安排应当运行多久才回到正常状态？

只要恢复正常的判定标准尚未满足，就继续运行——这也是这张图采用循环、而不是假定一个固定时长的原因。“按约定间隔检视状态”与“延长连续性安排”之所以存在，是因为变通方案有保质期：人工处理产能、临时场地和各方的善意都会被消耗，而积压则一直在增长。开始时把检视节奏排密，随着局面稳定再拉长；并且把恢复正常当成一个由某个人签字的决策，而不是悄悄滑回旧习惯。

使用这份模板能让我们符合 ISO 22301 吗？

不能。ISO 22301 是业务连续性管理体系的国际标准，符合性取决于整个体系——最高管理者的承诺、业务影响分析与风险评估、成文的计划与程序、演练与测试、绩效评价与改进——而不取决于任何一张图。一张清晰、有负责人的流程图可以支撑其中若干项要求，在审核或客户问卷中也是有用的证据，但它是管理体系的一个组成部分，而不是体系合规的证明。