私有化办公系统里，几台服务器显示的时间一样，不足以证明时间同步已经合格。它们可能共同跟随了一个不准确的内网时间源，也可能仍显示上一次选中的源，而新的测量早已停止。验收需要分别确认节点是否一致、参考时间是否可信且持续更新、实际偏差与业务表现是否符合约定。
这篇文章面向负责内网部署与运维交接的团队，使用 chrony 4.9 的官方字段作为 Linux 环境示例。只有实际环境使用 chrony 时才套用这些字段；本文不说明石墨办公的私有部署产品采用哪种授时组件，也不替具体部署设定统一的秒数门槛。
先区分时区显示、节点一致与真实时间
网络时间协议 NTP 用于在网络中同步时钟。所参考的NTP 入门文章提出了内部时间源和定期验证的方向，但具体命令、精度和网络条件应以当前组件官方文档及部署环境为准，不能直接当成办公平台的验收标准。
两份日志一个显示 UTC，一个显示北京时间，显示差异不一定是时钟漂移；先按时区标记转换到相同时间表达，再判断事件间的偏差。systemd 手册把系统时钟与时区作为不同设置项。调整显示时区不能代替时间同步核验。
反过来，节点之间显示一致也可能缺少可靠的外部参考。chrony 的 local 模式说明明确区分了内网计算机相互同步与真实时间准确性：在没有外部源的情况下，服务仍可向客户端表现为已同步。因此，隔离环境应说明采用何种时间基准、谁维护它，以及准确性边界。
看到星号或收到响应，为什么仍要继续检查
在已安装 chrony 的节点，可由运维人员使用 chronyc tracking 与 chronyc sources -v 读取状态。这两项是本文的只读检查示例，不要求改配置、重启服务或手工校时。
| 证据 | 可以说明什么 | 不能单独证明什么 |
|---|---|---|
| sources 中的 * | 当前选中的同步源 | 该源此刻仍可达；官方 FAQ 说明失联后可能继续保留选中状态 |
| Reach 与 LastRx | 近期响应情况，以及最近一次可用样本距今多久 | 仅有响应不等于新测量持续参与校时 |
| tracking 的 Ref time | 上次处理参考源测量的 UTC 时间 | 不能将陈旧测量当作本次检查的新结果 |
| System time 与 Leap status | 系统时钟与 chronyd 的 NTP 时钟偏差，以及同步状态线索 | 单个小偏差或 Normal 状态不是独立的 UTC 准确性证明 |
chronyc 手册说明，Reach 显示为 377 表示最近八次轮询收到了有效响应或样本，但质量不足的样本仍可能被丢弃。官方 FAQ还举出 Reach 保持 377、LastRx 却持续变旧的情况。监控只盯进程、端口、星号或响应计数，都可能漏掉“还在通信，但没有新鲜可用测量”的状态。
读数还要带上环境：节点名称、查询时刻、所选源、实际组件版本、是否使用 local 模式。对来源不可信或已经失联的情况，不能只拿节点之间相差很小作为通过依据。
将失联与恢复写进可执行的验收条件
上线前由部署和业务负责人约定允许偏差、观察周期、离线容忍范围及异常负责人。偏差要求应来自实际业务和组件约束，不直接套用网上的“统一标准”。验证时同时保存参考源状态与各节点状态，才能区分源本身的问题和单个节点的问题。
- 正常状态：检查来源符合既定方案，测量时间持续更新，实际偏差满足约定。业务日志以带时区的方式记录，方便跨节点对照。
- 受控失联：在获准的测试环境与窗口内，验证既定告警和处置流程。记录测量变旧时怎样识别，不能只等进程退出。
- 恢复之后：确认新的可用测量重新到达、校正达到约定，再验证代表性的登录、文档保存和日志关联等实际业务。网络恢复并不等于时钟已经校正完成。
这些业务操作是建议的验收样本，不是时间偏差一定会引发对应故障的断言。若需要时间跳变，必须走环境既有的变更流程。chrony 对 makestep 的说明警告，突然改变系统时间可能严重影响某些软件；不应为了快速拿到正常读数就直接跳时，更不能关闭认证或证书的时间检查来掩盖问题。
把“谁保证时间”写进部署交接
交接材料至少包含时间源归属与维护人、节点清单、只读检查方法、通过条件、失联与恢复证据，以及无法对真实时间作保证的范围。这样遇到“日志先后顺序看起来不对”时，团队知道应先查时区、节点还是上游来源。
评估石墨办公套件私有部署时，可通过预约演示沟通部署环境与实施边界，并由实际交付团队确认基础设施责任。文档平台、身份系统和基础设施各自负责哪些检查，需要明确交接；一张显示“时间正常”的截图不足以完成这件事。也可以先看私有化部署方案，了解部署形态与交付范围。