结论先行：终端防护产品替换的难点，不在新旧任一方的功能，而在两套东西同时存在的这段重叠期。这个阶段机器上跑着两个采集与拦截组件，它们各自扫描、各自上报、各自处置，冲突迟早会以卡顿、进程反复重启、同一份样本被两次处置的形式出现。可行的做法是在动手之前把三件事定死：谁负责拦截、日志以哪一方为主、卸载按什么顺序走。本文只谈替换重叠期的安排，不谈兼容性矩阵怎么建，也不谈替换完成之后的日常运维。

重叠期为什么比替换本身难

单看每一步都不复杂：旧产品覆盖广、规则成熟；新产品对国产环境适配好、有本地支撑。麻烦在于中间那段——旧产品还没到下线时间，因为还有一批终端没换完系统；新产品已经必须上线，因为合规检查要求覆盖率达到某个数。两套组件同时驻留在一台机器上，问题集中在同一条资源通道上：两套都在做文件实时扫描，两套都在抓进程行为，两套都想在发现威胁时抢先处理。

常见的表现形式有三类。一类是性能：开机变慢、大文件复制卡顿、编译和设计类软件明显掉速。一类是稳定性：组件之间抢同一套内核接口，表现为进程反复重启、蓝屏或者网络短暂中断。一类是结果不可解释：同一份可疑文件，一边判成拦截、一边判成放行，一线看到两条相反的结论，最后谁也不信。

三件事必须在装之前定

其一，谁负责拦截

重叠期如果两个组件都在做主动拦截，冲突概率最高。比较省事的安排是分权：由旧的或新的其中一方承担实时拦截，另一方在这段时间降为仅检测、只记录不处置。这个约定必须写成明确的执行参数，而不是靠策略描述里的「建议」。降为仅检测的一方要提前跟用户侧讲清楚，否则它上报的告警没人处置，反而会把安全团队的信噪比拉低。

其二，日志以哪一方为准

两套组件都产生日志，内容重叠但不完全一致，字段定义也不一样。不做约定的话，重叠期结束时会留下两份互相对不上的历史记录，事后取证时说不清哪份算数。可行的做法是指定一方为这段时间的取证源，另一方只保留原始日志不做二次加工；到切换节点上，再按同一套字段把历史补齐。

其三，卸载按什么顺序走

卸载顺序排错，会出现「先卸的被重新装上」或者「后装的卸不掉」。经验上比较稳的顺序是按依赖关系倒着来：先停掉一方的实时防护、观察一个业务周期，确认没有漏检之后再做卸载清理，最后才动另一方。卸载脚本和旧版本安装包要在动手之前备好——回退的时候现找，往往找不到同一个版本。

四个可观测信号

重叠期不需要每天盯着指标，但下面四类信号一旦出现，就说明这段安排需要重新调整。

  • 双份告警。同一台终端、同一份文件、同一个时间点，两条内容相近的告警分属两个组件。这条信号出现，通常意味着拦截权没有分清楚。
  • 资源占用抬升。同一批终端在替换启动前后的内存与处理器占用出现台阶式上涨，且回不到原水平。这是两个组件同时在跑的直接证据。
  • 同一样本两种处置。需要人工去判断「到底该不该拦」，说明两边规则库对同一类行为的定性不一致，得先把口径统一，再谈覆盖率。
  • 卸载后残留。组件卸载了但驱动、服务或注册项还在，表现为重启后进程又出现。这类残留往往要等下一次系统更新才暴露。

重叠期要多长，怎么退出

重叠期不宜长。太短，验证不充分；太长，两套授权同时付费，用户侧也已经习惯性忽略其中一个的告警。比较可行的划法是以终端批次为单位推进：每批终端在重叠期内完成安装、观察一个完整业务周期、确认没有漏检，然后进入卸载。全部批次走完就是重叠期的结束，而不是按日历定一个截止日。

退出时要留下三份东西：每批终端的替换记录（什么时候装、什么时候卸、谁确认的）、重叠期的告警对照表（哪些是双份、哪些只有一方报）、以及一份残留检查结果。这三份材料在后面做合规自证或者被问题件时，比任何功能说明都有用。

边界与前提

本文讨论的是同一类能力（终端防护）的新旧替换，不涉及不同类型安全组件之间的功能重叠——那是另一个问题，取决于各自管哪一层。

另外两点需要说明。其一，拦截权如何分配，最终取决于客户自己的风险偏好与合规要求，不存在通用答案；本文给出的是一种可操作的分权方式，具体落到哪个组件上要按现网情况定。其二，文中提到的观察周期、批次安排为参考性做法，实际以项目实测与业务窗口为准，不同规模的环境差异较大。

深圳市奇摩计算机有限公司在承接国产化替换类项目时，通常把重叠期单独作为一个阶段排进计划：先定拦截权与取证源，再按批次推进安装与卸载，而不是把两个动作压在同一次窗口里。这一段排好了，后面投诉和返工的量会明显少一截。预约咨询