为每个客户的托管责任指定负责人。

将所有权与日常访问权限分开

确定谁持有每个托管、域名、DNS 和第三方账户，谁支付账单，谁控制恢复。这些角色可能属于不同的人。上传发布版本的维护者不应成为唯一能够恢复客户项目的人。

列出账户标识符、业务负责人、恢复联系人所有者和授权管理员。记录恢复材料的存放位置，但不要将材料本身放入此表。确认业务连续性不依赖于即将离职的承包商的个人电子邮件或设备。

共同完成责任矩阵

下面的示例是供讨论的提案，不是 PrivateHostLab 合同义务的声明。客户拥有业务决策权，代理机构承担其接受的技术工作，提供商的义务来自实际服务协议。将角色替换为具名人员或文档化的提供商联系人。

为每一行添加批准边界和约定的联系方法。替补人员必须接受该角色并拥有必要访问权限。空白替补或未知的提供商升级路径是未决行动，不是假定的覆盖。

水平滚动以查看所有表格列。

为操作人员提供其任务所需的访问权限

在相关系统支持的情况下使用个人身份。在实际可行的情况下，将发布、部署、计费和账户恢复权限分开。OWASP 建议授予所需的最小权限，并审查权限以了解累积访问。将该原则转化为每个项目账户的具名任务和审查日期。 OWASP 授权备忘单.

约定谁可以添加或删除 SSH 密钥，以及谁验证结果。在更改 SSH 配置之前，保留一个已知可用的会话和一条已确认的恢复路径；在应用之前验证配置，然后在关闭旧会话之前证明新的授权连接可用。Ubuntu 明确建议在重启 OpenSSH 之前检查配置，以避免失去访问权限。 Ubuntu OpenSSH 服务器文档.

交接文档应包含密钥指纹或访问记录引用，绝不能包含私钥、密码或钱包恢复短语。

按业务影响定义升级

将日常内容请求、计划维护更改和影响关键客户工作流的事件分开。写下覆盖时间、时区、第一联系人、替补人员和下一次沟通检查点。不要将便捷的消息渠道变成隐含的响应时间保证。

警报应导致某人可以采取的行动。Google 的监控指南将可见症状与可能原因区分开，并询问页面是否紧急且可操作。对于此项目，“无法提交咨询”比“服务器看起来异常”是更清晰的事件描述。 Google SRE 监控指南.

有用的升级说明记录受影响的工作流、首次观察到的时间、最后已知成功、近期更改和已采取的行动。从支持日志中删除个人数据和机密信息。

分配恢复决策以及备份任务

商定数据必须恢复到哪个时间点，以及在企业受到实质性影响之前恢复可以持续多久。这些是 NIST 的 恢复点 和 恢复时间 目标所反映的不同规划问题。

指定负责维护副本的人员、负责测试副本的人员以及生产环境恢复的审批人。在单独的目标环境上进行演练。记录已恢复的数据点、功能检查、耗时和差距；一次成功的演练只能作为该次演练的证据，并不保证未来每次事件都能成功。

交接可用的项目记录

设想某客户在一次活动结束后更换日常维护方。即将退出的代理机构提供当前发布版本、依赖清单、部署步骤、数据库和上传恢复流程、调度器详情、DNS 映射以及第三方账户登记表。客户确认哪些账户和正在进行的工作移交给接替方。

接收方运维人员应使用这些文档进行一次受控演练：找到已批准的发布版本、在隔离环境中恢复样本数据、找到下一个计划任务并确定续期负责人。记录未能完成的事项，并在依赖该运维人员处理事件之前解决。

• 在移除离职人员的访问权限之前，确认接替方的授权访问权限。
• 轮换曾共享的凭据，或在适当的情况下撤销个人身份。
• 在整个项目清单中移除过期的密钥、部署令牌和访问授权。
• 根据约定的移交条款确认剩余副本和未完成工作的处置。

接受该表，然后维护它

将每项移交检查标记为已接受、受阻或需要跟进，并注明审核人和证据位置。未解决的恢复联系人应保持可见，而不是消失在笼统的“移交完成”消息中。

每当客户、代理机构、提供商范围或应用发生变化时，审查该表。将其链接到 已批准的托管预算 和 迁移记录。本工作表用于准备运营协议；它不替代实际的卖方条款，也不构成提供商支持承诺。将其与已发布的 服务范围 进行比较，并明确解决缺失的细节。

保持项目推进

• 制定客户托管预算
• 规划受控的客户迁移
• 审查服务责任