账号生命周期：入职开通离职回收

去年审计，查出一个离职三个月的员工账号还能登录报销系统。人走了，流程没走完，IT 那边没收到通知，账号就一直在。同一份审计报告里还有另一条：当月入职四十人，账号平均三点二天才开齐，有人头两天用同事的账号提了单据。

这两件事根子上是一件事：账号是手工建的，也是手工停的。手工建就有延迟，手工停就有遗漏，而遗漏的那一个恰好是很容易被利用的。

后来我们把账号改成由人事主数据推导：入职事件生成账号，调岗事件换权限，离职事件停用并转交。这篇讲三件事：账号该按什么推导、同步配置怎么写、离职回收为什么不能直接删。结论前置：账号的生命周期要挂在人事事件上，不能挂在人的记忆上。

一、账号是推导出来的，不是建出来的

1.1 从人事事件出发

人事系统里有三种事件和我们相关：入职、调岗、离职。每种事件带一组字段，员工号、姓名、部门、岗位、职级、上级、办公地点。这组字段足以决定一个人该有什么账号、该进哪些角色。

我们不再让部门在 OA 里提“开通账号申请”。申请单的本质是把人事事实又抄了一遍，抄的过程中会错、会漏、会慢。人事系统已经是事实来源，再抄一次没有意义。

例外只有两类：外包和实习。这两类人不在正式编制里，人事系统可能没有记录，我们保留手工开户通道，但要求填用工起止日期，到期自动停用。

1.2 权限挂在岗位上

一个人能看什么，取决于岗位，不取决于他自己。这条说起来是常识，落地时却经常被绕过：某人临时帮忙，单独给他开了两个菜单，半年后他调走了，菜单还在。

我们的做法是角色只按部门和职级两个维度定义，个人不直接挂权限。临时需求走代理，代理有明确的起止时间，到期自动失效。这样一个人调岗时，只需要把他从旧部门的角色里摘出来，挂到新部门的角色上，不用逐条回忆他曾经开过什么。

1.3 三道闸

入职这道闸解决“有没有”，调岗这道闸解决“对不对”，离职这道闸解决“还在不在”。三道闸里，离职这道闸的优先级高于另外两道，因为它对应的是风险，不是效率。

我们给离职设了一个硬约束：离职事件生效当天，账号状态改为停用，不等交接完成。交接期需要看资料，用临时授权，授权到期时间不超过七天，且必须由接手人发起。

二、同步配置怎么写

2.1 先把映射关系列清楚

人事字段和账号字段不是一一对应。员工号可以直接做登录名，姓名做显示名，部门代码映射成组织单元，职级映射成岗位名称。邮箱和手机号是联系字段，可能为空，空的时候不能阻断开户。

映射表要写成配置，不要写进代码。字段改名、部门代码调整这类事情一年总要发生两三次，写死在代码里，每次都要发版。写成配置，改完重启任务就生效。

2.2 配置示例

sync:
  source: hr_master
  schedule: "0 2 * * *"
  batch_size: 200
  timezone: local

account:
  login_pattern: "{employee_no}"
  default_status: active
  force_reset_on_login: true

mapping:
  employee_no: login_name
  name: display_name
  dept_code: org_unit
  job_level: title
  email: mail
  mobile: phone

role_rules:
  - when: {dept_code: "FIN", job_level: "M2"}
    grant: ["fin_approver", "report_viewer"]
  - when: {dept_code: "QA"}
    grant: ["quality_reader"]
  - when: {dept_code: "IT", job_level: "M1"}
    grant: ["asset_operator"]

lifecycle:
  on_hire: [create_account, bind_role, notify_manager]
  on_transfer: [revoke_roles_by_dept, bind_role, keep_account]
  on_leave: [disable_account, revoke_all_roles, transfer_owner]

guard:
  skip_login_prefix: ["svc_", "ext_"]
  on_conflict: report_only
  dry_run: false

配置里有两处容易忽略。skip_login_prefix 是给服务账号和外部账号留的口子，这两类账号不在人事系统里，同步任务不能碰它们。on_conflict 决定同一个人匹配到多条人事记录时怎么办，我们选只报告不处理，因为冲突通常意味着人事数据本身有问题，自动挑一条反而埋雷。

2.3 幂等与差异比对

同步任务必须幂等。同一批数据跑两次，结果要一样，不能重复建号、不能重复发通知。做法是用员工号做唯一键，存在就更新，不存在才创建，角色绑定先算差集再增删。

每次跑完输出一份差异报告：新增几个账号、停用几个、角色变更几条、跳过几条。这份报告比任务成功与否的日志有用得多，因为任务成功不代表结果正确。

同步任务本身不复杂，这块我们放在搭贝的定时任务里跑，凌晨两点触发，跑完把差异报告推到运维群。任务失败会自动重试两次，两次都失败就停在那天，不连续刷。

2.4 失败怎么兜底

同步失败分两种。一种是连不上人事系统，整批没跑，第二天补跑就能自愈。另一种是单条数据有问题，比如员工号为空、部门代码在组织表里找不到，这种要跳过并记入异常表，不能让它卡住整批。

异常表每天有人看，超过二十条就排查。我们曾经因为一个部门改名，导致那个部门三十多个人的角色全部绑定失败，异常表里堆了三十条，第二天上午就发现了。

三、离职回收：停用不是删除

3.1 停用、转交、留档

账号停用之后，人登不进来，但他名下的数据还在。待办要转给接手人，审批中的单据要改派，个人文件夹要归档，这些动作和停用是同一批做的。

删除账号是另一回事，我们放在停用一百八十天之后。删之前要确认三件事：名下没有在途单据、没有作为审批人的流程、没有被其他地方引用为负责人。三件事有一件不满足，就继续停用状态。

3.2 数据归属

单据上的创建人、审批人字段存的是账号 ID，不是姓名。账号删除之后，历史单据上的名字会变成空白，审计就查不下去了。所以我们的做法是账号只停用不物理删除，界面上显示姓名加“已离职”标记。

如果确实要清理，用归档账号：把登录名改成一个不可登录的标记，保留 ID 和姓名，其余字段清空。这样历史数据不断链，账号也不能再用。

3.3 外部账号与共享账号

外部账号指供应商、客户、外包人员的账号。这类账号不归人事管，但同样要有生命周期，靠合同起止日期驱动。合同到期前两周提醒业务负责人，到期当天停用。

共享账号我们原则上不允许，但车间看板、仓库扫码枪这类场景确实存在。对这类账号的处理是：绑定固定设备、限定登录时段、操作日志全量保留，并且每季度由责任人确认一次是否还在用。

四、异常与对账

4.1 每天对三张表

对账不用很复杂，三张表就够：人事在职名单、账号启用名单、角色绑定名单。人事有而账号没有，是漏开；账号有而人事没有，是漏停；角色绑定的部门和人事部门不一致，是漏改。

三张表的差异每天出一份清单，按部门汇总。清单发给各部门的接口人，比发给 IT 有效，因为只有业务知道某个人到底该不该在。

4.2 影子账号

影子账号是那些在账号表里存在、但人事系统里查不到的人。来源通常是历史遗留、测试数据、以及离职后没停用的账号。我们头一次跑对账，扫出七十三个影子账号，其中十九个在过去三十天有过登录。

清理影子账号不能一刀切。先按登录活跃度分组，活跃的先查是谁在用，不活跃的批量停用，观察两周没有申诉再归档。一刀切会误伤外包和设备账号。

4.3 调岗与兼职

调岗是三类事件里很容易出错的。人有两边兼职的情况，人事系统里可能只有主岗位，也可能有两条记录。我们的处理是：主岗位决定账号归属部门，兼职岗位通过代理授权，代理有起止日期。

如果一个人在人事系统里有两条在职记录，同步任务会按员工号合并，取主岗位，另一条记录进异常表让人确认。这一步不做，就会出现同一个人的角色每跑一次同步就翻一次的情况。

五、跑了一年的账

5.1 时长与工单量

账号开通的平均时长从三点二天降到当天，因为同步任务凌晨跑，早上人到了就能登录。账号相关的 IT 工单从每月六十多张降到十二张，剩下的主要是密码重置和设备绑定。

离职账号的停用及时率从百分之七十一升到百分之九十九点六。剩下那零点四不是任务没跑，是人事那边离职日期填错了，这类只能靠对账清单兜。

5.2 没做到的部分

跨系统的账号打通还没做完。现在人事、OA、邮箱是通的，生产系统和设备系统还是各管各的，那两边的账号仍然手工建。原因是老系统的接口太旧，只能导文件。

另一个遗留是权限回收的颗粒度。停用账号时我们是全量摘角色，但有些场景需要保留只读权限给接手人一段时间，现在靠人工开临时授权，做得比较笨。

常见问题

问：人事系统每天全量推一次，还是只推变更？

答：推荐全量推，量小的时候全量更稳。全量的好处是不依赖变更日志，中间漏了一次，第二天自动补上。变更推送效率高，但一旦丢消息，就得人工比对。我们的做法是每天全量，白天再加一次按小时的增量，增量只用于入职当天的加急开户。

问：一个员工有多个岗位，账号权限按哪个算？

答：按主岗位算归属和基础权限，兼职岗位单独走代理授权。不要在账号上叠加两套角色，否则调岗时无法判断该摘哪一套。代理授权的关键是有明确的到期时间，到期自动失效，不依赖人记得去关。

问：账号停用之后，他审批到一半的单据怎么办？

答：停用时同步执行改派，把在途单据转给他的上级或者指定的接手人。改派要记录原审批人和新审批人，审批记录里两条都保留。不建议直接把单据退回发起人，那会让流程从头再走一遍，业务上通常不能接受。

问：同步任务把角色绑错了，怎么回滚？

答：靠差异报告。每次同步都记录角色变更的前后值，出问题按批次回滚，把这一批的变更反向执行。前提是角色绑定表要有变更日志，没有日志就只能靠备份恢复，粒度是整个库，代价太大。