集团、分支、部门三层管理员，谁能看到谁

结论先行：分级管理员做错的方式高度雷同——把权限拆成了账号，却没拆边界。分级的实质是三条线各自划清：通讯录里看得见谁、组织架构里改得动谁、操作日志里查得到谁。三条线不一起拆，最常见的后果是分支管理员能看到集团全员名单，而集团管理员的操作没人看得见。

本文只谈纵向分几层、每一层的可见与可改范围怎么划，不谈三类管理角色该不该由同一个人担任——那是横向职责分离的事，另一条线上的内容。

先想清楚：分级到底在分什么

一个常见误解是把「分级」理解成「建几个管理员账号，各管一块」。账号建完，事没解决——因为大家默认「管理员就是管理员」，权限按模板发，发出来的是同一套。

真正需要分开的是三样东西，它们对应三个不同的问题：

• 看得见谁：通讯录里能看到哪些人、哪些字段。这一条决定信息暴露面。
• 改得动谁：能改谁的资料、能拉谁进群、能建删哪些部门。这一条决定误操作的影响半径。
• 查得到谁：操作日志能翻到哪一层。这一条决定事后能不能说清。

三层管理员，每一层在这三条上的答案都应该不同。如果三层答案一样，那就不叫分级，只叫多开了几个号。

三层各自该管什么

这张表看着清楚，落地时最容易出问题的是分支层那一行。因为分支管理员往往有实际业务诉求——要跨部门拉人协作、要查某个同事的联系方式。诉求合理，于是「临时放开一下」，放开之后没人收。

可行的折中是：跨分支可见范围放开到姓名和岗位，但手机号、工号这类字段保持隐藏；确需查看的走一次申请，留下记录。这样既不妨碍协作，也不会让一张分支账号变成全员通讯录的出口。

两个最常见的失效

失效其一：分支管理员拿到了全员可见。原因通常不是配置错，是默认值。很多平台建账号时会给一个「管理员」预设权限包，包里带着通讯录全量查看。建号的人图省事直接套用，边界就没了。

检查方法很简单：用一个分支账号登录，翻通讯录，数一下能看到多少人。这个数如果等于集团总人数，就已经失效了。

失效其二：集团管理员自己的操作没人查。分层之后，每层都在看下一层，顶层没人看。日志里记着集团管理员的所有操作，但没有任何角色被赋予查看它的职责。

解决办法不是再加一层管理员——那会变成无限套娃。常见做法有两种：一是把这份日志定期导出，交给不归属该管理员管辖的第三方角色（内审、合规）定期抽查；二是做自动比对，把集团层的高权限操作与变更单号对账，没有对应变更单的自动列出来。

后一种更省人力，前提是变更单号真的存在且被强制填写。这一点在选型阶段就该确认。

三样东西要能随时查

分级之后，日常运维的判断依据就落在三份清单上。这三份要能随时导出来，而不是靠谁记得：

• 当前所有管理员的清单，含所属层级和授权时间；
• 每个管理员账号的可见范围清单，含被单独放开的例外项；
• 高权限操作的记录，可按人、按时间、按操作类型筛。

这三份清单如果在系统里导不出来，只能靠人工整理，那这套分级在头一次人员变动之后就会失真。

管理员离职或轮岗，要交清什么

这是分级体系里最薄弱的一环。普通成员的离职交接有清单可循，管理员往往只在工单里改一句「已回收账号」。

要交清的是三样，缺一样都会留隐患：

三样里前面两样最容易漏，因为它们不是「账号」的一部分，是「账号做过的事」。账号一停用，这两样就查不到了——除非事先有导出机制。

所以这项动作要前移到设计阶段：不是等人走了再想怎么查，而是在建账号时就规定，管理类账号每季度导出一份权限与操作摘要留档。这份东西平时没人看，人员变动时能省掉大量解释。

从哪儿开始

不必一次把三层全铺开。可以先做一步：把现有管理员账号列出来，逐个标注「看得见谁、改得动谁、查得到谁」，标完和上面对照，差异就是待收的口子。

深圳市奇摩计算机有限公司在做协作平台交付时，通常会在开账号之前先把组织架构的层级和可见范围对齐成一张表，三方各确认一次再往下走。这张表比事后调权限省事得多。需要梳理自己的分级边界，可以预约咨询。