[博客翻译]离职员工信息系统趣记




在我供职过的大型企业中,普遍存在一种员工信息管理服务,用以记录谁是现任员工,谁已离职。通过定期导出该列表并与其先前版本进行比较分析,往往能洞察到一些有趣的现象。

某一公司内部为此开发了一项名为“墓志铭”的服务,当员工从LDAP系统中“消失”(即离开公司)后一两天,其个人信息便会出现在这一平台上。在职同事可在其页面上添加诸如“重返校园”、“移居爱达荷州”等评论。

这项服务具有一个有趣的副效应:本人无法编辑自己的“墓志铭”,因为根据定义,在个人页面存在之前,你必须已经离开公司。因此,需要其他了解你的人来添加这一信息。我曾收到过这样一封邮件:“我即将离职,请在信息出现时为我添加XYZ内容。”对于他们对我的信任,我感到十分荣幸,几天后,我按照要求将内容粘贴到了相应位置。

另一家公司则没有类似的服务。尽管存在查看员工在职时间的“内部档案”,却没有提供定期更新的功能。于是,我决定自行创建这样的工具。实际上,所需的努力并不多。我在开发服务器(一台位于数据中心且可以访问我的主目录的物理机)上设置了一个cron任务,使其每天执行几次,将整个员工列表导出至文件,并与上次导出的列表进行比较,提取出unix账户名字段,并将结果追加至日志文件中。

随着时间推移,越来越多的同事了解到这一工具的存在,由于我将其设置为全球可读,他们可以通过运行“tail -f <路径>”实时关注变动情况。有时,日间会突然出现令人惊讶的变化——有人悄无声息地离职,有时则是某些奇特的情况为离职事件增添了背景信息。

日志条目格式如下:
2024年2月8日星期四 18:26:42 PST :uid:<某人>

只需看到这样的条目,若你关心为何这位特定员工不再任职于此,便可进一步深入调查;否则,这并不会给你带来冗余无用的信息。

有一次,我在IRC频道中贴出了这样一行数据,而那位<某人>恰好在线回应道:“没错,我已经不在这里工作了”。原来,虽然其账号已被禁用,但他们仍有一个客户端保持连接状态。当我提及他们的账号名称时,他们收到了通知,切换到相关窗口并进行了回复。我们利用那几分钟的时间聊了聊此事。

以这种方式告别某位同事颇为奇特。通常情况下,电子通信渠道会在离职初期就被切断。我想之所以会发生这种情况,是因为IRC服务器仅在连接时验证身份,之后便不会再次确认会话是否仍然与现任员工关联(这是一个相对棘手的问题)。

另一次,一位经理级别的员工在参加一场会议前表示,他们会因某个“愚蠢的管理事务”而迟到。果不其然,在会议开始几分钟后,一条消息滚动显示了他们下属之一的账号被停用。显然,他们当时正忙于进行人力资源部门安排的解雇面谈。

我认为,应在入职新公司或公司规模扩大到拥有LDAP或其他员工信息系统时,就开始实施这样的监控操作。这意味着,最佳时机就是今天。

顺带一提,“comm”工具在这种场景下表现得相当出色。可通过以下命令完成对比操作:

comm -2 -3 <(grep ^uid: old | sort) <(grep ^uid: new | sort)

然而,此类方法并非万无一失。如果未能及时发现错误,一旦导出失败,却仍使用完整列表与空列表进行对比,结果将显示所有员工似乎都已辞职,而这显然不是所期望的结果。此外,在大型企业中,自动化流程偶尔会出现异常,导致所有人“被解雇”,每个账号都被停用。若你在该公司待得足够久,这种状况甚至可能会发生不止一次。

另外,如果有人对你运行这类工具感到不满,或许你并不适合在那里工作。反之,如果你能在不引起IT部门或其他相关部门担忧的情况下构建此类工具,那么你可能正处在一家珍视创新和实用工具创造的企业之中。请珍惜这样的工作环境,因为它们往往难以持久。