接管运维

接管运维是对并非由我们团队建设的系统进行运维，因此在签订长期合同之前，我们会先做一次检查：我们必须清楚自己接管的是什么。对我们团队建设的系统进行运维，属于“系统与集成”服务中的“运维与持续开发”。

接管前我们检查什么

代码：公司是否在代码仓库（即保存修改历史的地方）中拥有完整的源代码，能否用它构建出服务器上正在运行的系统。访问权限：谁拥有服务器、数据库和域名的管理员账号，其中哪些属于已经不在公司的人。文档：是否存在，是否与系统的实际行为一致。许可：公司以什么条件使用数据库和库（即现成的代码组件），费用是否按时缴纳。备份：是否在生成、存放在哪里、上一次有人用备份恢复系统是什么时候。不再受支持的组件：哪些组件（比如数据库）已不再获得厂商的补丁。

共同过渡期，或在没有前任的情况下接管

如果原承包商可以配合，我们会约定一个共同过渡期：先由他处理工单，我们观察和提问，然后双方角色互换。过渡期以交接记录收尾：我们收到了什么，缺了什么。如果没有前任，我们就从现有的东西接手：服务器上的代码、运行日志，以及与业务部门的交流。最初几周用于读懂系统；只有弄清一项修改会触发什么之后，我们才会实施修改。

缺失项清单与首轮整改

检查中发现的每个缺失项都会列入清单，写明它对公司构成什么风险，并给出三种处理方式：恢复、替换，或在知情的前提下保留现状。由您来选择，我们为每种方式提供报价。根据您的决定形成首轮整改计划，按以下顺序进行：

• 建立公司自己的管理员账号，收回公司以外人员的访问权限；
• 进行备份，并试行恢复系统；
• 将代码放入公司账号下的代码仓库；
• 搭建测试环境，即用于检验修改的系统副本；
• 更新不再受支持的组件。

最后，我们把系统当前的实际功能写下来，以此取代旧文档。

之后的持续运维

业务部门提交的工单进入同一个登记簿：缺陷是指偏离了接管当天系统运行方式的情况，变更是指新功能，其先后顺序由您决定。变更通过版本发布上线，即在测试环境中检验过的变更包，附有说明和回滚方法。监控，即对系统运行状态的观察，会在系统停止响应时通知指定人员。当您希望自行运营系统时，把系统交给您的员工属于另一项服务范围：知识转移。

当代码不归公司所有时

有时与原承包商的合同没有把代码权利转让给公司，或者系统是对方的产品，许可中不含修改权。这种情况下，由我们具备法律背景的人员审读合同；法律意见由律师事务所出具。可选的出路有：购买代码权利或修改许可；只对数据、配置和服务器进行运维；或者制定替换系统的计划。在权利问题解决之前，我们不修改代码。

1. 在保密协议下，按约定的范围和期限检查系统。成果：检查报告和缺失项清单，供您据此决定是否接管。
2. 接管：与原承包商共同过渡，或者从现有的东西接手。成果：交接记录、公司自己的管理员账号、存放在公司代码仓库中的代码。
3. 按计划进行首轮整改。成果：经过验证的备份、测试环境、受支持的组件、反映当前状态的文档。
4. 提供持续运维。成果：统一的工单队列、按约定节奏发布的版本、监控，以及定期的系统运行汇总。

1. 用我们现有的代码，能否构建出目前在服务器上运行的系统？由谁来确认？
2. 你们将接管哪些管理员账号，收回前任人员的哪些账号，我们这边由谁批准？
3. 上一次有人用备份恢复系统是什么时候？你们什么时候做？
4. 没有代码的系统部分怎么处理：列入缺失项清单，还是盲目接管？
5. 与原承包商的合同是否允许我们修改代码？如果不允许，你们会怎么做？

每次接管都从系统分析开始：在决定签订长期合同之前，您就会拿到检查报告和缺失项清单。