Summary

Severity reasoning: 用户可见的严重性能下降（p99 15s vs 80ms基线），8%请求失败，影响核心商品浏览功能，且发生在黑五高收入时段，符合SEV1定义。

deepseek-chat·prompt v1·output: zh·14977ms·1835↑ / 1842↓ tok·$0.00252

Root cause hypotheses

• high缓存键统一在09:00 UTC过期，导致所有请求同时穿透至数据库

  Evidence: Redis缓存命中率从98%骤降至5%，日志显示08:59:58最后一次缓存命中，09:00:00开始大量'cache miss + DB query'日志

• high黑五营销邮件导致流量突增12倍，超出数据库连接池容量

  Evidence: 09:00 UTC流量为正常12倍，DB连接池在09:00:02达到上限，查询开始排队

• medium数据库锁等待加剧性能问题，导致CPU 100%

  Evidence: Postgres CPU 100%且锁等待持续攀升，表明查询互相阻塞

• high预缓存TTL设置不当（7小时），未考虑黑五流量模式

  Evidence: 缓存预加热在02:00 UTC，TTL 7h正好在09:00过期，与流量高峰重合

Investigation checklist

1. 确认当前数据库连接数和活跃查询

   SELECT count(*) FROM pg_stat_activity WHERE state = 'active';

   Copy

   Expected: 活跃连接数接近max_connections（如200），大量查询处于'active'状态

2. 检查是否有长时间运行的查询阻塞

   SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 10;

   Copy

   Expected: 多个查询运行超过10秒，且查询内容为商品详情SQL

3. 确认Redis缓存键的过期时间分布

   redis-cli -h <redis-host> -p 6379 SCAN 0 MATCH 'catalog:item:*' COUNT 1000 | xargs -I {} redis-cli -h <redis-host> -p 6379 TTL {} | sort | uniq -c | sort -rn

   Copy

   Expected: 大量键TTL为0或接近0，表明同时过期

4. 查看catalog-svc的请求速率和错误率

   kubectl -n production top pods -l app=catalog-svc

   Copy

   Expected: Pod CPU和内存使用率接近上限，请求速率异常高

5. 检查数据库CPU使用率是否由慢查询导致

   SELECT query, calls, total_time / calls AS avg_time, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;

   Copy

   Expected: 商品详情查询（如SELECT * FROM items WHERE id = ?）平均执行时间远高于基线

Mitigation plan

• 立即启用catalog-svc的限流机制，将请求速率限制在正常流量的2倍，保护数据库

  Risk: 部分用户会收到429限流错误，但可防止数据库完全崩溃

  Rollback: 关闭限流：kubectl annotate ingress catalog-svc-svc nginx.ingress.kubernetes.io/limit-rps-

• 手动预热缓存：通过脚本批量查询热门商品ID，将结果写入Redis，设置TTL为2小时（错开过期时间）

  Risk: 预热查询本身会增加数据库负载，需控制并发度（如每次10个查询，间隔100ms）

  Rollback: 停止预热脚本，并删除已写入的缓存键：redis-cli -h <redis-host> KEYS 'catalog:item:*' | xargs redis-cli DEL

• 临时增加数据库连接池大小（如从200增至400），并重启catalog-svc以应用新配置

  Risk: 过多连接可能导致数据库内存压力，需监控

  Rollback: 恢复连接池大小并重启：kubectl set env deployment/catalog-svc DB_POOL_SIZE=200 && kubectl rollout restart deployment/catalog-svc

Customer impact

黑五期间，所有访问商品详情页的用户遭遇严重延迟（15秒以上），约8%的请求直接失败（503）。用户无法正常浏览商品，可能导致购物车放弃和收入损失。预计在缓存预热完成后15分钟内恢复。

Postmortem draft

Follow-ups

• P0实现缓存键TTL随机化，避免同时过期— service owner
• P0引入singleflight模式防止缓存穿透— service owner
• P1黑五前进行全链路压测，模拟缓存雪崩场景— platform team
• P1增加缓存命中率告警（低于90%触发）— on-call SRE
• P2审查所有预缓存任务的TTL设置，确保错开过期时间— service owner
• P2编写缓存雪崩应急手册，包含自动限流和预热脚本— on-call SRE