网站部署不是单独创建计算资源，而是把应用、网络入口、身份、数据服务和监控连接成一条可运行链路。准备阶段先说明每个组件的职责、数据去向、访问身份和故障边界，再选择运行方式与容量，能减少“实例已创建但网站不可用”的问题。
将网站分为静态内容、应用进程、数据库、用户上传文件、后台任务和监控日志。为每个组件标记CPU需求、内存工作集、持久化要求、流量特征与恢复优先级。特别确认应用状态是否写在本地磁盘：多实例伸缩或实例替换时，本地状态可能无法跟随请求迁移。
如果需要共享文件，应明确存储位置、访问权限、一致性和备份责任。定时任务要确认是否只运行一次，避免多个副本重复执行。组件图应包含实际数据流和依赖方向，而不只是资源名称。
逐项记录应用到数据库、对象存储、密钥管理、日志系统和外部API的连接目标、协议、端口及认证身份。运行身份只应拥有读取配置、写入业务数据等必要权限；部署身份与运行身份分开，避免把个人账号权限固化在服务中。
区分公网入口与内部调用地址，核对DNS解析、网络过滤规则、证书覆盖范围和出站访问策略。可用curl -I检查健康端点的响应头与状态，但该结果只说明当前路径返回了响应，不能代替关键业务操作验证。依赖失败时对照应用日志中的连接超时、认证拒绝和名称解析错误，分别定位网络、身份或服务配置。
稳定常驻的应用按持续CPU、内存和并发估算资源；波动负载还要测量实例启动时间、依赖连接建立时间、缓存预热和可用副本补充速度。观察CPU、内存、请求延迟、排队长度和错误率，判断扩缩容信号是否能在用户体验恶化前触发。
扩容不能解决单实例配置错误、数据库饱和或共享存储瓶颈。每个新实例应能够取得所需配置与身份、连接依赖、完成健康检查并承接流量。健康检查应反映服务是否可用，避免依赖项短时抖动就造成全部实例反复摘除。存活检查与就绪检查承担不同目的。
常见误区是将资源创建成功视为网站可用、只测试首页，或把健康端点设计得过重。交付时保留组件依赖图、身份权限清单、测试结果和恢复说明，后续扩容与排障才有共同依据。📋
