发现运行问题，保存资产，并追查操作过程

“员工不能继续工作”可能来自模型、预算、任务、运行环境或基础服务。管理员不需要一遇到问题就重建环境或恢复备份；先找到受影响对象和原因，才能选择影响最小的处理方式。

本章涉及四个入口：运营事件帮助发现持续问题，平台运行检查整体状态，备份与恢复保护员工资产，审计事件还原谁在什么时间做了什么。

先选对入口

想回答的问题	打开哪里	得到什么
现在有哪些持续问题，需要先处理哪个？	运营事件	按严重程度汇集的当前问题、恢复记录、事件数据更新时间。
平台能否启动新任务，基础服务是否有异常？	平台运行	任务与环境概况、基础服务检测、新任务准入开关。
某位员工的文件和会话需要备份、恢复或交接？	备份与恢复	员工恢复点、手工备份、恢复、停用员工代导出。
谁改过设置，操作成功还是失败？	审计事件	有时间、操作者、目标和结果的操作记录。

运营事件是系统对问题状态的判断；审计事件是已经发生的操作事实。看过运营事件不会将它改成“已恢复”，调整设置也不会抹去旧的审计记录。

1.用运营事件查找持续问题

打开“运行与维护→运营事件”。默认显示“正在发生”的问题，页面也列出严重、重要和提醒数量。

图9-1：先确认问题来源与级别，再检查下方“事件数据更新”，避免把过旧或未更新的数据当成当前事实。

在“问题状态”选择“正在发生”或“已恢复”。
按需要选择“事件来源”“严重程度”，或输入完整“对象标识”。
需要缩小范围时填写开始和结束时间，点击“查询事件”。
点击事件行或“查看”，打开详情。
阅读首次发现、最近一次确认、相关信息和“事件进展”，点击“打开对应管理页面”处理原因。

时间筛选在“正在发生”时按最近一次确认时间查找，在“已恢复”时按恢复时间查找；它不是按首次发现时间统一筛选。开始时间包含在内，结束时间不包含在内。

图9-2：事件进展保留“发现问题”“影响升级”“问题恢复”的时间。打开详情不会改变问题状态。

目前会汇集哪些问题

事件来源	可能看到的事件	通常去哪里处理
模型预算	模型预算压力。	用量与费用：核对费用、未知数据、预算及超额处理。
模型主路由	模型主路由持续失败。	模型服务和模型调用：核对近期失败、当前配置和上游情况。
工作空间运行环境	运行环境启动失败、运行环境状态不一致。	工作空间：核对状态、代次、容量和维护过程。
定时任务	定时任务自动暂停。	通过对应管理入口查看相关审计，再由任务所有者检查和处理定时任务。

“严重”需要优先处理，“重要”表示部分功能已受影响，“提醒”表示管理员需要知晓。选择状态或筛选条件后，应结合当前列表理解统计，不把已恢复记录当成仍在发生的问题。

没有事件，不一定代表已经检查过一切

“事件数据更新”展示系统从各来源收集事件的最近成功时间和失败原因。它有“正常”“更新失败”“尚未更新”“更新延迟”等状态；最近成功更新超过3分钟时显示延迟。

更新失败表示收集事件失败，并不直接等于对应功能不可用；反过来，尚未更新也不能证明功能正常。先到相关功能页核对实际状态，再处理事件收集问题。

页面通常每60秒刷新一次。点击“加载更多”查看后续记录时暂停自动替换列表，避免打断阅读；需要新状态时点击“手工刷新”。“事件动态”按时间倒序展示最近的问题变化。

2.用平台运行页检查整体状态

打开“运行与维护→平台运行”。顶部展示最近检测时间、新任务启动状态和运行概况。

图9-3：基础服务状态与新任务启动开关是两件事。恢复开关不会修复模型、容量或业务凭据。

看顶部是否显示“新任务启动已暂停”，以及运行中、排队中任务数量。
查看“基础服务检测”中优先排在前面的故障、警告或未知项，阅读检测说明和时间。
需要最新基础服务状态时点击“重新检测”。这项检测只读，不调用真实AI模型。
运行异常与告警涉及员工环境时，转到“工作空间”。容量信息缺失或超过5分钟时，在工作空间页点击“重新检测容量”。

“平台运行平稳”表示当前已读取的检查结果没有显示相应异常，不代替模型真实调用验证。平台页重新检测不会更新工作空间容量采集时间，也不会自动修复故障。

“运行异常与告警”汇集失败环境、容量受限、Docker存储告警和容量未确认等项；同一工作空间可能涉及多个问题，不应直接把该数当作受影响员工总数。

什么时候暂停启动新任务

需要维护基础服务或防止故障继续扩大时，可以暂时停止接收和启动新任务，同时保留当前运行中的任务。

在“新任务准入控制”阅读当前状态、变更人、变更时间和原因。
点击“暂停启动新任务”。
阅读影响，填写原因，点击“确认暂停启动新任务”。
核对状态变为“已暂停启动”，并确认操作已写入审计。

暂停后，不能创建新任务，排队中的任务不会开始运行，也不会启动新的运行环境；正在运行的任务不会被取消。这是全平台控制，会影响所有员工，不能代替取消某位员工的单项任务。

处理完问题后怎样恢复

先检查基础服务和工作空间容量，确认原问题已处理，再点击“允许启动新任务”，填写原因并确认。成功后平台重新允许创建和启动任务，也会检查等待队列；工作空间容量、业务系统和凭据仍各自需要通过检查。

如果状态变更提示冲突，说明他人或系统已经更新了状态。重新读取后再判断，不要直接重复原操作。

3.理解备份、恢复和导出各自解决什么问题

操作	用途	对当前员工资产和环境的影响
备份	保存一个以后可以回到的时间点，形成“恢复点”。	手工备份会停止目标运行环境，完成后保持停止；不删除当前资产。
恢复	把当前员工资产替换为恢复点中的状态。	取消未结束任务、停止环境、替换当前资产，完成后尝试恢复运行环境。不能自动撤销。
导出	把员工资产打包下载，用于交接或留存。	管理员只能为已停用员工代导出；导出不是点击即可恢复的恢复点。
重建运行环境	重新准备执行程序的容器。	继续使用当前工作空间文件，不会把文件退回某个历史时间点。

员工资产包括工作目录、个人目录，以及会话、已结束任务、个人Skill、安装记录、个人记忆和定时任务等可移植信息。归档不包含容器系统层，也不会把平台管理的凭据作为可移植凭据一起导出。目录文件本身仍可能含业务资料或员工保存的敏感内容，下载后按资料实际内容保管。

这里的“备份与恢复”面向员工工作空间资产，不是整个部署、数据库或所有服务的完整灾难恢复入口。界面可以查看每日备份形成的恢复点，但没有设置每日备份计划、保留期限或删除恢复点的按钮。

4.手工保存一位员工的恢复点

打开“运行与维护→备份与恢复”。页面分为“员工工作空间”“恢复点”“导出包”三个页签。

图9-4：先定位员工和运行影响，再执行备份。顶部历史失败记录是累计事实，不等同于当前故障数。

在“员工工作空间”搜索员工姓名或登录名。
核对账号状态、Workspace/Runtime状态、运行中和排队任务数量。
点击目标行“立即备份”。
阅读当前运行环境和任务影响，填写原因，点击“确认创建手工备份”。
完成后记录恢复点编号，切换“恢复点”核对状态、快照时间和文件大小。展开行可以查看文件数、源数据量、完成时间和失败原因。

为了取得一致的文件和记录，备份会取消该员工所有未结束任务，包括运行中和排队任务，并停止目标运行环境；已经发生的业务操作不会自动撤销。手工备份完成后环境保持停止；不要把没有自动重新运行视为备份失败。

“创建中”表示尚未形成可用恢复点；“失败”应展开查看原因。“可恢复”才表示可以作为恢复来源。“历史失败记录”不会因为后来备份成功而归零。

如果操作报错但不清楚结果，先“刷新状态”，查看是否已经出现恢复点和对应审计，不要立即重复创建。

5.从恢复点恢复员工资产

恢复会覆盖当前资产。执行前必须核对员工、快照时间和要找回的内容，判断快照之后的文件、会话或配置是否仍需要保留；如需保留当前资产，应先形成可用的当前备份或导出。对于真实业务数据，按所在环境的授权和恢复验证要求安排操作。

切换“恢复点”，选择员工及恢复点状态。
找到正确的快照时间，展开检查恢复点ID、文件数、源数据量、最近恢复和失败原因。
点击“恢复”。已完成过恢复的恢复点可能显示“再次恢复”，它仍会再次覆盖当前资产。
阅读替换范围、取消任务及运行环境影响，填写原因，点击“确认恢复员工资产”。
等待结果并点击“刷新状态”。检查恢复点状态、最近恢复时间，以及工作空间运行状态；再由员工核对所需文件和会话。

恢复点中原为活动或暂停的定时任务，恢复后统一保持暂停，需要员工检查后手动恢复，避免旧任务自动执行。

当前仅“可恢复”和已完成收尾的“已恢复”记录允许恢复。“恢复中”不可重复提交；“等待清理”表示资产已恢复但收尾尚未完成，也不能重复恢复。失败或已过期恢复点不是可用恢复来源。

特别注意“资产已恢复，运行环境启动失败”

这表示文件和可移植信息已经替换成功，失败发生在随后启动环境的阶段。按页面提示到“工作空间”检查并处置环境，不要为了让环境启动而再次恢复同一个恢复点。

恢复界面没有“撤销恢复”按钮。若要回到恢复前状态，需要另一个已经保存并验证可用的恢复点；并非所有情况都能恢复，所以先判断覆盖影响比反复点击恢复更重要。

6.为停用员工代导出并下载

代导出用于员工离职或停用后的资产交接。活跃员工不能由管理员代导出，“代导出”按钮会不可用。

在“员工工作空间”找到已停用员工，核对身份和归属。
点击“代导出”，阅读包含范围，填写原因并确认。
切换“导出包”，按员工或状态筛选，确认包为“可下载”。
检查过期时间和大小，展开查看来源、原因、文件数、完成时间和失败原因。
对管理员代导出的可用包点击“下载”，确认浏览器已经取得文件。

导出包有效24小时，过期前可重复下载。下载仍检查当前登录身份及导出归属，不是拿到包编号就能任意下载。管理员页面不会提供员工自助导出包的下载入口。

“创建中”“失败”“已过期”不能下载；失败时先查看原因，过期时需要重新形成导出包。下载或代导出操作会留下审计记录。导出包不能在此页上传为新的恢复点。

7.用审计事件还原一次管理操作

打开“运行与维护→审计事件”。它适合回答“谁改了预算”“什么时候暂停平台”“某次恢复到底成功了没有”等问题。

图9-5：先缩小时间和目标范围，再展开单条记录核对标识及补充记录。

设置开始和结束时间，默认最近7天。开始时间包含在范围内，结束时间不包含在范围内。
按需要选择“事件类型”“执行结果”“操作者”。操作者下拉列出管理员；不指定时还可以看到系统和员工相关记录。
如果已知目标，填入完整账号、员工、工作空间或任务编号，点击“查询”。此字段接受编号，不是姓名关键词。
查看发生时间、事件、成功/失败/处理中、操作者、目标和关键摘要。
展开行首箭头，核对审计记录编号、请求标识、相关工作空间、会话或任务编号及补充记录。点击复制按钮可把标识交给排查人员。

操作原因是管理员对目的的说明，操作结果才是平台记录的实际状态。看到“处理中”时，继续核对业务页面和后续记录；看到一条成功记录也要明确它对应的具体动作，不能拿“配置已保存”代替“环境已应用成功”。

导出审计记录

先在页面确认筛选结果。
点击“导出CSV”，阅读导出范围并点击“确认导出审计CSV”。
确认文件已下载，核对页面显示的导出条数和导出审计事件编号。

导出使用当前筛选条件，最多31天、10000条。超过限制时应缩小时间或事件范围，分批导出；不要认为已下载一部分就覆盖了全部调查范围。导出行为本身也会写入审计。

CSV可能包含员工身份、对象编号及操作摘要，交付给需要使用这些记录的人，并按组织要求保管。

8.按症状走一遍排查路径

大量员工突然不能提交任务

先看“平台运行”是否暂停新任务，以及基础服务状态；再看“运营事件”是否有预算、路由或运行环境问题。平台处于暂停时，先确认最近变更原因及维护是否结束，再决定恢复。不要先批量重建员工环境。

只有一位员工的任务一直等待

在“任务管理”查该员工的运行和等待任务，再到“工作空间”核对启动状态、容量采集时间、账号和维护状态。达到并行度时等待已有任务结束；容量未知时重新检测；处于恢复或配额维护时先完成该操作。

任务开始后失败，模型调用没有记录

先读取任务终止原因。鉴权、模型路由或预算等前置拒绝未必产生实际调用记录。核对模型是否在执行引擎中开放、是否有默认模型、预算是否硬限额；需要日志时保存请求标识交给运维人员。

恢复后文件已回来，但员工仍不能工作

先确认是否属于“资产恢复成功、运行环境启动失败”。检查工作空间运行状态、容量和运营事件，再处置环境。不要重复恢复已经成功的资产，也不要把当前容器失败直接解释为恢复点无效。

操作超时，不知道有没有生效

保留页面提示与发生时间，刷新对应功能，查审计事件和对象当前状态。确认实际结果后再决定重试。模型配置、配额、恢复等操作有不同阶段，一次请求报错不代表此前每一步都没有完成。

交给运维或研发时保留哪些信息

记录环境名称、发生时间、员工或工作空间标识、任务标识、错误提示、当前状态及已执行的动作。有请求标识或审计事件编号时一并提供。只提供必要业务信息，不在普通截图或交流正文中粘贴API Key、密码或其他凭据明文。