私有化 Office 升级前，正在编辑的文档保存好了吗？
私有化 Office 升级前，不能只凭页面上的“已保存”提示，就判断所有正在编辑的文档都已收尾。需要确认本次维护范围内的编辑会话已经按约定结束，最终变更进入业务存储，而且文件能够重新打开核对。仍在处理、报错或状态未知的文件，应先明确处理方式，再决定是否停机。
对企业而言，装好软件只是起点。维护窗口里的关键问题是：怎样让进行中的工作安全收尾，谁来确认最后一份文件，以及什么情况下必须暂停。本篇讨论计划维护，不替代具体版本的运维手册。
编辑结束与业务文件保存，要分别确认
以 ONLYOFFICE Docs 为例，官方保存流程说明：所有用户结束编辑后，编辑服务汇总变更，通过回调通知文档存储服务；文档存储服务随后下载并保存最终文件。因此，“编辑服务已经生成结果”和“业务存储已经接收并保存结果”是两个需要衔接的环节。
其回调文档把 status=2 定义为文档已准备好保存，status=6 则对应编辑尚在继续时的当前状态强制保存。前者不能单独证明业务存储已完成落盘，后者也不能当作所有编辑会话都已结束的证据。这些状态码属于 ONLYOFFICE 的特定接口，不代表石墨或其他产品采用同样机制。
ONLYOFFICE 社区版 Docker 升级指南要求更新前备份数据、记录版本，并在停止服务前按其流程断开编辑用户、等待收尾。保存耗时还受转换处理和配置影响，不能用固定等待若干秒替代结果核查。具体停机方式应由运维人员依据实际部署版本执行。
先把维护范围内的新编辑收住
以下是建议的验收设计，需要与产品支持的维护机制对应。先明确维护哪些节点、业务入口和时间窗口，再通知使用者停止新增编辑、完成手头工作。若系统支持限制新会话或维护模式，应核对它覆盖哪些入口；不支持时，也要约定可执行的业务安排，而不是假设所有人都会退出。
统计时要区分“仍然登录的人”和“仍在编辑的会话”。已有页面、移动端入口、嵌入业务系统的编辑页都可能需要单独确认。不能因为首页进不去了，就推断已打开的编辑页已经结束；也不应为了清零计数而直接中断尚未确认的工作。
用文件状态记录决定是否放行
在正式使用前，可以在授权测试环境做一次演练：准备虚构项目文档，让两个测试账号先后加入编辑，分别写入能辨认的测试标记，再按拟定维护流程收尾。这是测试设计，不是已经完成的产品实测。
- 确认编辑收尾：记录测试账号退出或由维护机制断开后的状态，核对是否还有编辑、转换或保存任务未结束。页面关闭只是一个观察点，不是全部证据。
- 确认业务存储接收：由负责存储或集成的人员核对保存结果，记录对应文件版本和错误状态。收到回调与处理成功分开记录，未知结果不填“成功”。
- 读回最终文件：从业务系统实际保存的位置重新打开文档，核对两人的最后变更是否存在、内容是否完整，再由业务代表确认。这比只看服务进程运行更接近使用者的验收目标。
每条记录至少写清文件标识、预期最后变更、编辑结束证据、保存结果、读回结果和确认人。技术日志只保留定位问题所需的信息，不把客户正文或敏感内容复制到公共交接记录。
若保存报错、还有未完成任务、最终版本无法核对，或者维护过程中又产生新的编辑，应暂停本次放行，按对应版本手册处理或重新安排窗口。不能把缺失的最后变更交给升级后的用户自行发现，也不能认为已有备份必然包含尚未完成的编辑。
恢复开放前，再验证一遍实际使用
升级完成后，先由指定测试身份读取维护前确认的文件，核对内容仍在；再做一次新的编辑、保存和重新打开，确认接下来的工作能够继续。满足约定的恢复条件后，再开放业务入口。失败时按已经约定的恢复或回退方案处理，不临时删除旧数据或猜测哪个版本正确。
采购和交付时，可以把这次演练的操作步骤、成功证据与停止条件纳入验收，而不是只收一份安装成功截图。它关注的是一次维护中的在途工作，不等同于灾备恢复演练，也不能证明升级完全不中断。
石墨办公套件私有部署当前官网要求结合项目确认升级、备份恢复与验收责任。带着实际编辑入口、典型文件和可接受的维护窗口预约演示，核对交付版本怎样完成编辑收尾、保存确认和恢复开放，再形成企业自己的维护清单。
在企业文档中验证
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。