在我供职过的大型企业中，普遍存在一种员工信息管理服务，用以记录谁是现任员工，谁已离职。通过定期导出该列表并与其先前版本进行比较分析，往往能洞察到一些有趣的现象。
某一公司内部为此开发了一项名为“墓志铭”的服务，当员工从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部门或其他相关部门担忧的情况下构建此类工具，那么你可能正处在一家珍视创新和实用工具创造的企业之中。请珍惜这样的工作环境，因为它们往往难以持久。
