在线编辑服务的进程仍在运行，不代表该实例此刻适合接收新请求；实例不再接常规流量，也不代表已有编辑连接已经转移。评估高可用时，应分别确认存活判断、接流资格和现有会话的实际结果，不能只收一个“健康检查正常”的截图。
本文面向企业架构师与实施人员，以 Kubernetes 的公开探针和端点语义解释这几种状态。它只是机制例子，不表示目标办公产品采用 Kubernetes，也不提供生产配置或故障切换承诺。以下用例为待执行设计，未操作集群、删除实例或进行产品实测。
存活与就绪，触发的处理不同
Kubernetes 官方探针说明将 liveness 与 readiness 分开：前者用于判断何时需要重启容器，后者用于判断是否准备好接收流量。存活检查在达到失败容限后可触发容器的重启处理；就绪检查失败则将容器标为不就绪，影响匹配 Service 的流量资格，容器仍可继续运行和接受后续探测。
所以“进程还在”和“入口不再把常规请求发给它”可以同时成立。这里讨论的是容器与服务实例，不是把就绪失败认作整台物理服务器宕机。项目若采用其他编排或负载均衡方案，也应把各自的状态与响应动作写清楚，不照搬名称就认为语义相同。
慢启动还要与运行中失去响应区分。官方说明，配置 startup probe 时，在其成功之前不执行 liveness 和 readiness。是否采用这种机制、容许多长初始化时间，应依据实际启动过程与版本约定；不能把所有失败都用增加等待时间处理。
先问探针证明了什么，再看它是否通过
探测方式决定证据范围。前述官方文档中的 TCP 检查以端口能否建立连接为判断依据；HTTP 检查按其响应规则判断。端口能连通，或某个路径返回满足规则的状态码，都不等于用户已经成功打开文档、开始编辑并完成保存。
接入验收应要求一份对应关系：探针检查了哪项内部条件，该条件变化会触发什么处理，哪些业务路径不在其覆盖范围。不要让一个始终返回成功的页面承担所有健康语义，也不要为了“更严格”把每次复杂文件编辑塞进高频存活检查。
存活检查要重点回答“重启是否有助于修复这个实例的故障”。AWS 的探针与负载均衡健康检查指南提醒，不恰当的依赖检查可能导致级联问题。例如，共享依赖出现问题时，重启所有应用实例未必解决依赖故障，却可能扩大影响。依赖条件是否进入就绪判断，应结合实际服务关系和降级策略设计，不能给所有系统套同一个探针函数。
ready 为 false，不等于所有工作已经停止
Kubernetes 的端点终止流程示例展示，终止中的端点可以同时具有 ready=false、serving=true 和 terminating=true。ready 用于常规接流判断，而 serving 可为支持相应语义的客户端提供额外状态。这些字段并不互相矛盾。
这个例子有助于解释：从常规接流范围摘除，与进程退出、既有连接结束，是不同事件。客户端是否利用这些状态执行连接排空，取决于真实实现；不能只看到一个状态变为 false，就推断旧 WebSocket 已经迁往另一个实例，也不能反过来保证旧连接一定不断。
有多个副本，同样不能自动回答现有会话如何恢复。要继续确认实际请求入口、负载均衡的状态更新、已有连接的处理，以及应用在重连后的鉴权与状态恢复协议。实例数量、探针恢复和业务连续性各有自己的证据。
入口健康检查也应单独核对
应用探针与负载均衡的健康检查，可能由不同组件执行、使用不同路径和更新节奏。前述 AWS 指南也将它们分别说明。实施方应指出每一项检查的执行位置和流量影响范围，不应认为应用内部已不就绪，所有入口就会在同一瞬间停止新请求。
先列实际存在的入口与实例关系，再核对状态怎样传播。项目没有某个组件，就不为凑架构图补上它；某条入口无法观察时，记录为证据缺口。不要引用另一个云服务的默认延迟作为本项目的摘流时间承诺。
验收时同时观察一条旧连接和一次新请求
可以在授权隔离环境，用合成文档和测试身份安排一组状态变化。先约定通过条件、恢复方式及负责人，再按产品支持的测试方法执行；本文没有运行任何故障操作，也不建议直接在生产修改探针。
| 情形 | 分开记录 | 不能直接推断 |
|---|---|---|
| 存活通过，就绪失败 | 实例是否继续运行，新请求实际去向 | 容器已经重启或服务器宕机 |
| 存活失败达到约定条件 | 容器变化、重启处理和恢复过程 | 全部业务立即恢复 |
| 就绪状态恢复 | 入口是否重新选用实例，新请求结果 | 旧会话已经迁移 |
| 状态变化期间已有编辑连接 | 原连接、重连与应用可见状态 | 连接恢复等于内容保存完成 |
使用统一时间口径，将探针结果、容器变化、端点或入口资格、新请求和已有连接的记录关联起来。重连成功后再验证约定业务动作；保存与读回按独立流程核对，不用“健康”替代最终文件结果。无法观察的阶段保持未知，不填成通过。
评估石墨办公文档中台私有部署的高可用方案时，可带上实际拓扑、业务入口与可接受的中断范围，预约架构演示，请实施方明确每项健康状态改变什么、已有编辑如何恢复、哪些结果需要另行验证。本文不预设产品的编排平台、探针接口或无感切换能力。也可以先看私有化部署方案，了解部署形态与交付范围。