test: capture ordering regressions and enforce deploy resources

docs/IM-监控运维对接文档.md

@@ -123,7 +123,7 @@ HEALTHCHECK --interval=1m --timeout=3s --start-period=20s \
 | 探针 | 路径 | 初始延迟 | 周期 | 超时 | 失败次数 |
 |---|---|---:|---:|---:|---:|
 | im-server readinessProbe | `/healthz` | 15s | 10s | 3s | 3 |
-| im-server livenessProbe | `/healthz` | 30s | 30s | 3s | 3 |
+| im-server livenessProbe | `/livez` | 15s | 20s | 3s | 3 |
 | im-manager readinessProbe | `/healthz` | 15s | 10s | 3s | 3 |
 | im-manager livenessProbe | `/healthz` | 30s | 30s | 3s | 3 |
 

docs/test/IM-单聊压测Pod日志根因分析与改进方案-20260927.md

@@ -297,3 +297,28 @@ Run ID：`p2p-200-20260927-01`，A/B 两台压测机各模拟 200 个用户，
 - ACK P95 和到达 P95 均落在 2 秒直方图上界，未达 500ms / 1s 门槛。
 - ArgoCD 已将 StatefulSet 资源回滚为 `request 100m/128Mi`、`limit 500m/256Mi`，且 liveness 仍使用 `/healthz`。压测期间存在 CPU throttling 累计，部署配置必须在 GitOps 声明源中固化，否则应用后仍会被回滚。
 - 403 修复发布后应重跑 200 对；只有 ACK 成功率、实时到达率、MySQL 精确落库均达标，才进入 500 对档位。
+
+## 12. 200 对第三轮复测结果
+
+Run ID：`p2p-200-20260927-03`。压测前修复了压测工具复用固定 `Idempotency-Key` 而跳过好友关系校验的问题，并重新核对、修复 200 对测试账号。
+
+| 指标 | 结果 |
+|---|---:|
+| WS Ready | 400/400 |
+| Publish 尝试 / ACK | 4000 / 4000 |
+| Publish 拒绝 / 403 / 502 / 503 | 0 / 0 / 0 / 0 |
+| ACK 后应到达 / 实际到达 | 4000 / 4000 |
+| 实时到达率 | 100% |
+| 历史查询 | 4000/4000 |
+| MySQL 精确匹配 | 4000/4000 |
+| MySQL 缺失 / 错配 / 重复 / 非 ACK 落库 | 0 / 0 / 0 / 0 |
+| 丢失 / 重复 / 断连 | 0 / 0 / 0 |
+| 乱序 | 1 |
+| Cluster 队列采样最大值 | 0 |
+| Kafka 峰值 lag / 最旧 backlog age / 最终 lag | 3028 / 92.624s / 0 |
+
+结论：跨 Pod 发送、ACK 后实时投递、Kafka 最终消费和 MySQL 落库的数据正确性已通过 200 对验证。结果报告仍为不通过，原因是 B 端记录 1 次单连接 Topic seq 回退，以及 ACK P95 和投递 P95 均落入 1-2s 区间。
+
+资源采样显示，三个 Pod 峰值内存低于 94MiB，但 Pod 0/1/2 在本轮窗口内的 CPU throttled 增量约为 7.62s / 0.78s / 8.51s。实际 StatefulSet 仍是 `request 100m/128Mi`、`limit 500m/256Mi`，且 liveness 仍是 `/healthz`。因此延迟和 Kafka 追平速度尚不能作为扩容到 500 对的验收基线。
+
+已增加 `deploy/argocd/im-server-test/statefulset-performance-patch.yaml`，要求 ArgoCD 声明源固化 `request 1C/512Mi`、`limit 2C/1Gi`和 `/livez` liveness。部署流水线改为等待 ArgoCD 回写后严格校验，如果再被回滚则直接失败。压测工具保留乱序为失败门禁，并新增最多 100 条 `receiver/topic_hash/previous_seq/current_seq/client_mid` 明细，用于下轮精确定位。