北京
服务器还在跑，数据也恢复了，业务却未必能继续运转。这个落差正在逼企业重新理解"韧性"二字。
InfoScale 高级副总裁兼总经理布尚·塔卡尔（Bhooshan Thakar）把问题说得很直白：传统灾备一次只保护一个组件——服务器、存储、网络，各管各的。攻击者用 AI 把攻击规模放大，企业又把自动化嵌进关键流程，这套按组件修补的思路就跟不上了。
他的原话是："基础设施活下来了，运行状态没有。从业务角度看，核心问题变成：企业还能不能有把握地继续运营？"在他看来，韧性归根到底是维持对运行状态的信任。
塔卡尔是在 theCUBE 的直播访谈中讲这番话的，主持人是克里斯塔·凯斯（Krista Case），场合为 AI 网络安全与韧性峰会。访谈主题是：为什么静态的灾备预案在动态的 AI 环境里会失效。
从"恢复"转向"运行中"
变化的速度本身就是问题的一部分。过去企业每半年做一次计划内切换演练，现在为了应对安全威胁，关键业务应用的补丁按天或按周打。塔卡尔说，AI 还在加快这个循环。InfoScale 的母公司 Cloud Software Group 已在 6 月加入 Anthropic PBC 的 Project Glasswing，用 Claude Mythos Preview 模型做安全工作。
他对停机这件事的判断也变了："过去，中断或停机是'如果'而不是'何时'的事件。今天不是'如果'，是'一直'。"意思是，无论计划内还是计划外，都必须始终为中断做准备。
公有云则带来一种虚假的安全感。应用负责人常以为云服务商替自己兜住了韧性，但业务应用是多层堆栈，层与层互相依赖。塔卡尔指出，任何一层失效或数据损坏，业务就停了，哪怕基础设施那边报告一切健康。
"如果真去看细则，云服务商保证的是云的韧性，而云里的韧性是你的责任，也就是应用负责人的责任。"他说，"你最终要看的是业务有没有韧性，而不是堆栈里某个组件有没有韧性。"
预防会漏，恢复太慢
这个判断决定了 InfoScale 的做法：韧性平台不该只在故障发生后动作，而应与在线应用并行运行，跟踪依赖关系、运行状态和数据完整性；实时复制加上不可篡改的检查点，让团队能快速回到一个可信的良好状态。
塔卡尔还点出过去十年投入的结构性缺口："买家的预算花进了两个孤岛：预防，在安全侧；恢复，在备份和基础设施侧。说穿了，预防是有漏洞的，恢复是太慢的。"
度量方式也得换。停机如今除了财务损失和客户流失，还带来监管风险。他建议别再盯"恢复一台虚拟机要多久"，改测"在真实中断进行中，多久能完成第一笔经过验证的干净业务交易"——这个指标把运行韧性和业务结果绑在一起。
他描述了自己与首席信息安全官、首席信息官交流时的变化：这些人不再问厂商"我出故障后你多快能恢复我的数据"，"那是昨天的问题"；他们问的是"你的平台如何保证我的关键应用或业务在中断进行中一直跑着"。
服务器活着不等于业务活着，这道缝，正是他想让企业先看见的地方。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
