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

service: order-svccreated: 6/2/2026, 11:53:25 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 的进程内请求缓存未设置驱逐机制，导致内存线性增长直至耗尽。当前 12 个 Pod 中 3 个已 OOMKilled，其余 9 个运行中，HPA 已达最大副本数。

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

deepseek-chat·prompt v2·output: zh·11917ms·2167↑ / 1820↓ tok·$0.00259

Root cause hypotheses

highv3.7 部署引入的请求缓存 Map 未设置大小限制或驱逐策略，导致内存无限增长直至 OOM。
Evidence: 堆快照显示约 340Mi 内存被以请求 ID 为键的 Map 占用，且从未释放；部署时间与内存增长起始时间吻合。
medium新 JSON 解析器 fast-json-stringify 存在内存泄漏，每次序列化分配内存未回收。
Evidence: 堆快照中未发现明显与 JSON 解析相关的残留对象，且内存增长模式为线性而非阶梯式，与缓存泄漏更吻合。
low上游服务（如支付服务）响应变慢，导致请求堆积在 order-svc 的线程池或缓冲区中。
Evidence: 日志中未发现上游超时或错误率上升，且 order-svc 自身 CPU 和 I/O 正常，排除外部阻塞。

Investigation checklist

确认缓存 Map 的引用链和大小

kubectl exec -n prod -c order-svc $(kubectl get pod -n prod -l app=order-svc -o jsonpath='{.items[0].metadata.name}') -- jcmd 1 GC.heap_dump /tmp/heap.hprof && kubectl cp -n prod $(kubectl get pod -n prod -l app=order-svc -o jsonpath='{.items[0].metadata.name}'):/tmp/heap.hprof ./heap.hprof && echo 'done'

Expected: heap.hprof 文件生成成功，后续用 Eclipse MAT 分析显示 Map 对象占主导

检查 v3.7 部署的代码变更，确认缓存实现
```
kubectl logs -n prod -l app=order-svc --since=1h --tail=100 | grep -i 'cache\|map\|evict' || echo 'no cache logs'
```
Expected: 无相关日志，需查看代码仓库确认缓存实现
验证内存增长趋势与部署时间的关联
```
kubectl top pod -n prod -l app=order-svc --sort-by=memory --no-headers | head -12
```
Expected: 内存使用量从 180Mi 线性增长至接近 512Mi 限制
检查 HPA 是否达到上限导致无法扩容
```
kubectl describe hpa -n prod order-svc-hpa | grep -A5 'Metrics\|Min\|Max\|Replicas'
```
Expected: 当前副本数 12，最大副本数 12，已达上限

Mitigation plan

立即回滚 order-svc 至 v3.6（上一个稳定版本）
Risk: 回滚期间可能短暂中断连接，但服务仍可继续处理已有请求；无数据丢失风险。
Rollback: 若回滚后问题未解决或出现新问题，重新部署 v3.7 并同时启用缓存限制（见后续修复）
在回滚前，临时增加 Pod 内存限制至 1Gi 以争取更多时间
Risk: 可能掩盖根本问题，且节点资源可能不足；若节点内存不足，可能导致其他 Pod 被驱逐。
Rollback: 将内存限制改回 512Mi，并继续执行回滚
如果回滚不可行，则通过环境变量禁用请求缓存（需代码支持）
Risk: 禁用缓存可能导致性能下降，但可立即阻止 OOM；需确认代码支持此开关。
Rollback: 重新启用缓存（设置环境变量为 true）

Customer impact

约 3% 的订单请求超时或失败，影响结账流程。部分用户可能看到错误页面或订单提交失败。当前服务仍处理大部分流量，但性能下降。预计在回滚后 10 分钟内恢复。

Postmortem draft

Summary

[FILL IN]

Timeline (UTC)

04:00 - order-svc v3.7 部署完成
09:12 - 首个 Pod OOMKilled
09:14 - 分页触发
09:16 - 确认错误率上升至 3.2%
[FILL IN] - 开始调查
[FILL IN] - 执行回滚
[FILL IN] - 服务恢复

Impact

影响时间：09:12 - [FILL IN]
错误率：从 0.3% 升至 3.2%
影响用户数：约 [FILL IN] 用户
收入影响：待评估

Root Cause

v3.7 引入的进程内请求缓存（Map 实现）未设置大小限制或驱逐策略，导致内存线性增长直至 OOM。

Detection

Pod OOMKilled 触发 Kubernetes 重启，随后监控告警（Pod 重启率、错误率）触发分页。

Response

09:14 分页响应
09:16 确认严重性并开始调查
[FILL IN] 执行回滚
[FILL IN] 确认恢复

What Went Well

监控告警及时触发
回滚操作快速执行

What Went Poorly

代码审查未发现缓存无限制问题
缺乏内存使用趋势告警
无金丝雀部署策略

Action Items

[ ] 为缓存 Map 添加大小限制和 TTL 驱逐
[ ] 设置内存使用率告警（>80% 限制）
[ ] 实施金丝雀部署
[ ] 代码审查增加内存安全 checklist

Follow-ups

P0为请求缓存添加最大条目限制和 TTL 驱逐机制— order-svc 服务所有者
P1设置 Pod 内存使用率告警（>80% 限制持续 5 分钟）— 平台团队
P1实施金丝雀部署策略，逐步放量— 平台团队
P2代码审查 checklist 增加内存安全相关项（无限制集合、缓存等）— SRE 团队
P2审查 HPA 最大副本数配置，考虑增加上限或基于内存的扩缩容— 平台团队

Similar past incidents

lexical match (pg_trgm)