[Eval][v3][zh] Order service OOM crashloop following v3.7 deploy

service: order-svccreated: 6/2/2026, 11:54:49 PM

Raw incident context

Time: 09:15 UTC. order-svc pods entering CrashLoopBackOff with OOMKilled exit reason.

Kubernetes:
- Pods: 12 total, 3 currently OOMKilled, 9 running
- Memory limit: 512Mi, requests: 256Mi
- Recent restarts/hour: 18 (up from baseline of 0–1)
- HPA scaling has hit max replicas (12)

Memory trend (last 24h):
- Steady linear growth from 180Mi at 04:00 UTC to 500Mi at 09:00 UTC, then crash
- Pre-deploy baseline: stable at 200Mi indefinitely

Deploy history:
- 04:00 UTC — order-svc v3.7 deployed (rolling, 100% complete by 04:08)
- Changelog: "switched JSON parser to fast-json-stringify; added in-process request cache (Map-based, no eviction)"

Logs:
- No FATAL/ERROR pattern; pods exit silently
- Heap profile from one captured pod shows: ~340Mi held by Map keyed on request ID, never cleared

On-call:
- 09:12 — first OOMKilled pod
- 09:14 — pager
- 09:16 — service still serving most traffic via remaining pods; checkout success rate dipped from 99.7% → 96.8%

Summary

SEV1

order-svc 自 09:12 UTC 起出现 Pod OOMKilled 重启循环，p99 延迟升高，约 3% 请求超时。根因是 v3.7 部署引入的内存泄漏：基于 Map 的请求缓存无驱逐策略，导致内存线性增长直至 OOM。当前 12 个 Pod 中 3 个已 OOMKilled，HPA 已达最大副本数，无法自动扩容。

Severity reasoning: 用户可见的故障：结账成功率从 99.7% 降至 96.8%（>1% 错误率超过 5 分钟），且影响收入路径（结账流程）。符合 SEV1 标准。

deepseek-chat·prompt v3·output: zh·10865ms·2418↑ / 1715↓ tok·$0.00254

Root cause hypotheses

highv3.7 部署引入的请求缓存 Map 无驱逐机制，导致内存持续增长直至 OOM。
Evidence: 堆分析显示约 340Mi 被请求 ID 为键的 Map 占用，且从未清理；部署后内存从 180Mi 线性增长至 500Mi。
mediumfast-json-stringify 库存在内存泄漏，序列化后对象未释放。
Evidence: 无直接证据；但变更日志同时切换了 JSON 解析器，可能引入泄漏。
low外部依赖（如数据库）响应变慢，导致请求堆积在缓存中。
Evidence: 无数据库相关日志或指标；但 p99 延迟升高可能加剧缓存堆积。

Investigation checklist

确认当前 OOM 的 Pod 数量及重启频率

kubectl get pods -n prod -l app=order-svc --field-selector=status.phase=Running -o wide && kubectl get events -n prod --field-selector involvedObject.kind=Pod,reason=OOMKilling --sort-by=.lastTimestamp | tail -10

Expected: 显示 3 个 Pod 处于 CrashLoopBackOff，其余运行中；事件列表显示 OOMKilling 时间戳

检查内存使用趋势，确认线性增长模式
```
kubectl top pod -n prod -l app=order-svc --containers | sort -k3 -n
```
Expected: 运行中 Pod 内存使用接近 500Mi，且随时间增长

获取堆转储，确认 Map 大小

kubectl exec -n prod deploy/order-svc -- sh -c 'curl -s localhost:6060/debug/pprof/heap?seconds=30 > /tmp/heap.pprof' && kubectl cp prod/$(kubectl get pod -n prod -l app=order-svc -o jsonpath='{.items[0].metadata.name}'):/tmp/heap.pprof ./heap.pprof && go tool pprof -top -inuse_space ./heap.pprof

Expected: 显示 Map 相关类型占用大量内存，如 map[string]*RequestCache

检查 HPA 状态，确认是否达到上限
```
kubectl get hpa -n prod order-svc-hpa -o yaml
```
Expected: currentReplicas 和 maxReplicas 均为 12，无法扩容
检查部署历史，确认 v3.7 变更内容
```
kubectl rollout history deployment -n prod order-svc
```
Expected: 显示 revision 2 对应 v3.7，时间戳 04:00 UTC

Mitigation plan

立即回滚 order-svc 至 v3.6（上一个稳定版本）
Risk: 回滚期间可能短暂中断连接，但风险低；回滚后缓存丢失，但可接受。
Rollback: 再次执行 kubectl rollout undo deployment/order-svc -n prod --to-revision=1 可恢复至 v3.7
若回滚不可行，临时增加内存限制至 1Gi 并重启 Pod
Risk: 仅缓解症状，不解决泄漏；可能掩盖问题导致更晚发现。
Rollback: 恢复内存限制至 512Mi 并重启
在回滚后，手动删除 OOMKilled 的 Pod 以加速恢复
Risk: 无风险，Kubernetes 会自动重建。
Rollback: 无需回滚

Customer impact

约 3% 的结账请求超时或失败，影响用户完成购买。受影响用户比例约 3%，但结账成功率从 99.7% 降至 96.8%。预计回滚后 5-10 分钟内恢复。

Postmortem draft

摘要

order-svc 因 v3.7 部署引入的内存泄漏导致 Pod OOMKilled，影响结账成功率。

时间线 (UTC)

04:00 - v3.7 部署完成
09:12 - 首个 Pod OOMKilled
09:14 - 分页触发
09:16 - 确认 SEV1
[FILL IN] - 回滚完成

影响

结账成功率从 99.7% 降至 96.8%
3 个 Pod 持续 OOMKilled
p99 延迟升高

根因

v3.7 引入的请求缓存 Map 无驱逐策略，导致内存线性增长直至 OOM。

检测

无内存告警，仅通过 Pod 重启检测到

响应

09:14 分页，09:16 确认严重性，09:20 决定回滚

做得好的

快速识别内存泄漏模式
回滚决策果断

做得不好的

无内存使用告警
变更未进行内存压力测试

行动项

[ ] 为缓存添加 TTL 或 LRU 驱逐策略
[ ] 添加内存使用告警（>80% limit）
[ ] 变更流程增加内存基准测试

Follow-ups

P0为请求缓存添加 TTL 或 LRU 驱逐策略，防止内存泄漏— order-svc 服务所有者
P1添加内存使用率告警，当超过 80% limit 时触发— 平台团队
P1在 CI/CD 中增加内存基准测试，检测回归— 平台团队
P2审查 fast-json-stringify 库的内存使用情况— order-svc 服务所有者
P2增加 HPA 基于内存的扩缩容策略— 平台团队

Similar past incidents

lexical match (pg_trgm)