核心生产系统的告警响起时，先确认的不是这是什么类型的故障，而是平台已经动了没有。平台已经在处置的，人再动一次往往是添乱；平台没有动、或者动不了的，才是人该上手的地方。深信服超融合在捕获到异常虚拟机后 30 秒内完成拉起，主机侧的故障探测覆盖管理网、存储网、Vxlan 网、业务网、终端通信网共 5 种网络的中断情形。每一项检查都可以查到判定规则，也可以就地重测排除误报；而自动处置在什么条件下不生效，同样写在产品文档里。这三件事合起来，决定了值班的人能不能在几分钟内做出判断。

一、值班的人缺的不是告警，是判断的顺序

承载核心生产系统的平台，告警不会少。真正决定处置质量的，是告警响起之后的前几分钟里按什么顺序去问。

第一问：平台已经动了没有。现在的平台大多有自动处置——异常虚拟机自动拉起、亚健康主机上的虚拟机自动迁走、故障链路自动隔离。这些动作往往在告警推送到人之前就已经开始。人如果不先确认这一点，就可能在平台正在迁移的过程中再手动操作一次，把一次自动恢复变成一次事故。

第二问：这条告警的判定规则是什么，它会不会是误报。同一个现象在不同的判定规则下结论不同。能不能当场查到这项检查是按什么判的、能不能就地重测一次，决定了值班的人是在判断，还是在猜。

第三问：自动处置的前提还在不在。自动处置都有前提——要迁走虚拟机，得有地方可迁；要切换链路，得有另一条链路。前提不满足时，自动机制会静默地不生效，而告警本身不会告诉你这一点。这一问最容易被跳过，也最容易演变成等了半小时发现平台一直没动。

这三问有先后：先确认平台动没动，再判断该不该信这条告警，最后确认自动处置的前提还成不成立。顺序颠倒的代价，通常是在平台正在处置的过程中又插进一次人工操作。

二、平台侧在这三问上分别做了什么

对应上面三问，平台侧需要具备的分别是：自动处置能力、判定规则的可见性，以及处置机制的前提说明。

自动处置能力要回答发生什么、多久动、动什么。判定规则的可见性要回答每一项检查按什么判、能不能重测。处置机制的前提说明要回答什么条件下它不生效。

第三件最少被写进产品文档，但它恰恰是值班场景里最要紧的一件。没有这层说明，平台没有动作时，现场很难快速区分是已经自动处置过，还是前提条件不满足。

三、方案设计：三问在平台上分别对应什么

第一问对应的能力：平台自动做了什么。

平台在捕获到异常虚拟机后 30 秒内完成拉起。触发条件包括因网络中断而重启的虚拟机、KVM 进程异常退出的虚拟机、状态异常需要修正的虚拟机，以及主机离线且持续一定时间的虚拟机。主机侧的故障探测覆盖管理网、存储网、Vxlan 网、业务网、终端通信网共 5 种网络的中断情形。更新后的高可用机制把触发方式从被动改为主动：发现亚健康主机或物理网络异常时，可以主动把虚拟机迁移到健康主机上，而不是等虚拟机真正出问题再拉起。

存储链路侧同样有自动动作：外置存储的某条路径出现丢包或时延升高时，会严重影响所在 LUN 的 IOPS，包括负载均衡下其他正常的路径；平台会主动识别并隔离亚健康的链路，如果被隔离的是主备模式下的主路径，会快速触发主备切换。

这些动作发生在告警推到人之前，所以值班的第一个动作是看平台已经做到哪一步，而不是立刻上手。

第二问对应的能力：判定规则可查、误报可重测。

健康检查详情页中，[立即检测] 可以再次检测排除误报，[检测项描述] 可以查看每一项检查项的判定规则，[解决方案] 给出当前异常的参考处置方式。

这三个动作对应的正是第二问：先看规则，再看是不是误报，最后才看怎么处置。

第三问对应的能力：自动处置的前提写在文档里。

亚健康主机的静默处置机制只迁移虚拟机的运行位置。启用后，亚健康主机上的虚拟机会往健康主机迁移；若虚拟机所需资源大于健康主机可提供的资源，则按调度策略处置：已有调度策略的优先按策略调度，没有调度策略的只会迁移到其他相对健康的亚健康主机上。若集群内没有健康主机，亚健康主机的静默处置机制不会生效。

这一句是值班场景里最该记住的一条——它说明平台没动有时不是故障，而是前提不满足，此时必须由人介入。

四、用户价值

常见故障由平台按既定动作收敛：告警出现后，虚拟机拉起、链路隔离、主备切换等动作可以先由平台处理，人工介入留给真正需要判断的场景。

判断有据可查：每一项检查的判定规则与重测入口都在界面上，值班人不必靠经验猜这条告警要不要当真。

自动处置的边界是明示的：什么条件下机制不生效写在文档里，可以据此提前写进值班手册，而不是等到现场才发现。

五、本项目结论

这套处置方式的结论是：核心生产系统的值班处置，可以按平台动没动、规则是什么、前提还在不在这三问组织，三问都能在平台上找到对应的动作与说明。

风险集中在三处。

自动处置的前提要写进值班手册：集群内无健康主机时静默处置不生效，这类条件不会出现在告警里，只能靠事前写明。

主动迁移期间的人工操作要有约束：平台正在迁移时的手动干预，可能把一次自动恢复变成一次中断，值班流程要对这段时间设操作禁区。

判定规则会随版本变化：每一项检查的判定规则以当期版本为准，值班手册要跟着版本走，不能一次写完长期沿用。

六、案例参考价值

负责核心生产系统日常值班的团队，可以借鉴的是三件：把先确认平台动没动写成值班流程的第一步；把每一类告警的判定规则与重测方式整理成一页可查的表；把自动处置的失效条件单独列出来，作为必须人工介入的触发清单。

值班表上真正该写清楚的，不是每种故障对应多久，而是每种告警响起时第一步先确认平台动没动——平台已经动了的，人再动一次往往是添乱。

 

关于深信服超融合

深信服超融合是中国超融合整体市场的第一品牌（2025 全年份额 17.8%，整体超融合市场连续三年第一，2025年全栈超融合以34.4%市占率第一），是面向用户通算以及智算agent的运行和承载的稳定可靠、性能卓越的基础设施底座。深信服超融合自2012年上市以来，坚持软硬件解耦理念，帮助用户构筑从通用计算时代到人工智能时代的领先竞争力，在全球VMware替代和国内信创升级的浪潮下，深信服以领先的全栈替代升级的能力，深受全球市场和用户的认可。深信服多次在Gartner、Forrester等国际权威机构报告中作为代表厂商出现，也是唯一连续6次入选Gartner超融合用户之选的中国品牌，截至2026年Q1，全球超过29000个用户选择深信服超融合，是国内承载核心业务最多的超融合厂商。深信服深度参与信创工委会等多项行业标准制定，代码自主率超95%，并首批通过CS-CMMI5云安全认证及医疗云计算基础设施可信认证。

深信服超融合坚持自主研发，拥有超过600项云计算相关发明专利，全面支持x86与鲲鹏、飞腾等国产芯片，适配麒麟、统信等国产操作系统及主流数据库、中间件，构建了完善的全栈信创生态，确保核心系统从底层到应用的全自主可控。

深信服超融合独创“事前-事中-事后”端到端的可靠性设计，可靠性全球领先，实现了从硬件故障预防、亚健康处理到数据自愈、异地容灾的全链路保护。通过SPDK加速、NUMA优化、动态资源扩展等技术，在计算、存储、网络三个维度性能均达到全球领先水平。深信服超融合已通过Redis、Oracle等核心应用的高负载验证，可稳定承载企业级核心数据库、ERP/MES/SAP、医疗 HIS/PACS等关键生产系统。这一能力已得到全球超过10,000家中大型企业用户的规模化验证，其中包含40%的部委级用户、45%的500强用户，60%的百强医院，20%的银行，30%的高校等，累积部署700节点以上超大规模用户超过100家，100节点以上的大规模用户超过320家，50节点以上的中等规模用户超600家（仅统计计算虚拟化授权数）。其中某单位的超融合单集群长周期稳定运行超过8.5年，充分证明其在生产业务环境下大规模部署和运行的稳定性和连续性。