去年我参与了一家年营收规模在5亿左右的电商平台业务连续性演练复盘，结果让我很意外。这家公司过去12次IT系统演练全部通过，管理层对演练得分很满意。但三个月后一次真实数据库故障，业务中断了4小时，而演练场景中这种故障的RTO（恢复时间目标）是30分钟。差距是8倍。问题出在哪？我花了两周时间梳理了他们的演练数据，发现一个核心事实：演练通过率越高，业务连续性越差。这不是一个悖论。这是数据分析缺位导致的系统性盲区。
业务连续性演练本身是一个“制造故障”的过程，但大多数企业只关注演练有没有“跑通”，不关注数据有没有“说话”。我们看到的演练报告往往是“本次演练成功，系统恢复用时25分钟，符合RTO目标”。但二十五分钟里有多少是脚本执行时间、多少是人工等待时间、多少是系统自动恢复时间？没人知道。演练结束后，所有人签字确认，演练报告归档，下一次演练换一个场景再来一次。这种重复不会带来能力的提升，只会带来虚假的安全感。
这篇文章不是讲“什么是业务连续性”，也不是讲“演练的重要性”。这些内容任何一个搜索引擎都能告诉你。我要讲的是数据分析如何让业务连续性演练从“定性描述”变成“定量评估”，从“表演”变成“真正的压力测试”。我会把自己过去几年亲自参与过的演练项目、踩过的坑、总结的判断逻辑全部拆开，给你一套可复用的数据框架。
我接触过很多企业的演练流程，发现一个普遍现象：数据采集是演练结束后才开始的。演练结束了，运维人员开始翻日志、导监控数据、写报告。这种“事后补数”的做法导致两个问题。第一，数据颗粒度不够。你只能看到整体结果，看不到每个环节的耗时和异常。第二，数据失真。演练过程中很多人为操作没有记录，最终报告里的数据是“美化后的版本”，不是真实情况。
我自己的判断逻辑很简单：演练数据必须在演练前设计好，演练中实时采集，演练后不做任何回溯修改。只有这样，数据才能反映真实能力，而不是反映报告撰写能力。
我参与过一个零售企业的演练项目。他们的做法是：在演练脚本中嵌入数据采集节点，每个步骤完成后系统自动记录时间戳和状态码。演练结束后，数据直接进入BI平台生成分析报告，中间没有任何人工干预。结果他们发现，演练中有一个环节的耗时比预期高出3倍，原因是人工审批流程需要等待领导邮件确认。这个瓶颈在之前的演练报告中从未出现过，因为之前的数据是人工汇总的，审批等待时间被“四舍五入”掉了。
所以，核心结论只有一句话：演练数据的设计要与演练脚本同步进行，而不是事后补作业。
讲一个真实场景。2022年，我帮一家中型制造业企业做业务连续性评估。这家企业有3个工厂、1个数据中心、大约2000名员工。他们的演练频率是每季度一次，主要演练内容是服务器故障切换和网络中断恢复。我拿到他们的演练数据后发现，过去两年的8次演练中，有7次是“成功”的。但当我查看他们的实际故障处理记录时，发现过去两年共发生12次真实故障，平均恢复时间比演练RTO高出2.5倍。
为什么演练数据和真实数据差距这么大？我访谈了他们的运维团队，发现三个问题。
第一个问题：演练场景过于理想。他们演练的故障场景都是“单一服务器故障”，但真实故障往往是“存储故障+网络抖动+应用层报错”的复合场景。演练场景的设计没有基于真实故障数据，导致演练的“难度系数”远低于真实情况。
第二个问题：演练数据被“取巧”了。演练时，运维人员知道演练开始时间，知道故障类型，甚至提前准备好了备用方案。演练数据是在“全知视角”下采集的，而不是在“未知视角”下采集的。真实故障发生时，没有人提前知道，数据也会完全不同。
第三个问题：演练数据没有用于改进。每次演练结束后，报告写完了，问题列出来了，但没有人去跟踪改进项的完成情况。下一次演练时，同样的故障场景，同样的恢复时间，同样的报告格式。
这三个问题本质上是同一个原因：演练数据没有被当作“能力评估数据”来对待，而是被当作“合规证明数据”来对待。企业做演练是为了通过审计，而不是为了提升真实的恢复能力。数据驱动的演练，核心目标是打破这种“合规导向”，建立“能力导向”。
我后来建议这家企业做三件事。第一，从真实故障数据中提取演练场景，而不是凭空设计。第二，演练采用“盲测”方式，不通知演练开始时间，用监控数据自动触发演练评价。第三，建立演练数据看板，每次演练后自动生成改进项，并设置下季度演练的“目标差距”。
实施半年后，他们做了两次盲测演练，第一次RTO恢复时间比目标高出40%，第二次比目标高出15%。数据开始真实反映能力差距，管理层也开始重视演练数据而不是演练得分。
在数据分析领域，有一个基本原则：垃圾数据产生垃圾分析。在业务连续性演练中，这个原则同样适用。我总结了三个最常见的、用错数据的误区。
这是最普遍的错误。很多企业把“演练通过率”作为衡量业务连续性能力的核心指标，甚至写入KPI。但我在前面已经用真实案例说明，演练通过率越高，真实恢复能力反而可能越差。原因很简单：演练通过率衡量的不是恢复能力，而是演练脚本的完成度。如果演练脚本本身设计得不够有挑战性，通过率100%不代表任何能力。
我建议的做法是：不要用“通过率”作为核心指标，改用“目标达成差距”。差距越小，说明能力越强。差距越大，说明需要改进。差距的计算方式很简单：真实恢复时间除以目标RTO，得到一个比值。比值小于1说明达标，大于1说明不达标。但更重要的是看趋势，连续三次演练的差距是否在缩小。
RTO和RPO是业务连续性演练中最重要的两个指标。但很多企业只关注RTO，忽视了恢复质量。我见过一个案例：某企业为了在演练中达到RTO目标，用了“快速恢复方案”，直接切换到一个没有数据同步的备用系统。系统恢复时间确实达标了，但备用系统上的数据是三天前的，RPO（恢复点目标）完全失控。最终，RTO指标漂亮，但业务连续性实际上没有保障。
所以，在做数据分析时，必须同时关注RTO和RPO，并且要加上一个“恢复质量指标”。恢复质量指标可以包括：数据一致性检查通过率、业务功能可用性比例、用户访问响应时间等。这些指标组合在一起，才能全面评估演练的真实效果。
大多数演练数据采集只关注“系统”的指标：CPU使用率、内存占用、网络延迟、数据库连接数。但业务连续性演练中，人是最不确定的因素。我参与过一个金融企业的演练，系统恢复在15分钟内完成了，但恢复后的业务验证花了45分钟，因为负责人不知道验证流程是什么，需要临时打电话问。这个45分钟没有出现在任何演练报告中，因为验证阶段的数据没有被采集。
解决这个问题的方法是：在演练数据采集框架中加入“人员响应时间”和“决策时间”指标。比如，从故障发生到第一责任人响应的时间、从识别故障到决策切换的时间、从恢复完成到业务验证完成的时间。这些数据比系统指标更能反映真实能力。
基于我过去几年的经验，我总结了一套数据驱动的演练评估框架。这套框架分为四个层次：数据采集层、指标计算层、分析评估层、改进闭环层。每个层次都有具体的判断逻辑和操作要点。
数据采集是基础。我建议在演练脚本中定义至少三个数据采集节点：故障注入节点、恢复执行节点、业务验证节点。每个节点需要采集的数据包括：时间戳、状态码、操作人、操作时长、异常记录。如果条件允许，建议使用自动化采集工具，避免人工录入导致的偏差。
有一个关键点需要注意：数据采集的粒度要足够细。比如，一个恢复流程分为“故障识别-故障上报-决策切换-系统恢复-数据校验-业务验证-用户通知”七个步骤。每个步骤单独采集数据，而不是只采集一个总时间。这样，后续分析时才能定位真正的瓶颈环节。
指标计算层负责将原始数据转化为可评估的指标。我建议建立三个维度的指标体系：
每个指标都需要设定一个“基线值”和一个“目标值”。基线值来自历史演练数据或正常运行数据，目标值来自业务连续性目标。演练结束后，计算每个指标的实际值，并与基线值和目标值对比，得出差距分数。
分析评估层是整个框架的核心。我建议使用“差距分析”方法，而不是“通过/不通过”的二元判断。差距分析的核心是：找出当前能力与目标能力之间的差距，并量化差距的大小和原因。
具体操作步骤：
这种方法的好处是，每次演练都能看到能力的变化趋势，而不是“这次通过/下次不通过”的简单状态。
最后一个层次是改进闭环。数据驱动的演练评估，最终目的是推动能力提升。所以，每次演练结束后，必须生成一个“改进项清单”，并设置明确的负责人、完成时间和验收标准。
我建议的做法是：将改进项分为三类。第一类是“立即修复项”，需要在下一次演练前完成。第二类是“计划优化项”，需要在下个季度内完成。第三类是“长期建设项”，需要纳入年度规划。每次演练复盘时，先检查上一轮改进项的完成情况，再评估本轮演练的能力变化。
我在2023年帮助一家金融科技公司实施了数据驱动的演练评估框架。这家公司有核心交易系统、风控系统、用户管理三个子系统，每月进行一次容灾演练。我记录了他们在实施框架后的三次演练数据，正好可以展示数据驱动的效果。
第一次演练，我们没有做任何干预，只是帮他们建立了数据采集框架。演练结果出来之后，管理层非常震惊。核心交易系统的RTO达成率只有60%，目标RTO是15分钟，实际恢复时间是25分钟。差距最大的环节是“决策切换”，这个环节耗时12分钟，占整个恢复时间的48%。原因是，决策流程需要运维主管、技术总监、风险审批官三个人签字，而演练时三个人分别在不同的地方，电话沟通花费了大量时间。
这个数据在之前的演练中从未被暴露过，因为之前只统计总耗时，不统计分环节耗时。我建议他们将决策流程改为“预授权+自动通知”模式，演练时不需要等待审批，只需要事后补签。这个改进项在两周内完成。
第二次演练是一个月后。这次演练的重点是验证决策流程改进的效果。结果显示，核心交易系统的RTO恢复时间从25分钟降到18分钟，其中决策环节耗时从12分钟降到3分钟。RTO达成率从60%提升到85%。但这次演练也暴露了一个新问题，风控系统的数据一致性检查通过率只有70%，低于目标值95%。原因是，风控系统的备用数据同步存在延迟，演练时切换后，数据还没有完全同步。
这个发现验证了“只看RTO不看质量”的误区。如果只关注RTO，这次演练的得分是85%，看起来不错。但加上数据一致性指标，实际能力并没有达标。我建议风控团队优化数据同步机制，并设置一个数据同步的自动校验节点。
第三次演练是第三个月。这次演练的综合数据明显改善。核心交易系统RTO达成率95%，RPO达成率100%，数据一致性检查通过率98%。人员响应时间从平均8分钟降到4分钟，决策时间从3分钟降到1.5分钟。更重要的是，改进项的落地率从前两次的60%提升到85%。
三次演练的数据变化清晰地展示了数据驱动演练评估的价值：不是通过一次演练提高能力，而是通过数据闭环让能力持续提升。
数据驱动的演练评估框架不是一刀切的方案。不同企业、不同阶段、不同资源条件，需要不同的实施策略。我根据自己服务过的企业类型，总结了三种常见情况下的行动建议。
如果你的企业只有几十人，没有专职的运维团队，也没有预算购买专业的演练监控工具，怎么办？我的建议是：从Excel开始。
具体做法：在演练脚本中手动记录每个步骤的开始时间和结束时间，演练结束后汇总到Excel表格中。计算每个步骤的耗时、总耗时、与目标RTO的差距。不要追求自动化，先追求“有数据”。
重点关注的指标：总耗时、耗时最长的步骤、人员响应时间。这三个指标足以覆盖80%的改进方向。
需要取舍的地方：不要追求精细化的数据采集。小型企业的人力有限，如果花太多时间在数据采集上，反而会影响演练执行。先保持“每月一次演练、每次一份Excel报告”的节奏，持续三个月后，再考虑引入自动化工具。
中型企业是数据驱动演练评估框架的主要受益者。这类企业通常有运维团队，有监控系统，但数据分散在不同的工具中，日志系统、监控平台、ITSM系统、演练报告。数据不打通，导致分析效率低，很多数据被浪费了。
我的建议是：建立一个演练数据看板，整合所有数据源。可以使用BI工具（如帆软BI、Power BI、Tableau等），将不同系统的数据接入同一个看板。看板的核心视图包括：演练总览、环节耗时分布、指标达成率、改进项跟踪。
重点关注的指标：时效性指标、准确性指标、效率性指标全部覆盖。但优先级顺序是：时效性 > 准确性 > 效率性。
需要取舍的地方：不要试图一次覆盖所有子系统。先选择核心业务系统（如交易系统、订单系统），建立数据采集和分析的标准流程。验证可行后，再扩展到其他子系统。一步到位往往会导致项目失败，因为数据源太多、协调成本太高。
大型企业通常有合规审计要求，演练数据需要满足监管标准。这类企业面临的最大挑战是：如何在满足合规要求的同时，实现数据驱动的能力提升。
我的建议是：在合规框架内，叠加数据分析层。合规要求的数据（如演练记录、恢复时间、签名确认）保持不变，继续用于审计。在此基础上，增加一套“管理数据”，用于内部能力评估。管理数据包括：环节耗时、差距分析、改进项跟踪、趋势对比。这两套数据并行运行，互不干扰。
重点关注的指标：所有指标都需要保留，但需要区分“合规指标”和“管理指标”。合规指标用于对外报告，管理指标用于内部改进。
需要取舍的地方：不要为了数据分析而修改合规流程。合规流程是经过审计认可的，修改成本高、风险大。最好的做法是，在合规流程的“数据采集环节”插入自动化采集工具，不改变流程，只提高数据采集的精细度。比如，合规流程中要求“记录恢复开始时间和结束时间”，你可以在这个基础上，自动记录中间每个步骤的耗时，而不需要改动合规流程本身。
数据驱动的演练不是免费的。它需要投入时间、人力、工具和预算。在有限的资源下，你必须做出取舍。我根据自己的经验，总结了三个关键取舍点。
数据采集越精细，演练效率越低。每增加一个数据采集节点，就需要多一个操作步骤，多一个记录动作。如果数据采集节点太多，演练本身可能被拖慢，甚至影响演练的“真实性”。
我的判断是：演练效率优先于数据完整性。演练的核心目标是检验恢复能力，而不是收集数据。数据是在演练过程中自然产生的，不应该为了数据而影响演练。所以，我建议每个演练场景的数据采集节点不要超过10个，确保演练流程不会因为数据采集而中断。如果某个环节的数据采集会影响演练效率，就放弃这个数据点，用事后分析替代。
自动化数据采集工具（如监控平台、自动日志采集）可以大幅提高数据准确性和效率，但也会降低灵活性。自动化工具只能采集预设的数据点，如果演练中出现了预期外的异常，自动化工具可能无法捕捉。
我的判断是：在核心数据上坚持自动化，在边缘数据上保留人工记录。核心数据是指RTO、RPO、环节耗时等关键指标，这些数据必须通过自动化工具采集，确保准确性和一致性。边缘数据是指演练中出现的异常操作、人员行为、环境变化等，这些数据可以通过人工记录或事后访谈补充。自动化工具做“标准化采集”，人工记录做“异常捕捉”，两者互补。
很多企业认为，演练数据越多越好，最好能从过去几年的演练数据中提取趋势。但历史数据有一个问题：数据口径不一致。不同年份的演练场景不同、指标定义不同、数据采集方式不同，直接对比可能会导致错误结论。
我的判断是：重视实时数据，谨慎使用历史数据。如果你要建立数据驱动的演练评估框架，建议从当前开始，定义统一的数据口径，采集新的数据。历史数据可以作为参考，但不要作为决策依据。至少积累六次演练（大约半年）的数据后，再开始分析趋势变化。在数据口径统一之前，历史数据只是“参考值”，不是“基准值”。
我参与过很多演练复盘会，最让我无奈的一幕是：会议结束后，大家握手告别，演练报告被归档，下一次演练依然是同样的流程、同样的结果。数据没有被用来做决策，只是被用来做记录。
业务连续性演练的本质不是“测试”，而是“学习”。每一次演练都是一次学习机会，让我们知道当前恢复能力的上限在哪里、瓶颈在哪里、改进空间在哪里。数据是实现这个目标的工具，不是目的本身。
所以，我的最后一个建议是：不要做“数据分析”，做“数据决策”。当你看到演练数据时，不要只问“数据说了什么”，要问“数据告诉我下一步该做什么”。如果数据告诉你RTO达成率只有60%，那么下一步就是优化决策流程。如果数据告诉你人员响应时间太长，那么下一步就是建立应急响应通知机制。数据不是用来解释的，是用来行动的。
你现在就可以做一件事：下一次演练时，多带一个数据记录员，多带一个Excel模板，多带一个“差距分析”的思路。演练结束后，不是写一个“成功”报告，而是写一个“差距”报告。差距在哪里，改进就从哪里开始。数据驱动的演练评估，从这一次开始。
我最近负责公司的一次业务连续性演练，发现大家只盯着RTO和RPO，但演练结束后复盘时，还是说不清问题出在哪。比如系统恢复时间达标了，但业务数据丢了更多；或者RPO看起来没问题，但恢复后的数据一致性很差。到底该测哪些数据指标才能真实反映恢复能力？
你踩过的坑我全踩过。第一次带演练时，我盯着RTO倒计时看，系统恢复用了18分钟（目标20分钟），兴高采烈宣布通过。结果财务部门发现当日订单表单里缺失了3笔交易记录，因为数据库恢复时只回滚到最近一次全量备份，增量日志却没完全应用。我的教训是：除了RTO和RPO，必须加三类指标。
第一类：数据完整性指标。比如“数据丢失条目数”或“字段校验失败率”。我们后来在演练中插入一个已知的测试记录（比如单号TEST-001），恢复后对比该记录的字段值是否正确。若错误率超过1%，就算RTO达标也要判为失败。第二类：服务降级比例。演练中允许部分功能降级，但必须量化。
比如核心交易功能可用，但报表导出功能延迟超过5秒，则算半降级。我们设阈值：降级服务数不超过总服务数的10%。第三类：人员响应时间。记录从故障通知到第一责任人确认的时间。我们曾发现网络组实际响应比规定慢了8分钟，但仪表盘显示“正常”，因为手动确认按钮被误触。
所以后来强制要求日志自动记录时间戳，不与人工确认挂钩。
另外，分享一个表格：
| 指标类型 | 示例指标 | 阈值 | 采集方式 |
|---|---|---|---|
| 数据完整性 | 记录丢失数 | 0 | 事前插入测试数据，事后比对 |
| 服务降级 | 响应延迟>5s的服务占比 | <10% | APM工具自动采集 |
| 人员响应 | 首次确认时间 | <2分钟 | 日志时间戳 |
建议：演练前先定义好这组指标，并写进“演练数据采集清单”，否则复盘时全是主观判断。
我们公司做了一次核心数据库切换演练，监控系统显示内存使用率飙升到95%，警报响个不停，但实际演练并没出问题。后来才发现是演练脚本中一个dump操作触发了临时内存暴涨，但这不是故障。每次演练都有大量类似“假信号”，怎么用数据把真故障和演练噪音区分开？
这个问题我花了三次演练才搞明白。第一次，我看到CPU飙升，直接叫停演练，结果发现只是监控脚本同时跑了一个定时任务。第二次，我吸取教训，把所有演练操作都手动记录在Excel里，但复盘时根本对不上时间戳。我的做法是：在演练前构建一个“基线参考窗口”。
具体步骤： 1. 采集过去一周同一时段（比如周二下午2点-4点）的正常运行时指标，包括CPU、内存、IOPS、网络延迟的均值与标准差。2. 演练开始时，将实时数据与基线对比。如果偏差超过3倍标准差，才标记为“潜在异常”；若偏差在1倍标准差以内，视为正常波动。
同时，让演练脚本在每次关键操作（如切换、备份、停止服务）时自动向日志写入“演练事件标记”，比如时间戳+操作类型。这样在监控仪表盘上叠加一条事件时间线，一眼就能看出哪些指标变化是脚本导致的。
案例：我去年做数据库灾备演练，内存使用率突然从45%跳到82%，但基线是40%-55%，且事件标记显示此时正在执行“增量日志应用”，所以判定为正常操作，继续演练。而网络延迟从2ms上升到200ms，且无对应事件标记，最终发现是防火墙策略误触发。关键：不要相信人工记录，必须让脚本自动打标记。
如果你用开源工具，可以在Ansible或Shell脚本末尾加一条curl命令向监控系统发送一个自定义事件。
每次演练结束，我们收集了一大堆日志、指标截图、操作记录，但复盘会上大家各说各话：运维说“网络稳定”，开发说“代码没bug”，业务又说“数据有问题”。到底该怎么从数据中找出真正的瓶颈？我试过鱼骨图，但感觉太虚。
我过去也陷入过“数据越多越迷茫”的陷阱。后来我总结了一套“三层过滤法”，每层只回答一个具体问题。第一层：达标性过滤。将演练数据与预设阈值对比，列出所有未达标的指标。比如RTO超了、RPO差了两分钟、数据完整性丢失了3条记录。这一步是筛选出“有问题”的环节，而不是把所有数据摊开。
第二层：时间线对齐。将未达标指标的时间戳与演练事件时间线叠加。比如RTO超标发生在第18分钟，但事件标记显示第15分钟才执行“数据同步”操作，说明同步动作滞后。此时把日志中该阶段的所有操作耗时排序，找到耗时最长的步骤。第三层：根因定位。针对最长耗时步骤，进一步拆分微操作。
比如“数据同步”步骤包含“全量备份传输”、“增量日志应用”、“校验”。用微秒级日志分析哪个子步骤的耗时占比最大。我们曾发现“增量日志应用”里有个I/O等待占了70%，原因是磁盘队列深度设置过小。举个例子：一次演练中RTO目标20分钟，实际28分钟。第一层发现超时。
第二层对齐时间线，发现“应用切换”步骤耗时最多（15分钟）。第三层拆解该步骤，发现“停止旧服务”用了5秒，“启动新服务”用了3秒，但“切换DNS”用了14分钟，因为DNS解析缓存刷新策略配置错误，导致等待TTL过期。整改后该步骤缩短到2分钟。建议：复盘报告不要列所有指标，只列三层过滤的结果。
我每次给管理层汇报时，只用一张图：左边是三层过滤漏斗，右边是根因和整改措施。这样决策者一眼就能看懂该做什么。
我们公司只有几十人，IT团队就三个人，没有钱买Zabbix或Splunk。但老板要求每季度做一次业务连续性演练，并且要拿出数据报告。我目前只能用Excel记录所有操作时间和结果，但复盘时发现数据很乱，经常对不上。想知道Excel到底能不能撑起演练数据分析，有哪些坑？
完全可以，但必须建立一套模板，否则数据会越记越乱。我帮一家70人的贸易公司做过，他们连监控都没有，最后用Excel+日志文件跑了三次演练，数据质量足够支撑改进。我的经验分成三步： 第一步：准备三个Excel工作表。- 表1：演练计划清单，包含演练场景、预期RTO/RPO、参与人员、脚本步骤。
时间戳精确到秒，格式统一为“YYYY-MM-DD HH:MM:SS”。操作人用拼音缩写，不要在单元格里写中文描述。异常标记用“Y/N”布尔值。这样后期用VLOOKUP或数据透视表才能快速聚合。第三步：利用Excel的“模拟分析”功能做假设推演。
比如记录下每次演练的“故障注入时间”和“恢复时间”，用散点图拟合趋势线，预测下次演练可能达到的RTO。我们曾通过这个发现，随着数据量增长，恢复时间呈线性增长，提前预警了扩容需求。避坑提醒： – 不要手动输入时间，按下Ctrl+Shift+;（分号）插入当前时间，避免打字误差。
我常用柱状图对比多轮演练的RTO，再加一个雷达图展示完整性、响应速度、资源损耗等维度。不需要花钱买工具，关键是数据采集的规范。
上一篇：数据分析之漏洞管理 – 修复周期
读者评论
文章提到的“事后补数”问题太真实了，我们团队每次演练都是结束后翻日志写报告，数据颗粒度粗，还经常美化。审批等待时间这种瓶颈从没在报告里出现过，但实战中恰恰是它拖了后腿。建议所有运维团队都按文章建议，在演练脚本中嵌入自动采集节点，让数据实时说话。
作为管理者，过去只盯着演练通过率，觉得达标就万事大吉。看了文章才明白，通过率越高反而可能掩盖真实能力的短板。差距分析比二元判断更有意义，下一步我准备推动盲测和基于真实故障的演练场景，让数据真正反映能力差距。
文章的数据框架非常实用，尤其是把人员响应时间和恢复质量纳入指标体系。很多企业只关注RTO，却忽略了RPO和业务验证时间，结果恢复后业务依然不可用。数据分析师应该从演练设计阶段就参与进来，用结构化数据驱动持续改进，而不是事后补一份漂亮的报告。
合规导向的演练确实是普遍现象，我们公司过去也是为应付审计，演练场景过于理想，数据取巧，改进项无人跟踪。文章建议的“从真实故障数据提取场景”和“建立改进闭环”是根本解决之道。演练不是表演，而是压力测试，必须让数据来评估真实能力。
作为审计人员，我们通常只检查演练报告是否签字齐全、指标是否达标。但文章指出数据失真问题，提醒我们要关注数据采集过程而非结果。未来审计应要求企业提供实时采集的原始数据记录，而非人工汇总的美化版本，这样才能真正评估业务连续性能力。