唯一的 IT 管理员离职：一份交接计划

一句话回答： 风险不在于岗位空了，而在于一整套没有文档的 IT 资产，装在一个人的脑子里走出了办公室。在一个月通知期里，先拿访问权，再拿清单，最后拿只有他知道的那些事——顺序就是这样，因为前两样在他账号被停用的那一刻就拿不到了。

香港一家五十人测量师行的管理合伙人，用一句话向我们描述过这件事：「他周一递了辞呈，到周三我才意识到，公司里没有第二个人知道任何一个系统的密码。」

那家公司再典型不过。三十到八十人之间，专业服务，一位在职五到八年的 IT 同事，一套围绕这个人而不是围绕任何成文设计长出来的 IT 环境。储藏室里有一台服务器，没人打开过那个柜门。域名注册商的账号挂在他的私人邮箱下。会计系统有一个变通做法是有原因的，而只有他记得那个原因。有一家硬件供应商只接他的手机，不接公司总机。

这些都不是失职。当一个有能力的人独自撑起一家「增长速度快过其文档」的公司的 IT 时，就会长成这样——而这描述了香港相当大比例的专业服务公司。

下面讲的是：你手上那四个星期该怎么用。

为什么这在香港这个规模段的公司里如此常见

在这个特定区间里，有三件事叠加在一起。

规模段很尴尬。 三十人以下，公司通常会外包 IT，或者靠消费级工具凑合。一百人以上，公司会有一支至少两个人的 IT 团队。夹在中间，一个人既养得起、又够用，而且——所有人都假设——没问题。这个区间里没有人为冗余做过预算，因为在辞职信到达之前，表面上什么都没出错。

香港的专业服务公司用一支很薄的团队撑着一套很宽的环境。 一家五十人的测量、会计或咨询行，通常会有一个域名、一个 Microsoft 365 或 Google Workspace 租户、一台文件服务器或 NAS、给外勤同事用的 VPN、一套项目管理或成本核算系统、一套带保留义务的文档管理系统、几个各自带授权服务器的行业专用应用、若干供应商门户，以及贯穿这一切的 PDPO 风险敞口。这不是一套小环境，它只是一套从来没有被写下来的环境。

通知期短，市场流动性高。 香港非管理岗的标准通知期是一个月。一位读写中英文的资深基础架构通才，不会长期待业。所以这个窗口是固定的、是短的，而且在他签了下家之后，不会因为人情而延长。

结果是一场可预测的危机，而公司里没有任何人演练过。

「只有他知道」到底指什么

值得说具体一点，因为这个问题的抽象版本——「我们需要更好的文档」——会导出一份谁都不满意的文档。

走出去的知识有四类，而它们的行为方式很不一样。

凭据。 管理员账号、注册商登录、防火墙的 enable 口令、备份控制台、NAS 的 root 账号、供应商门户，以及那些登记在他个人名下或个人邮箱下的账号。这一类是二元的：要么你在他最后一天就拿到了，要么你开始一个可能耗时数周、有时还需要公证公司文件的找回流程。
清单。 有什么、在哪里、什么授权、什么保修、什么日期续期、用哪张信用卡付。这一类没有他也能恢复，只是很慢，而且会有缺口。
依赖关系。 关掉储藏室那台机器会坏掉什么。哪份报表依赖哪个计划任务。VPN 上那条看起来不对劲的静态路由为什么存在。这一层是第二个月里制造不愉快惊喜的那一层。
隐性知识。 那个变通做法为什么存在、哪家供应商真的会接电话、2023 年试过什么并且失败了、哪个用户绝对不能被踢出哪个系统——理由是政治性的而不是技术性的。这是唯一一层真正无法重建的知识，也是大多数人留到最后才处理的那一层。

按这份清单来安排你的四个星期，而不是按一份通用检查表。另外要注意，这个顺序不是按重要性排的——隐性知识大概才是最值钱的——而是按失效时间排的。凭据和清单在账号被停用时就不再可得；隐性知识衰减得慢一些，而且必要时，如果关系还在，还可以通过一份付费顾问安排部分找回。

第一周：访问权与身份

先做这件事，在其他任何事情之前，并且不要让它被当下运营上着火的任何事情挤到后面。

枚举每一个带管理权限的账号，横跨身份租户、防火墙、交换机、NAS、虚拟化平台、备份系统、终端管理控制台、防病毒租户，以及公司付费的每一个 SaaS 应用。不是「他常用的那些」——是全部，包括服务账号和应急账号。

现在就建立第二个管理员，不要留到以后。 建好它，用另一台机器独立登录测试一遍，然后把凭据存进一个公司控制的密码管理器里，管理合伙人或财务总监也要有访问权。测试这一步很要紧：一个存在但从没登录过的管理员账号不是一道控制，是一个愿望。

找出所有挂在他个人名下的东西。 这是最常被跳过的一步，也是最经常演变成真正危机的一步。域名注册商账号、SSL 证书账号、移动运营商账号、供应商支持门户、一张登记到他邮箱的公司卡、应用商店开发者账号，以及任何以他个人手机为种子的双因素认证。每一项都需要在他还愿意帮忙的时候，转移到一个公司拥有的身份下——一个共享邮箱或一个角色账号。在他最后一天之后，其中好几项要走供应商的账号找回流程，而有些流程确实很难走。

在他最后一天该改的就要改，并且事先知道哪些改动有爆炸半径。在不知道什么在用它的情况下轮换一个服务账号的密码，是让公司在他离职后的第一个周一全面下线的好办法。

把续期日历写下来。 域名到期、SSL 到期、授权周年、支持合同结束日、线路合同结束日。离职四个月后域名续费失效，是一种常见且完全可以避免的事故。

第二周：清单与依赖

访问权拿稳之后，把「你到底拥有什么」这幅图画出来。

不但要在逻辑上走一遍，也要在物理上走一遍。应该有人和他一起打开弱电柜，把里面的东西拍下来，然后写清楚每一样是干什么的——包括那个没贴标签、从 2019 年起一直在给某个重要东西供电的盒子。第二个办公室或工地临时房里的设备，同样处理。

对每一台设备和每一个系统记录：它是什么、在哪里、干什么、谁依赖它、成本多少、支持或保修何时结束，以及它停了会发生什么。最后那一栏，才是把一份资产清单变成有用东西的那一栏。

然后对非物理的部分做同样的事：订阅、授权、线路、移动套餐、云租户，以及任何对你系统拥有常设访问权的第三方。带远程访问权的供应商经常是个意外——比如那家自 2021 年实施以来一直有 VPN 账号的项目管理系统供应商，这既是一项运营依赖，也是一个值得问一问的 PDPO 问题。

最后：测试备份。 不是「确认备份任务报告成功」——是真的还原一样东西，还原到另一个位置，然后打开它看看。一位即将离职的独立 IT 管理员留下来的最常见的东西，就是一套多年来一直报绿、却从来没有被还原过的备份机制。你希望在他还在职的时候发现这件事。

第三周：隐性那一层

这是大多数交接会跳过的一周，也是为什么那么多交接明明产出了一份很厚的文档却依然失败。

一个人独自写出来的文档，是一份乐观写成的文档。让一位即将离职的工程师独自去写，他会把架构记成当初设计的样子而不是漂移之后的样子；会略掉那个变通做法，因为它有点难堪；还会忘记那些对他来说太理所当然、以至于根本不被识别为「知识」的东西。

替代做法是：和他一起走一遍这套环境，并把过程录下来。坐在他旁边，挑一个系统，让他讲：这是什么、为什么这么配、什么会弄坏它、坏了之后你怎么做、你打给谁。把这次会话录下来——音频就可以，屏幕录制更好。然后让另一个人照着这段讲解去做一件例行任务。缺口会立刻现形。

优先级按这个顺序排：今天就会让公司停摆的东西；带合规或客户保密维度的东西；那些一年才发生一次、失败之前没人看得见的事件，比如年结流程或授权续期；最后才是「知道了更好」的部分。

也要直接问那份让人不舒服的清单。你最担心哪个系统？你一直想修但没修的是什么？有什么是靠某种你不会写进文档的办法撑着的？如果这是以同行礼貌而不是审计的方式问出口，大多数即将离职的工程师会诚实作答。

第四周：用做来验证，而不是用读来验证

一次交接不会因为存在一份文档就算完成。它是在「除了那位离职者以外的某个人真的把活干了一遍」时才算完成。

在最后一周，让接替者——内部的、临时的，或者即将接手的服务商——在他还在场可以纠正的时候，真的执行一遍例行操作：

跑一次还原。 端到端，还原到可用状态，从真正的备份系统还原。
跑一次入职。 建账号、分配授权、配置设备、授予应用访问权，并确认这位新用户能把自己的工作做起来。
跑一次离职。 停用、回收、转交邮箱、收回设备，并确认没有遗漏。这同时是一项与 PDPO 相关的控制，也是交接工作与离职权限回收纪律自然交汇的地方——那篇讲的是回收一位普通用户的访问权；你这里做的是获取一位管理员没有写下来的知识，那才是更难的那一半。
跑一次变更。 推一个补丁、重启点什么、按文档走一遍回滚。
触发一次升级。 用你记录下来的账号信息打给供应商，确认在他不在场的情况下，供应商认可你有开单的权限。

任何一件照着文档做不出来的事，就是一个缺口——而你还有几天时间把它补上。

通知期结束之前必须做的那个决定

其实只有两条路，而「推迟选择」本身就是一种选择——它会把你默认推进第一条路的糟糕执行版本。

换一个人。 再招一位独立 IT 管理员。这是熟悉的选项，保留了组织的形状。它同时也原样复制了你此刻所处的位置：一位新的同事，会在接下来五年里积累出他自己那套没有文档的环境；而且从他最后一天到新人到岗之间的那段空窗，你没有任何人顶着。

换一个模式。 转向托管服务，让文档、监控、补丁和服务台成为一套系统而不是某个人的记忆，并且让任何一位工程师在设计上就是可替换的。

老实说，两条路都站得住。环境的规模、公司对「办公室里要有一位有名有姓的人」的偏好，以及那位离职者究竟是在做基础架构工作还是主要在做服务台工作，都应该影响这个判断——我们那篇香港中小企：托管 IT 与自建团队之比较把这笔账算得比较完整。站不住的是靠惯性做决定：启动一个招聘流程，四周之内没招到，然后用一位合伙人的助理和一张旧发票上找到的救火电话来填那个空窗。

对比：面对独立 IT 离职的三种处理方式

直接招一个替代者

能给你：模式的连续性、办公室里有名有姓的一个人、对优先级的完全控制。
代价：一个你多半无法在通知期内走完的招聘周期、一段没有覆盖的空窗，以及从零开始重建的同一个单点故障位置。
适合：这个岗位确实宽泛且带战略性，公司本来也在向第二个 IT 编制成长，并且有一位资深的人能在技术上监督这次交接。

请一位临时合同工顶住空窗

能给你：很快到位的人手，以及一位在交接失效之前能接住它的人。
代价：一个日费率，以及知识转移要发生两次——一次给合同工，一次给之后的人——每一跳都会损耗。
适合：永久性的决定确实无法在四周内做出，而你需要先把时钟按停。

转向托管服务并走一次结构化接管

能给你：作为交付物而不是人情的、归你所有的文档；不依赖任何人记忆的监控与补丁；有排班的服务台；以及到场者背后的升级深度。
代价：一笔按人计的月费，以及一个要真正做好就超过四周的过渡项目。
适合：环境是标准的而不是奇异的，离职者的时间大部分花在支持而不是工程上，并且公司宁愿买一套系统而不是买一个人。

一次结构化接管实际长什么样

如果你选第三条路，那么在任何服务商的方案里要检验的，是这次过渡究竟有没有一个明确的形状，还是只是一张入职表格。

Brocent 自己的 IT 过渡与上线服务是一次为期三个月的结构化接管，值得把它描述出来，因为重点在于那个形状而不是那个招牌：

第 1–2 周，勘察与审计。 现场走访、IT 资产盘点、设备审计、网络拓扑、数据分级与备份/还原策略复核，外加一项明确动作：识别出排名前三的基础架构薄弱点。最后这一项在本场景里格外要紧：离职者的那套环境，几乎总有三件他知道不对、却一直没时间修的事。
第 2–4 周，知识转移。 工程师跟着离职者见习或研读其文档，在管理平台上建起 CMDB，把所有资产、配置和授权编目，并为每一项重复性任务定义标准作业程序。
第 3–6 周，见习与再见习。 接手的工程师在被观察的状态下跑支持流程，直到达到「无需监督即可独立操作」的基准；同时处理已识别的三个薄弱点，并做安全加固。
第 3 个月起，服务上线。 完整移交、带 SLA 的服务台（P1 首次响应 15 分钟）、7×24 监控、月度报告，以及一份成文的升级矩阵——之后还有一次正式的上线后 30 天复核，专门用来捕捉那些只有在真正运营之后才会浮现的知识缺口。

要坚持写进合同的是交付物：一份带保修与授权记录的完整资产清单、一个 CMDB，以及一份覆盖架构、供应商联系人、升级矩阵、授权续期、备份与灾备流程和历史已知问题的技术运维手册。正是那份手册，让下一次离职——无论是服务商那边的还是你这边的——从一场危机降级为一个排期问题。

关于时间线有一点值得注意：三个月的接管比一个月的通知期长。这不是矛盾，这恰恰是「第一周就该开始谈，而不是第四周」的真正理由。那些必须在离职者还在的时候完成的部分——知识转移和凭据捕获——在设计上就被放在了序列的前端。

为什么「文档归你所有」才是整件事的重点

一次独立 IT 离职更深的教训，不是「我们当初应该多写点文档」，而是：跟着人走的文档根本不算文档——而且如果你放任的话，同样的失败会在服务商身上重演一遍。

检验方法很简单，值得拿去问每一家你在考虑的服务商：如果我们终止合作，我们能拿到什么，那是合同上的权利还是一次人情？

Brocent 的答案是：客户拥有文档与凭据，是每一档 Managed IT 套餐里的包含项——资产记录、凭据、运维手册和站点笔记按长期政策归客户所有，而不是谈判换来的让步。不管你用哪家服务商，都要把等价的条款写进合同。一家不肯把这件事写下来的服务商，正在构建的恰恰是你此刻正在花钱摆脱的那种依赖。

另外有一个合规维度值得提，但不必夸大。在 PDPO 之下，资料使用者对其持有的个人资料负有问责责任，包括由代理人处理的资料。上面描述的那套凭据卫生——不共用个人账号、管理员密码不放在个人密码管理器里、最后一天干净地回收权限、一份成文的「拥有常设访问权的第三方」清单——首先是好的 IT 实践，其次才是合规的副产品。它不是你把交接做好的理由，但它是你的审计方迟早会问到的理由。

如果这件事正在发生，从哪里开始

如果辞职信已经在桌上了：今天下午就开始第一周。枚举管理员账号，建立并测试第二个管理员，列出所有登记在他个人名下的东西。这三件事最先失效。

如果你读到这里时桌上并没有辞职信，那么有用的练习更短。这周就请你的 IT 同事交给你三样东西：每一个管理凭据的清单、每一个挂在他个人名下的账号，以及关于这套环境最让他担心的三件事。如果这份清单一周之内交不出来，你其实已经知道那次交接会是什么样子了。

无论哪种情况，如果你希望这套环境由一套系统而不是某个人的记忆来记录、监控和支持，那正是按人计费的托管套餐的用途——而如果离职已经迫在眉睫、你想把过渡序列对着你的具体通知期排一遍，联系我们。Brocent 自 2016 年起在香港运行这类接管，自 2007 年在北京创立以来一直在做结构化过渡。

常见问题

一次 IT 交接要多久？

捕获阶段——凭据、清单、依赖和隐性知识——只要从第一周就开始、并且按失效时间而不是按重要性排序，是装得进一个月通知期的。完整迁移到托管服务则更长：Brocent 的结构化接管跑三个月，其中知识转移被刻意安排在第 2 到第 4 周，好让它发生在离职者还在的时候。两者是重叠的，不是先后串行的。

如果人已经走了怎么办？

那你处在「恢复」而不是「交接」阶段，更慢，但并非没希望。优先重新取得管理控制权：走供应商的账号找回流程，这些流程通常需要公司注册文件和一位董事的授权；做一次完整的发现扫描重建清单；做一次还原测试，弄清楚你的备份是不是真的。为一段「变更能力下降」的时期留出预算——你不应该对一套自己还没搞懂的系统做有风险的变更。在前雇员愿意的情况下，为隐性那一层安排一份短期付费顾问，通常是花得很值的钱。

文档归谁所有？

永远应该归你，而且合同上应该这么写。在 Brocent，客户拥有文档与凭据是每一档 Managed IT 套餐的包含项，而不是谈出来的东西。如果一家现有或潜在的服务商把文档当作自己的财产，那你买到的就是你正想摆脱的那个单点故障，还附带一张发票。

如果凭据在个人密码管理器里怎么办？

趁他还在职处理，这是一次转移作业；拖下去，它就变成对每一家供应商分别走一次账号找回作业。要一份与工作相关条目的导出，逐条独立登录验证，然后存进一个公司控制的保险库，至少两个人持有访问权。往后的规则是：公司凭据住在公司保险库里——个人密码管理器是给个人账号用的，而这是管理合伙人层面的政策问题，不是技术偏好。