石墨协同编辑不可用故障案例

1. 案例背景

某大厂环境出现协同编辑不可用类故障，影响用户对部分表格和文档的正常编辑与保存。故障过程中，用户侧看到保存失败、编辑卡顿、Kafka 写入超时等现象；服务侧同时出现对象存储读取慢、节点 CPU 异常、TCP/FD 指标异常等问题。

本案例用于说明：协同编辑不可用并不一定由编辑服务本身直接引起，也可能由底层资源超卖、节点调度集中、中间件写入变慢、对象存储读路径异常、连接泄漏等问题共同放大。

2. 故障表现

本次故障的主要影响表现为：

协同编辑链路不可用、卡顿或接口超时。

部分表格或文档无法正常保存。

编辑侧弹窗提示 kafka 写入超时。

对象存储读取耗时升高，进一步影响编辑链路处理。

Pod 监控看似正常，但用户侧持续反馈保存失败、编辑卡顿、接口超时。

3. 初步排查过程

3.1 从用户现象进入编辑链路

客户最先反馈的是部分文档异常，因此初始排查方向按照协同编辑问题展开：

检查编辑保存链路。

检查相关服务日志。

检查 Kafka 写入情况。

检查对象存储读写耗时。

排查中发现两个重要异常：

编辑链路出现 kafka 写入超时。

对象存储读取耗时异常。

3.2 外部依赖初步确认

排查过程中分别与外部依赖负责人确认：

与对象存储侧确认，未发现云厂商侧明显异常。

与 Kafka 运维确认，未发现 Kafka 集群侧明显异常。

因此，问题不能直接归因于对象存储或 Kafka 服务本身，需要继续向本地业务节点、网关、连接池、网络和资源层排查。

3.3 从 Pod 监控转向 Node 监控

最初查看 Pod 监控时，CPU 和内存均在相对安全范围内，但客户反馈 Node 节点 CPU 被打满。

这一点是本次定位的关键转折：

在资源超卖情况下，Pod 监控不一定能真实反映节点压力。

Node CPU 打满后，容器内业务处理能力下降。

业务处理变慢后，会进一步表现为对象存储读慢、Kafka 写慢、请求堆积和保存失败。

4. 故障影响链路

5. 关键发现

5.1 节点 CPU 异常

多个 Node 节点按时间先后出现 CPU 异常：

10.142.191.54 在 18:20 开始异常。

10.76.176.65 在 18:30 开始异常。

10.76.238.202 在 18:40 开始异常。

10.142.206.216 在 18:42 开始异常。

10.142.175.191 在 18:45 开始异常。

可以看到，最早出现异常的是 10.142.191.54，随后其他节点陆续出现 CPU 问题，符合单点资源异常向多节点扩散的特征。

5.2 CPU 与内存超卖

故障前后资源超卖情况如下：

场景	资源	集群容量	Request 总量	Request 占比	Limit 总量	超卖
nodejs-fc pod 6	CPU	192 核	33.75 核	17.6%	457 核	238.0%
nodejs-fc pod 6	内存	768 GiB	57.24 GiB	7.5%	884 GiB	115.1%
nodejs-fc pod 12	CPU	192 核	45.75 核	23.8%	493 核	256.8%
nodejs-fc pod 12	内存	768 GiB	81.24 GiB	10.6%	980 GiB	127.6%
nodejs-fc pod 12 扩容后	CPU	320 核	45.75 核	14.3%	493 核	154.1%
nodejs-fc pod 12 扩容后	内存	1280 GiB	81.24 GiB	6.3%	980 GiB	76.6%

正常情况下，CPU 超卖控制在 150% 左右相对可接受。本次扩容前 CPU 超卖已经达到 238%，翻倍扩容后达到 256.8%，存在很高的突发流量雪崩风险。

5.3 Pod 调度集中

某大厂环境的 K8s 默认调度策略倾向于先把一个节点用满，再使用剩余节点。服务滚动部署或临时扩容时，多个高负载服务容易集中到少数 Node 上。

高风险组合包括：

一个节点上存在多个 svc-nodejs-fc 实例。

同节点同时运行 svc-edit-worker-bigmosheet 和 ingress。

同节点叠加 storage-gateway 连接泄漏或内存上涨。

5.4 Storage Gateway 连接与内存泄漏

进一步检查 Node TCP 监控和 storage-gateway Pod 指标后发现：

total_fd 持续增长。

socket_fd 持续增长。

TCP 连接长期处于 ESTABLISHED。

连接未及时释放，FD 未归还连接池。

Pod RSS / Working Set 持续增长，且回收后不能恢复到正常水位。

如果 total_fd、socket_fd 和内存占用同时持续增加，说明连接未释放已经伴随内存持续增长，需要按连接与内存泄漏处理，并关注所在 Node 的 MemoryPressure 和 OOM 风险。

5.5 版本差异影响

旧版本中，图片附件数据直接写入数据表。新版本为了降低 MySQL 使用和存储成本，将图片附件信息改写入对象存储 Metadata，并使用直接操作对象存储的 /x 读路径。

在代理模式下，判断对象存储 Key 是否存在的底层函数未正确释放连接，引发连接泄漏。该问题叠加资源超卖和调度集中后，被放大为协同编辑不可用故障。

5.6 对象存储与 Storage Gateway 监控证据

为确认问题是否位于对象存储侧、业务服务侧或代理层，本次对对象存储和 storage-gateway 进行了对比排查：

对象存储读耗时升高，写入耗时相对正常，异常主要集中在读路径。

storage-gateway Pod 的 CPU、RSS / Working Set 和内存增长率持续升高。

total_fd 和 socket_fd 持续增长，TCP 连接长期处于 ESTABLISHED。

连接未及时释放，FD 未归还连接池，Node 同时出现内存压力和 OOM 风险。

对象存储侧未发现与业务异常规模相匹配的服务端故障，因此优先将排查重点收敛到 storage-gateway 代理读路径。

综合判断：对象存储读慢并非单纯的对象存储服务故障，而是 storage-gateway 连接未释放后，FD、TCP 连接、内存和节点资源压力逐步累积造成的结果。

5.7 FD/TCP 泄漏判断过程

本次通过以下判断链路确认 storage-gateway 存在连接泄漏：

判断结论：当 total_fd、socket_fd、ESTABLISHED 连接数和 Pod 内存占用在同一时间窗口同步增长时，可将“连接未释放导致的 FD/TCP 与内存泄漏”作为主要根因方向；若对象存储读慢、写正常同时出现上述指标异常，应优先检查代理读路径。

6. 根因结论

本次故障的根因链路为：

集群存在明显 CPU 超卖，部分阶段 CPU 超卖超过 250%。

服务滚动发布或临时扩容时，Pod 调度集中，导致单节点资源压力过高。

svc-nodejs-fc、svc-edit-worker-bigmosheet、ingress 等高负载服务集中在部分节点上。

storage-gateway 在对象存储代理读路径中存在连接未释放问题，造成 FD、TCP 连接和内存占用持续增长。

所在 Node 出现内存压力和 OOM 后，容器重启、镜像拉取、服务冷启动及上游重试进一步推高 CPU、网络和磁盘 IO 压力，造成对象存储读慢、Kafka 写慢。

对象存储读慢和 Kafka 写入超时最终表现为协同编辑不可用、保存失败和编辑卡顿。

7. 节点资源雪崩扩散图

本故障中的业务服务均运行在 K8s 集群中。storage-gateway 内存泄漏首先消耗所在 Node 的可用内存，随后通过 OOM、容器重启、镜像拉取、服务冷启动和上游重试形成资源消耗正反馈；当异常 Pod 被重新调度或流量转移到其他节点后，压力会继续向健康节点扩散，最终造成集群级雪崩。

图中需要重点关注两个放大环：

节点内正反馈环：OOM → kubelet 重启或拉取镜像 → 冷启动 → 上游重试和新连接增加 → CPU、内存、网络、磁盘 IO 压力继续升高 → 再次 OOM。

跨节点扩散环：异常节点上的 Pod 被重调度、入口流量转移或剩余实例接管请求 → 健康节点负载升高 → 其他节点重复出现 OOM 和重启 → 集群可用容量持续下降。

8. 处置与修复

8.1 短期处置

对异常入口或异常节点执行网关流量摘除，先阻断新流量继续进入高压链路。

重启 FD、TCP、内存持续增长的异常服务。

将高负载 Pod 从高压节点迁移或分散。

对 CPU 打满节点进行 Pod 驱逐或节点隔离。

避免只扩容业务 Pod，优先补充 Node 资源。

对 svc-edit 增加 sync 接口快速失败能力，避免请求长时间堆积。

8.2 长期修复

修复对象存储代理模式下判断 Key 是否存在时连接未释放的问题。

为核心服务配置反亲和策略，避免高风险服务集中在同一节点。

配置节点驱逐策略，避免节点资源耗尽后继续承载核心服务。

建立 CPU 和内存超卖监控。

服务扩容前必须评估客户环境资源水位，并与项目负责人确认扩容方案。

对核心服务建立 OOM、FD、TCP、慢请求、Kafka 堆积、对象存储读写耗时告警。

9. 案例复盘结论

本次故障说明：协同编辑不可用不能只盯编辑服务日志排查。若底层节点资源已经打满，业务服务会整体处理变慢，并表现为 Kafka 写入超时、对象存储读慢、保存失败等多个上层症状。

后续处理类似问题时，应优先确认集群和 Node 资源，再逐层进入中间件、业务监控、日志和 Trace 链路，避免从单个服务日志开始陷入局部排查。

1. 案例背景#

2. 故障表现#

3. 初步排查过程#

3.1 从用户现象进入编辑链路#

3.2 外部依赖初步确认#

3.3 从 Pod 监控转向 Node 监控#

4. 故障影响链路#

5. 关键发现#

5.1 节点 CPU 异常#

5.2 CPU 与内存超卖#

5.3 Pod 调度集中#

5.4 Storage Gateway 连接与内存泄漏#

5.5 版本差异影响#

5.6 对象存储与 Storage Gateway 监控证据#

5.7 FD/TCP 泄漏判断过程#

6. 根因结论#

7. 节点资源雪崩扩散图#

8. 处置与修复#

8.1 短期处置#

8.2 长期修复#

9. 案例复盘结论#