Summary

Severity reasoning: 用户可见的结账失败（收入影响），错误率 12%，影响范围广（所有使用 payment-svc 的客户），且当前无自动恢复机制，需人工干预。

deepseek-chat·prompt v1·output: zh·11801ms·1769↑ / 1941↓ tok·$0.00261

Root cause hypotheses

• highv2.41 新增的定时任务（cron: */30 * * * *）执行全表扫描查询 SELECT * FROM ledger_entries WHERE status='pending'，因 status 列无索引，扫描 1200 万行，耗时 2.4s，每30秒运行一次，导致连接长期占用。

  Evidence: 慢查询日志显示该查询每30秒执行一次，耗时约2.4s；deploy 历史显示 13:50 部署 v2.41，新增该定时任务。

• high数据库连接池耗尽（max_connections=500），新连接被拒绝，导致 payment-svc 无法获取数据库连接，返回 500 错误。

  Evidence: 应用日志显示 'FATAL: sorry, too many clients already' 和 'connection refused'；Postgres 指标 active_connections=500/500。

• medium慢查询阻塞了其他正常查询，导致请求排队，进一步加剧延迟和错误。

  Evidence: Postgres 指标 waiting_queries=87，表明大量查询在等待锁或资源。

• lowv2.41 部署本身存在内存泄漏或线程泄漏，导致连接池耗尽。

  Evidence: 无直接证据，但部署后立即出现症状，需进一步排查应用指标。

Investigation checklist

1. 确认数据库连接池是否耗尽

   kubectl exec -n prod deployment/payment-svc -- pg_isready -h postgres-primary -U app -d paymentdb

   Copy

   Expected: 返回 'connection refused' 或超时，确认连接池满

2. 查看当前活跃连接和等待查询

   psql -h postgres-primary -U postgres -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';" -c "SELECT count(*) FROM pg_stat_activity WHERE wait_event IS NOT NULL;"

   Copy

   Expected: 活跃连接接近500，等待查询数>0

3. 检查慢查询日志，确认全表扫描查询

   psql -h postgres-primary -U postgres -c "SELECT query, calls, total_time, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;"

   Copy

   Expected: 看到 SELECT * FROM ledger_entries WHERE status='pending' 总耗时最高

4. 验证 ledger_entries 表 status 列是否有索引

   psql -h postgres-primary -U postgres -c "\d ledger_entries"

   Copy

   Expected: status 列没有索引（只有主键索引）

5. 确认定时任务是否由 v2.41 引入

   kubectl logs -n prod deployment/payment-svc --since=13:50 | grep -i 'settlement\|batch\|cron'

   Copy

   Expected: 看到 'Starting settlement batch' 或类似日志，每30分钟出现

6. 检查 payment-svc 连接池配置

   kubectl exec -n prod deployment/payment-svc -- cat /app/config.yaml | grep -A5 'datasource\|hikari\|connection'

   Copy

   Expected: 确认 max-pool-size 是否设置为500或更高

Mitigation plan

• 立即禁用 v2.41 引入的定时任务（通过配置或 feature flag），停止全表扫描查询。

  Risk: 定时任务功能（结算批处理）暂时不可用，但无数据丢失风险。

  Rollback: 重新启用定时任务（恢复配置或 flag）

• 临时增加数据库 max_connections 到 800（若资源允许），并重启 payment-svc 以释放连接。

  Risk: 增加连接数可能消耗更多内存，需监控 DB 内存使用。

  Rollback: 恢复 max_connections 为 500，并重启 DB 或 reload 配置

• 为 ledger_entries.status 列创建索引，加速查询。

  Risk: 创建索引期间可能短暂锁表，影响写入。建议在低峰期或使用 CONCURRENTLY。

  Rollback: 删除索引：DROP INDEX IF EXISTS idx_ledger_entries_status;

• 回滚 payment-svc 至 v2.40（上一个稳定版本）。

  Risk: 回滚期间服务短暂不可用（滚动更新），但可快速恢复。

  Rollback: 重新部署 v2.41（修复后）

Customer impact

客户在结账时遇到失败（HTTP 500），无法完成支付。影响所有使用 payment-svc 的用户，预计在实施缓解措施后 15-30 分钟内恢复。

Postmortem draft

Follow-ups

• P0为 ledger_entries.status 列创建索引（使用 CONCURRENTLY 避免锁表）— 数据库管理员
• P1增加数据库连接池使用率告警（>80%）— on-call SRE
• P1审查 v2.41 代码，确保定时任务使用只读副本或添加索引— 服务负责人
• P2更新部署流程，要求变更前进行性能影响评估— 平台团队
• P2为 payment-svc 添加慢查询检测和自动熔断机制— 服务负责人
• P2编写 postmortem 文档并在团队内分享— on-call SRE