先确定系统清单和责任人。
列明纳入服务的应用、云资源、模型连接及依赖，确认客户账号负责人、技术联系人和审批角色。一起检查配置与交接资料，记录已知问题。访问权限对应具体运维任务，并由客户授权和审阅，系统所有权及决策责任需要在服务安排中清楚体现。
专业服务
交付之后，明确环境怎样持续运行。
从系统边界和所有权开始，把监测、故障处理、变更与用量回顾组织成适合当前环境的服务范围，并明确各方责任。
讨论托管运维覆盖与不覆盖，先写清楚
可约定纳入：指定系统监测、事件协同、批准后的配置变更、用量回顾及运行记录。
需单独确认：新功能开发、模型训练、客户自管系统修复、数据恢复和第三方产品缺陷。服务时段与响应目标以协议为准。
让故障和变更过程可追溯。
发现 → 判断 → 授权处理 → 验证 → 复盘
客户：批准权限和变更，提供业务背景，并协调客户自行负责的系统。
Corebyte：在约定服务范围内执行支持工作，维护相应处理记录。
供应商：通过对应渠道处理由其控制的资源及服务问题。
运行报告样张
示例 · 非客户数据
- 系统范围：约定的模型应用与相关资源
- 事件记录：影响、判断依据、操作、批准人及当前状态
- 下一步：未结事项、责任人、复核时间与退出交接要求
让监测信号对应到行动。
约定观察哪些指标，以及这些信号对业务意味着什么，可涉及服务健康、请求错误、资源用量和可取得的账单资料。明确谁接收告警、怎样判断、何时需要其他团队或供应商参与。监测覆盖和响应安排一起确认，避免有了数据却无法判断谁负责处理。
结合上下文回顾用量和表现。
利用约定系统可提供的记录，讨论容量、请求表现和成本，说明资料缺口及建议所采用的假设。回顾可以形成资源调整或进一步调查的行动项。新增优化、模型评测或微调工作，需要先讨论实际能力与独立范围，再决定是否纳入项目。
将服务条件写入协议并持续核对。
服务时段、响应目标、事件分类、升级联系人和回顾频率在协议中确认。可约定故障历史、已批准变更、用量摘要和待办记录等输出。环境变化后，复核系统清单与分工是否仍然适用；服务转交或结束时，安排文档、未结事项与已授权访问的交接。
讨论需要持续支持的系统。
提供系统清单、现有运行职责和团队需要的支持安排。