总部和分部，策略谁定、谁签发

结论先行："总部统一制定策略、分支分级运营"这句话，听起来是一个部署架构，落到执行上其实是三份明确的约定：分支的资产由谁登记、分支的例外由谁批准、网络断开时分支按哪一套规则跑。这三件事不定，统一管控就会演变成一种局面——平时总部说了算，出事总部担责，而分支的具体情况总部并不掌握。

统一的两个意思，先分清

统一管控在采购需求里常常是一个词，但在产品上对应两件不同的事。

• 一套策略——全集团用同一套规则模板，分支不另立标准。它的好处是口径一致、审计简单；代价是分支的特殊业务会被硬套。
• 一个视图——分支各有一套落地细节，但总部能看到全部资产、全部告警、全部合规状态。它的好处是贴合现场；代价是口径要额外做归一。

多数集团实际需要的是两者的组合：底座模板统一，例外登记在册，总部看得到例外。这就是"多级租户"这类设计真正要解决的问题——不是把权限分成几层好看，而是让每一层都知道自己管什么、上报什么。

分支的资产，谁登记

统一策略的前提是知道有哪些设备。这件事如果只靠总部发一张表让分支填，结果可以预见：填得不全、填完就不更新、新买的机器没人填。

把登记动作绑到流程上，比发文件有效。可行的一条链是：分支采购或上线新设备时，纳管动作作为交付的一部分完成；纳管之后资产自动进入平台台账，台账定期与实际在线情况比对，差异出一份清单回给分支确认。差异清单机制很关键——它把"你漏了"变成"系统发现你漏了"，不需要总部一台一台去问。

还有一类更容易被漏掉的：分支自行采购的设备、部门自建的小系统、临时测试机。这些往往不进采购流程，也就进不了台账。治理它们的办法通常是从网络侧反推——按网段或按接入位置扫一遍，跟台账比对，差出来的就是这批。这件事一个季度做一次就够，但要做。

例外谁批，批完记在哪

统一策略一定会遇到例外。分支说这台老服务器装不了客户端，那台专用了某个旧版驱动不能升级。这些例外如果只在群里说一声就放过去，一年之后总部手上会有一堆说不清来历的白名单。

比较稳的做法是给例外建一张表，三栏即可：谁提的、什么原因、什么时候到期。审批权限放在分支负责人，总部只做一件事——定期看这张表的存量与到期情况。存量突然涨，说明统一模板和现场脱节了；到期没人续，说明这个例外其实已经不需要了。

例外表还有一个隐性价值：它把"合规做不到"从一种难堪转成一个可管理的事实。审计来问为什么这台机器没装防护，答案是"在例外表第几条、原因是什么、什么时候到期"，这比现场解释有说服力得多。

断链时，分支按什么跑

集团网络不是永远在线。专线抖动、分支上联设备故障、区域网络调整，都会造成分支与总部管控端失联。这时候分支的防护还跑不跑、策略还生效不生效，是个必须提前答的问题。

这张表里最容易含糊的是"恢复之后"。断链期间分支在本地改过什么，恢复时如果直接由总部覆盖，分支会不高兴；如果完全不动，两套版本会长期并存。折中的做法是：恢复后先出一份差异清单，逐条确认是采纳总部版本还是保留本地版本，保留的要登记为例外。多花半天，省掉后面半年的口径混乱。

分级运营，切的是责任不是权限

分级运营做得好不好，看一个指标：出了问题之后，事情先落到谁手上。如果落点永远是总部，那分级就没落地；如果分支能自己把常规问题处理掉、只在越过红线时才上升，那才叫分级。

要让这件事发生，权限配置之外还得配两样东西：分支侧要有能看懂告警、能处置常规事件的人；总部侧要有明确的上收清单，写清哪些事必须报、什么时限报。前者靠培训和日常带教，后者靠一页纸的清单。深圳市奇摩计算机有限公司在集团类项目里做这块，通常会把上收清单和例外表作为交付物的一部分，原因也是这两样东西不定，多级架构就只是个界面。

本文只谈集团多级部署中资产登记、例外审批与断链降级三处的责任划分，不谈两地三中心场景下策略该做一套还是两套，也不谈防护能力本身的技术指标。文中流程为通用做法梳理，具体以各单位管理制度与合同约定为准。

多级架构最容易出的问题，不是技术不通，是责任不清。把资产、例外、降级三张表在项目启动阶段就定下来，后面每个分支上线都会顺很多。预约咨询，可以按你的组织层级把这三张表先搭出来。