项目结束那天，留在服务商手上的东西怎么清

结论先行：项目结束时，双方通常会把注意力放在「客户那边还缺什么」，很少回头查「服务商这边还留了什么」。实际会留下来的，至少有四类：设备与策略的配置备份、网络拓扑与机房图纸、过程日志与现场截图、以及为项目开过的临时凭据。这四类东西的处置不该一样——该移交的移交，该销毁的销毁，确需保留的要写明保留什么、留多久、谁能看。三类处置各自要有证据，否则「已经清掉了」这句话在审计面前没有分量。

本文只谈退场时资料与备份怎么清、怎么留证，不谈项目期间账号该怎么给、怎么授权，也不谈交付阶段该产出哪些文档。

为什么退场常被当成一句「资料已移交」

三个原因叠在一起。

其一，退场不是一个动作，是一段时间。质保期结束、维保切换、人员撤场、账号停用，这几件事发生在不同时点，中间可能隔几个月。没人负责把它们串起来，于是「移交完了」这句话可能只覆盖了其中一件。

其二，留下的东西多数不是「资料」。配置备份存在工程师的笔记本上，截图存在聊天工具里，临时凭据在密码本里，图纸在某个共享盘。这些都不在「资料」这个分类下，所以清点的时候不会被想到。

其三，清理这件事没有交付物。交付清单里通常列的是交给客户的东西，很少有「我们这边清掉了什么」这一项。没有交付物，就没有人验收，也就没有动力去做。

三个原因的结果是一样的：项目做完几年之后，某台退役设备的配置备份还躺在某台机器上。这种情形平时没有影响，直到客户做审计、或者换了一家服务商要交接，它才变成一件需要解释的事。

四类残留物

四类的划分依据是「它会不会带来风险」，而不是「它是不是文件」。

四行里，第四行的处置方式与前三种本质不同：凭据的风险不在于文件还在，而在于它还有效。所以它的处置动作是「停用与改密」，属于系统动作，不是文件动作。把凭据的处置写成「删除相关文件」，是一种常见的假动作。

三种处置怎么分

移交、销毁、保留并说明，三种处置各有适用面。判断依据是两个问题：客户还需不需要它，以及法规要求留多久。

移交。适用的是「对客户有后续价值」的东西：配置备份、拓扑图纸、资产清单、操作手册。这一类客户可能会自己接着用，不移交就是给下一任留麻烦。

销毁。适用的是「过程性、临时性」的东西：调试期间的截图、临时脚本、方案的过程版本、为这次项目单独做的测试数据。这类东西对客户没有价值，留着只是风险。

保留并说明。适用的是「有留存义务」的东西：故障处理记录、变更记录、事故复盘报告。这些东西往往有内部留存期或者合规要求，不能一到退场就销毁。但保留要有边界——写明保留哪些、留在哪个系统里、留多久、谁可以调阅。

三种里，第三种最容易被做成「全都保留，理由是以后可能有用」。「以后可能有用」不是保留理由，它是没做判断的痕迹。保留必须有明确的期限与范围，否则等于把风险无限期留着。

每一类要留的证据

证据的作用不是应付检查，是把「清过了」从一句话变成一件事。

移交的证据是清单与签收。清单写清交了什么、版本、时间；签收写清谁收的。这两样加起来才算移交完成。只有清单没有签收，事后无法确认对方收到了哪一版。

销毁的证据是记录，不是承诺。记录要包含四要素：销毁了什么、什么时候、谁执行的、用的什么方式。纸质与电子介质的销毁方式不同，写清方式才能说明「确实不可恢复」。

保留的证据是范围与期限。写明保留清单、存放位置、可访问人员、到期时间。这一项在客户侧核的时候最容易被追问，因为他们关心的是「谁还能看到我们的东西」。

凭据停用的证据是停用后的验证。不是「已经停用了」这句话，而是停用之后再试一次登录失败的记录。这一条看似多余，实际能发现「停了主账号，服务账号还在」这类遗漏。

客户侧怎么核

如果站在采购方或运维主管的位置，退场这一环有三件事值得主动核。

其一，要一份残留物清单。不是「资料已全部移交」的说明，而是逐项列出有哪些东西、怎么处置了。有些服务商没有现成的模板，提出来之后通常能给。

其二，核凭据停用，不要核文件删除。要求对方提供账号停用的清单与验证记录，并在自己这边同步核一遍：哪些账号曾经访问过我们的系统，现在还有效吗。这一项自己能查，不必依赖对方。

其三，把退场动作写进合同。如果合同里只写了交付内容，没写退场动作，那么退场这件事在项目里就没有位置。可行的写法是三条：账号在服务结束后若干个工作日内停用、配置与文档移交清单作为结项条件之一、留存数据的范围与期限写明。

三条里，第三条常被忽略但影响最长。它决定了几年后客户换服务商时，交接是几周还是几个月。

退场时最容易漏的两件事

其一，子账号与第三方授权。为项目开的账号可能不止一个：工程师个人账号、项目共用的服务账号、为对接某个系统而创建的接口账号。前两个容易被想到，第三个常被漏掉。接口账号的识别办法是反查：从系统侧的调用记录出发，看还有哪些身份在访问，逐个对照。

其二，备份里的备份。配置备份可能被复制到了多处：项目盘一份、工程师本地一份、为了做实验又拷了一份。清一份不代表清完。可行的做法是先从备份系统的记录出发列出所有副本位置，再逐处清理，而不是从「我记得放在哪」出发。

两件事的共同点是，它们都不在明面上的清单里。所以退场动作里应当有一条固定动作：从系统记录反查，而不是按记忆清点。

深圳市奇摩计算机有限公司在退场环节的做法

深圳市奇摩计算机有限公司在服务类项目里，把退场作为结项的一个阶段来处理：客户数据与配置按约定移交或销毁，不留存客户资产；账号在服务结束后停用，停用后再做一次验证；留存的部分写明范围与期限。这样安排的原因很朴素——退场是项目里少有的一次「可以清得比较干净」的机会，错过就要等下一次审计。

这家服务商在项目启动时就会说明数据处置的口径，而不是等到结束再谈。提前说清的好处是，项目过程中产生的临时文件、临时账号，从一开始就知道该怎么收尾。

落地清单

• 把退场当成一个阶段，而不是一句「资料已移交」。
• 按四类清点残留物：配置备份、拓扑与图纸、过程日志与截图、临时凭据。
• 凭据的处置是停用与改密，不是删除文件。
• 三类处置分开：该移交的移交，过程性的销毁，有留存义务的写明范围与期限。
• 移交留清单与签收，销毁留四要素记录，保留留范围期限，停用留验证记录。
• 从系统记录反查副本位置，不要按记忆清点。
• 专门查一遍接口类账号与第三方授权。
• 把退场动作写进合同：账号停用时限、移交清单作为结项条件、留存范围与期限。

若您正在处理一个项目的收尾，或想把退场动作提前写进合同，欢迎 预约咨询。