从运营需求开始
在比较配置之前，收集每个项目的应用程序栈、数据库、上传内容、计划任务、集成和预期变更。确定谁需要内容访问、部署访问和主机管理权限。这些是不同的工作。编辑页面的客户可能只需要应用程序账户；维护操作系统的承包商则需要大得多的权限。
还要记录可接受的维护窗口、谁批准停机、恢复副本保存在哪里以及谁支付运营工作费用。将客户对单独服务器或账户的任何要求记录为决策约束。资源电子表格无法解决所有权或访问要求。
- 为每个项目指定主操作人员和替代人员。
- 列出共享依赖项：DNS 访问、部署凭据、数据库服务和备份目标。
- 在承诺此安排之前，先将未知需求标记为客户决策事项。
在服务器规模之前选择访问边界
OWASP 建议仅授予个人工作所需的权限，并验证预期的限制是否生效。将这一原则应用于托管方案：使用独立身份、项目专属应用凭据和文档化的部署路径。以客户命名的目录只是组织辅助手段，而非访问策略。
如果使用 Docker，请将对守护进程的访问视为主机级责任。Docker 的安全文档说明，受信任的守护进程操作者可以挂载并修改主机文件。因此，将不受限制的 Docker 控制权授予外部承包商，与承载无关客户数据的主机并不匹配。
独立的 VPS 实例允许各自进行操作系统管理和发布决策。它们仍需要在每个项目内谨慎配置权限。共用的机构凭据或共享部署账户可能重新引入你本打算隔离的风险。
处理两个虚构的客户简报
以下客户为虚构示例，并非客户历史记录。该机构目前同时运营这两个项目，但它们的访问和时机要求不同。
将这两个项目放在一起，会使 Morrow 的承包商访问和上线时间表成为 Aster 的运营风险的一部分。独立服务器的决策遵循这些约束；它并不声称 Morrow 需要特定数量的 CPU，也不声称 Aster 没有风险。
水平滚动以查看所有表格列。
| 决策因素 | Aster Furniture：宣传册网站 | Morrow Workshops：报名网站 |
|---|---|---|
| 工作负载 | 公开页面和偶尔的内容更新 | 表单、数据库和定时报名导出 |
| 访问 | 客户编辑内容；机构负责部署 | 外部开发者需要主机管理权限 |
| 维护 | 约定的晚间窗口 | 预订上线期间无计划变更 |
| 事件影响 | 临时页面中断可以协商 | 丢失或重复的提交需要调查 |
| 退出要求 | 导出内容并迁移应用 | 转移独立运营的环境 |
| 临时决策 | 考虑与兼容的机构运营站点共享 | 使用独立 VPS 和独立项目凭据 |
比较两种安排的全部成本
使用当前配置器构建两个预算版本：一个共享配置和一个项目单独配置。对于每个版本，分别列出所选期间的托管总费用、经常性选项、外部服务和机构维护时间。避免将旧价格复制到客户简报中。记录配置准备时间以及谁批准了分配。
对于共享主机，需约定客户如何分摊固定成本，以及当一方离开或需要升级时如何处理。等额分摊简单，但当某个项目导致大部分存储增长或运营工作时可能不合适。独立服务器使归属更清晰，同时增加独立的补丁、监控和恢复任务。
为发布、备份和临时工作预留资源余量。Docker 容器默认没有 CPU 或内存限制；请配置适当的限制并评估合并工作负载。仅凭容器列表并不能证明资源预算可行。
使维护和恢复因项目而异
在共享主机上，操作系统重启会影响所有驻留项目。将主机维护放入公共日历，并确定由谁联系每个客户。在实际可行的情况下保持应用发布独立，并避免在一个项目的重要上线期间安排另一个项目的数据导出。
恢复笔记应标明项目的数据库、文件、配置和所需凭据，但不要将机密复制到笔记中。计划恢复到单独的测试目标。将恢复整个共享主机作为第一响应，可能会覆盖另一客户端的健康变更。
对于独立 VPS 实例，记录仍然共享的服务。公共 DNS 账户、备份目标或操作者仍可能同时影响两个项目。服务器分离并不证明物理基础设施独立或可用性有保障。
验证安排并设置审查触发条件
在接受此安排之前，请由第二位操作者检查项目身份能否执行其分配的工作，且无法读取另一项目的文件、备份或机密。除了应用界面外，还要审查数据库权限和已部署凭据。在约定的环境中使用无害测试数据；不要探查另一客户的生产数据。
将结果记录为已接受、已拒绝或等待具名纠正。如果无法证明隔离，请先缩小访问权限或迁移项目，然后再授予更广泛的权限。首页成功响应并不等于访问或恢复检查。
- 保留决策记录，包含所选布局、已批准的成本分摊、负责人和未解决事项。
- 当外部管理员加入、上线窗口变更、存储增长或客户准备离开时，重新审查该选择。
- 使用责任指南将技术选择转化为运营协议。
来源与审查
技术参考资料已于 2024 年 9 月 12 核查。2026 示例为规划演练；所引用的软件文档并不确立 PrivateHostLab 的服务能力。